April 2010 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH 1/2] check for valid optarg before using strdup
by Serge Ziryukin 26 Apr '10

26 Apr '10

Signed-off-by: Serge Ziryukin <ftrvxmtrx(a)gmail.com> --- src/pacman/pacman.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index d32d4d1..206cdcf 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -489,6 +489,7 @@ static int parseargs(int argc, char *argv[]) setarch(optarg); break; case OP_PRINTFORMAT: + check_optarg(); config->print_format = strdup(optarg); break; case 'Q': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_QUERY); break; -- 1.7.0.6

2 3

[pacman-dev] [PATCH] New pactests for the phonon/qt issue
by Nagy Gabor 24 Apr '10

24 Apr '10

Original work by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- pactest/tests/sync405.py | 26 ++++++++++++++++++++++++++ pactest/tests/sync406.py | 31 +++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+), 0 deletions(-) create mode 100644 pactest/tests/sync405.py create mode 100644 pactest/tests/sync406.py diff --git a/pactest/tests/sync405.py b/pactest/tests/sync405.py new file mode 100644 index 0000000..d170cec --- /dev/null +++ b/pactest/tests/sync405.py @@ -0,0 +1,26 @@ +self.description = "phonon/qt issue" + +sp1 = pmpkg("kdelibs") +sp1.depends = ["phonon"] +self.addpkg2db("sync", sp1); + +sp2 = pmpkg("qt", "4.6.1-1") +self.addpkg2db("sync", sp2) + +sp3 = pmpkg("phonon") +self.addpkg2db("sync", sp3) + +lp = pmpkg("qt", "4.5.3-1") +lp.provides = ["phonon"] +lp.conflicts = ["phonon"] +self.addpkg2db("local", lp) + +self.args = "-S %s" % " ".join([p.name for p in sp1, sp2]) + +self.addrule("PACMAN_RETCODE=0") +self.addrule("PKG_EXIST=kdelibs") +self.addrule("PKG_EXIST=qt") +self.addrule("PKG_EXIST=phonon") +self.addrule("PKG_VERSION=qt|4.6.1-1") + +self.expectfailure = True diff --git a/pactest/tests/sync406.py b/pactest/tests/sync406.py new file mode 100644 index 0000000..c15862f --- /dev/null +++ b/pactest/tests/sync406.py @@ -0,0 +1,31 @@ +self.description = "phonon/qt issue (2)" + +sp1 = pmpkg("kdelibs") +sp1.depends = ["phonon"] +self.addpkg2db("sync", sp1); + +sp2 = pmpkg("qt", "4.6.1-1") +self.addpkg2db("sync", sp2) + +sp3 = pmpkg("phonon") +self.addpkg2db("sync", sp3) + +sp4 = pmpkg("kdeapp") +sp4.depends = ["qt>=4.6"] +self.addpkg2db("sync", sp4) + +lp = pmpkg("qt", "4.5.3-1") +lp.provides = ["phonon"] +lp.conflicts = ["phonon"] +self.addpkg2db("local", lp) + +self.args = "-S %s" % " ".join([p.name for p in sp1, sp4]) + +self.addrule("PACMAN_RETCODE=0") +self.addrule("PKG_EXIST=kdelibs") +self.addrule("PKG_EXIST=qt") +self.addrule("PKG_EXIST=phonon") +self.addrule("PKG_EXIST=kdeapp") +self.addrule("PKG_VERSION=qt|4.6.1-1") + +self.expectfailure = True -- 1.7.0.5

1 0

[pacman-dev] [PATCH] makepkg: deprecate repackaging without a package function
by Allan McRae 23 Apr '10

23 Apr '10

File permissions are not guaranteed to stay the same on exit from fakeroot, so repackaging may result in files with different permissions. This is avioded when using a package() function (or split packages) as the packaging step is rerun. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- This extents the earier patch sent to the list and now deprecates the rebuilding of packages without package() functions. scripts/makepkg.sh.in | 20 +++++++++++++++----- 1 files changed, 15 insertions(+), 5 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b2b449c..b306620 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1847,9 +1847,14 @@ fi if (( INFAKEROOT )); then if (( ! SPLITPKG )); then if (( ! PKGFUNC )); then - if (( BUILDFUNC && ! REPKG )); then - run_build - tidy_install + if (( ! REPKG )); then + if (( BUILDFUNC )); then + run_build + tidy_install + fi + else + warning "$(gettext "Repackaging without the use of a package() function is deprecated")" + plain "$(gettext "as it may not preserve file permissions.")" fi else run_package @@ -1975,8 +1980,13 @@ else if (( PKGFUNC )); then run_package tidy_install - elif (( ! REPKG )); then - tidy_install + else + if (( ! REPKG )); then + tidy_install + else + warning "$(gettext "Repackaging without the use of a package() function is deprecated")" + plain "$(gettext "as it may not preserve file permissions.")" + fi fi create_package else -- 1.7.0.5

