[pacman-dev] New pacman testing RC
So, there's been a handful of changes recently. Most have been code cleanup, but there were some performance improvements and all that jazz too. New RC has pkgrel 5 and is here: http://archlinux.org/~aaron/pacman/ In case you haven't been following, this DOES install side-by-side with the existing pacman. You should have nothing to fear (except fear itself?) For the record, this has a changelog in it now, so if you install it with pacman3 you can then pacman3 -Qc pacman-rc to see the changelog (currently, abysmally empty - I suck at documentation). If you guys can, please please test this out. Here are the pending bugs still: http://bugs.archlinux.org/index.php?cat=6&type=1 I'd like to get the "Critical" and "High" ones complete and pushed out of there before giving this URL to the masses (soon, I swear it this time!) for better testing. All-in-all, I'd like to have nothing but "Low" / "Very Low" (excepting Feature Requests) before pushing this out. Thanks everyone, and special thanks to all the new contributors. We currently have 5 people stepping up to the plate and helping out with this, which is great, and highly appreciated.
2007/1/22, Aaron Griffin <aaronmgriffin@gmail.com>:
So, there's been a handful of changes recently. Most have been code cleanup, but there were some performance improvements and all that jazz too.
New RC has pkgrel 5 and is here: http://archlinux.org/~aaron/pacman/
Oh, yeah! :-D
For the record, this has a changelog in it now, so if you install it with pacman3 you can then pacman3 -Qc pacman-rc to see the changelog (currently, abysmally empty - I suck at documentation).
Great feature! I hope many packages will have changelogs after pacman3 release.
Here are the pending bugs still: http://bugs.archlinux.org/index.php?cat=6&type=1
#6094 is not a bug, but a feature request now, as can be seen from http://bugs.archlinux.org/task/6094#comment13357 and other comments below. #6246 should be fixed, but I didn't test it, can someone confirm? #3569 should be fixed too, but needs a confirmation. #5388 - not fixed yet? #3163 - is this still valid? (it was missed when reassigning bugs from Judd to you, Aaron). #5120 - same
I'd like to get the "Critical" and "High" ones complete and pushed out of there before giving this URL to the masses (soon, I swear it this time!) for better testing. All-in-all, I'd like to have nothing but "Low" / "Very Low" (excepting Feature Requests) before pushing this out.
Thanks everyone, and special thanks to all the new contributors. We currently have 5 people stepping up to the plate and helping out with this, which is great, and highly appreciated.
Yeah, thanks everyone! So many Pacman-related bugs were closed recently. -- Roman Kyrylych (Роман Кирилич)
-Ss is most definitely broken. Internal pacman error: Segmentation fault Please submit a full bug report, with the given package if appropriate. That is what I get no matter what I search. Time to fiddle in pacman's search code. ~ Jamie / yankees26
On Mon, 22 Jan 2007 17:57:20 -0500 James Rosten <seinfeld90@gmail.com> wrote:
-Ss is most definitely broken.
Internal pacman error: Segmentation fault Please submit a full bug report, with the given package if appropriate.
I get this as well. Also, -Sg is broken now too for me - I get no output whatsoever. When trying to install a group, it says the group doesn't actually exist. -- Travis
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
-Ss is most definitely broken.
Internal pacman error: Segmentation fault Please submit a full bug report, with the given package if appropriate.
Probably something I introduced with the alpm_list_t migration. I'll fix this tonight.
On 1/22/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
-Ss is most definitely broken.
Internal pacman error: Segmentation fault Please submit a full bug report, with the given package if appropriate.
Probably something I introduced with the alpm_list_t migration. I'll fix this tonight.
Debug output below. It only segfaults if it finds a matching package, if that helps. If you search for nonsense, it finishes correctly, so it must be in whatever code adds the found package to some list. $ pacman3 -Ss --debug=1 kernel26 [19:27:57] debug: config: new section 'options' [19:27:57] debug: config: logfile: /var/log/pacman.log [19:27:57] debug: config: noupgrade: etc/logrotate.conf [19:27:57] debug: config: noupgrade: var/abs [19:27:57] debug: config: noupgrade: etc/abs/supfile.community [19:27:57] debug: config: noupgrade: etc/abs/supfile.arch [19:27:57] debug: config: noupgrade: etc/abs/supfile.unstable [19:27:57] debug: config: noupgrade: etc/abs/supfile.extra [19:27:57] debug: config: noupgrade: etc/passwd [19:27:57] debug: config: noupgrade: etc/group [19:27:57] debug: config: noupgrade: etc/shadow [19:27:57] debug: config: noupgrade: etc/sudoers [19:27:57] debug: config: noupgrade: etc/fstab [19:27:57] debug: config: noupgrade: etc/raidtab [19:27:57] debug: config: noupgrade: etc/mdadm.conf [19:27:57] debug: config: noupgrade: etc/ld.so.conf [19:27:57] debug: config: noupgrade: etc/inittab [19:27:57] debug: config: noupgrade: etc/rc.conf [19:27:57] debug: config: noupgrade: etc/rc.local [19:27:57] debug: config: noupgrade: etc/modprobe.conf [19:27:57] debug: config: noupgrade: etc/modules.conf [19:27:57] debug: config: noupgrade: etc/lilo.conf [19:27:57] debug: config: noupgrade: boot/grub/menu.lst [19:27:57] debug: config: noupgrade: etc/mkinitrd.conf [19:27:57] debug: config: holdpkg: pacman [19:27:57] debug: config: holdpkg: glibc [19:27:57] debug: config: new section 'custom' [19:27:57] debug: opening database 'custom' [19:27:57] debug: config: new section 'current' [19:27:57] debug: opening database 'current' [19:27:57] debug: config: including /etc/pacman.d/current [19:27:57] debug: attempt to re-register the 'current' database, using existing [19:27:57] debug: config: new section 'current' [19:27:57] debug: attempt to re-register the 'current' database, using existing [19:27:57] debug: config: new section 'extra' [19:27:57] debug: opening database 'extra' [19:27:57] debug: config: including /etc/pacman.d/extra [19:27:57] debug: attempt to re-register the 'extra' database, using existing [19:27:57] debug: config: new section 'extra' [19:27:57] debug: attempt to re-register the 'extra' database, using existing [19:27:57] debug: config: new section 'community' [19:27:57] debug: opening database 'community' [19:27:57] debug: config: including /etc/pacman.d/community [19:27:57] debug: attempt to re-register the 'community' database, using existing [19:27:57] debug: config: new section 'community' [19:27:57] debug: attempt to re-register the 'community' database, using existing [19:27:57] debug: config: new section 'testing' [19:27:57] debug: opening database 'testing' [19:27:57] debug: config: new section 'unstable' [19:27:57] debug: opening database 'unstable' [19:27:57] debug: config: including /etc/pacman.d/unstable [19:27:57] debug: attempt to re-register the 'unstable' database, using existing [19:27:57] debug: config: new section 'unstable' [19:27:57] debug: attempt to re-register the 'unstable' database, using existing [19:27:57] debug: opening database 'local' [19:27:57] debug: searching for target 'kernel26' [19:27:57] debug: loading package cache (infolevel=0x3) for repository 'custom' [19:27:57] debug: searching for target 'kernel26' [19:27:57] debug: loading package cache (infolevel=0x3) for repository 'current' [19:27:58] debug: search target 'kernel26' matched 'kernel26' Internal pacman error: Segmentation fault Please submit a full bug report, with the given package if appropriate.
On Mon, Jan 22, 2007 at 05:30:50PM -0600, Aaron Griffin wrote:
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
-Ss is most definitely broken.
Internal pacman error: Segmentation fault Please submit a full bug report, with the given package if appropriate.
Probably something I introduced with the alpm_list_t migration. I'll fix this tonight.
You removed the "empty list assertion" in alpm_list_getdata, which prevented the dereference of NULL pointers? void *alpm_list_getdata(const pmlist_t *entry) { ASSERT(entry != NULL, return(NULL)); return(entry->data); } Jürgen
On 1/22/07, Jürgen Hötzel <juergen@hoetzel.info> wrote:
You removed the "empty list assertion" in alpm_list_getdata, which prevented the dereference of NULL pointers?
void *alpm_list_getdata(const pmlist_t *entry) { ASSERT(entry != NULL, return(NULL)); return(entry->data); }
Hmmm, looks like I did. However, at the same time, I would never expect "assert" to actually do something like return. I'm going to just add in a normal check, that macro seems a bit silly to me. Regardless, _getdata shouldn't be called with a null list entry, so the fact that the list node is null is probably the root of the problem.
You removed the "empty list assertion" in alpm_list_getdata, which prevented the dereference of NULL pointers?
void *alpm_list_getdata(const pmlist_t *entry) { ASSERT(entry != NULL, return(NULL)); return(entry->data); }
I made that change and compiled and -Ss works again, but -Sg still doesn't list anything. Also: james->monkeybox : ./test/usr/local/bin/pacman.static -Ss ^kernel26$ current/kernel26 2.6.19.2-1 The Linux Kernel and modules extra/kernel26beyond 2.6.19.beyond2-1 The Linux Kernel and modules, with the Beyond patchset. Shouldn't that only give me kernel26? ~ Jamie / yankees26
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
I made that change and compiled and -Ss works again, but -Sg still doesn't list anything.
Fixed in CVS. I broke alpm_list_add_sorted by removing the ->last pointer.
Also: james->monkeybox : ./test/usr/local/bin/pacman.static -Ss ^kernel26$ current/kernel26 2.6.19.2-1 The Linux Kernel and modules
extra/kernel26beyond 2.6.19.beyond2-1 The Linux Kernel and modules, with the Beyond patchset.
Shouldn't that only give me kernel26?
Yeah, lemme take a peek at that now.
Also: james->monkeybox : ./test/usr/local/bin/pacman.static -Ss ^kernel26$ current/kernel26 2.6.19.2-1 The Linux Kernel and modules
extra/kernel26beyond 2.6.19.beyond2-1 The Linux Kernel and modules, with the Beyond patchset.
Shouldn't that only give me kernel26?
Yeah, lemme take a peek at that now.
After you left IRC, we realized klapmeutz was correct about the provides thing. We realized that kernel26beyond said it provides kernel26 in its info, while kernel26ck, kernel26mm, and kernel26suspend2 do not say they provide kernel26. More evidence pointing to this is that pacman -Ss ^mpd$ (with smoons repo which has mpd-svn) shows both mpd and mpd-svn. ~ Jamie / yankees26
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
After you left IRC, we realized klapmeutz was correct about the provides thing. We realized that kernel26beyond said it provides kernel26 in its info, while kernel26ck, kernel26mm, and kernel26suspend2 do not say they provide kernel26. More evidence pointing to this is that pacman -Ss ^mpd$ (with smoons repo which has mpd-svn) shows both mpd and mpd-svn.
Yeah, I didn't even notice it regexes 'provides' as well... in fact, that doesn't appear documented anywhere and I actually didn't know it worked that way. Do we want this behavior? While I can see if being useful, shouldn't the actual output contain something to indicate WHY it matched?
2007/1/23, Aaron Griffin <aaronmgriffin@gmail.com>:
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
After you left IRC, we realized klapmeutz was correct about the provides thing. We realized that kernel26beyond said it provides kernel26 in its info, while kernel26ck, kernel26mm, and kernel26suspend2 do not say they provide kernel26. More evidence pointing to this is that pacman -Ss ^mpd$ (with smoons repo which has mpd-svn) shows both mpd and mpd-svn.
Yeah, I didn't even notice it regexes 'provides' as well... in fact, that doesn't appear documented anywhere and I actually didn't know it worked that way.
Do we want this behavior? While I can see if being useful, shouldn't the actual output contain something to indicate WHY it matched?
Doing pacman -Ss ^pkgA$ and getting pkgA and completely-differenly-named-pkgB is confusing IMO, especially when no reason is indicated. Either there should be indication that it was matched because it provides searched package or this searching-in-provides feature should be dropped, IMHO. -- Roman Kyrylych (Роман Кирилич)
On 1/23/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
After you left IRC, we realized klapmeutz was correct about the provides thing. We realized that kernel26beyond said it provides kernel26 in its info, while kernel26ck, kernel26mm, and kernel26suspend2 do not say they provide kernel26. More evidence pointing to this is that pacman -Ss ^mpd$ (with smoons repo which has mpd-svn) shows both mpd and mpd-svn.
Yeah, I didn't even notice it regexes 'provides' as well... in fact, that doesn't appear documented anywhere and I actually didn't know it worked that way.
Do we want this behavior? While I can see if being useful, shouldn't the actual output contain something to indicate WHY it matched?
Odd that it regexes provides and nothing else- matching depends would make just as much sense (say you were trying to find a GUI subversion client or something). If we keep these other fields in our searches, I think we need to do something a bit special when they match. For normal name/description matches, we should keep the output the same. For a provides (and maybe depends) we could take at the end of the name line something like this (fictional package name, btw): community/guisvn 1.0-1 (provides subversion) OR community/guisvn 1.0-1 (depends on subversion) Just my thoughts. The only other thing would just be to dump this behavior all together, but it does seem helpful in those cases such as cdrecord where a rename occurs (btw, searching for cdrecord doesn't yield a whole lot of helpful things- someone needs to look at these descriptions). -Dan
2007/1/23, Dan McGee <dpmcgee@gmail.com>:
On 1/23/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 1/22/07, James Rosten <seinfeld90@gmail.com> wrote:
After you left IRC, we realized klapmeutz was correct about the provides thing. We realized that kernel26beyond said it provides kernel26 in its info, while kernel26ck, kernel26mm, and kernel26suspend2 do not say they provide kernel26. More evidence pointing to this is that pacman -Ss ^mpd$ (with smoons repo which has mpd-svn) shows both mpd and mpd-svn.
Yeah, I didn't even notice it regexes 'provides' as well... in fact, that doesn't appear documented anywhere and I actually didn't know it worked that way.
Do we want this behavior? While I can see if being useful, shouldn't the actual output contain something to indicate WHY it matched?
Odd that it regexes provides and nothing else- matching depends would make just as much sense (say you were trying to find a GUI subversion client or something).
If we keep these other fields in our searches, I think we need to do something a bit special when they match. For normal name/description matches, we should keep the output the same. For a provides (and maybe depends) we could take at the end of the name line something like this (fictional package name, btw): community/guisvn 1.0-1 (provides subversion) OR community/guisvn 1.0-1 (depends on subversion)
I don't think adding depends is a good idea, because we'll get a lot of matches for some packages. If we want to have depends matching - then it should be "reverse depends" feature. ;-) Example: # pacman -Sr subversion community/guisvn 1.0-1 . . . # pacman -Ssr ^subversion$ community/guisvn 1.0-1 . . . -- Roman Kyrylych (Роман Кирилич)
Added pkgrel=6 up at the same URL. -Ss and -Sg works. Other changes are more internal.
On Tue, 23 Jan 2007 21:06:53 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Added pkgrel=6 up at the same URL. -Ss and -Sg works. Other changes are more internal.
I got the attached oddness when I tried to install xfce4 and xfce4-goodies with 3.0.0-6 -- Travis
On 1/23/07, Travis Willard <travisw@wmpub.ca> wrote:
On Tue, 23 Jan 2007 21:06:53 -0600 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Added pkgrel=6 up at the same URL. -Ss and -Sg works. Other changes are more internal.
I got the attached oddness when I tried to install xfce4 and xfce4-goodies with 3.0.0-6
Should be fixed in -7. Looks like that error may have been around slightly longer than I thought, as it was related to groups only.
Em Qua 24 Jan 2007, Aaron Griffin escreveu:
On 1/23/07, Travis Willard <travisw@wmpub.ca> wrote:
On Tue, 23 Jan 2007 21:06:53 -0600
"Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Added pkgrel=6 up at the same URL. -Ss and -Sg works. Other changes are more internal.
I got the attached oddness when I tried to install xfce4 and xfce4-goodies with 3.0.0-6
Should be fixed in -7. Looks like that error may have been around slightly longer than I thought, as it was related to groups only.
Seems that is it working for me now :)
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
participants (7)
-
Aaron Griffin
-
Dan McGee
-
Douglas Soares de Andrade
-
James Rosten
-
Jürgen Hötzel
-
Roman Kyrylych
-
Travis Willard