March 2013 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH 0/2] separate ini parsing from pacman/conf.c
by Sascha Kruse 06 Jul '13

06 Jul '13

This set of patches separate the ini parsing from pacman/conf.c into its own file to make the code reusable for future additions, like parsing config files for hooks. The config file gets parsed into a list of ini_section_t which contains the name of the section and a list of directives which in turn contain key, value, file and linenum. File and linenum are included to keep the ability to mention the location of errors in pacmans error messages. I realize that a new release is planed for the near future and this patch is not intended to be included in that release, since it adds new strings to be translated and it probably needs more than one review cycle. Best regards, Sascha Kruse

4 7

[pacman-dev] [PATCH] removed duplicate macros SYMEXPORT and SYMHIDDEN from alpm_list.c, using them from util.h
by Paul Barbu Gheorghe 29 May '13

29 May '13

Signed-off-by: Barbu Paul - Gheorghe <barbu.paul.gheorghe(a)gmail.com> --- lib/libalpm/alpm_list.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/libalpm/alpm_list.c b/lib/libalpm/alpm_list.c index 39eded1..b9e7cba 100644 --- a/lib/libalpm/alpm_list.c +++ b/lib/libalpm/alpm_list.c @@ -21,13 +21,11 @@ #include <stdlib.h> #include <string.h> +#include "util.h" + /* libalpm */ #include "alpm_list.h" -/* check exported library symbols with: nm -C -D <lib> */ -#define SYMEXPORT __attribute__((visibility("default"))) -#define SYMHIDDEN __attribute__((visibility("internal"))) - /** * @addtogroup alpm_list List Functions * @brief Functions to manipulate alpm_list_t lists. -- Barbu Paul - Gheorghe Common sense is not so common - Voltaire Visit My GitHub profile to see my open-source projects - https://github.com/paullik

6 9

[pacman-dev] Mark outdated packages automatically (aka Livecheck)
by Anatol Pomozov 18 Apr '13

18 Apr '13

Hi, I believe in automatization. Any routine work that can be done automatically should be done this way. One such thing that can be improved in Arch project is discovering out-of-date packages. Currently it is done by users who go to https://www.archlinux.org/packages/ find the package and then click "Flag Package Out-of-Date" link. Why to bother users? Why not to let some bot to visit websites and check for new versions? There are examples of package managers that have such functionality - macports http://guide.macports.org/chunked/reference.livecheck.html Their Portfiles can have information about how to find released files (using regexp). Then periodically (e.g. daily) a bot visits webpages, parses html and checks if new files are present. Is it possible to have such functionality in pacman? It would save users time and make package update time lower.

4 8

[pacman-dev] code reuse for PKGBUILD
by Kent Fredric 12 Apr '13

12 Apr '13