1 0

[pacman-dev] [PATCH] contrib/pactree: generate reverse dependency trees
by Allan McRae 20 Apr '10

20 Apr '10

From: Christophe Chapuis <chris.chapuis(a)gmail.com> Add an option to show the tree of packages which depend on a given package Signed-off-by: Allan McRae <allan(a)archlinux.org> --- Just a git diff from Christophe's original patch. I adjusted the patch slightly so that the original was the first path in the if/else statements. Also bumped pkgver a larger version. contrib/pactree | 31 ++++++++++++++++++++++++++----- 1 files changed, 26 insertions(+), 5 deletions(-) diff --git a/contrib/pactree b/contrib/pactree index df53671..73bece3 100755 --- a/contrib/pactree +++ b/contrib/pactree @@ -41,7 +41,7 @@ arrow1_color="chocolate4" #color of the normal arrow arrow2_color="grey" #color of the "provided by" headless arrow readonly prog_name="pactree" -readonly prog_ver="0.2" +readonly prog_ver="0.3" _usage(){ echo "This program generates the dependency tree of an installed package" @@ -52,13 +52,14 @@ _usage(){ echo " -d, --depth INT Limit the shown dependencies depth" echo " -g, --graph Use graphviz to make an image of the tree" echo " -l, --linear Enable linear output" + echo " -r, --reversed Show reversed dependancies" echo " -s, --silent Shh, let me hear those errors!" echo " -u, --unique Print the dependency list with no duplicates" echo echo " -h, --help Print this help message" echo " -v, --version Print the program name and version" echo - echo "Example: $prog_name -c -d 2 readline" + echo "Example: $prog_name -c -d2 readline" } _version(){ @@ -140,7 +141,16 @@ _tree(){ if [[ ! " ${dep_list[@]} " =~ " $pkg_name " ]] && [ $spaces -ne $max_depth ]; then dep_list=( "${dep_list[@]}" "$pkg_name" ) - for dep_pkg in $(_grabfield "$pkg_dir/depends" %DEPENDS%); do + if [ $reversed_dep -eq 0 ]; then + deps_pkg="$(_grabfield "$pkg_dir/depends" %DEPENDS%)" + else + reqs_pkg_dir="$(_finddep "$pkg_name" %DEPENDS% depends)" + unset deps_pkg + for req_pkg_dir in $reqs_pkg_dir; do + deps_pkg=$(echo "$deps_pkg" "$(_grabfield "$req_pkg_dir/desc" %NAME%)") + done + fi + for dep_pkg in $deps_pkg; do spaces=$2 #Bash scoping ;_; if [ $graphviz -eq 1 ]; then echo "\"$1\" -> \"${dep_pkg%%[<>=]*}\" [color=$arrow1_color];" @@ -208,6 +218,12 @@ for (( n=0 ; n < $len_options ; n++ )); do continue fi + if [ "${options[$n]}" = "-r" -o "${options[$n]}" = "--reversed" ]; then + unset options[$n] + reversed_dep=1 + continue + fi + if [[ "${options[$n]}" =~ -d[[:digit:]]+ || "${options[$n]}" == "--depth" ]]; then if [[ "${options[$n]#-d}" =~ [[:digit:]]+ ]]; then max_depth="${options[$n]#-d}" @@ -229,6 +245,7 @@ linear=${linear:-0} silent=${silent:-0} nodup=${nodup:-0} graphviz=${graphviz:-0} +reversed_dep=${reversed_dep:-0} if [ $colored -ne 1 ]; then unset branch1_color @@ -292,8 +309,12 @@ if [ $graphviz -eq 1 ]; then root_pkgs="${options[@]}" # Uncomment for the "generated by pactree" node in graphviz #advert="xyz [height=0.07, fontsize=8.0, label=\"GENERATED WITH PACTREE\",shape=box,color="black",style=filled,fontcolor="white"];\n" - - echo -e "digraph G { START [color=$start_color, style=filled];\n node [style=filled, color=$nodes_color];\n$(_main)\n$advert}" | dot -T$gformat -o "${root_pkgs// /_}.deps.$gformat" + if [ $reversed_dep -eq 0 ]; then + file_extension="deps.$gformat" + else + file_extension="reqs.$gformat" + fi + echo -e "digraph G { START [color=$start_color, style=filled];\n node [style=filled, color=$nodes_color];\n$(_main)\n$advert}" | dot -T$gformat -o "${root_pkgs// /_}.$file_extension" else _main fi -- 1.7.0.5

