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

[arch-dev-public] Fw: Archlinux Mirror
by Judd Vinet 26 Jun '07

26 Jun '07

We have a new mirror for use. Scott says he has plenty of bandwidth, so North American Archers can use it. - J Begin forwarded message: Date: Sat, 23 Jun 2007 18:02:39 -0600 From: Scott <scott(a)unixheads.com> To: Judd Vinet <jvinet(a)zeroflux.org> Subject: Re: Archlinux Mirror Judd- The primary node is pulling from your server now. Either the mirror I pulled from was out of date, or something strange happened. It seems to be pulling a lot of packages all over again. So I would not consider my mirror fully up to date yet, perhaps in 6-12 hours. I am currently only getting 100k or so from your master server, so if it ends up getting everything again I suppose it could take a few days. It took 8-9 hours or so at 7 times the speed, so if it does it all over again it could be about 70 hours :-) Once the primary node is done, I will sync my backup node up with it before hitting yours with the backup node. But the URLS are: http://mirrors.unixheads.org/archlinux ftp://mirrors.unixheads.org/archlinux rsync://mirrors.unixheads.org/archlinux Scott..

2 1

[arch-dev-public] ABS cleanup, round 2
by Dan McGee 26 Jun '07

26 Jun '07

I just made another script today to do some more cleanup- this untags all files that have been removed from CVS but did not drop their CURRENT or CURRENT-64 tag. I went ahead and ran it on both the [current] and [extra] repos for both i686 and x86_64. If anyone notices any problems building certain packages from ABS now, it may be due to this, in which case I'll put the blame squarely on the person who originally deleted the file. :) With the script below, it was as easy as running this command in the top level directory of the CVS checkout (that has not had directories pruned): ./cleantags.sh > cleanlist.txt cat cleanlist.txt | xargs cvs tag -d CURRENT (or CURRENT-64, of course) If anyone wants to run this on community, or thinks I should, let me know. I felt a little more worried about messing something up there I can't fix. I would recommend it get done however- this single cleanup dropped 336 files from ABS, which is rather significant. -Dan #!/bin/bash # find files in CVS that have been deleted but not untagged # tag to search for tag="CURRENT" #tag="CURRENT-64" #tag="TESTING" #tag="TESTING-64" # path to CVSROOT ,v files path="/home/cvs-arch/arch/build" #path="/home/cvs-extra/extra" #path="/home/cvs-community/community" #path="/home/cvs-unstable/unstable" atticdirs="$(find $path -type d -name Attic)" for dir in $atticdirs; do for file in $(ls $dir); do grep -Pq "\t$tag:" $dir/$file if [ $? -eq 0 ]; then echo "$dir/$file" | sed -e 's|,v||' -e "s|$path|.|" -e 's|Attic/||' fi done done

1 0

[arch-dev-public] kvm, qemu-kvm maintainer searched
by Tobias Powalowski 26 Jun '07

26 Jun '07

Hi i tried this kvm crap now to get it running with kernel 22rc5 kvm-modules do compile, no problem here. to get this stuff running we need a gcc3.4 version kvm-qemu is bugged and doesn't compile with gcc 3.3 i have no hardware to test it and no need for it, it would be great if someone who has the hardware and the fun to do this stuff. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 10

[arch-dev-public] Inactive
by Phil Dillon-Thiselton 25 Jun '07

25 Jun '07

Hello all, Not sure you can really be inactive before you even are active but I've had some bad news today, which is going to keep me occupied for a little while. Ironically the good news and the bad news came within about 30 mins of each other. It's probably traditional to do a proper "hello" sort of thing but I think I better postpone that until I'm ready to do it properly and get started. I'm sure you were all really looking forward to it and that comes as a crushing disappointment but I'm sure you can all cope in the meantime ;-) Looking forward to getting started eventually though :-) Thanks and best, Phil

1 0

[arch-dev-public] "Don't-Panic" kernel-2.6.22 rc5git8 686 Isos available
by Tobias Powalowski 25 Jun '07

25 Jun '07

Hi now also available latest kernel install isos. http://www.archlinux.org/~tpowa/rc-iso/ everything mentioned here is fixed: http://bugs.archlinux.org/task/7410 INFORMATION: kernel 22rc5git8 snapshot Iso called beta1 :) - ftp install will not work with any iso image, because it will grep the wrong kernel from ftp! use ftp iso only for checking if 22rc5 runs on your system! have fun and enjoy the new "Don't-Panic" beta1 release try to break it! greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 7

[arch-dev-public] restructure our printing system
by Andreas Radke 22 Jun '07

22 Jun '07