So, I'm sort of new to Arch, but I've already found some things in how a few things work I have rather sizable miss-givings about, and see room for improvement. *~~~ BEGIN CONFUSING RANT HERE ~~~* *( or skip past it to the TL;DR )* The primary one at present is "No code re-use in PKGBUILD. Period" And this strikes me as a bad idea. I understand that having a PKGBUILD become not fully independent might be undesirable to some, but I'm hoping there is a pivotal middle-ground that can be useful. 1. Many PKGBUILD files are seriously outdated 2. Each and every Perl Module PKGBUILD requires the author to know *everything* about packaging Perl modules, and this is a somewhat hard thing to know: - version normalisation # I haven't seen anyone do it yet, and its the only sure-fire mechanism to get versions to play nicely together. - lots of boilerplate , cargo-cult copypasted around, see : https://aur.archlinux.org/packages/pe/perl-json-any/PKGBUILD Consider this for a moment: Gentoo, like Arch have been nuking '.packlist' files for some time, until recently it became apparent that some programs actually need those files to do their job. https://bugs.gentoo.org/show_bug.cgi?id=438660 This is "bad practice", and because the behaviour is not codified in some shared library that all perl module packages use, in order to "Fix" this problem on arch, it requires a considerable number of person-hours to vet the hundreds of perl PKGBUILDS to eliminate this behaviour. https://aur.archlinux.org/packages/pe/perl-devel-nytprof/PKGBUILD Another bad example of people reinventing all their own wheels, and doing all make/make test/make install during build. This behaviour should really be codified in a shared module. That way, when people realise the way the shared module has been doing things is for whatever reason, wrong, its simply a matter of fixing that, and every build past and present benefits from the change, with no additional effort on the PKGBUILD maintainers. What I hope to do is find some sort of consensus on how it would be best to add a little bit of code-reuse to pkgbuild, as this will, I feel, greatly improve maintenance of these files. Because *both* of those 2 PKGBUILD files I posted could have been easily refactored, and had *100%* of their independent code eliminated in favour of shared behaviour. extensions=('perl-module') _perl_distname=json-any _perl_ver='1.29' _perl_author=PERIGRIN pkgver='1.290.0' pkgrel='1' pkgdesc="Wrapper Class for the various JSON classes." arch=('any') options=('!emptydirs') depends=('perl-json>=2.02' 'perl-json-xs>=2.3' 'perl-yaml-syck') makedepends=() md5sums=('f7eea523d532668555456e4153334342') Notes: _perl_ver and pkgver are different due to my recommendation that upstream versions undergo a normalisation process prior to being used for arch versions. This is important, as perl versioning semantics are wildly different from the rest of the worlds. The average packager will not even realise how big a deal this is, but simple to say, perl versions are a nightmare: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ On Gentoo, we've developed a tool to make it easier to convert perl versions to versions we can use in packages, and it basically "Just works". https://metacpan.org/module/Gentoo::PerlMod::Version license= is omitted, as this way, it can default to the most common license on CPAN, "The Perl5 License" -> license=('PerlArtistic' 'GPL') and can be overridden as needed. url= is omitted, as this can easily be generated from the _perl_distname value, and overridden only when necessary. This means you can either have the underlying module refer to pages on search.cpan.org, or metacpan.org source=() is also omitted, as the primary src URI can also be divined from combining _perl_distname , _perl_author and _perl_ver and you can usually leave out build(), check() and package(), as these phases are all very well known and have to meet a standard behaviour to operate with 'cpan' clients, so its quite straightforward to have a set of default behaviours. Implementation wise, my biggest question is "Where is 'perl-module' stored". The simplest option is a pacman distribution, such as 'pacman-extensions', that installs files in /usr/lib/pacman/extension/ , and makepkg/pacman can be made aware of this feature and load the modules on demand. For those who don't like the inherent issue where "PKGBUILD depends on code outside tar.gz", it could be engineered so that `makepkg -S` copies files from /usr/lib/pacman/extension/ into the built tree at /extensions/ , and then have some sort of mechanic that chooses between using the "system" version of the extension or the "bundled" version of the extension. With built packages, the behaviours from the extension would probably have to be cooked in to the dist ( somehow ), but thats an accepted caveat of how binary distribution usually works. *========= TL;DR TL;DR TL;DR TL;DR TL;DR =========* 1. I'm a noob to Arch 2. ... But I have substantial experience packaging perl modules for gentoo ( https://github.com/gentoo-perl/perl-experimental/graphs/contributors , https://www.ohloh.net/p/gentoo-perl- overlay/contributors/summary ) 3. And I strongly feel that in regard to packaging things, the PKGBUILD spec at present seems a little immature 4. And I strongly feel, that PKGBUILD could gain a great deal of improvement utility by having /some/ shared code mechanism 5. ... But I'm not quite sure what the best way to do this is 6. And I'm strongly against any ideas that involve developing a *Second* platform that simply emits files in the PKGBUILD format, or implementing competing products to `makepkg` 7. And I'd rather *not* have hard-inlining behaviour , I'm fine with the external behaviour being shipped independently, but if thats not universal, then I'd like to find a middleground In advance, thanks for your consideration =). -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz

6 18

[pacman-dev] [PATCH] makepkg: don't run remove_deps twice when unneeded
by William Giokas 10 Apr '13

10 Apr '13

