- Pacman-dev - lists.archlinux.org

[pacman-dev] pacman-5.0:error run updpkgsums when there is source_i686 or source_x86_64 in PKGBUILD
by Zuyi Hu 25 Jan '16

25 Jan '16

I am using the pacman's latest master branch,When I run updpkgsums when there is source_i686 or source_x86_64 in PKGBUILD. it will complain: /usr/share/makepkg/lint_pkgbuild/variable.sh: line 60: declare: sha512sums: not found ==> ERROR: sha512sums_i686 should be an array /usr/share/makepkg/lint_pkgbuild/variable.sh: line 60: declare: source: not found ==> ERROR: source_i686 should be an array /usr/share/makepkg/lint_pkgbuild/variable.sh: line 60: declare: sha512sums: not found ==> ERROR: sha512sums_x86_64 should be an array /usr/share/makepkg/lint_pkgbuild/variable.sh: line 60: declare: source: not found ==> ERROR: source_x86_64 should be an array ==> ERROR: Failed to generate new checksums for example, you can use nvidia's PKGBUILD in extra repo, and try run updpkgsums. I think this bug is introduced by this commit: https://projects.archlinux.org/pacman.git/commit/?id=23f128ad5e2b26733376d1… a simple workaround patch is: diff --git a/scripts/libmakepkg/lint_pkgbuild/variable.sh.in b/scripts/libmakepkg/lint_pkgbuild/variable.sh.in index 4943c50..183e740 100644 --- a/scripts/libmakepkg/lint_pkgbuild/variable.sh.in +++ b/scripts/libmakepkg/lint_pkgbuild/variable.sh.in @@ -57,7 +57,7 @@ lint_variable() { v="${i}_${a}" eval "keys=(\"\${!${v}[@]}\")" if (( ${#keys[*]} > 0 )); then - if [[ "$(declare -p $i)" != "declare -a "* ]]; then + if [[ "$(declare -p $v)" != "declare -a "* ]]; then error "$(gettext "%s_%s should be an array")" "$i" "$a" ret=1 fi

2 1

[pacman-dev] Redundant spaces in package information.
by Viacheslav Chimishuk 21 Jan '16

21 Jan '16

Hi there. I have noticed that pacman package information output has a redundant spaces. Let me show you an example. $ pacman -Qi pacman | grep Install Installed Size : 3.95 MiB Install Date : Tue 27 Oct 2015 03:46:31 PM EET Install Reason : Explicitly installed Install Script : No [vchimishuk@latitude pixel-submitter] $ As you can most of lines have only one space after ':' character, but "Installed Size" has three spaces. It depends of the size value itself. Here is a code that prints the line: printf("%s%s%s %6.2f %s\n", config->colstr.title, titles[T_INSTALLED_SIZE], config->colstr.nocolor, size, label); My question is next. Why do we need "6." here? It will works just fine without this extra space formatting. Is this is a bug or feature? :) Best regards, Viacheslav.

3 5

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v4.2.1-312-gad65462
by allan＠archlinux.org 17 Jan '16

17 Jan '16

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v4.2.1-311-g9ff2954
by allan＠archlinux.org 17 Jan '16