after talking to Till Kampeter at Linuxtag in Berlin and reading around how other distributions are packaging the printer drivers i want to restructure our packages(cups, gutenprint, foomatic, gimp-print-lprng,cups-pdf....): - package only still developed software - stick with stable tree releases - drop outdated packages/move to AUR rarely - improve features the last point will force us to have almost all printing related packages in either current or extra. now they are splitted and can not depend on each other. i suggest to move such hardware related packages + virtual printers all into current/system or current/office. but extra would also be fine for me. where's the better location? AndyRTR

2 4

Re: [arch-dev-public] [pacman-dev] pacman screws up permissions
by Dan McGee 20 Jun '07

20 Jun '07

On 6/20/07, Thomas Bächler <thomas.baechler(a)gmx.de> wrote: > I just installed the ntfs-3g package with pacman 3.0.5-1: > > $ /bin/ls -lhF /bin/ntfs-3g /usr/man/man8/ntfs-3g.8.gz > -rwxrwxrwx 1 root root 36K 20. Jun 01:45 /bin/ntfs-3g* > -rwxrwxrwx 1 root root 3,0K 20. Jun 01:44 /usr/man/man8/ntfs-3g.8.gz* > > The permissions in the tarfile are 755 for /bin/ntfs-3g (and I suppose > they are 644 for the manpage, didn't check that). This behaviour can > cause critical bugs and in this case is security-relevant, as a user > could change the ntfs-3g binary, which is executed at boot time on many > systems. This has to be fixed FAST. Has anyone read my recent emails? I've said the same thing, and I think it is due to a "fix" that didn't get tested well in pacman 3.0.5. I think I'm going to roll back that fix tonight unless someone else can come up with a solution. Relevant stuff: http://archlinux.org/pipermail/arch-dev-public/2007-June/001048.html http://archlinux.org/pipermail/pacman-dev/2007-June/008567.html http://archlinux.org/pipermail/pacman-dev/2007-June/008567.html http://bugs.archlinux.org/task/7461 http://bugs.archlinux.org/task/7323 -Dan

2 2

[arch-dev-public] Cleanup of some base libs
by Dan McGee 20 Jun '07

20 Jun '07

While trying to figure out my libtool libarchive issue, I looked at the PKGBUILDs for acl and attr and was pretty scared at what I saw. I attempted to clean them up a lot, and I think I succeeded, but I wanted some testing from you guys first before I push these to testing and then maybe to current. I also want to make sure no one sees an issue with building them this way. I set up a small repo here: [baseclean] Server = http://archlinux.org/~dan/baseclean The repo has the following packages (I rebuilt those that depend directly on acl/attr): acl, attr, libarchive, pacman (because libarchive has been upgraded), and xfsdump. The one package missing that should be here is coreutils, but I had a build failure (not sure if this is related to the gcc 4.2 upgrade). In addition, has anyone else noticed this issue- http://bugs.archlinux.org/task/7461? It is kind of a big deal, and I'm going to be gone starting tomorrow for the entire weekend so I want to find some resolution before then. -Dan Note to self: add some comments to the acl/attr PKGBUILDs explaining those weird variable settings used in the install line (include/builddefs, buildmacros, etc.).

1 1

[arch-dev-public] libarchive, pacman, and libtool-slaying
by Dan McGee 20 Jun '07

20 Jun '07

I'm sending this to two lists to see who can offer some insight, as I tried and failed earlier to get pacman to correctly build with a newer version of libarchive. I think it may deal with having la files in the package, but I am not sure so I'll outline what I've tried and know so far. Libarchive website: http://people.freebsd.org/~kientzle/libarchive/ Current version: 2.2.3 Current Arch Linux version: 1.3.1-2 As you can see, we are a ways behind. I up-ed the PKGBUILD for libarchive, rebuilt it without problems (as far as I can tell), and then pacman -U <new libarchive> and tried to compile pacman. The ldd output showed that it correctly linked against the new libarchive.so.2, but it had somehow also linked against libarchive.so.1. I tried rebuilding libarchive using options=(!libtool), but that didn't seem to fix anything- it actually just spit some more errors saying libarchive was missing la files and such. OK, long explanation, but it comes down to this: 1. How can we get pacman to compile with libarchive without needing the la files? libdownload seems to work fine without them, etc. 2. Where is this mysterious link to libarchive.so.1 coming from when it isn't even present on my system anymore? This applies to both the most recent CVS release and our GIT tree at projects.al.org. -Dan

4 5

[arch-dev-public] Updating gcc3 package
by Jason Chu 20 Jun '07

20 Jun '07

Does anyone have any problems with me updating the gcc3 package to gcc3.4? It looks like the only packages that depend on it in extra are qemu and kvm-modules. Like tpowa said, kvm doesn't compile with gcc 3.3 but will with gcc 3.4. It seems that qemu doesn't care, just as long as it's not gcc 4. Do any packages depend on gcc 3.3? Jason

5 4