1 0

[pacman-dev] VCS-PKGBUILDs
by David Campbell 18 Apr '10

18 Apr '10

Does anyone find it odd that the non-VCS PKGBUILDs explicitly check to make sure the sources have not changed and that the PKGBUILD someone uses is actually going to build the package the maintainer wrote it for, yet, VCS PKGBUILDs don't? VCS sources may change frequently, but this does not make them more secure and requiring of less scrutiny than non-VCS packages. If anything, they probably should be more scrutinized, since it would be more likely for someone to make a troublesome commit than a troublesome official release. There is also the issue that by automatically grabbing new sources without completely updating the PKGBUILD, many PKGBUILD fields may be incorrect, not just the pkgver. If the license a package is released under changes, the PKGBUILD won't care, etc.. Rather than making an often failed attempt to automatically update the pkgver and ignoring the rest of the PKGBUILD fields, why not have VCS PKGBUILDs behave more like all the other PKGBUILDs. When PKGBUILD sources change, a maintainer should have to update the PKGBUILD and PKGBUILDs which try to build using sources that don't match the PKGBUILD should fail. Figuring out the best way to check sources for all VCSs may require some creativity, but at least git would be really simple: check the hash for the last commit. Also, instead of using the date for the pkgver field of a VCS PKGBUILD, have the pkgver reflect the most recent release that the given development package is based off of. Then, use a commit field to show how many commits ahead of that release a package is. These fields would make it more clear what exactly the PKGBUILD is a PKGBUILD for. If there is no release to use commits since, the field could be left blank. This avoids ambiguity caused by different sources of a development project being released on the same day as well as issues with the sometimes significant difference between when a commit is authored and actually committed. -- David Campbell

4 5

[pacman-dev] pactree reverse dependancies
by Christophe Chapuis 15 Apr '10

15 Apr '10

Hello all, I just added an option to pactree, in order to look for reversed dependancies of a package instead of the normal dependancies. I already sent a mail to carlocci, who was the initial developper of this script, but as he doesn't answer I wonder if I should contact someone else. So, what should I do with this little patch? Attach it here in the mailing list? Tofe

2 5

[pacman-dev] .so provides/depends patches review
by Allan McRae 14 Apr '10

14 Apr '10

Hi, Sorry this has taken me a while... so long in fact that I do not have the original email stored anymore to reply to. But here goes my comments on the patches for soname provides/depends: http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010431.html My comments are currently only on functionality. I'll get to code after that is fully sorted. Firstly, it works well and does as advertised. So no issues there... However: 1) If I put a bad soname provides in the array (e.g. provides="readline.so") it just silently ignores it. No error and nothing put in the .PKGINFO. There needs to be an error (or at minimum a warning). The same goes for depends (although these are mostly caught by the initial dependency checking in makepkg). 2) Building readline on i686 with provides="libreadline.so", in the .PKGINFO I get: provides = libreadline.so=6-elf32_i386 My concern about that is that the library is not i386 but is i686. I may be prepared to accept that though as I guess x86 is x86 really... But what additional information is the elf32 providing? I could perhaps understand the operating system from the host triplet. If anything, my preferences are: libreadline.so=6-i686_linux (best) libreadline.so=6-i686 / libreadline.so=6-i386_linux libreadline.so=6-i386 (worst) Allan

4 5

[pacman-dev] [PATCH] makepkg: warn about repackaging without a package function
by Allan McRae 14 Apr '10

14 Apr '10

File permissions are not guaranteed to stay the same on exit from fakeroot, so repackaging may result in files with different permissions. This is avioded when using a package() function (or split packages) as the packaging step is rerun. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- Two areas to comment on: 1) "makepkg -R --asroot" does not give this warning. This is because it is assumed that the initial packaging stage was also done as root and so file permissions will be correct. Is that a fair assumption? 2) Should we depricate repackaging without a package function in pacman-3.5? Using a package function was supported in 3.3 and using only a package function (no build function) will be supported in 3.4. If that is reasonable, I will alter the warning and add it to the --asroot case too. scripts/makepkg.sh.in | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b2b449c..09a99e1 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1847,9 +1847,14 @@ fi if (( INFAKEROOT )); then if (( ! SPLITPKG )); then if (( ! PKGFUNC )); then - if (( BUILDFUNC && ! REPKG )); then - run_build - tidy_install + if (( ! REPKG )); then + if (( BUILDFUNC )); then + run_build + tidy_install + fi + else + warning "$(gettext "Repackaging without the use of a package() function may not")" + plain "$(gettext "preserve file permissions.")" fi else run_package -- 1.7.0.5