17 Jan '16

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 9ff29545e5185105438c9383f66bbd02af13affc (commit) via 8d9890d3f4c18189eb13ebc8612e3df56a4c9589 (commit) via ab50864a758a7c3d26d5423521743c5753a6cffe (commit) via 9813107c3368684784706cf2b77bd056bea58e3c (commit) via 00c03295315cb2d359733858d2945bb6a7070c70 (commit) via 88f348f2b15fed8a7b92085d01ffeced117f3599 (commit) via 875c017e4d74bd29bc7424c2c7ff2050f90b7767 (commit) via 2a0d188d6b289025bee18c9d9b615e0a9e19fc50 (commit) from fa72c2cdc2682eb55edd0d8b19fb1eba4e061670 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9ff29545e5185105438c9383f66bbd02af13affc Author: Johannes Löthberg <johannes(a)kyriasis.com> Date: Mon Jan 4 09:40:10 2016 +0100 doc: alpm-hooks.5: Remove extra space in alpm-hooks man page Signed-off-by: Johannes Löthberg <johannes(a)kyriasis.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 8d9890d3f4c18189eb13ebc8612e3df56a4c9589 Author: Allan McRae <allan(a)archlinux.org> Date: Fri Jan 15 14:52:05 2016 +1000 Cast events to void* before passing to callback Silence warnings from clang about typecasting alignment. Reported-by: Rikard Falkeborn Original-patch-by: Olivier Brunel Signed-off-by: Allan McRae <allan(a)archlinux.org> commit ab50864a758a7c3d26d5423521743c5753a6cffe Author: Andrew Gregory <andrew.gregory.8(a)gmail.com> Date: Mon Jan 11 09:29:22 2016 -0500 add alpm_list_append alpm_list_add always returns the provided list making it impossible for callers to check whether or not the operation actually succeeded without manually comparing the list length before and after. alpm_list_append instead returns a pointer to the newly created list item so that success can be checked. Signed-off-by: Andrew Gregory <andrew.gregory.8(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 9813107c3368684784706cf2b77bd056bea58e3c Author: Dominik Fischer <d.f.fischer(a)web.de> Date: Mon Dec 7 21:37:09 2015 +0100 test version range restrictions corner case The test introduced herein illustrates a behavior that may be unexpected to package writers. It creates a package "pkg3" that is configured to depend on a "dependency" which version is between 3 and 4, inclusive. Two other packages are already present, providing "dependency" in version 2 and 5, respectively. So, the situation looks roughly like this: pkg1 pkg3 pkg2 provides depends on provides | <------------> | version __________2____________3____________4____________5___________... This seems to be enough to satisfy pacman when installing "pkg3". From an iterative standpoint, this is completely logical: First, the requirement "dependency>=3" is checked. There is a package that satisfies this restriction, it is called "pkg2". Afterwards, "dependency<=4" is covered in the same way by "pkg1". Nonetheless, what a package writer intends when specifying depends=('dependency>=3' 'dependency<=4') is most probably that pacman should only allow this package to be installed when there indeed is a package present that provides a version of "dependency" that lies _between_ 3 and 5. Signed-off-by: Dominik Fischer <d dot f dot fischer at web dot de> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 00c03295315cb2d359733858d2945bb6a7070c70 Author: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> Date: Thu Dec 31 14:19:31 2015 +0100 Add pacsort tests with invalid input Signed-off-by: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 88f348f2b15fed8a7b92085d01ffeced117f3599 Author: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> Date: Thu Dec 31 14:19:30 2015 +0100 pacsort, introduce define for escape_char error code The signedness of char is implementation defined. On systems where char is unsigned, comparing a variable of type char with -1 is never true, due to integer promotion rules. To avoid this, introduce a define for invalid field separators where -1 is cast to char. This will ensure that the return value check works for both unsigned and signed char. Fixes one warning [-Wtype-limits] for comparissons with -1 when compiling with -funsigned-char. Signed-off-by: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 875c017e4d74bd29bc7424c2c7ff2050f90b7767 Author: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> Date: Thu Dec 31 14:19:29 2015 +0100 Make alpm_graph state signedness explicit The signedness of char is implementation defined. Since the alpm_graph state is clearly meant to be signed, make the signedness explicit. This fixes bugs on systems where char is unsigned, in comparissons of the following type: if(v.state == -1) which, if state is unsigned, will never be true due to integer promotion rules. Fixes failing test/pacman/tests/sync012.py when compiling with -funsigned-char. Fixes two warnings [-Wtype-limits] for comparissons with -1 when compiling with -funsigned-char. Signed-off-by: Rikard Falkeborn <rikard.falkeborn(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 2a0d188d6b289025bee18c9d9b615e0a9e19fc50 Author: Allan McRae <allan(a)archlinux.org> Date: Thu Dec 31 20:18:22 2015 +1000 Update NEWS for pacman-5.0 Signed-off-by: Allan McRae <allan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: NEWS | 64 ++++++++++++++++++++++++++++++++++++++-- doc/alpm-hooks.5.txt | 2 +- lib/libalpm/alpm_list.c | 34 ++++++++++++++------- lib/libalpm/alpm_list.h | 1 + lib/libalpm/graph.h | 2 +- lib/libalpm/hook.c | 4 +-- lib/libalpm/trans.c | 4 +-- src/util/pacsort.c | 11 +++---- test/pacman/tests/TESTS | 1 + test/pacman/tests/deprange001.py | 19 ++++++++++++ test/util/pacsorttest.sh | 18 ++++++++++- 11 files changed, 136 insertions(+), 24 deletions(-) create mode 100644 test/pacman/tests/deprange001.py hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Fwd: Problem installing pacman-4.2.0 and 4.2.1
by Michaila Goula-Dimitriou 15 Jan '16

15 Jan '16

Hello, I am not sure if this is a bug but trying the "make" command on both 4.2.0 and 4.2.1 versions of packman gave me the exact same error: callback.o: In function `get_time_ms': /home/mixa/pacman-4.2.1/src/pacman/callback.c:59: undefined reference to `clock_gettime' collect2: ld returned 1 exit status make[3]: *** [pacman] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Is there something to do in order to fix this? Thank you. Goula-Dimitriou Michaila

3 3

[pacman-dev] Clang warnings
by Rikard Falkeborn 15 Jan '16

15 Jan '16

There are some warnings recently introduced when compiling with Clang (with --enable-warningflags) for x86_64. The warnings are related to casting of specific alpm_event-types to alpm_event_t where the required alignment differs between the types. On x86, it shouldn't be a problem, but maybe there are other architectures pacman should work on where this is a real issue? Either way, I think it would be good if pacman built cleanly with Clang. Any suggestions on how to fix this? For reference, the warnings are: hook.c:732:3: warning: cast from 'alpm_event_hook_t *' (aka 'struct _alpm_event_hook_t *') to 'alpm_event_t *' (aka 'union _alpm_event_t *') increases required alignment from 4 to 8 [-Wcast-align] EVENT(handle, &event); ^~~~~~~~~~~~~~~~~~~~~ ./handle.h:37:16: note: expanded from macro 'EVENT' (h)->eventcb((alpm_event_t *) (e)); \ ^~~~~~~~~~~~~~~~~~~~ hook.c:761:3: warning: cast from 'alpm_event_hook_t *' (aka 'struct _alpm_event_hook_t *') to 'alpm_event_t *' (aka 'union _alpm_event_t *') increases required alignment from 4 to 8 [-Wcast-align] EVENT(handle, &event); ^~~~~~~~~~~~~~~~~~~~~ ./handle.h:37:16: note: expanded from macro 'EVENT' (h)->eventcb((alpm_event_t *) (e)); \ ^~~~~~~~~~~~~~~~~~~~ 2 warnings generated. trans.c:202:2: warning: cast from 'alpm_event_any_t *' (aka 'struct _alpm_event_any_t *') to 'alpm_event_t *' (aka 'union _alpm_event_t *') increases required alignment from 4 to 8 [-Wcast-align] EVENT(handle, &event); ^~~~~~~~~~~~~~~~~~~~~ ./handle.h:37:16: note: expanded from macro 'EVENT' (h)->eventcb((alpm_event_t *) (e)); \ ^~~~~~~~~~~~~~~~~~~~ trans.c:226:3: warning: cast from 'alpm_event_any_t *' (aka 'struct _alpm_event_any_t *') to 'alpm_event_t *' (aka 'union _alpm_event_t *') increases required alignment from 4 to 8 [-Wcast-align] EVENT(handle, &event); ^~~~~~~~~~~~~~~~~~~~~ ./handle.h:37:16: note: expanded from macro 'EVENT' (h)->eventcb((alpm_event_t *) (e)); \ ^~~~~~~~~~~~~~~~~~~~

4 12

[pacman-dev] [PATCH] add alpm_list_append
by Andrew Gregory 11 Jan '16

11 Jan '16

alpm_list_add always returns the provided list making it impossible for callers to check whether or not the operation actually succeeded without manually comparing the list length before and after. alpm_list_append instead returns a pointer to the newly created list item so that success can be checked. Signed-off-by: Andrew Gregory <andrew.gregory.8(a)gmail.com> --- lib/libalpm/alpm_list.c | 34 ++++++++++++++++++++++++---------- lib/libalpm/alpm_list.h | 1 + 2 files changed, 25 insertions(+), 10 deletions(-) diff --git a/lib/libalpm/alpm_list.c b/lib/libalpm/alpm_list.c index 62b2843..f3effc7 100644 --- a/lib/libalpm/alpm_list.c +++ b/lib/libalpm/alpm_list.c @@ -93,28 +93,42 @@ void SYMEXPORT alpm_list_free_inner(alpm_list_t *list, alpm_list_fn_free fn) */ alpm_list_t SYMEXPORT *alpm_list_add(alpm_list_t *list, void *data) { - alpm_list_t *ptr, *lp; + alpm_list_append(&list, data); + return list; +} + +/** + * @brief Add a new item to the end of the list. + * + * @param list the list to add to + * @param data the new item to be added to the list + * + * @return the newly added item + */ +alpm_list_t SYMEXPORT *alpm_list_append(alpm_list_t **list, void *data) +{ + alpm_list_t *ptr; ptr = malloc(sizeof(alpm_list_t)); if(ptr == NULL) { - return list; + return NULL; } ptr->data = data; ptr->next = NULL; /* Special case: the input list is empty */ - if(list == NULL) { + if(*list == NULL) { + *list = ptr; ptr->prev = ptr; - return ptr; + } else { + alpm_list_t *lp = alpm_list_last(*list); + lp->next = ptr; + ptr->prev = lp; + (*list)->prev = ptr; } - lp = alpm_list_last(list); - lp->next = ptr; - ptr->prev = lp; - list->prev = ptr; - - return list; + return ptr; } /** diff --git a/lib/libalpm/alpm_list.h b/lib/libalpm/alpm_list.h index 801f4a0..5af84e1 100644 --- a/lib/libalpm/alpm_list.h +++ b/lib/libalpm/alpm_list.h @@ -57,6 +57,7 @@ void alpm_list_free_inner(alpm_list_t *list, alpm_list_fn_free fn); /* item mutators */ alpm_list_t *alpm_list_add(alpm_list_t *list, void *data); +alpm_list_t *alpm_list_append(alpm_list_t **list, void *data); alpm_list_t *alpm_list_add_sorted(alpm_list_t *list, void *data, alpm_list_fn_cmp fn); alpm_list_t *alpm_list_join(alpm_list_t *first, alpm_list_t *second); alpm_list_t *alpm_list_mmerge(alpm_list_t *left, alpm_list_t *right, alpm_list_fn_cmp fn); -- 2.7.0

1 0

[pacman-dev] Why is FS#30993 still open?
by Alastair Hughes 11 Jan '16

11 Jan '16

pacman can obviously be built statically, so I've probably missed the point; why is FS#30993 still open? What functionality is broken (if any) in the static version? I haven't found anything yet, but... Regards, Alastair Hughes

2 1

[pacman-dev] [PATCH] doc: alpm-hooks.5: Fix missing space before Description
by Johannes Löthberg 04 Jan '16

04 Jan '16

Signed-off-by: Johannes Löthberg <johannes(a)kyriasis.com> --- doc/alpm-hooks.5.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/alpm-hooks.5.txt b/doc/alpm-hooks.5.txt index f33ff8c..aee2ff8 100644 --- a/doc/alpm-hooks.5.txt +++ b/doc/alpm-hooks.5.txt @@ -64,7 +64,7 @@ defined the hook will run if the transaction matches *any* of the triggers. ACTIONS ------- -* Description =* ...:: +*Description =* ...:: An optional description that describes the action being taken by the hook for use in front-end output. -- 2.6.4

1 1

[pacman-dev] [PATCH] libalpm, fix leak if malloc fails in be_sync
by Rikard Falkeborn 04 Jan '16

04 Jan '16

--- lib/libalpm/be_sync.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/libalpm/be_sync.c b/lib/libalpm/be_sync.c index b09b060..9229622 100644 --- a/lib/libalpm/be_sync.c +++ b/lib/libalpm/be_sync.c @@ -178,6 +178,7 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) const char *dbext; alpm_list_t *i; int ret = -1; + int memory_error = 0; mode_t oldmask; alpm_handle_t *handle; alpm_siglevel_t level; @@ -230,8 +231,7 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) /* print server + filename into a buffer */ len = strlen(server) + strlen(db->treename) + strlen(dbext) + 2; - /* TODO fix leak syncpath and umask unset */ - MALLOC(payload.fileurl, len, RET_ERR(handle, ALPM_ERR_MEMORY, -1)); + MALLOC(payload.fileurl, len, memory_error = 1; goto cleanup); snprintf(payload.fileurl, len, "%s/%s%s", server, db->treename, dbext); payload.handle = handle; payload.force = force; @@ -269,8 +269,7 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) len = strlen(server) + strlen(db->treename) + strlen(dbext) + 6; } - /* TODO fix leak syncpath and umask unset */ - MALLOC(payload.fileurl, len, RET_ERR(handle, ALPM_ERR_MEMORY, -1)); + MALLOC(payload.fileurl, len, memory_error = 1; goto cleanup); if(final_db_url != NULL) { snprintf(payload.fileurl, len, "%s.sig", final_db_url); @@ -322,9 +321,10 @@ int SYMEXPORT alpm_db_update(int force, alpm_db_t *db) } cleanup: - _alpm_handle_unlock(handle); free(syncpath); umask(oldmask); + ASSERT(memory_error == 0, RET_ERR(handle, ALPM_ERR_MEMORY, -1)); + _alpm_handle_unlock(handle); return ret; } -- 2.6.2

3 2