Update of iproute to the latest version, please sign off.
On Tue, 26 Feb 2008 16:12:33 +0100 Thomas Bächler thomas@archlinux.org wrote:
Update of iproute to the latest version, please sign off.
warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1)
There should be a force for this update.
Daniel
Daniel Isenmann schrieb:
On Tue, 26 Feb 2008 16:12:33 +0100 Thomas Bächler thomas@archlinux.org wrote:
Update of iproute to the latest version, please sign off.
warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1)
There should be a force for this update.
done
On Tue, Feb 26, 2008 at 05:11:00PM +0100, Thomas Bächler wrote:
Daniel Isenmann schrieb:
warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1)
There should be a force for this update.
done
Please have a look at : http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003307.html
Xavier schrieb:
On Tue, Feb 26, 2008 at 05:11:00PM +0100, Thomas Bächler wrote:
Daniel Isenmann schrieb:
warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1)
There should be a force for this update.
done
Please have a look at : http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003307.html
I am not sure if our repository scripts already recognize that. Anyway, the package has a force flag in the repo db and is updated properly.
Any signoffs yet?
On Wed, Feb 27, 2008 at 10:09 AM, Thomas Bächler thomas@archlinux.org wrote:
Xavier schrieb:
On Tue, Feb 26, 2008 at 05:11:00PM +0100, Thomas Bächler wrote:
Daniel Isenmann schrieb:
warning: iproute: local (070710-3) is newer than testing (2.6.24_rc7-1)
There should be a force for this update.
done
Please have a look at : http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003307.html
I am not sure if our repository scripts already recognize that. Anyway, the package has a force flag in the repo db and is updated properly.
Don't make a broken PKGBUILD to satisfy broken repo scripts- this helps no one. Correct PKGBUILDs force us to correct our repo scripts if they are broken.
Any signoffs yet?
lnstat segfaults when ran. I don't use any of these utilities, but ifstat seems OK, not sure about tc.
-Dan
Dan McGee schrieb:
lnstat segfaults when ran. I don't use any of these utilities, but ifstat seems OK, not sure about tc.
-Dan
lnstat works here ...
On Wed, Feb 27, 2008 at 1:31 PM, Thomas Bächler thomas@archlinux.org wrote:
Dan McGee schrieb:
lnstat segfaults when ran. I don't use any of these utilities, but ifstat seems OK, not sure about tc.
-Dan
lnstat works here ...
dmcgee@dublin ~/projects/pacman-maint (maint) $ gdb lnstat GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/sbin/lnstat (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault. 0x080491b8 in ?? () (gdb) c Continuing.
Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) q
dmcgee@dublin ~/projects/pacman-maint (maint) $ lnstat Segmentation fault
On Wed, Feb 27, 2008 at 1:38 PM, Dan McGee dpmcgee@gmail.com wrote:
On Wed, Feb 27, 2008 at 1:31 PM, Thomas Bächler thomas@archlinux.org wrote:
Dan McGee schrieb:
lnstat segfaults when ran. I don't use any of these utilities, but ifstat seems OK, not sure about tc.
-Dan
lnstat works here ...
dmcgee@dublin ~/projects/pacman-maint (maint) $ gdb lnstat GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/sbin/lnstat (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault. 0x080491b8 in ?? () (gdb) c Continuing.
Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) q
dmcgee@dublin ~/projects/pacman-maint (maint) $ lnstat Segmentation fault
The real address, not that it matters: 0x080491fc in ?? ()
I downgraded and the old version also segfaults for me, and that was the first printout. The new version does the same.
-Dan
On Wed, 27 Feb 2008, Dan McGee wrote:
On Wed, Feb 27, 2008 at 1:38 PM, Dan McGee dpmcgee@gmail.com wrote:
On Wed, Feb 27, 2008 at 1:31 PM, Thomas Bächler thomas@archlinux.org wrote:
Dan McGee schrieb:
lnstat segfaults when ran. I don't use any of these utilities, but ifstat seems OK, not sure about tc.
-Dan
lnstat works here ...
dmcgee@dublin ~/projects/pacman-maint (maint) $ gdb lnstat GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/sbin/lnstat (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault. 0x080491b8 in ?? () (gdb) c Continuing.
Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) q
dmcgee@dublin ~/projects/pacman-maint (maint) $ lnstat Segmentation fault
The real address, not that it matters: 0x080491fc in ?? ()
I downgraded and the old version also segfaults for me, and that was the first printout. The new version does the same.
-Dan
Here lnstats segfaults only when you don't give it any argument: 'lnstat --help' or 'lnstat -d' works. I don't really use these tools but the ones I checked seems to work fine.
So signing off x86_64
Eric
Eric Belanger schrieb:
On Wed, 27 Feb 2008, Dan McGee wrote:
On Wed, Feb 27, 2008 at 1:38 PM, Dan McGee dpmcgee@gmail.com wrote:
On Wed, Feb 27, 2008 at 1:31 PM, Thomas Bächler thomas@archlinux.org wrote:
Dan McGee schrieb:
lnstat segfaults when ran. I don't use any of these utilities, but ifstat seems OK, not sure about tc.
-Dan
lnstat works here ...
dmcgee@dublin ~/projects/pacman-maint (maint) $ gdb lnstat GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /usr/sbin/lnstat (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault. 0x080491b8 in ?? () (gdb) c Continuing.
Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) q
dmcgee@dublin ~/projects/pacman-maint (maint) $ lnstat Segmentation fault
The real address, not that it matters: 0x080491fc in ?? ()
I downgraded and the old version also segfaults for me, and that was the first printout. The new version does the same.
-Dan
Here lnstats segfaults only when you don't give it any argument: 'lnstat --help' or 'lnstat -d' works. I don't really use these tools but the ones I checked seems to work fine.
So signing off x86_64
Eric
No segfault here, even without any argument, x86_64 as well.
I don't know what lnstat does, but 'ip' works just fine for me (which is the only tool I ever used from this package).
On Mon, Mar 03, 2008 at 09:53:22AM +0100, Thomas Bächler wrote:
Eric Belanger schrieb:
Here lnstats segfaults only when you don't give it any argument: 'lnstat --help' or 'lnstat -d' works. I don't really use these tools but the ones I checked seems to work fine.
So signing off x86_64
Eric
No segfault here, even without any argument, x86_64 as well.
I don't know what lnstat does, but 'ip' works just fine for me (which is the only tool I ever used from this package).
And here, it segfaults only when I run it with -w 1. I tried a bunch of other combinations (with or without arguments, and with different values) and they all worked. (i686)
On Wed, Feb 27, 2008 at 05:09:11PM +0100, Thomas Bächler wrote:
I am not sure if our repository scripts already recognize that. Anyway, the package has a force flag in the repo db and is updated properly.
I can't assure you that it works, but the updatesync-many script (if that's used) apparently support the new, correct, and consistent syntax : http://projects.archlinux.org/git/?p=dbscripts.git;a=blob;f=updatesync-many;...
Besides, since makepkg 3.1.2, the options=(force) syntax in PKGBUILD is supported, which means this information is now put in the packages themselves (in .PKGINFO). This information will then be recognized by repo-add when adding a package to a database. Before 3.1.2, specifying the force flag in PKGBUILD had no effect to makepkg and repo-add. The only way was to use repo-add --force when adding the package. This option is now deprecated in favor of the above method.
To sum up, if you use the standard makepkg / repo-add tools, only options=(force) will work. And I heard that making use of repo-add in dbscripts was Aaron's first priority :)
2008/2/27, Xavier shiningxc@gmail.com:
On Wed, Feb 27, 2008 at 05:09:11PM +0100, Thomas Bächler wrote:
I am not sure if our repository scripts already recognize that. Anyway, the package has a force flag in the repo db and is updated properly.
I can't assure you that it works, but the updatesync-many script (if that's used) apparently support the new, correct, and consistent syntax : http://projects.archlinux.org/git/?p=dbscripts.git;a=blob;f=updatesync-many;...
Besides, since makepkg 3.1.2, the options=(force) syntax in PKGBUILD is supported, which means this information is now put in the packages themselves (in .PKGINFO). This information will then be recognized by repo-add when adding a package to a database. Before 3.1.2, specifying the force flag in PKGBUILD had no effect to makepkg and repo-add. The only way was to use repo-add --force when adding the package. This option is now deprecated in favor of the above method.
To sum up, if you use the standard makepkg / repo-add tools, only options=(force) will work. And I heard that making use of repo-add in dbscripts was Aaron's first priority :)
ehm, shouldn't all packages that have 'force' (in either form) be rebuilt with makepkg 3.1.2 then? otherwise old packages won't get 'forced' in db.
On Wed, Feb 27, 2008 at 10:01:37PM +0200, Roman Kyrylych wrote:
ehm, shouldn't all packages that have 'force' (in either form) be rebuilt with makepkg 3.1.2 then? otherwise old packages won't get 'forced' in db.
With the previous repo-add / makepkg, the force flag in either form was not supported. Since 3.1.2, you have the possibility to use options=(force), but not force=y.
This only concern repo-add users though, and dbscripts doesn't use that yet. You will only need to convert old PKGBUILD to the new syntax when rebuilding them and re-adding them with newer dbscripts that don't even exist yet.
arch-dev-public@lists.archlinux.org