- Pacman-dev - lists.archlinux.org

[pacman-dev] Non-existing user/group ownership and chroot
by Armin K. 06 Mar '17

06 Mar '17

Hi all. I'm using pacman for my LFS install, and as part of that, I also use hooks used by Arch for, say, systemd-sysusers, systemd-tmpfiles, etc. Some packages require that certain files/directories are owned by a certain user/group after install. This is somehow hard to achieve with .install file when systemd-sysuser hook is used (see [1] for an example). Since this is a LFS, it's "bootstrapped" from an already existing linux distro (doesn't have to be arch, it has its own temporary pacman). I use pacman -U -r /path/to/lfs to install packages from the host system. The issue I'm having is when an user isn't created and chown is ran in PKGBUILD's with statically assigned id's (ie, chown 20:20, where 20 will be an UID for the created user), pacman chowns those files/directories to something else entirely. I did however notice that on my host (Arch, of course), those missleading uids/gids correspond to the uids/gids of the users that are going to be created in LFS. So, if I have user/group named:named with uid:gid 20:20, and host system (Arch) has same user:group, with with uid:gid 40:40, the files that I explicitly chowned to 20:20 in PKGBUILD will be chown-ed to 40:40 instead when pacman -U -r ... is ran. So, how do I solve this problem? I suppose it's an issue in pacman -U with -r option. I can use chown 20:20 in .install file (before the user:groups have been created), and the file will be created with proper ownership. Thanks in advance. [1] https://bugs.archlinux.org/task/52680

3 12

[pacman-dev] [PATCH 0/2] Deprecate md5sums, show sha256sums as an example-by-default.
by Mike Swanson 26 Feb '17

26 Feb '17

Both the MD5 and SHA-1 hash functions have known collision attacks, providing an attack vector for malicious hosts and MITMs to provide tampered code without being detected by md5, or sha1, hashing. We should move to sha256-by-default, and encourage their use by changing the documentation and example files to follow suit. The SHA-2 family of hashes are currently secure against normal attacks (even at the scale of having Facebook's or Google's datacenters). Int the future, pacman should gain SHA-3 support though, because SHA-2 itself has some theoretical preimage attacks and possible collision attacks. Mike Swanson (2): proto: Encourage the use of sha256sums by example. doc, makepkg.conf: Deprecate md5sums, show examples using sha256sums. doc/PKGBUILD-example.txt | 4 ++-- doc/PKGBUILD.5.txt | 31 +++++++++++++++++++------------ doc/makepkg-template.1.txt | 2 +- etc/makepkg.conf.in | 2 +- proto/PKGBUILD-split.proto | 2 +- proto/PKGBUILD-vcs.proto | 2 +- proto/PKGBUILD.proto | 2 +- 7 files changed, 26 insertions(+), 19 deletions(-) -- 2.11.1

6 19

[pacman-dev] [PATCH 1/1] split repository and package with VerbosePkgLists
by Christian Hesse 14 Feb '17

14 Feb '17

From: Christian Hesse <mail(a)eworm.de> Acting on packages from lots of different repositories makes the view look cluttered. So split repository and package with VerbosePkgLists. Signed-off-by: Christian Hesse <mail(a)eworm.de> --- src/pacman/util.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/src/pacman/util.c b/src/pacman/util.c index 64ea8c57..92fac07a 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -806,9 +806,11 @@ static alpm_list_t *create_verbose_header(size_t count) alpm_list_t *ret = NULL; char *header; - pm_asprintf(&header, "%s (%zu)", _("Package"), count); + add_table_cell(&ret, _("Repository"), CELL_TITLE); + pm_asprintf(&header, "%s (%zu)", _("Package"), count); add_table_cell(&ret, header, CELL_TITLE | CELL_FREE); + add_table_cell(&ret, _("Old Version"), CELL_TITLE); add_table_cell(&ret, _("New Version"), CELL_TITLE); add_table_cell(&ret, _("Net Change"), CELL_TITLE); @@ -830,11 +832,16 @@ static alpm_list_t *create_verbose_row(pm_target_t *target) if(target->install) { const alpm_db_t *db = alpm_pkg_get_db(target->install); if(db) { - pm_asprintf(&str, "%s/%s", alpm_db_get_name(db), alpm_pkg_get_name(target->install)); + pm_asprintf(&str, "%s", alpm_db_get_name(db)); } else { - pm_asprintf(&str, "%s", alpm_pkg_get_name(target->install)); + str = NULL; } + add_table_cell(&ret, str, CELL_NORMAL | CELL_FREE); + + pm_asprintf(&str, "%s", alpm_pkg_get_name(target->install)); } else { + add_table_cell(&ret, NULL, CELL_NORMAL | CELL_FREE); + pm_asprintf(&str, "%s", alpm_pkg_get_name(target->remove)); } add_table_cell(&ret, str, CELL_NORMAL | CELL_FREE); -- 2.11.0

3 2

[pacman-dev] [PATCH] Provide a better guess about who the packager is.
by Kieran Colford 01 Feb '17

01 Feb '17

The system usually has enough information in various places to guess the name and email of the person running the makepkg script. Use these instead of defaulting to "Unknown Packager" to minimize configuration necessary by the user. This particular implemenation should provide relatively good guess that's compatible with other programs (i.e. git). Signed-off-by: Kieran Colford <kieran(a)kcolford.com> --- scripts/makepkg.sh.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 29408929..65114862 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -618,7 +618,7 @@ write_pkginfo() { if [[ -n $PACKAGER ]]; then local packager="$PACKAGER" else - local packager="Unknown Packager" + local packager="${NAME:-$(getent passwd ${USER:-$(whoami)} | cut -d : -f 5 | cut -d , -f 1)} <${EMAIL:-${USER:-$(whoami)}@$(hostname --fqdn)}>" fi local size="$(@DUPATH@ @DUFLAGS@)" -- 2.11.0

5 14

[pacman-dev] [PATCH] zsh: use pacman instead of parsing pacman.conf
by Earnestly 27 Jan '17

27 Jan '17

This mimics the approach taken with the bash completion scripts and simply calls pacman -Sl to generate our list of unique repositories. This fixes cases where custom repos are defined in pacman.d/config snippets. --- scripts/completion/zsh_completion.in | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/scripts/completion/zsh_completion.in b/scripts/completion/zsh_completion.in index f74fa297..d7435f6d 100644 --- a/scripts/completion/zsh_completion.in +++ b/scripts/completion/zsh_completion.in @@ -316,8 +316,7 @@ _pacman_completions_all_packages() { typeset -U packages ${seq} _wanted packages expl "packages" compadd ${sep[@]} - "${(@)packages}" - repositories=(${(o)${${${(M)${(f)"$(<@sysconfdir@/pacman.conf)"}:#\[*}/\[/}/\]/}:#options}) - typeset -U repositories + repositories=(${(u)${${(f)"$(pacman -Sl)"}%% *}}) _wanted repo_packages expl "repository/package" compadd -S "/" $repositories fi } @@ -348,9 +347,7 @@ _pacman_all_packages() { # provides completions for repository names _pacman_completions_repositories() { local -a cmd repositories - repositories=(${(o)${${${(M)${(f)"$(<@sysconfdir@/pacman.conf)"}:#\[*}/\[/}/\]/}:#options}) - # Uniq the array - typeset -U repositories + repositories=(${(u)${${(f)"$(pacman -Sl)"}%% *}}) compadd "$@" -a repositories } -- 2.11.0

3 5

[pacman-dev] [Fwd: desc/.PKGINFO files: I need help to understand the values of some variables]
by Anna Ivanova 24 Jan '17

24 Jan '17

I have one question about pacman and I was in a hoping that I write to the right mailing list, but I didn't find in the archives similar posts. So that's why I write here... sorry if I mistook. -- Anna Ivanova +7 (999) 105-20-48

3 3

[pacman-dev] [PATCH] fixed: INSTALL instructs to use autogen.sh
by Stefan Klinger 14 Jan '17

14 Jan '17

Signed-off-by: Stefan Klinger <git(a)stefan-klinger.de> --- INSTALL | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/INSTALL b/INSTALL index 007e9396..73ec9ec8 100644 --- a/INSTALL +++ b/INSTALL @@ -12,14 +12,17 @@ without warranty of any kind. Basic Installation ================== - Briefly, the shell commands `./configure; make; make install' should -configure, build, and install this package. The following -more-detailed instructions are generic; see the `README' file for -instructions specific to this package. Some packages provide this -`INSTALL' file but do not implement all of the features documented -below. The lack of an optional feature in a given package is not -necessarily a bug. More recommendations for GNU packages can be found -in *note Makefile Conventions: (standards)Makefile Conventions. + Briefly, the shell command `./autogen.sh && ./configure && make` +should configure and build this package. Then proceed using `make +check` to run the test suite, or `make install` for installation. + + The following more-detailed instructions are generic; see the +`README' file for instructions specific to this package. Some +packages provide this `INSTALL' file but do not implement all of the +features documented below. The lack of an optional feature in a given +package is not necessarily a bug. More recommendations for GNU +packages can be found in *note Makefile Conventions: +(standards)Makefile Conventions. The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses -- 2.11.0

3 3

[pacman-dev] Is there an architectural document for pacman
by Wink Saville 14 Jan '17

14 Jan '17

Today pacman didn't behave the way I expected so I asked a question on the arch linux newbie list (https://bbs.archlinux.org/viewtopic.php?pid=1683611) and got the basic question answered. But the other question was a request for links to "understand how pacman works". I've done some searching and really didn't find what I was looking for, I'm a programmer so I'm looking for an "architectural document", is there such a thing? The README file in the sources doesn't go into much as detail as I was looking for, so is there anything more? Or maybe it just "Read the sources". -- Wink

3 2

[pacman-dev] [PATCH] Add http://EditorConfig.org configuration
by Eli Schwartz 06 Jan '17

06 Jan '17

Signed-off-by: Eli Schwartz <eschwartz93(a)gmail.com> --- .editorconfig | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 .editorconfig diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 00000000..af9b70d1 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,15 @@ +# EditorConfig configuration for pacman +# http://EditorConfig.org + +# Top-most EditorConfig file +root = true + +# Unix-style newlines without trailing whitespaces, but with a newline +# ending every file, utf-8 charset, set indent to tabs +[*] +end_of_line = lf +insert_final_newline = true +trim_trailing_whitespace = true +charset = utf-8 +indent_style = tab +indent_size = tab -- 2.11.0

3 4

[pacman-dev] Pacman configuration parser library
by Xyne 04 Jan '17

04 Jan '17

Happy new year! It would be useful for third-party developers to have access to the Pacman configuration file parsing functions and datatypes in src/pacman/conf.h. Would you consider providing a shared library for this (or adding it to libalpm)? It would be more reliable than third-party custom parsers. Aside from providing the actual shared object file, the only change needed* would be to remove the lines from parseconfig (conf.c) that free config->repos so that users could access repo information directly via config->repos after invoking the function (config_free will free that memory later). Regards, Xyne * It would be nice as well to have the option of parsing a file without initializing alpm, but that isn't necessary and I expect that would require more intrusive changes due to the current use of a global variable.

5 7