remove_deps already has a check and won't run unless -r is specified, so if this was meant to remove dependencies of a failure no matter what, then it's not doing it, and with -r it is run twice on a failure for no real reason. Signed-off-by: William Giokas <1007380(a)gmail.com> --- scripts/makepkg.sh.in | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 73f45d4..3bcc527 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1356,7 +1356,6 @@ error_function() { if (( ! BASH_SUBSHELL )); then error "$(gettext "A failure occurred in %s().")" "$1" plain "$(gettext "Aborting...")" - remove_deps fi exit 2 # $E_BUILD_FAILED } -- 1.8.2

2 1

[pacman-dev] [PATCH] makepkg: avoid file|grep dependency for CRLF check
by Dave Reisner 06 Apr '13

06 Apr '13

Signed-off-by: Dave Reisner <dreisner(a)archlinux.org> --- scripts/makepkg.sh.in | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 73f45d4..a63b267 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -2744,8 +2744,7 @@ if [[ ! -f $BUILDFILE ]]; then source_safe "$BUILDFILE" fi else - crlftest=$(file "$BUILDFILE" | grep -F 'CRLF' || true) - if [[ -n $crlftest ]]; then + if [[ $(<"$BUILDFILE") = *$'\r'* ]]; then error "$(gettext "%s contains %s characters and cannot be sourced.")" "$BUILDFILE" "CRLF" exit 1 fi -- 1.8.2

2 1

[pacman-dev] [PATCH] remove continue from download_local
by Daniel Wallace 31 Mar '13

31 Mar '13

introduced by a6291858cc1570e56204c4a1e7a68f76c4853336 popd doesn't run in the for loop in download_sources() if the continue in download_files is executed. Causing the extract_files to extract everything into $SRCDEST instead of $srcdir --- may be able to remove the pushd commands from all the extract_* functions without this scripts/makepkg.sh.in | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 6c89849..da620a4 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -314,7 +314,6 @@ download_local() { msg2 "$(gettext "Found %s")" "${filepath##*/}" rm -f "$srcdir/${filepath##*/}" ln -s "$filepath" "$srcdir/" - continue else local filename=$(get_filename "$netfile") error "$(gettext "%s was not found in the build directory and is not a URL.")" "$filename" -- 1.8.2

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v4.1.0rc1-43-gafc77a8
by allan＠archlinux.org 30 Mar '13

30 Mar '13

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 afc77a808db7927866afab4951b80a8e09846d8a (commit) via c85d155f3a789ce149ecfca5f9ef205e329bb675 (commit) via 950443a43810b9c12d541cb4b74fb65b7a6bcfde (commit) from d5c0f391449078f02694c10abd4d08a09fa88b04 (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 afc77a808db7927866afab4951b80a8e09846d8a Author: Simon Gomizelj <simongmzlj(a)gmail.com> Date: Tue Mar 26 13:39:29 2013 -0400 pm_asprintf logs 'failed to allocate' already Signed-off-by: Simon Gomizelj <simongmzlj(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit c85d155f3a789ce149ecfca5f9ef205e329bb675 Author: Richard Pougnet <richard(a)pougnet.ca> Date: Sun Mar 24 20:02:06 2013 -0400 Improve documentation of libalpm interface functions Add details to the doxygen for the initialization and relase functions of the library. Signed-off-by: Richard Pougnet <richard(a)pougnet.ca> Signed-off-by: Allan McRae <allan(a)archlinux.org> commit 950443a43810b9c12d541cb4b74fb65b7a6bcfde Author: Andrew Gregory <andrew.gregory.8(a)gmail.com> Date: Fri Mar 29 21:52:55 2013 -0400 makepkg: unset GREP_OPTIONS grep allows options to be set from the environment with GREP_OPTIONS. Many of these options will alter grep's output, breaking makepkg. GREP_OPTIONS=--line-number breaks installed dependency removal, for instance. Signed-off-by: Andrew Gregory <andrew.gregory.8(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/alpm.c | 9 ++++++--- scripts/makepkg.sh.in | 2 ++ src/pacman/util.c | 1 - 3 files changed, 8 insertions(+), 4 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH 1/4] pm_asprintf logs 'failed to allocate' already
by Simon Gomizelj 30 Mar '13

30 Mar '13

Signed-off-by: Simon Gomizelj <simongmzlj(a)gmail.com> --- src/pacman/util.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/pacman/util.c b/src/pacman/util.c index ef66638..862c8e8 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -749,7 +749,6 @@ void signature_display(const char *title, alpm_siglist_t *siglist, ret = pm_asprintf(&sigline, _("%s, %s from \"%s\""), status, validity, name); if(ret == -1) { - pm_printf(ALPM_LOG_ERROR, _("failed to allocate string\n")); continue; } indentprint(sigline, len, maxcols); -- 1.8.2

2 4

[pacman-dev] [PATCH] Improve documentation of libalpm interface functions
by Richard Pougnet 30 Mar '13

30 Mar '13

Add details to the doxygen for the initialization and relase functions of the library. Signed-off-by: Richard Pougnet <richard(a)pougnet.ca> --- lib/libalpm/alpm.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/lib/libalpm/alpm.c b/lib/libalpm/alpm.c index cd14adb..d914495 100644 --- a/lib/libalpm/alpm.c +++ b/lib/libalpm/alpm.c @@ -37,8 +37,9 @@ * @{ */ -/** Initializes the library. This must be called before any other - * functions are called. +/** Initializes the library. + * Creates handle, connects to database and creates lockfile. + * This must be called before any other functions are called. * @param root the root path for all filesystem operations * @param dbpath the absolute path to the libalpm database * @param err an optional variable to hold any error return codes @@ -86,7 +87,9 @@ cleanup: return NULL; } -/** Release the library. This should be the last alpm call you make. +/** Release the library. + * Disconnects from the database, removes handle and lockfile + * This should be the last alpm call you make. * After this returns, handle should be considered invalid and cannot be reused * in any way. * @param myhandle the context handle -- 1.8.2

2 1