- Arch-dev-public - lists.archlinux.org

[arch-dev-public] [signoff] findutils 4.4.1-2
by Tobias Powalowski 13 May '09

13 May '09

Hi fixes scriptlet error: http://bugs.archlinux.org/task/14687 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 3

[arch-dev-public] [signoff] dcron-3.2-4
by Tobias Powalowski 13 May '09

13 May '09

Hi fixed manpath: http://bugs.archlinux.org/task/13764 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] sysfsutils 2.1.0-5
by Tobias Powalowski 13 May '09

13 May '09

Hi fixed manpath: http://bugs.archlinux.org/task/13764 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

Re: [arch-dev-public] Status of arch=any ?
by Firmicus 12 May '09

12 May '09

Aaron Griffin: > I made a few small changes and pushed them to git. I have not fully > committed all of the db-update changes, as I'm not entirely sure why > some of these changes were made - for instance: why was the pkglisting > broken out to the top of the file? > > It seems I had forgotten to reply to the above! Sorry. The current dev version of db-update will stop with errors if, for at least one of the three arch categories, no package is present under $staging. In other words, if you run it and there are N packages for arch=any, but none for arch=i686, for instance. The script attempts to copy files for each arch, but if none is there, cp returns an error and db-update will die. I send you a patch to fix that by checking first for the existence of at least one package before attempting to copy it to the ftp tree. I'm also sending you three additional patches: a second one to create the $WORKDIR before cd'ing to it, a third one that fixes an obvious bug in the creation of symlinks, and a fourth one to fix the incorrect redirection of error messages for get_svnpath in db-functions. Hope it helps... > Regarding the new convert2any script you added - I'd prefer to fix the > existing script rather than add a new one - or at least preserve some > of the logic (such as sourcing of makepkg.conf) > > All right, perhaps Abhishek can do that? ;) F

2 1

Re: [arch-dev-public] [arch-general] LZMA - in or out? ([signoff] libarchive 2.6.0 )
by Pierre Schmitz 12 May '09

12 May '09

Am Dienstag, 12. Mai 2009 09:00:30 schrieb Pierre Schmitz: > I am just doing some very simple test right now. (default compression > preset) > > core (x86_64) (decompress time) > none 552M > gzip 186M 12s > xz 121M 17s And here are the numbers for extra; a lot more intersting imho: extra (x86_64) none 13,8G gzip 5,5G 10min xz 4,1G 11min -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre(a)jabber.archlinux.de WWW http://www.archlinux.de

1 0

Re: [arch-dev-public] [arch-general] New vi/vim/gvim in testing requires intervention
by Dan McGee 12 May '09

12 May '09

On Tue, May 12, 2009 at 2:19 AM, Tobias Kieslich <tobias(a)justdreams.de> wrote: > On Tue, 12 May 2009, Magnus Therning wrote: >>>> And a quick guess, it looks like the new vim package puts its colors here: >>>> /usr/share/vim/vim72/colors/ >>>> >>>> Any reason the old /usr/share/vim/ shouldn't be on the default runtimepath? >> >> Looking at other distros it seems using /usr/share/vim/vimX is the place >> for system-wide configurations. Not saying that's right or wrong. > > Well, I tied up quite a few requests into the new vim packages. Becuase > we serve the runtime files with one package(vim) and have other > packages(gvim) depend on it, I used to set the runtime path explicitely. > Users told me that causes vim to search always in two pathes(the > explicite one AND the default one). Hence I started toi stick with the > default path, which is /usr/share/vim/vimxy. > > That means all plugins need to be rebuild and some users that set fixed > pathes in .vimrc will have to adjust. Looks like we have a new rebuild list then: $ pacman -Sqs vim- gvim vim-a vim-bufexplorer vim-buftabs vim-colorsamplerpack vim-doxygentoolkit vim-guicolorscheme vim-matchit vim-minibufexpl vim-omnicppcomplete vim-project vim-taglist vim-vcscommand vim-workspace vim-pastie vim-rails vim-supertab vim-surround vim-timestamp vimpager Why the heck gvim and vimpager showed up in there I'm not sure, but the above plugin packages probably all use the default location. We should additionally make sure they depend on 'vim' and not 'vi', as I rebuilt two or three plugins already that made the assumption they were one and the same. -Dan

1 0

[arch-dev-public] LZMA - in or out? ([signoff] libarchive 2.6.0)
by Dan McGee 12 May '09

12 May '09

On Sat, Jan 3, 2009 at 6:00 AM, Andreas Radke <a.radke(a)arcor.de> wrote: > I'd like to keep unneeded packages out of core. I see no need to move > lzma into core. We only support tar.gz for our repos. Whoever wants to > use a different format can rebuild libarchive easily. > > I also wonder if our new tar package now supports lzma and lzop > compression (no tests so far). Both packages were not present when > building the tar package in he chroot. But even when it's now possible > to use these formats at runtime they should stay in extra until we may > use them for our repos. I don't want to go too back and forth on this on the signoff thread so I'll move it here. I was thinking much more in the context of archives in general rather than just pacman using libarchive. libarchive ships with bsdtar, which I have found to be quicker than GNU tar at extracting (so I use it nearly exclusively). It would be a shame to tell people "we don't support .tar.lzma for anything"- that seems rather arbitrary, doesn't it? I too think [core] should stay as slim as possible, but when that requires we compile our packages with a less than ideal set of features, I want to at least give it some thought. -Dan

11 23

[arch-dev-public] [signoff] sqlite3 3.6.14-1
by Andreas Radke 12 May '09

12 May '09

upstream update. please signoff. -Andy SQLite Release 3.6.14 On 2009 May 7 (3.6.14) Changes associated with this release include the following: * Added the optional asynchronous VFS module. * Enhanced the query optimizer so that virtual tables are able to make use of OR and IN operators in the WHERE clause. * Speed improvements in the btree and pager layers. * Added the SQLITE_HAVE_ISNAN compile-time option which will cause the isnan() function from the standard math library to be used instead of SQLite's own home-brew NaN checker. * Countless minor bug fixes, documentation improvements, new and improved test cases, and code simplifications and cleanups. A complete list of SQLite releases in a single pages is also available. A detailed history of every check-in is available at http://www.sqlite.org/cvstrac/timeline.

3 2

[arch-dev-public] [signoff] wireless_tools 29-3
by Tobias Powalowski 12 May '09

12 May '09

Hi fixed manpath: http://bugs.archlinux.org/task/13764 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] [signoff] toolchain
by Allan McRae 12 May '09

12 May '09

Hi all, Signoffs are needed for the toolchain gcc-4.4.0 rebuild. This involves the following packages gcc{,-libs}-4.4.0-1 glibc-2.9-7 bintuils-2.9-7 kernel-headers-2.6.29.1-1 and two new deps for gcc: ppl-0.10.2-2 cloog-ppl-0.15.3-1 I was going to wait until glibc-2.10 arrived at the end of the week to give people time to find fixes for gcc-4.4 issues but there are issues with C++ programs compiled with gcc-4.4 running against (or to be more precise, not running with) the gcc-4.3 libs. So not moving the toolchain would probably block KDE from moving from [testing]. Also, Fedora has done their rebuild using gcc-4.4 for F11 so patches should be available for any problems encountered. Allan

5 7