2 1

[pacman-dev] implement .so dependencies?
by Florian Pritz 13 Apr '10

13 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Regarding the current mass rebuilds because of libpng I'd like to suggest implementing so dependencies again. There will be no more cases where packages break because of library updates and as a nice side effect AUR users see what they have to rebuild. Pacman will treat those dependencies like others so if a user is sure he wants to update he can use -Sd. I've also tested if packages with sodeps would slow down pacman operation, but that's not really the case. The current patch adds "sodep-$arch-$soFileName" for every .so file that's owned by a package in the depends array. Files from optdepends are silently ignored and if no dependency owns the file there will be a warning. I've just rebased the old patch onto HEAD, fixed a little bit and tested it with libjpeg, so it should be fine. - -- Florian Pritz -- {flo,bluewind}(a)server-speed.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJLWgg0AAoJEG0WVcFM4cE+xlYP/08Ec1K9gFz0g8Q/+ag4S8+S U9mInCwJTe9xnu+H1J9JRsMwZ8DzP8WUlc99pqgz9n9Nxk8cpE1eUU9IIluHzjvR bJglYvAKIIknEtc1OkLVicFW2OfvgNzSwx73W6J3fELlzABpxtEMwmmXAJMaVZKq aIVgZ/zFP5b6XJT14FfQJbR7Mj4V5mCAhY0W+5SJL58RIHxPRz1PJKbzuZUcqLBo ouBcBPH9YuiSKufJhbsowyE6Hfyg4btFVHktr7EBvHtB/nb8Kk09LduloaQ9ZtEl hdSlbQL36AI2xJdN4XyuP4+UKmSh4hJKxfVBBCcDeWZd4ZbcC4WIersBY4Ia3hle 96Z8IZG8ydfC6+Ii5wdhdgzwzgaI2ZitgzO/XTLvBB1xpL+gQpupcSFSuypiU0K0 Yz3gybnj1XKb/8UEpNgjuKu6G1UChnmbenSS6lYFotXNWilQM9kAkYTDMV/KoQa0 CeyflEuUJuggMsKPz71NJnRCxcXSEdhVebeB9jKX8l2TIOgHwIYmmbO3yMaowzF+ 39zEAgxYxaLlTXQ2mnL/OkPrFjNQ1exyWwD1nW1N8n7Sr0zT21P4XK8kOrCQlTp7 XswSeZBV+pfR2Uby5hU6tUW9UvWZOHq2YZB7SAWfI7IEzcQxyVcbwwjuxplVgUr+ whZlxxDSfR0k6Uc9jeGm =/iDR -----END PGP SIGNATURE-----

9 28

[pacman-dev] [PATCH] Fix a mistake in the cross-compilation fix
by Matthias Lanzinger 09 Apr '10

09 Apr '10

I noticed a serious mistake in my previous patch. -lssl and -lcrypto were beeing added to $LIBS and by that they were added as linker flags during compilation. This overruled the --as-needed flag and causes ssl to be directly linked to pacman. Signed-off-by: Matthias Lanzinger <mlaenz(a)gmail.com> --- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index d0fed48..9bb0cd1 100644 --- a/configure.ac +++ b/configure.ac @@ -142,8 +142,8 @@ if test "x$internaldownload" = "xyes" ; then AC_MSG_RESULT(yes) AC_DEFINE([INTERNAL_DOWNLOAD], , [Use internal download library]) # Check for a download library if it was actually requested - AC_CHECK_LIB([fetch], [fetchParseURL], [AC_SUBST([LIBS], ["-lfetch -lssl -lcrypto -ldl $LIBS"])], - AC_MSG_ERROR([libfetch is needed to compile with internal download support]), [-lssl -lcrypto -ldl] ) + AC_CHECK_LIB([fetch], [fetchParseURL], [AC_SUBST([LIBS], ["-lfetch -ldl $LIBS"])], + AC_MSG_ERROR([libfetch is needed to compile with internal download support]), [-lcrypto -ldl] ) # Check if libfetch supports conditional GET # (version >=2.21, struct url has member last_modified) AC_CHECK_MEMBER(struct url.last_modified, , -- 1.7.0.3

3 2