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

[arch-dev-public] 2007.10 ISO release on saturday 6th october?
by Tobias Powalowski 04 Oct '07

04 Oct '07

Hi i moved in the 0.3 test isos to ftp/iso directory. If no real showstopper is reported till Saturday i would suggest to announce them officially, and remove the other old ISOs from ftp. Your thoughts on it? Announcement on homepage: --- start Hi Arch community, Arch Linux Don't Panic 2007.10 ISO release I changed everything to fit to the new core repository, 2 ISOs left ftp ISO and core ISO. Changelog: GENERAL: - kernel 2.6.22.9 usage - disabled arch_addons hook by default, it is now triggered by arch-addons boot parameter In order to boot and install successfully, the new RAM recommendations: - RAM usage increased to 256 MB (FTP-ISO,CORE-ISO arch boot image) - RAM usage 96 MB (CORE-ISO lowmem boot image) FIXES: - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - fixed km to not show broken chars after exit - fixed grub installing with xfs filesystem - fixed package clearing if setup option was chosen NEW STUFF: - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - added hosts.deny and hosts.allow to config editing dialog - added licenses to install environment - added new lowmem boot image to core iso stripped everything out that is not necessary for installation As usual check md5sum before using the images and also be aware of the new RAM recommendations the images have. Have fun greetings tpowa --- end have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 19

[arch-dev-public] GIT Daemon up on projects.archlinux.org
by Dan McGee 04 Oct '07

04 Oct '07

For all out there that may not be aware, we now have a subdomain at http://projects.archlinux.org where we host some of our internal Arch projects. We have been moving a lot of our projects from other version control systems to GIT as of late, and currently have quite a bunch of these projects hosted, as you can see here: http://projects.archlinux.org/git/ For those interested in helping out with these projects or just following along with the code, we now have a git daemon up and running. All of these projects can still be fetched over http if need be, but using the GIT native protocol is much more efficient. The following two examples should get you started on cloning one of our projects: (Over HTTP) git clone http://projects.archlinux.org/git/namcap.git namcap (Over GIT) git clone git://projects.archlinux.org/pacman.git pacman Note the slight difference in URLs- for cloning over GIT, no /git directory is used. Happy git-cloning, and we'd really like to see some community participation with these projects if you have something to contribute! Patches always welcome on the mailing lists. -Dan

1 0

[arch-dev-public] A big baad idea: ArchCon 2009
by Tom K 03 Oct '07

03 Oct '07

High concept: "What do you think would happen if as many Arch people as possible gathered in the same place at the same time?" Audience breakdown: All members of the dev team (well, duh) TU-selected members of the TU team Other Archers fanatical enough to attend People off the street Program: Hacking Talking Bonding (aww....) Drinking (woohoo!) etc TBC: Continent Country City Venue Menu Activities Restrooms Size of Mugs Imperial or Metric Yadda Yadda etc Teaser: one particular member of the dev team will volunteer to organise the whole shebang! I'm posting this here, because if the devs aren't interested, well... All the best Tom.

13 17

[arch-dev-public] Test Isos 2007.10-0.3 with core repository and 96MB RAM image
by Tobias Powalowski 03 Oct '07

03 Oct '07

Hi here the changelog: i changed everything to fit to new core repository, 2 isos left ftp iso and core iso, the rest was setup/archboot changes to achieve this. - I cleaned up our documentation, to fit to those stuff please read it and tell me what is missing or wrong. GENERAL: - disabled arch_addons hook by default, it is triggered by arch-addons boot parameter - Ram usage increased to 256MB (FTP-ISO,CORE-ISO arch boot image) - Ram usage 96 MB (CORE-ISO lowmem boot image) FIXES: - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - fixed km to not show broken chars after exit - fixed grub installing with xfs filesystem - fixed packages are now cleared if setup option was chosen NEW STUFF: - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - added hosts.deny and hosts.allow to config dialog - added licenses to install environment - added new lowmem boot image to core iso stripped everything out that is not necessary for installation TODO: - nothing from my side, it's nearly perfect :) you can download i686 Isos here: http://www.archlinux.org/~tpowa/rc-iso/686 you can download x86_64 Isos here: http://www.archlinux.org/~tpowa/rc-iso/x86_64 About memory usage: It's a pacman bug that it increased to 256MB and 96MB so don't blame me on it ;) http://bugs.archlinux.org/task/8155 We should really replace our current Isos with them soon, the old ones are all a bit bugged and ftp is broken on them anyway. so removing old isos from server and place those ones instead is highly recommenden from my side. Your thoughts on it? have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] namcap status
by Jason Chu 03 Oct '07

03 Oct '07

Since I emailed out about devtools and pacbuild, here's the last email about namcap. Development on namcap is moving along nicely now that I've had help from Jesse Young and JJDaNiMoTh. I only have one thing left on my todo list related to namcap: updated licensepkg code. I want to actually inspect the packages and verify that they have the custom licenses distributed with them that they say they do. After I make that update, I plan on releasing namcap 2.0. Since namcap is hosted on projects now, where should the tarballs go? ftp/other or somewhere else? I don't think anyone's thought about this yet... Jason

3 2

[arch-dev-public] Moving forward [was: Cleanup/Orphans]
by Aaron Griffin 03 Oct '07

03 Oct '07

On 10/2/07, Andreas Radke <a.radke(a)arcor.de> wrote: > Hm. Your words are sounding more polite. True. > > But don't you get the same feeling that some of our developers lost > their interest/time in maintaining packages? Some were even hired to do > other jobs. Who else should do it? We had a decision to not give away > the packaging process to the community. So we have too do it our best. Oh yes, don't get me wrong, I agree with you. But I think _demanding_ the drive back is not the right way to do it. In fact, while you criticized me (us?) for it - I strongly feel that the thread discussing what we do in our free time is _critical_ to us moving forward. See. Here's the thing. This isn't a job. This is a hobby. And a lot of us have started treating it like a job. We're all serious and stoic. Acting like we _must_ do things this way, etc etc. That's not going to cut it. That's the fastest way to defeat if we're not getting any sort of compensation. The compensation is our enjoyment. We should be having fun here. This shouldn't be a chore. It needs to be rewarding. > I just don't want to fall back into the time when Jan, Tobias and me > were doing the majority of packaging almost alone again. And now we have > to take about two architectures. Let's spread it over all our shoulders. See now again, it's important to point out that everyone has other duties here. Writing code is just as time intensive as packaging. And in the end, it's beneficial to _you_ too. If someone improves our packaging tools, streamlines the process, it makes everyone's job easier. > Let's improve our infrastructure step by step but don't forget our > daily work of packaging. We have become famous for our good compromise > of bleading edge and quality. We should try to keep this alive. Everyone has daily work. But I need to emphasize something that I feel is overlooked - pacman, devtools, the web site, gerolde maintenance - these are all AS important. > One possible way it to force a dev to also maintain all dependencies > for his packages. But what about the rest? I actually like this idea, and I will use it to autoassign packages at the end of the week - if you maintain a package and one of the dependencies is an orphan, I'll assign that to you - it just makes sense that way. Thanks Andy!

3 3

[arch-dev-public] Social?
by Aaron Griffin 02 Oct '07

02 Oct '07

Ok ok.... let me preface this a tad. One of the things I think we've lost in arch, is a bit of the good ol' fun we used to have. Maybe it was just me having fun, but hey, I'm not the only one who got excited when skoal came back to the forums. So let's try and have some fun here, I'm sure we all have other things in common besides just Arch, right? This is the land of Web3.9 - there's no sense in me actually TELLING you guys what I like, because I can just paste links.... so here's some: music http://last.fm/user/phrakture movies http://www.netflix.com/Profile?prid=258042279 (sorry this one is most likely US only, as netflix probably doesn't ship overseas yet) random http://twitter.com/phrakture And you all got my previous text related (oops) spam, I'm sure. And there's much much more - for instance I own the entire set of Stargate SG1, Battlestar Galactica, Firefly, Farscape, and am closing in on the full set of Star Trek: TNG. So what about you all? A lot of us know very little about each other. So what do *YOU* do in your free time (besides the copious amounts of beer, heh)?

11 26

[arch-dev-public] pacbuild status
by Jason Chu 02 Oct '07

02 Oct '07

Ok, I missed sending this out last week. I really need to put more time into pacbuild. It has a todo list now of the things I think it needs to be used in production. It's in the git repo, but I'll repost it here. I'll explain some of the points better - Better logging in apple * There have been lots of requests for more logging in general. I'm trying to get the python logging module working with apple and strawberry. - Automatic chroot rebuilding (either triggered by apple or a "no update since" timer) * I wanted to see what Aaron's chroot building code looked like, it's possible I'd want to replace waka with it. - Unionfs * This is all in the chroot building as well. These days my package cache is so big and my free space is so small that unionfs will be the only way I can keep testing. * Simo has a patch or two that started adding unionfs but it needed more testing. Again, I'm waiting on Aaron's mkarchroot. - Dependency handling (know what packages other packages depend on) - Repo contents knowledge - Apple will have to know all the versions of all the packages in all the repos for all the architectures - New status -- inrepo - When a package moves from built to in the repo, we need to know its the one we can access and no others - New status -- depwait - When a package can't be built because another package isn't built yet * These are the meat of the delay. I need to change some of the architecture of pacbuild's db. I learned a lot reading about debian's dbuild. * I may even get rid of the multiple architectures in a single apple db decision. I originally put them all together because I wanted arches to be able to build the same packages, but I eventually realized that the apple daemon isn't the right place for that. - Update pacman python module (because the one with namcap currently sucks) * This one will be easy. I already rewrote the namcap pacman module, now I just have to use the new module when implementing the "Dependency handling" task. There's my pacbuild status. I'm trying to devote a handful of hours to arch development on saturdays when my girlfriend is studying, so I'm hoping to at least move forward on these things soon. Jason

1 0

[arch-dev-public] Problem with X?
by Jason Chu 01 Oct '07

01 Oct '07

I've got this weird problem that I think is caused by X. I've been following testing for a while now (so I have gnome, db, and heimdal). Every so often, and apparently randomly, X will stop taking any input except for mouse movement. But the mouse movement doesn't even trigger the focus follows mouse. The panel will still update and so will windows, but my input just totally doesn't work. The only thing that I can do to fix it seems to be sshing in and killing X. I run xfce4 so it might be the gnome/gtk updates that aren't working well with it... Has anyone heard anything about problems with X or is it just me? Jason

7 8

[arch-dev-public] Status Report 2007-10-01
by Aaron Griffin 01 Oct '07

01 Oct '07

Hey! Second status report. It's like some sort of milestone! I'm going to keep some of the short and long term tasks in here, until we check them off. ----------------- ArchLinux Status Report, 2007-10-01 == Newsworthy Items == * Some "interesting" front page news. http://archlinux.org/news/350/ It kinda *ahem* speaks for itself. * Damir completed his Master's program I just wanted to send out a public congratulations, here. I've always thought of Damir as "the biology student", but I guess I can't do that anymore. Hooray! == Completed Tasks == * db and heimdal rebuilds These so renames were moved to testing over the weekend. Thanks a lot Andy and anyone else who participated. Relevant forum thread: http://bbs.archlinux.org/viewtopic.php?id=37984 == Pending Tasks, Short Term == * New Round of Package Cleanup Let's try and get this "complete" this week. I'd like to get at least 2 or 3 of us together with Eric to go through these packages and start moving them to community or unsupported. We have an internal list for this here: https://www.archlinux.org/wiki/Repo%20Cleanup/ Please add candidates if you find them. Eric, when is a good time for you? * DVD and Additional Package ISO Lists Previous discussion has pushed us toward a solution, but we need to sit down and define what packages we explicitly want (or, rather, _don't_ want) on these images - that is, * Unified chroot build tools I failed here. Deadlines aren't my strong point. Time to redouble my efforts to get you all some fun chroot building tools! * Use vendor_perl for pacman perl packages We weren't able to get to this last week. If anyone has some free time, I'd appreciate you taking a look at this. If not, I will get to it myself closer to the end of the week. This is an easy bug to fix, it's just tedious. http://bugs.archlinux.org/task/8082 Any takers? Jan, you brought up concern over our perl policy earlier, are you up to the task? * Move all Arch related projects to gerolde Yet another ping here. We're still missing one or two projects which are important - archboot, some of our internal scripts, etc. http://bugs.archlinux.org/task/7789 * Next ISO Release Date We're currently at testing release 0.2 of our next iso. Please test it out, for all of those interested. Tobias, can you approximate a date of release for all of us interested? http://archlinux.org/pipermail/arch-dev-public/2007-September/001849.html * DB Script Rewrite Yup, this one still needs to be done. It's not critical, as we're in one of those not-broke-won't-fix stages. * Devtools updates See this thread: http://archlinux.org/pipermail/arch-dev-public/2007-September/001883.html There are a few complaints with devtools I want to address shortly. If you have any other pending issues, let me know, and I will see what I can do. == Pending Tasks, Long Term == * Pacman 3.1 Release We have a decent amount of issues to be closed in the 3.1 release. Please take a look and see if you have any input. http://bugs.archlinux.org/task/8109 Sadly, my time is (heh) fractured into many different things now, but one of these days Dan and I are gonna sit down and bang out a large chunk of these. * Official pacbuild usage Jason, could we get a "heads up" here - just some sort of direction for people who would be interested * 'Continuous Integration' setup / machine Since the last status report, I got two offers for hardware to run a CI machine, which is great. Volunteers always make us over on this side of the fence happy. Maybe when I get time to breathe, I'll bang out a prelim script... a man can dream, right? * Multiple Maintainers on the Dashboard * Multiple Architectures on the Dashboard Damir lumped these two together and called it "modernizing" our dashboard - which I like. I guess, what we really need, is more people with "their hands in the code". Any volunteers? Who wants to learn Django? * Architecture Independent Repos Relevant thread: http://archlinux.org/pipermail/arch-dev-public/2007-September/001829.html This was discussed and we all seem to agree that it is a good idea to maintain the packages which aren't specific to any one architecture in only one repo, rather than maintaining 2 packages. Still, this needs some coordinated changes to scripts and pacman and the like - fairly minor stuff, but perhaps we can sneak it in in the 3.1 pacman release. * ArchCon 2009: Big Baaad Idea Yep, I'm still riding this one. A big ol' ArchCon would be fun. We're all in totally different parts of the world, so we never get to see each other. http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html == Bugs and Issues == * X input lockups This relates to the Xorg in testing, and may be XFCE related, but it appears important enough to mention here: http://archlinux.org/pipermail/arch-dev-public/2007-October/001899.html ----------------- So there we go. Status report numero dos down. Lots of this is copied from the last one, and see, that's on purpose. This list will keep growing and growing until we start closing out some of these issues. Thanks for your continued work, guys. -- Aaron

1 0

Re: [arch-dev-public] [arch-commits] CVS update of extra/devel/slang (PKGBUILD)
by Dan McGee 01 Oct '07

01 Oct '07

I think the options=(!makeflags) would work for this... -Dan On 10/1/07, andyrtr(a)archlinux.org <andyrtr(a)archlinux.org> wrote: > Date: Monday, October 1, 2007 @ 14:51:02 > Author: andyrtr > Path: /home/cvs-extra/extra/devel/slang > > Modified: PKGBUILD (1.15 -> 1.16) > > fixed smp build > > > ----------+ > PKGBUILD | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > > Index: extra/devel/slang/PKGBUILD > diff -u extra/devel/slang/PKGBUILD:1.15 extra/devel/slang/PKGBUILD:1.16 > --- extra/devel/slang/PKGBUILD:1.15 Sat Sep 29 04:26:02 2007 > +++ extra/devel/slang/PKGBUILD Mon Oct 1 14:51:02 2007 > @@ -1,4 +1,4 @@ > -# $Id: PKGBUILD,v 1.15 2007/09/29 08:26:02 juergen Exp $ > +# $Id: PKGBUILD,v 1.16 2007/10/01 18:51:02 andyrtr Exp $ > # Contributor: Tom Newsom <Jeepster(a)gmx.co.uk> > # Maintainer: Juergen Hoetzel <juergen(a)archlinux.org> > > @@ -17,5 +17,5 @@ > # patch -p1 -i $startdir/src/$pkgname-2.0.6-makefile.patch || return 1 > ./configure --prefix=/usr > make || return 1 > - make install DESTDIR=$startdir/pkg/ > + make -j1 install DESTDIR=$startdir/pkg/ > } > > _______________________________________________ > arch-commits mailing list > arch-commits(a)archlinux.org > http://archlinux.org/mailman/listinfo/arch-commits >

2 1

Re: [arch-dev-public] Arch mirrors
by eliott 01 Oct '07

01 Oct '07

There is a FS ticket for part of this thread: http://bugs.archlinux.org/task/7006 I support changing the link on the downloads page to reference the wiki. This would, however, allow end users to modify the mirror page thus changing the mirror list in a way that may be seen as more 'official'. We could perhaps lock the mirrors page, but that semi-defeats the purpose of the change control suggestion. Any thoughts or feedback of a high caliber?

5 10

[arch-dev-public] Fwd: Arch mirrors (discuss)
by Roman Kyrylych 01 Oct '07

01 Oct '07

---------- Forwarded message ---------- From: Vinay Shastry <vinayshastry(a)gmail.com> Date: 1 Жов 2007 09:03 Subject: Fwd: [arch-dev-public] Arch mirrors (discuss) To: roman.kyrylych(a)gmail.com ehm... i forgot that the ml is not open for the general public to jump in :P ---------- Forwarded message ---------- From: Vinay Shastry <vinayshastry(a)gmail.com> Date: Oct 1, 2007 11:29 AM Subject: Re: [arch-dev-public] Arch mirrors (discuss) To: Public mailing list for ArchLinux development <arch-dev-public(a)archlinux.org> > Well, I think official mirror list can be kept on our download page > (almost all official mirrors have iso dirs anyway, those who don't - > deserve removal :-P). > It can be a table with the following row format: > > mirror | FTP | HTTP | rsync | country > ------------------------------------------------ > mirror.domain.org | + | + | + | Country1 > mir1.domain2.com | + | - | - | Country2 > > where mirror name should be a URL to the FTP (or HTTP if FTP does not exist) > and those "+" (or some nice checkmark images) should be URLs of > respective protocol. > > And put a link to 'Unofficial mirrors' section on wiki page. > > This way official mirrorlist will be clean and could be changed only by devs. Won't it be nice if the mirror list is organised according to Continent/Country.. perhaps something like http://en.opensuse.org/Mirrors_Released_Version ? -- Vinay S Shastry http://vinayshastry.blogspot.com/ -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] Arch mirrors (discuss)
by eliott 29 Sep '07

29 Sep '07

Ok. Starting a new thread for some discussion. Roman did great work generating an up to date mirror list. I changed the "get arch" page to a layout more conducive to "new users". In doing so, I realized that the focus of that page is for downloading ISOs (eg. Getting arch). I think I am going to change the layout a bit, and link directly to the /iso/ folder on the mirrors listed. I am going to incorporate the changes roman made, regarding mirrors, and only include those that offer isos *in that page*. This leads me to an interesting suggestion. Should be create a page with an more official list of mirrors, and list only teir1 mirrrors (those that we allow rysnc from on gerolde)? We can list the top level http, ftp, and rsync locations for those servers (if they have them). We can then link to the Wiki for "teir2" mirrors. Those that we do not allow direct sync from gerolde, but are viable alternatives nonetheless. Maybe those servers sync from one of the teir1 servers. This should allow us to keep a handle on the teir1 servers, and whom we allow to sync against gerolde, as well as provide a mechanism for the community to manage the list of teir{n} servers more effectively. Not sure how the tie-in to pacman's mirror list is going to handle this, insofar as teir1..n mirrors. Thoughts?

3 5

[arch-dev-public] Additional Package ISOs
by Aaron Griffin 29 Sep '07

29 Sep '07

Continuing a discussion from earlier, on into a fresh thread. We need a plan for the additional ISOs. To reiterate what's going on here: There are a handful of users who would like to have a giant iso of packages to aid in installing on boxes with slower networks (for instance, they could download and burn the ISOs from school). So, I've seen a few ideas, and Thomas seems to have the best grasp on what is slated. Here's what I'd like to see: * A small script which constructs a repo from a list of packages, then runs mkisofs on it. This would allow users to very easily create a CD or DVD full of packages THEY want. * One or two officially built ISOs (CD? DVD?) using the above tool, with some nice utilities and tools, etc. * Perhaps a combination of the two, and a bootable "OMGHUGE" DVD. Opinions, what do you guys think? I haven't really heard much comment on this topic so far. Thanks in advance, Aaron

6 23

[arch-dev-public] Architecture Independent Packages
by Aaron Griffin 28 Sep '07

28 Sep '07

This was brought up in a previous thread started by Damir, regarding committing a package to more than one repo at a time. I think it'd be more beneficial for us to split of architecture independent packages, just to eliminate redundancy. Python modules, scripts, etc they'd all fit here. Does anyone have an opinion on the matter? I think adding a arch=(none) or arch=(all) setup would be a good idea, BUT there might be a lot of other things that need to be changed. For instance, pacman doesn't handle this case right now, we'd need code in there, etc Please discuss, I haven't put much thought into it. Thanks, Aaron

9 19

[arch-dev-public] Upcoming Rebuilds
by Andreas Radke 28 Sep '07

28 Sep '07

pending updates that force us to another major rebuild session due to a so bump are: heimdal - 15-20 (no old todo list so far) db - 30-40 rebuilds (old todo list is broken after repo shuffle in django) i have a major cups and ghostscript update pending. new cups depends on heimdal. other updates that _might_ have so bumps or forces us to rebuilds: - icu (means OOo) - libgphoto2 - flac a few other important updates are also pending: hplip, eclipse and some more. afaik Xorg and Gnome in testing shouldn't be a big problem. they shouldn't hold us back to start the db/heimdal bumps. we should just decide on which architecture we will go in front with the bumps. i vote for x86_64. 64bit devs can also do some i686 rebuilds if needed. if we find useless packages while rebuilding we should do a minor pkg cleanup. anything that holds us back? Andy

4 5

[arch-dev-public] fglrx-utils preferred over libgl-dri
by Alexander Baldeck 27 Sep '07

27 Sep '07

Hey all, I was just about to upgrade oxine and it used to only depend on xine-lib. xine-lib pulls a great deal of xorg stuff but then one strange thing happened. pacman felt like fglrx-utils would be the right package to pull to fulfill the requirement of 'libgl' on the system. Now I would like to not have that, what would happen if I were to go and change pkgname of libgl-dri to just libgl since Jan dropped libgl-mesa long ago? Pacman should prefer the real pkgname over provides, right? Cheers, -J

2 1

[arch-dev-public] Test Isos 2007.09-0.2 with core repository and 64MB RAM image
by Tobias Powalowski 27 Sep '07

27 Sep '07

Hi here the changelog: i changed everything to fit to new core repository, 2 isos left ftp iso and core iso, the rest was setup/archboot changes to achieve this. - I cleaned up our documentation, to fit to those stuff please read it and tell me what is missing or wrong. GENERAL: - disabled arch_addons hook by default, it is triggered by arch-addons boot parameter - Ram usage increased to 160MB (FTP-ISO,CORE-ISO arch boot image) - Ram usage 64 MB (CORE-ISO lowmem boot image) FIXES: - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - fixed km to not show broken chars after exit NEW STUFF: - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - added hosts.deny and hosts.allow to config dialog - added licenses to install environment - added new lowmem boot image to core iso stripped everything out that is not necessary for installation TODO: - update archboot on cvs - update documentation for lowmem image you can download i686 Isos here: http://www.archlinux.org/~tpowa/rc-iso/686 you can download x86_64 Isos here: http://www.archlinux.org/~tpowa/rc-iso/x86_64 have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] testing status announcements table
by Damir Perisa 25 Sep '07

25 Sep '07

hi devs, i just feel like bringing up an old idea about testing... we announce the happenings, which happen in testing in the news, in the mailinglists and maybe elsewhere (forums?). however, sometimes we do not know how long things need to reside there... and the overview is even sometimes for a dev lost, what is happening in testing. what i suggest is to maintain a small table... like the todo-table, but that is public. it should have the following contents: * name of task / name of single pkg * brief description about task / brief description on reason why pkg is in testing * possible effects * link to task in bugs.archlinux.org * date of entry in testing * condition of finishing testing (moving thigs out of testing) ** eventually deadline of testing / date for finishing the testing (if no reports come in) * responsible dev this would look like the following at the moment: * X.org 1.4.0 release * major upstream change in packages * impact on various xorg pkgs, breaking of drivers (wacom, ...), incompatibilities, instabilities (nvidia, ati), new drivers (video-intel) * 1234 (i do not remember the number, but there is one; i remember asking for one and that one was made *smile*) * 2007-08-xx * reported issues solved * Andreas * R 2.5.1-2 paths cleanup * path cleanup in the extra/science/r pkgs * possible impact on self-made CRAN pkgs * no bug associated (yet) * 2007-09-24 * 2007-10-07 - no issues * Damir ... this would help keeping an overview about the status of things in testing... we can even announce in advance a planned testing event. thoughts? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

2 3

[arch-dev-public] Status Report 24-09-2007
by Aaron Griffin 25 Sep '07

25 Sep '07

Hey all, One of the things I plan on doing, for myself and for all of us, is sending out a little "what's going on in devland" status report ever Monday. So here's the very first one! Please, if you can, split off any discussion to other threads, and only use this one for missed milestones that I may have forgotten. So without further ado: ----------------- ArchLinux Status Report, 24-09-2007 == Completed Tasks == * PHP Modularization Pierre completed a rehash of our php package, making it smaller, more agile, and modular. The full details can be found in another thread on the private list. Pierre, would you mind pushing the details somewhere so the public can see? * Move to [core] Repo I want to send a special "Thanks" out to everyone who participated in this. It was a long time coming, and it definitely gives us more of an idea of what's going on overall. So thanks guys, you all deserve it! * ISO Naming Scheme decision We will be using YYYY.MM-REL for ISO versioning, where REL is the release number of this ISO. For internal and testing ISOs, we will use the point release scheme popularized by the x86_64 architecture. For instance, 2007.12-1.5 is the 5th internal/testing release. To prevent complication, we will start with release 0 for these testing releases, so 0.1 should be the first internal release * GNOME 2.20 in [testing] If you are a GNOME user please take the time to test this, and let Jan know if there are any issues - please put them in the bug tracker. * X.org 7.3 in [testing] This release will probably need a lot of testing, especially with nvidia and fglrx drivers. Please test if you can. == Pending Tasks, Short Term == * New Round of Package Cleanup Eric will be leading the charge here. This will mostly be internal to the developers as we will get rid of packages that are not compatible between architectures and packages which no longer build or are just broken. * DVD and Additional Package ISOs We need to decide on what exactly we're shipping on these "extra" iso images. Thomas seems to have the idea mostly in hand, so I'd like him to lead the discussion here (if that's ok with you) * Unified chroot build tools I am in the process of creating a script to aid us all in building packages in a clean chroot. We should all be doing this whenever possible. I told you all I'd get this out by this weekend, but I failed. Sorry. I will spend tonight getting this prepped. Again, I apologize. * Use vendor_perl for pacman perl packages This is an easy bug to fix, it's just tedious. http://bugs.archlinux.org/task/8082 If someone has the time, I'd like to see this accomplished sometime this week. Any volunteers? * Move all Arch related projects to gerolde This is just a reminder - mainly to myself and Jason, and maybe Paul. We'd like to get all Arch oriented projects in a common location so we can all work on them and users can peek at things to see if they could contribute at all. http://bugs.archlinux.org/task/7789 * Next ISO Release Date I'd like to remain in the loop here. Could anyone project the next kernel release date and how long the ISO will take from the time of release? I'd like to start with (see above) a -0.1 release for internal and testing stuff, and give that a few days, then release a -1 version. * Upcoming Rebuilds Andy mentioned some incoming rebuilds for some libs and things like db. Is there any word on the schedule for these releases? Andy, could you fill us in? * DB Script Rewrite Our DB scripts are kinda messy and are in a serious need of a rewrite. Thomas and I have planned to sit down and fix these things, but if anyone else is interested, I'd like to start planning a "sprint", if you will, shortly. * Orphan Packages This is another one Andy brought up. We have A LOT of orphan packages. We need someone to evaluate all of these orphans, to see if we should 1) still support them or move them "down" to community/unsupported 2) get someone to maintain them. Seeing as Andy is concerned with this, could you take the reins here? Collaborating with Eric on the package cleanup is probably a good thing too. == Pending Tasks, Long Term == * Pacman 3.1 Release Dan and I are going to be working towards a 3.1 pacman release. Please attach bugs you feel are critical to this here: http://bugs.archlinux.org/task/8109 Dan and I will sort it out. * Official pacbuild usage This is Jason's boat. I'd like to get him some help here. The more hands we can get in pacbuild, the faster we can start using it. * 'Continuous Integration' setup / machine This is a pipedream of mine. I'd like to setup a CI server somewhere. For those unfamiliar with the term, what this means is that the server will, periodically, check out our PKGBUILDs and try to build ever single package. Clean chroots don't matter, what we're checking is whether it will build as the instructions say. I guess a pacbuild instance COULD be used here, but this should be a simple bash script. If anyone wants to do something fun, feel free to jump on this one, but otherwise it's not important. * Multiple Maintainers on the Dashboard Yeah yeah this has been around for a while. We need to hack at our django code, so we can have multiple maintainers per package. Right now Eliott and Simo are the only ones with their hands in this code. If anyone else has the desire to jump into this code, please help out with this. It's something we are in dire need of. * Multiple Architectures on the Dashboard This is the same as above, BUT we need support for packages in all architectures, AND the ability to assign different maintainers to each architecture (not all of us can build for more than one arch). * ArchCon 2009: Big Baaad Idea So Tom K started this one, and, well, let's just throw it out there. http://archlinux.org/pipermail/arch-dev-public/2007-September/001614.html The tentative idea, which might be just a pipedream, is to get all the devs and users, or as many as possible, together for a big-ol' meet up. Let's see how this pans out. ----------- Well, there it goes. Monday status report for Arch devland. I threw a few questions in there, feel free to use this thread for that, but lets not pollute things with long-winded discussion - break those off and help make our mail clients happy. Thanks for all your hard work guys, Aaron

4 12

[arch-dev-public] Integrity check in devtools
by Thomas Bächler 25 Sep '07

25 Sep '07

This is a little patch to check the integrity of the uploaded file after uploading it. It will avoid problems like the ones with kernel26 or openoffice-base recently. I don't have time to build new devtools packages now, so I'll do it later if nobody has done it already. You can however apply the patch to your local extrapkg and test it. --- extrapkg 2007-09-25 20:45:17.000000000 +0200 +++ /mnt/arch32/usr/bin/extrapkg 2007-09-19 21:37:52.000000000 +0200 @@ -46,6 +46,12 @@ if [ "$repo" != "community" ]; then scp $pkgfile archlinux.org:staging/$repo/add + if [ "$(md5sum $pkgfile | cut -d' ' -f1)" != "$(ssh archlinux.org md5sum staging/${repo}/add/$pkgfile | cut -d' ' -f1)" ]; then + echo "File got corrupted during upload, cancelled." + exit 1 + else + echo "File integrity okay." + fi else if [ ! -f ~/.tupkg ]; then echo "Must configure tupkg via ~/.tupkg, cancelled"

1 0

[arch-dev-public] moving php-suhopsin to [extra]
by Pierre Schmitz 25 Sep '07

25 Sep '07

Hi all, I am about to move the new php package to testing soon. (I will talk about this later) I would like to move the suhosin extension, which I currently maintain in [community], to [extra]. Everybody who wants to use php on a server should use this extension. Moving this to [extra] should underline this security aspect. What do you think about this? Any complaints? :-) Pierre -- archlinux.de

4 5

[arch-dev-public] commiting arch-independend pkgs to both repos at the same time
by Damir Perisa 25 Sep '07

25 Sep '07

weird idea, but i'm putting it here anyway: some pkgs are arch-independend (e.g. fonts). they can actually be built and commited to i686 and x86_64 at the same time, since the bindiff of the pkg is nonexistant. any chance to have this in devtools implemented? or generally asked: do you like the idea? the main advantage is, that this pkgs need to be uploaded only once (and then just copied to the other staging dir) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

4 5

[arch-dev-public] X.org 7.3 about to hit Testing
by Alexander Baldeck 25 Sep '07

25 Sep '07

Hey all, I've had several discussions with devs and users about X.org 7.3 and the question why it was not yet pushed to testing. My reasons were the ABI changes that rendered nvidia drivers unusable and I had no reports on fglrx so far. Now that nvidia released version 100.14.19 the -ignoreABI workaround is not necessary anymore. The legacy drivers have not yet been updated though and still no definite reports on fglrx. I would very much like to push 7.3 to testing still, as it would save a great deal of work since I would only have to maintain one version of it. What are your thoughts? Cheers, -F

5 13

[arch-dev-public] Test Isos with core repository
by Tobias Powalowski 24 Sep '07

24 Sep '07

Hi here the changelog: i changed everything to fit to new core repository, 2 isos left ftp iso and core iso, the rest was setup/archboot changes to achieve this. - I cleaned up our documentation, to fit to those stuff please read it and tell me what is missing or wrong. - fixed the nasty /dev mount bug - fixed the /dev/ttyS0 errors if no serial port is installed in the system - fixed repositories in install environment to fit to both architectures - added pptpclient to install environment - added sdparm to install environment - added all free wireless drivers to install environment - added intel wireless drivers to install environment which will be activated by intel-wireless boot parameter - disabled arch_addons hook by default, it is triggered by arch-addons boot parameter - Ram usage increased to 160MB - added hosts.deny and hosts.allow to config dialog - added licenses to install environment - fixed km to not show broken chars after exit you can download i686 Isos here: http://www.archlinux.org/~tpowa/rc-iso/686 you can download x86_64 Isos here: http://www.archlinux.org/~tpowa/rc-iso/x86_64 have fun in testing and report issues immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 8

[arch-dev-public] save some kb - ln ;)
by Damir Perisa 24 Sep '07

24 Sep '07

kde stores some licences under /opt/kde/share/apps/LICENSES/ and as we have this same licences already in arch (/usr/share/licenses/), what about replacing them in the kde pkg with links to the ones in our system? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

4 7

[arch-dev-public] Questions about quickinst
by Jason Chu 24 Sep '07

24 Sep '07

Maybe I missed the discussion on this one... I was trying to work on pacbuild but quickinst doesn't work for me. If I'm not mistaken, we should have a setup directory in core/os/i686, right? Is there a reason why we don't? Is this all we need to convert over to the new repo layout? Jason

4 5

[arch-dev-public] GNOME updates to testing
by Jan de Groot 24 Sep '07

24 Sep '07

Hi All, I'm preparing GNOME 2.20 for testing, which should be done by upcoming sunday. I'm not rushing anything: I'm evaluating package quality of every individual package (namcap, checkpkg), checking upstream SVN for post-release patches that should be included, etc. At this moment I have most of GNOME 2.20 platform in my staging dir on gerolde, the PKGBUILDs and patches have been committed to CVS. I haven't seen many issues with this release, most problems are tackled in the GNOME 2.19 repository already, some other known bugs are waiting for simple fixes which are known on the forums and our bugtracker. I think this release will sit in testing for one or maybe two weeks, nothing more. During this period I expect some rebuilds for applications that link to API/ABI unstable libraries in the GNOME desktop suite (totem-plparser has a sobump, probably libgtop and libwnck also, have to checkpkg for all the details of this). I'll keep everyone updated on the status of this.

3 5

[arch-dev-public] Which Way Forward For Package Maintainance [was: next major steps have to be planned]
by Aaron Griffin 23 Sep '07

23 Sep '07

aaron.proxy_mail(); Essien had some points to say on this topic, so I figured it was a good time to break this point out into a separate thread too. Here goes: ---------- Forwarded message ---------- From: Essien Ita Essien <me(a)essienitaessien.com> You know, we really need to have properly defined seperate dev teams, this main is going to focus on just one of them teams, but in a later mail i'll elaborate my ideas further. Paul Mattal wrote: >> <snip> >> 3) This has historically be a problem forever - unmaintained packages. >> Some of us do a lot of development work (Dan, Eliott, etc) and don't >> have huge amounts of time to help out with 200 packages at once. But >> we do need a way to stabilize this load a little better. >> Andy, you seem to know our current package set better than anyone. >> Could you possibly keep on bringing this up to people - in an attempt >> to push the load around just a little bit. >> By this, I mean, if we have a person with 10 packages (not people >> doing heavy development work) and others with 300, we should do >> something about that - you seem the best person for this job. > > I remain convinced that the way to tackle this problem is to allow > more than one maintainer per package. If groups of people are > responsible for a package, people will feel more empowered to work > on packages that aren't "theirs" and will know who to coordinate > with to do so. I agree with Paul here, but I even go futher and *formalize* the problem scope. The problem like I see it is that you *need* to be an *archlinux-developer* to be allowed to maintain packages in core and extra. I guess this is just to guarantee quality of packages but i think there are other ways of guaranteeing package quality and at the same time allowing the current strict definition of arch developers to be the only ones responsible for package maintainance. I want to propose the following approach. 1. The package management team should be properly defined out of the rest of the *blessed* archlinux development team. 2. Every member of this team will be a package Maintainer (even if you maintain just one package, you are a maintainer). But not every member of this team will be able to *commit* to the official repositories. 3. There will be some members of the team called _sponsors_ who will be the only ppl able to commit to the actual repositories and will also act as the QA guards to ensure proper quality of packages. 4. The other maintainers will have to go thru the sponsors to get their packages accepted or updated, and a sponsor can decide to desponsor a package for various reasons (like inactive maintainance by a maintainer or a maintainers non-response to bug reports). The thing is we already have this kind of setup:- namely the community/aur system. I think we _need_ to admit to ourselves that the communit/aur repo works properly, but we need to somehow co-opt that system now that our workload is growing. I propose that: 1. first... all *orphaned packages* from extra, core, community, aur, etc, should be moved into an [unmaintained] repository and just be done with it. 2. Then we should extend official status to community. (adding it to pacman repo files) 3. Then we should slowly start setting up the sponsor/maintainer infrastructure, with all TUs automatically becoming sponsors in the new dispensation along with current developers who want to continue with package maintainance tasks as opposed to other development tasks (ISO building, etc). 4. The new sponsors should go around and for packages that list them as Maintainers but have seperate Contributors, invite those contributors to become Maintainers. 5. Draw up guidelines for the operation of the sponsor/maintainer relationship. I'll be willing to help in any documentation that will be needed if this is to be done. 6. Encourage ppl that are maintaining packages on AUR to apply for package sponsorship for their packages and let the rest happen from there. > > I know I personally would sign up as a maintainer for more packages > if I weren't the "only one" taking them on but rather part of a team > maintaining those packages. I think the system i describe above is more efficient than staying tied to just a small team doing all the work. cheers, Essien

3 2

[arch-dev-public] Additional Package ISOs [was Xorg in extra]
by Aaron Griffin 22 Sep '07

22 Sep '07

On 9/20/07, JJDaNiMoTh <jjdanimoth(a)gmail.com> wrote: > I know that this isn't the right place, but I try. > What about people without a DSL connection? > They can download core isos ( that are more frequently released ) from university or > at work, it's right.. but how they can download all the packages in /extra? > Have we a plain for these situation (like a iso with-all, using a dvd)? > > Excuse me if this was recently discussed. Links are appreciated :D This was discussed, but it wasn't covered in a public manner all that well. The rough plan, at this point, would be to create *additional* ISOs with sets of packages. This was suggested around the proverbial water cooler, but was never really laid out all that well. Here's what I see, and I will bring this up with the rest of the developers, to see what they think, but I do agree it is something we didn't fully address before doing this. I personally feel we could make one or two addon disks which JUST have packages for people to download. Or, alternatively, throw some scripts out there so people can make a package iso simply... or hell, even both. What do the rest of the devs think?

4 3

[arch-dev-public] nfs init script changes
by Tom K 21 Sep '07

21 Sep '07

Ever since http://bugs.archlinux.org/task/7368 was raised, back in the summer, I've intended to do this, but life has been less than cooperative. Now that we have the new nfs-utils/util-linux-ng setup in place, it seems like a good time to address it, finally. The nfs-utils tarball includes this README: http://www.linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-utils;a=blob_plain;h=e219… which details the preferred daemon startup order for both server and client. There are significant differences between the order described there and our current nfs scripts, notably the omission of the /proc/fs/nfsd mount and the sm-notify command. I have edited the main /etc/rc.d/nfsd script accordingly, and I have also made changes to /etc/rc.d/nfslock and /etc/conf.d/nfs as required. I'd like to acknowledge shazeal's contribution, posted in the above-mentioned bug report, and also the 'inspiration' provided by the equivalent Gentoo scripts. ;) The end result works fine here, on my server-&-3-clients setup - mounted shares are retained/remounted over both server and client reboots. I'm inclined to put it straight into core, but being naturally cautious, I'm opting instead for a 'cooling-off' period, during which any peer who feels like doing some reviewing is more than welcome. The package is here: http://www.archlinux.org/~tom/packages/nfs-utils-1.1.0-2-i686.pkg.tar.gz and the build files are here: http://www.archlinux.org/~tom/packages/nfs-utils/ Unless there are valid objections, I'll put this up in 24 hours, accompanied by appropriate changes to the NFS wiki page. And just so it's clear - as with the current scripts, these ones handle nfsv2/3 only. Once this is in, I intend to look at nfsv4. Happy Friday T.

2 1

[arch-dev-public] Idea: ArchLinux News
by Paul Mattal 21 Sep '07

21 Sep '07

I know we are all inundated with sources of Arch Linux news and have tried various blogs and ideas that haven't worked well in the past, but I had a new twist on this idea. What if we set up a CMS allowing anyone to submit articles, and then assembled a small group of moderators with community track record and good language/editing skills who would triage/read/edit the articles/posts? This would create a more meaty way to generate interesting thought in the Arch community, and provide a more serious "publication" about Arch without extreme amounts of effort. If we used software optimized for this (there must be many choices), then approving posts and doing minor edits would be little work for the moderators. I'm imagining something like a Slashdot model for post/moderation but with more meaty new ideas and news by the poster. Essentially this would be a way to get your interesting material read and heard by the Arch world, regardless of how long you've been here or what positions you may have in the community. Content guidelines I would suggest: * should be related to Arch Linux and be of general interest to someone interested in Arch and the community * posts should provide some new information and reflect some new thoughts by the writer; these are intended to be "articles" that will enrich the community, and we want more than just a link to another post or an open-ended discussion-starter question * should be well-written and require as little editing as possible; the closer the submission is to press-ready, the less work the moderators will need to do and the more likely your post is to be accepted * submitted posts become openly licensed and are subject to editing by the moderators If such a system could be set up, I'd be willing to moderate regularly, and post occasionally. I could see this also as replacing the "news" on the main page, but also enriching it significantly. The nice part is that it would provide one single place people can go for their important Arch news. Of course, people are always free to look elsewhere-- but we'd guarantee a high-quality product with interesting news you'd want to read. What do folks think? Anyone have experience with using a CMS in this manner where anyone can create posts and moderators edit/approve/post them? Are there refinements of this idea that would work better? - P

4 5

[arch-dev-public] Next package cleanup [was next major steps have to be planned]
by Aaron Griffin 21 Sep '07

21 Sep '07

On 9/20/07, Eric Belanger <belanger(a)astro.umontreal.ca> wrote: > > > 4) So we need to revisit, once again, the package cleanup that I had > > started months ago. Eric, you were helpful last time - would you be ok > > with figuring out the details of another round of cleanup? > > Sure. I already have a few names in my mind because a while ago I tried > porting packages to x86_64 and came across several ones where the sources > were missing or that were dead projects. I'll also check again the wiki > list and the orphaned packages in the repo. > > Before removing anything, I'll post the list of candidates for removal > here with a short reason for the removal to inform you and give an > occasion to contest the removal of a package. Great, thanks a lot! The last time, we had a lot of success with a public wiki and getting the userbase involved. Do you think that's still appropriate until we winnow the packages to a more concrete set? Or should we stick to internal at this time and get rid of packages with incompatibilities and the like? -- Aaron

3 2

[arch-dev-public] core error/conflicts found
by Tobias Powalowski 20 Sep '07

20 Sep '07

Hi while testing the new ISO i found that the ralink fw packages provide the same LICENSE file, im gone the whole day so if someone could fix it would be cool. make is also missing from /devel or packages.txt was again broken, please take a look at it. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 5

[arch-dev-public] next major steps have to be planned
by Andreas Radke 20 Sep '07

20 Sep '07

The repo shuffle is almost done. Next big tasks are pending. So i want to discuss with you the order for the next steps and how much time we need to finish remaining tasks. 1) Xorg is in testing for months. should we move it knowing some things will be broken. Should it stay in testing for some more time. Give up the bump and delay the upgrade? It's not good to have such a big player in testing for so long. I'm not sure if any other pkg we want to build in testing will link against it and might make trouble later moving it to extra. 2) Pending big updates: db, heimdal, cups 1.3.x together with gpl ghostscript. You all know how long the list of rebuilds will become... 3) We need to make sure all packages in core/extra have at least one active(!) maintainer(not talking about wanted package divisions). Right now we have 550(before core move)-700(now) orphaned packages. Even 112 orphaned core packages after the move. This is not acceptable! Also some maintained packages keep waiting for updates for too long. 4) This brings us to the real repo cleanup. We had a Wiki side collecting ideas for removal and somebody was talking about an improved ArchStats. Both can help us. We should also leave the way how we choose packages we bring into the repo from "hey, I like it so I bring it in" to the needs of our users/community. 5) Move to another version control system. Was it a common decision to move to svn? Then we should prepare the move well not to far away. 6) Setup a standard build tool for all devs: force everyone to make use of a unionfs based devtool. 7) State of repoman? I don't want to hurry from one chaos to the next one. But I also don't want to see us again falling back and watch several months passing. Andy

4 3

[arch-dev-public] firefox 2.0.0.7 package
by Thomas Bächler 20 Sep '07

20 Sep '07

I am in rant mood again. namcap exists and I think whoever rebuilt firefox has read http://archlinux.org/pipermail/arch-dev-public/2007-September/001644.html Yet, firefox still depends on gcc instead of gcc-libs. The goal is to get rid of the gcc dependency, so when a big package is rebuilt, it is a good idea to check if such changes should be applied, as nobody will rebuild them "just for fun". We have been encouraged by Aaron to communicate more, and I think we did in the last couple of days, but this doesn't mean anything if we just ignore what we read.

4 3

[arch-dev-public] 'base' and 'base-devel' group
by Thomas Bächler 20 Sep '07

20 Sep '07

I am CC'ing this to the tur-users mailing list for reference, as the following applies to official repositories, as well as the community repository: I am planning to add all packages in core/base to the 'base' group and all packages in core/devel to the 'base-devel' group. The first allows quick installations in different roots with 'pacman -S base', the second will install a complete build environment for makepkg. This has been partially done already, but should be completed. In the next few days, all packages in core/base and core/devel will be rebuilt. This rebuild comes with a rule: No package outside of the 'core' repository may have group membership in 'base' or 'base-devel'. Thank you and good night Thomas

13 29

[arch-dev-public] ISO Bug Release naming scheme
by Aaron Griffin 20 Sep '07

20 Sep '07

Hey all, This is something that was never really discussed outright, so it's time to bring it up. Wel all agreed on a YYYY.MM naming scheme for our isos, but tacking on a release number (for bug fixes) makes it look like a day (in date format). Assuming we won't have bug releases is short sighted, so I think we should discuss a proper format for this, as it was never covered. Personally, I like: YYYY.MM-RELEASE for _all_ release. So the next kernel release would be: 2007.10-1 Opinions? Thanks, Aaron

12 21

[arch-dev-public] New NVIDIA package 100.14.19 uploaded to testing
by Thomas Bächler 19 Sep '07

19 Sep '07

I just added nvidia and nvidia-utils 100.14.19 to testing. As I don't have all those kernels installed, I didn't take care of nvidia-ck, nvidia-suspend2 and nvidia-mm, could the respective maintainers please do that? This release has some awesome improvements: - Improved GLX_EXT_texture_from_pixmap out-of-memory handling. - Improved compatibility with recent X.Org X servers. - Fixed a problem causing X to render incorrectly after VT switches with composited desktops. - Improved compatibility with recent Linux 2.6 kernels. The first and third will improve beryl and compiz usage with nvidia drivers considerably, the second will hopefully allow us to run xorg-server 1.4 with nvidia.

3 2

[arch-dev-public] newest bash and bash-completion
by Travis Willard 18 Sep '07

18 Sep '07

Hey guys, Newest bash seems to kill bash-completion. I custom-wrote a patch and phrakture, toofishes, and I have all had a run at testing it (definitely not extensively). Basically the way it handles setting of read-only vars makes it blow up, and causes the remainder of our .bashrcs (after sourcing bash_completion) to not be executed. I've pushed a patched version of bash-completion to TESTING - if those of you using bash_completion could all make sure it's solid I'd appreciate it. :) Thanks! -- Travis

2 3

[arch-dev-public] kernel-headers missing in packages.txt
by Tobias Powalowski 17 Sep '07

17 Sep '07

Hi did you change something in the last weeks, that kernel-headers is no more listed in packages.txt? this will break all ftp installs, just stumbled over it while trying to create ISO's with the ntfs bug fixed. i can recreate ISO's on sunday so would be cool if someone could look at the packages.txt issue. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 13

[arch-dev-public] cvslog added to core repo
by Aaron Griffin 17 Sep '07

17 Sep '07

The core repo should now send us emails on the arch-commits list. If someone has something legitimate to commit, please test and let me know if it worked - I don't want to artificially inflate the repo. Aaron

1 0

[arch-dev-public] Devtools problems
by Dan McGee 17 Sep '07

17 Sep '07

dmcgee@dublin ~/projects/repos/core/base/pacman $ corepkg scp: staging/core/add: No such file or directory Cancelled dmcgee@dublin ~/projects/repos/core/base/pacman $ ll /usr/bin/*pkg -rwxr-xr-x 1 root root 1.6K 2007-09-16 07:48 /usr/bin/checkpkg lrwxrwxrwx 1 root root 17 2007-05-12 01:46 /usr/bin/communitypkg -> /usr/bin/extrapkg lrwxrwxrwx 1 root root 8 2007-09-16 07:48 /usr/bin/corepkg -> extrapkg -rwxr-xr-x 1 root root 1.9K 2007-09-16 07:48 /usr/bin/extrapkg lrwxrwxrwx 1 root root 11 2007-06-18 11:02 /usr/bin/ghc-pkg -> ghc-pkg-6.6 -rwxr-xr-x 1 root root 28K 2007-06-20 01:25 /usr/bin/makepkg -rwxr-xr-x 1 root root 4.3K 2007-05-14 23:48 /usr/bin/queuepkg lrwxrwxrwx 1 root root 8 2007-09-16 07:48 /usr/bin/testingpkg -> extrapkg -rwxr-xr-x 1 root root 4.3K 2007-09-16 17:33 /usr/bin/testpkg -rwxr-xr-x 1 root root 5.2K 2007-02-22 02:23 /usr/bin/tupkg lrwxrwxrwx 1 root root 8 2007-09-16 07:48 /usr/bin/unstablepkg -> extrapkg -rwxr-xr-x 1 root root 5.4K 2007-08-02 02:40 /usr/bin/versionpkg A few problems here: 1. Why did the behavior of corepkg/extrapkg and friends suddenly require a staging directory on my machine? This seems wrong. The old way was perfectly acceptable... 2. Why is communitypkg an absolute link and the rest are not? Right now, devtools is broken to me. Let me know if someone plans on fixing it or if I'm going to back out changes that seem wrong to me. Right now I can't upgrade a package if I wanted to (pacman 3.0.6 anyone?). -Dan

2 2

[arch-dev-public] Important changes for all users, developers and TUs
by Thomas Bächler 17 Sep '07

17 Sep '07

Hi lists, we made some changes to repositories and packages which I'd like to summarize here. 1) (everyone, including users): The current repository is gone. Instead, we have a slimmer core repository and the rest of the packages went to the extra repository. I won't discuss the reasons for that change here, but if necessary, I'd be happy to explain it in a later post. If any packages are missing, don't hesitate to post bug reports. A pacman update will add a /etc/pacman.d/core file and users should change all references in pacman.conf from current to core. We added symlinks for compatibility, so the name current should still work for a while. 2) (everyone, including users): The repository scripts on our server now support the pacman3 style package naming. Our repositories are now partially incompatible with pacman2, as it will fail to find some files. If you haven't updated to pacman3 yet, you can still manually download the libarchive, libdownload and pacman packages from the ftp and install them with pacman2. 3) (users) FTP installations are broken for now, maybe we will have time to fix them soon. Until then, use a base CD to install. 4) (developers and TUs) Related to 1) and 2), a new devtools package has been uploaded. Packages are not renamed any more when uploading. An exception to this is communitypkg, as the community scripts on the server haven't been updated to the pacman3 naming style yet. All devs are encouraged to use the new style names from now on. The currentpkg script is gone, instead there is a corepkg script now, as well as /arch/db-core{,64} on the server. 5) (developers and TUs) The gcc package has been split in gcc and gcc-libs. Packages must not depend on gcc anymore, all those packages should be changed to depend on gcc-libs. This allows us to use C++ applications without forcing users to have gcc installled. Please update your packages as soon as possible. 6) (developers) All former current packages are now in extra or core. We lost the mantainer data for those, so please adopt all packages that were previously yours. This also affects packages which were moved from extra to core. If I forgot anything, tell me. Keep having fun with Arch. Thomas

3 6

[arch-dev-public] moving OOo/neon stuff from testing to extra
by Andreas Radke 16 Sep '07

16 Sep '07

Daniel and me are preparing to move neon and new OpenOffice incl. i18n later tonight. these are big uploads. it will take a while until we can run the db scripts. btw: i've changed the OOo splash - but it's still showing our nice non Abiword logo! :D Andy

1 0

[arch-dev-public] New fglrx drivers - no official package.
by Travis Willard 16 Sep '07

16 Sep '07

Hey guys. AMD's released their new radeon drivers, which are a complete rewrite. Exciting times, however AMD warns that these might not be production ready. After a bit of thought, I've decided to keep the 8.40.4 drivers in the repos for now (especially since this new release doesn't add kernel 2.6.23 or xorg 7.3 support) but make a custom repo for the new drivers for those who want to experiment. In the spirit of not doing things unilaterally, I'm notifying you all here. If there's no objection, I'll be posting an advisory to the forums later (maybe tonight or tomorrow) that will say essentially the following: -8<---8<---8<---8<---8<---8<---8<---8<-- Hi everyone, Today, AMD's 8.41.7 fglrx drivers, which are a complete rewrite of their codebase which they have spent more than a year of work on, were released today. On their release notes page, they offer the following recommendation: [quote]Caution: AMD recommends that this release of the AMD Proprietary Linux software driver not be used for distribution packages. Distributors should continue to use the AMD Proprietary Linux driver version 8.40.4[/quote] After some thought, I've decided to take this warning to heart, and will not be packaging this version of the drivers 'officially'. HOWEVER, tonight or possibly tomorrow I will be making packages for these drivers and a custom repo to obtain them from if you wish to test them out - these will not be 'official' archlinux packages, however, and the 8.40.4 release will remain in the repos until AMD releases a new version which they feel is suitable for general use. I will update this advisory once the new packages are available, and hope you all understand my reasoning on this. -8<---8<---8<---8<---8<---8<---8<---8<-- Any thoughts or suggestions, just reply to this thread. :) Thanks, Travis

5 9

[arch-dev-public] Arch mirrors
by Roman Kyrylych 16 Sep '07

16 Sep '07

Hi! The mirrorlist on http://archlinux.org/download/ page is outdated. I suggest we just write something like 'You can also download ISOs via FTP/HTTP/rsync from /iso/ directory on <a href="http://wiki.archlinux.org/index.php/Mirrors">mirrors</a>' instead of incomplete and outdated mirrorlist. Also, installer's mirrors.txt file should be updated as well (minus those that don't sync isos from main server). -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] [core] progress
by Tobias Powalowski 15 Sep '07

15 Sep '07

Hi ok guys sum up what already done: [core] cvs partially setup ok base is moved in and divided into the categories according to this: https://www.archlinux.org/wiki/Core-Repository/ - packages from extra is still missing though - gcc splitup is pending - syslogng needs to be reviewed - the move to of the rest of current to cvs-extra2 is not done im tired now and going to bed, i'll continue on it tomorrow morning. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 12

[arch-dev-public] Repository cleanup [current] and [base] --> [core], this weekend!
by Tobias Powalowski 15 Sep '07

15 Sep '07

Hi it's quite a long time ago we had a dev meeting, but i think there were quite some agreement what [core] should be and we should start doing this soon. Our next ISOs shouldn't have the big current anymore only ftp and [core]. [non-free] repository we should add a non-free repository with stuff that is not freely distributable, like acroread, sun java, firmware files, flash etc. this cleanup would affect [extra] and [current] that way we could finally have cds of [extra] too without getting into trouble. As Romashka said, these are the types we need to look at: 1) those that are not possible to distribute due to prohibition of original package modification, but it does not work without modifications to installation procedure - like vmware 2) those that are not allowed to be redistributed by EULA - like commercial edition of virtualbox 3) those that are not allowed to be sold on a CD, but can be distributed over internet 4) those that are just not Free Software - it's nice to have them splitted if someone wants to have FOSS-only mirror/CD/etc 1+2 should be probably moved out of the official repositories, if not already done. 3+4 should be ok [core] repository should be like [base] + some extra stuff the question is: what is extra stuff? imho, it should be everything that is needed for networking free kernel network modules free wlan stuff all supported main filesystems suggestion list of packages to add: ndiswrapper ndiswrapper-utils wlan-ng26 rt2500 madwifi madwifi-utils fuse ntfs-3g iptables bcm43xx-fwcutter dosfsutils ntfsprogs kexec-tools snarf dnsutils hdparm bridge-utils ifenslave xinetd portmap nfsidmap nfs-utils openssh netkit-telnet screen isdn4k-utils capi4k-utils vpnc openvpn everything else from [current] should be moved to [extra]. your opinions, lets get something done this weekend. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

17 42

[arch-dev-public] IMPORTANT: Repo DB scripts hacked!
by Thomas Bächler 14 Sep '07

14 Sep '07

As rewriting the repo db scripts is a time intensive process which involves cleaning up the web backend too, I did a few hacks to our current scripts to support both the pacman2 and pacman3 naming scheme. I changed the updatesync-many, pkgdb1, db-inc and genpkglist files. Please everyone who is familiar with the scripts (and everyone else, because noone is actually familiar with them) look over my changes and see if they make sense. If no errors are found, the scripts WILL be moved from CVS to /arch and WILL be used. So make sure I didn't screw up. For the lazy, I attached the diff. Index: db-inc =================================================================== RCS file: /home/cvs-arch/arch/scripts/db-inc,v retrieving revision 1.6 diff -u -r1.6 db-inc --- db-inc 7 May 2006 18:02:42 -0000 1.6 +++ db-inc 14 Sep 2007 16:38:14 -0000 @@ -16,6 +16,18 @@ exit 1 fi +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + cleanup() { rm -rf $TMPDIR # unlock @@ -134,7 +146,7 @@ cd $stagedir/del ( for i in *.pkg.tar.gz; do - pkgname=${i%-*-*} + pkgname=$(getpkgname $i) echo $pkgname done ) | $ARCHDIR/pkgdb2-del $repoid $stagedir/del @@ -147,7 +159,7 @@ if [ "$updatelists" ]; then echo "==> Generating Text Package List..." >&2 cd $TMPDIR/$cvsmod - $ARCHDIR/genpkglist $ftppath + $ARCHDIR/genpkglist $ftppath $arch # hack -- only Current's packages.txt goes in a "setup" subdir if [ "$reponame" = "current" ]; then Index: genpkglist =================================================================== RCS file: /home/cvs-arch/arch/scripts/genpkglist,v retrieving revision 1.14 diff -u -r1.14 genpkglist --- genpkglist 5 May 2006 01:38:33 -0000 1.14 +++ genpkglist 14 Sep 2007 16:38:14 -0000 @@ -8,8 +8,21 @@ # (also used to check for missing packages in the download directory) # +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + pkgfile="`pwd`/packages.txt" ftppath=$1 +dbarch=$2 rm -f $pkgfile for category in `find * -maxdepth 0 -type d | grep -v CVS`; do @@ -20,8 +33,10 @@ . PKGBUILD if [ -f $ftppath/$pkgname-$pkgver-$pkgrel.pkg.tar.gz ]; then echo "$category/$pkgname-$pkgver-$pkgrel.pkg.tar.gz" >>$pkgfile + elif [ -f $ftppath/$pkgname-$pkgver-$pkgrel-$dbarch.pkg.tar.gz ]; then + echo "$category/$pkgname-$pkgver-$pkgrel-$dbarch.pkg.tar.gz" >>$pkgfile else - echo "notice: Missing $pkgname-$pkgver-$pkgrel.pkg.tar.gz in ftp site" >&2 + echo "notice: Missing $pkgname-$pkgver-$pkgrel-$dbarch.pkg.tar.gz in ftp site" >&2 fi fi cd .. @@ -32,7 +47,7 @@ cd $ftppath unset DUPES DUPEFILES last for pkg in *.pkg.tar.gz; do - pkgname=${pkg%-*-*} + pkgname=$(getpkgname $pkg) if [ "$last" = "$pkgname" ]; then DUPES="$DUPES $pkgname" DUPEFILES="$DUPEFILES $pkg" Index: pkgdb1 =================================================================== RCS file: /home/cvs-arch/arch/scripts/pkgdb1,v retrieving revision 1.4 diff -u -r1.4 pkgdb1 --- pkgdb1 20 Feb 2006 06:33:40 -0000 1.4 +++ pkgdb1 14 Sep 2007 16:38:14 -0000 @@ -1,6 +1,18 @@ #!/bin/bash # $Id: pkgdb1,v 1.4 2006/02/20 06:33:40 judd Exp $ +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + STAGEDIR=`pwd` ABSDIR=$1 @@ -16,9 +28,8 @@ cd $STAGEDIR for pkgfile in `ls $STAGEDIR/*.pkg.tar.gz`; do - tmp=${pkgfile##*/} - pkgname=${tmp%-*-*}; - fullname=${tmp%.pkg.tar.gz} + pkgname=$(getpkgname $pkgfile); + fullname=$(basename $pkgfile) # find the matching PKGBUILD tmpf=$(mktemp /tmp/pkgdb1.XXXXXXXXXX) || exit 1 find $ABSDIR -type d -name "$pkgname" >$tmpf Index: updatesync-many =================================================================== RCS file: /home/cvs-arch/arch/scripts/updatesync-many,v retrieving revision 1.2 diff -u -r1.2 updatesync-many --- updatesync-many 5 May 2006 01:38:33 -0000 1.2 +++ updatesync-many 14 Sep 2007 16:38:14 -0000 @@ -1,4 +1,5 @@ #!/bin/bash +# $Id: $ # # updatesync-many # @@ -46,6 +47,18 @@ echo "updatesync-many: $*" >&2 } +# Get the package name from the filename +# hackish, but should work for now +getpkgname() { + local tmp + + tmp=${1##*/} + tmp=${tmp%.pkg.tar.gz} + tmp=${tmp%-i686} + tmp=${tmp%-x86_64} + echo ${tmp%-*-*} +} + check_option() { local i for i in ${options[@]}; do @@ -76,6 +89,9 @@ cd $pkgname-$pkgver-$pkgrel # desc : >desc + echo "%FILENAME%" >>desc + echo "$2" >>desc + echo "" >>desc echo "%NAME%" >>desc echo "$pkgname" >>desc echo "" >>desc @@ -138,10 +154,8 @@ delete_entry() { - # strip to the basename - tmp=${1##*/} # grab the pkgname - pkgname=${tmp%-*-*} + pkgname=$(getpkgname $1) for i in *; do if [ "${i%-*-*}" = "$pkgname" ]; then rm -rf $i @@ -152,9 +166,8 @@ update_entry() { pkgfile=$1 - tmp=${pkgfile##*/} - pkgname=${tmp%-*-*}; - fullname=${tmp%.pkg.tar.gz} + pkgname=$(getpkgname ${pkgfile}) + fullname=$(basename ${pkgfile}) # find the matching PKGBUILD tmpf=$(mktemp /tmp/updatesync-many.XXXXXXXXXX) || exit 1 @@ -185,7 +198,7 @@ pkgmd5sum=`get_md5checksum $pkgfile` [ -z $pkgmd5sum ] && die "error generating checksum for $pkgfile" - db_write_entry $pkgbuild || die "error writing entry for $pkgname" + db_write_entry ${pkgbuild} ${fullname} || die "error writing entry for $pkgname" cd - >/dev/null } @@ -237,9 +250,7 @@ lsof $pkgfile &>/dev/null [ $? -ne 1 ] && continue - tmp=${pkgfile##*/} - pkgname=${tmp%-*-*}; - fullname=${tmp%.pkg.tar.gz} + pkgname=$(getpkgname ${pkgfile}) if [ "$ACTION" = "del" ]; then msg "Deleting entry: $pkgname" delete_entry $pkgfile

2 2

[arch-dev-public] FYI: Split gcc/libgcc
by Thomas Bächler 14 Sep '07

14 Sep '07

Aaron is right about communication, so I am posting this here: While splitting the current/base category into core/base and core/devel, it has been decided to split the gcc package into gcc(tools) and libgcc(libs:libstdc++,libgcc_s,...), so that no package will have to depend on gcc in the future, but rather on libgcc. gcc will depend on libgcc, gcc will go to core/devel and libgcc will go to core/base. Jan hopes he can do the split tonight.

4 4

[arch-dev-public] [core] move oragnisation
by Tobias Powalowski 14 Sep '07

14 Sep '07

Hi this thread is intended to organise this move. I will create a dependency list that needs to move in tomorrow afternoon. Would it be possible to meet each other on IRC tomorrow evening, european time? aaron is 7 hours behind germany. Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules. will cause probably some issues on ftp installs in setup and kernel installation, which can then be solved with new isos eventually. well i think the rest will be clear tomorrow evening. thanks for participating, im too tired for more now. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

6 8

[arch-dev-public] Reactive development [was: Repository cleanup]
by Aaron Griffin 14 Sep '07

14 Sep '07

On 9/12/07, Simo Leone <simo(a)archlinux.org> wrote: > What I'm trying to get across here is that some parts of this dev team > have adopted a reactive development model. By this I mean that the > majority of your devel is driven by whatever issues come up, as they > come up. Do you realize why that's bad? > > Typically projects will go through some solid research and plannning to > avoid this situation. I've heard that when the developer has a solid > understanding of the problem, they often develop more generic tools that > have more unforseen uses in the future than when they develop > reactively. This is why, for instance, pacman is so versatile in that it > alone can be used to solve all these problems (like phil said). Gee, > what a great tool. > > Sorry for the slight OT, it's kind of related. Wow. Simo said exactly what I've been feeling for some time now, much more concisely that I even had formulated the thoughts. This is also a very CRITICAL point, and the root of every problem we've had recently. See, ok. Rant-ish time now. I know a lot of you don't do this for a living. You don't work in software. Me? I've been doing this for over 7 years now professionally. Companies large and small, new companies with new technology, old companies with giant 100MHz mainframes, writing code in over 10 different languages. I've written bugs that made people laugh, and bugs that cost a company thousands of dollars. I've been there and done every stupid bad thing you can imagine (update without a where clause on a production DB anyone?) I've been forced to learn how to go about the process here. That's our problem. We have a disparity here between people who don't know common software development practices, and those who do. Those who know these processes expect everyone to implicitly follow them, and those who don't know them think they're silly. Here's the long-and-short of it. When you have cost a company $10000 due to one bad line of code, you learn to appreciate what a one hour code review can do. You learn to appreciate proper communication channels when two people make "hotfixes" to a live DB that break each other. This is what we're lacking. And sadly, it's a word everyone hates. We're missing "process". It is a _fact_ that as groups grow, they need more control. A group of 5 of us could easily coordinate things, but we're well over 25 (Phil said 30? wow!) and at this point we CAN'T keep doing things without proper process. It's just silly. Communication channels must be kept in check. If you do anything that affects the rest of us, then we should know about it before the users do. This includes important module changes (oh crap guys, I broke your X!), changes to initscripts (isatty is missing, btw), new ISO releases (I burned 3 copies of "Don't Panic" 2 days before the new release, for the record), and just... well... anything. Seriously, communication isn't hard. Hell. I know english may be a barrier, but why don't you write in german or something with "Please Translate:" at the top just so we know something is happening. That said, we have always held that the mailing lists are our proper channel of communication. This is important. Hell, it's critical. Saying "hey guess what!" on IRC doesn't cut it. The mailing list not only informs everyone (not all devs are on IRC) but also has archival history. We need to communicate. We need to follow processes. If you find a bug or a user report, and you're unclear about it - **say something**. The great word being flung around these days is "unilateral" - we're not a group of 30 independent people doing their own things, we're a group of 30 people working together. We need to stop reacting and doing our own thing. If something seems questionable, say something. Say "hey guys what do you think about N?". Just bring it up. Not everyone will respond. That's expected. Sometimes you have no opinion, but at least we KNOW what's happening. Guys, seriously. We're floundering. Something needs to be done, and it's not up to one or two of us. It's up to all of us.

5 4

[arch-dev-public] READ ALL:Please hold commits, [core] repository will be setup soon.
by Tobias Powalowski 13 Sep '07

13 Sep '07

Hi as in the earlier thread stated we want to setup our new [core] repository this weekend, for making this possible please don't check in anything to extra/current the next days until we finished this. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] git cheat sheet.
by eliott 13 Sep '07

13 Sep '07

For all you devs out there. Kind of neat. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html A potentially very useful git cheat sheet. :)

2 2

[arch-dev-public] opencdk, gnutls and libtasn1 in testing
by Jan de Groot 12 Sep '07

12 Sep '07

A few minutes ago I pushed gnutls 2.0.0, OpenCDK 0.6.4 and libtasn 1.1 to testing. Though all of them have a new major version number, only OpenCDK has had a so-bump. It seems that GNUTLS is the only package that depends directly on opencdk, and running lddd.sh on my system shows no possible rebuilds for this upgrade. Please give these libraries some testing, as they're an important part of your system. Report bugs to flyspray so we can rebuild these broken applications.

1 0

[arch-dev-public] Away 9/9-9/15
by Paul Mattal 09 Sep '07

09 Sep '07

I will be on vacation and relatively offline 9/9 through 9/15. Feel free to feed and care for my packages in my absence. I plan to kick mythtv out of testing on my return, and tackle the new version of eclipse and eclipse-cdt. - P

1 0

[arch-dev-public] Xorg dummy package removal
by Travis Willard 07 Sep '07

07 Sep '07

Hi everyone, As recently pointed out in http://bbs.archlinux.org/viewtopic.php?id=37062&p=1 the xorg dummy package has been removed. While this could have been done a bit more elegantly and with warning, it's been done, and I'm post-emptively giving warning now I guess. Anyone maintaining packages with the dependency on 'xorg' please update your packages. Nothing should EVER depend on 'xorg' - use namcap to find out what the true deps to your package are and add them. Some packages in extra, community, and AUR-unsupported probably need fixes. To preserve convenience of installing Xorg, we're considering doing an xorg group between the packages previously pulled by the xorg metapackage. I'll follow up to this email when that's done. Thanks. -- Travis

4 3

[arch-dev-public] Do we like the same books?
by Aaron Griffin 07 Sep '07

07 Sep '07

I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading. Click below to join my group of friends on Shelfari! http://www.shelfari.com/Register.aspx?ActivityId=9198203&InvitationCode=a14… Aaron Griffin Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out. -------- You have received this email because Aaron Griffin (aaronmgriffin(a)gmail.com) directly invited you to join his/her community on Shelfari. It is against Shelfari's policies to invite people who you don't know directly. Follow this link (http://www.shelfari.com/actions/emailoptout.aspx?email=arch-dev-public@arch…) to prevent future invitations to this address. If you believe you do not know this person, you may view (http://www.shelfari.com/phrakture) his/her Shelfari page or report him/her in our feedback (http://www.shelfari.com/Feedback.aspx) section. Shelfari, 616 1st Ave #300, Seattle, WA 98104

1 0

Re: [arch-dev-public] [arch-dev] Package listing color offset update
by Travis Willard 06 Sep '07

06 Sep '07

> > Good idea, but the colour is wrong IMO. Try the background colour from > > the header row. > > Sure. Find me the hex color code and send it to me, and I will make the > change. I think the colour you're looking for is #EEE4CB. -- Travis

1 1

[arch-dev-public] X.Org 7.3 pre-release testing repo
by Alexander Baldeck 06 Sep '07

06 Sep '07

Hey all, X.Org 7.3's release is about to happen in the next few days/weeks. For that reason I've built the latest xorg-server snapshot which is at version 1.3.99.2 and most of the drivers and newly introduced packages. A lot has changed, primarily in the area of driver ABI. For example nvidia is broken, it does build but xorg-server rejects it when starting up with an API mismatch error. Forcing it leads to hardlocks. I am using xf86-video-nv for now but this issue needs to be addressed. I have no idea how well fglrx & unichrome-dri plays with the new server. So I'd like to hear about it. Anyone wanting to take part in testing, should add this repo: http://kth5.telekommunisten.net/xorg/ The PKGBUILs will soon be available with the same URL, just need to clean them up a bit. Cheers, -F

8 20

[arch-dev-public] Fwd: [arch] WWW Root dir
by Aaron Griffin 04 Sep '07

04 Sep '07

Can we revisit this please? http://www.archlinux.org/mailman/private/arch-dev/2007-March/004700.html for reference ---------- Forwarded message ---------- From: Sergej Pupykin <ps(a)lx-ltd.ru> Date: Sep 4, 2007 8:29 AM Subject: [arch] WWW Root dir To: arch(a)archlinux.org Hi, I see /srv in filesystem package. What about www root? What decision was reached? _______________________________________________ arch mailing list arch(a)archlinux.org http://archlinux.org/mailman/listinfo/arch

1 0

Re: [arch-dev-public] Stellarium 0.9.0 and repo considerations
by Damir Perisa 04 Sep '07

04 Sep '07

Hi Corrado, Tuesday 04 September 2007, you wrote: | I wrote a PKGBUILD for the new stellarium, and added my .desktop | file to it (there even was a bug report about that, nobody added | it in the new version but I'm going to send it to the stellarium | team, too). I also noticed that the new version depends on qt4, | which is in community, while stellarium is in extra, so either we | move qt4 to extra (I don't think many people would like it) or we | move stellarium to community. If you think the latter is a good | idea I can take care of it and maintain the package there, just | let me know what you think about it. qt4 is going to [extra] "soon". kde4 will need it and also other pkgs are waiting for update for it (qtiplot, qsynth, speedcrunch... just to mention a few). also the scim/skim qt-immodules are qt4 and not available in qt3. so once qt4 is in [extra] the input system SCIM will finally work in kde :) the problem with qt4 not yet being official is that for making it clean we need to make 3 pkgs: * the core libs (without any dependency on xorg) - for qt4 server apps * the qt4 everything else except the core and qt3 compatibility (legacy) libs * the qt3compatibility libs other distros are separating it exactly the same way. the splitting of the thing in 3 pkgs is a little bit tricky if we want to make it nice (not e.g. by building it and then just removing the files from the target pkg that do not belong to this pkg)... this is still work in progress and actually the only thing holding us back. no dev has yet time to digg in qt4 build system to make the 3 pkgs yet. qt4 will be placed in /usr and not in /opt as qt3 and qt4 can coexist, no big migration is needed, once qt4 is in [extra] => i do not want to update stellarium in [extra] yet. the qt4 waiting is exactly the reason. i also do not want to move it to community just to move it back in a few months. | Attached to this message you'll find the new build with the | .desktop file. if you want, i can backport it. however it would mean triggering a update and stellarium is a big pkg for up/download :) | The only thing I didn't take care of is the | license, which at a first glance seems a bit complex (I think it's | two or three licenses). You can find a summary of the various | licensed materials in $startdir/src/stellarium-0.9.0/README. pacman can handle multiple licenses. the license=() is an array. stellarium is at least GPL for sure, IIRC. :) if you want to take over and maintain it in community, feel free. but consider that it will soon have to be rebuilt against a qt4 in /usr anyway. thanx + greetings, Damir

1 0

[arch-dev-public] fixed checkpkg
by Paul Mattal 03 Sep '07

03 Sep '07

I fixed checkpkg to also look for new makepkg3-style package names, and rolled that into the makepkg3 patch in the devtools package. - P

1 0

[arch-dev-public] perl modules in archlinux
by Jan de Groot 03 Sep '07

03 Sep '07

Hi all, I've been busy modifying all perl packages today to follow the same installation method. I think I'm past halfway now, only 20-25 packages to go. I added some dependencies for modules which I retrieved from the META.yml and/or Makefile.PL files. Things I did: - make all build() functions the same - add !emptydirs to options to get rid of empty perl directories - add md5sums - update to newest versions - add licenses (used PerlArtistic for anything that doesn't have an official license) Please watch out carefully when adding new perl packages to the repository, we don't want these things to become bad again.

5 6

[arch-dev-public] anybody uses amule?
by Damir Perisa 02 Sep '07

02 Sep '07

i happen to be amule pkg maintainer... however, i never used it (too slow connection) so i just keep on updating it, but this is bad for good maintaining... anybody uses it and wants to take this pkg from me? to be done: http://bugs.archlinux.org/task/7908 if not, i would suggest moving it to AUR. as i'm now running my pkgs for 2 ARCHs, i want to optimise my resources by dumping such pkgs (i myself do not use) one after the other. thanx + greetings, damir

1 0

[arch-dev-public] Absence until 9.9.
by Thomas Bächler 31 Aug '07

31 Aug '07

I will be on a conference in Austria from Sunday on for one week. I will have internet there, but I won't have much time to work on arch. There won't be much time today and tomorrow either, so I wish you a pleasant week.

1 0

[arch-dev-public] forcedeth
by Paul Mattal 30 Aug '07

30 Aug '07

[If you don't use the forcedeth driver, you can stop reading; this is just for people who might benefit from the research we did on this.] For all of you with NVIDIA integrated ethernet adapters which use the forcedeth driver, I thought I'd share the results of some troubleshooting and benchmarking we did this week. As you may know, the forcedeth driver has a provision to limit the amount of work done by the driver per invocation of the irq handler. As far as I can tell, this was implemented specifically because there is some broken hardware out there which can get a stuck irq and so the handler will then never exit and hang your machine. In any case, in doing some nfs benchmarks (using bonnie++), I was able to reliably crash my forcedeth-equipped nfs client machine VERY HARD, even using 2.6.22.5 which includes a forcedeth-related patch to partially address this behavior. To make a long story short, we discovered that this problem goes away if you increase the limit by doing the following in /etc/modprobe.conf: options forcedeth max_interrupt_work=20 My theory is that this still is in the spirit of the initial implementation.. if you have broken hardware with a stuck irq, one imagines it's likely to go through the loop FAR more than 20 times and the mechanism will still prevent your whole system from hanging. But under heavy load, it will still perform fine. You could probably even go higher than 20 with no ill effects, but I've never hit the 20 limit even under heavy load, so it seemed like a good place to stop. *Maybe even more interestingly: Increasing max_interrupt_work seemed to boost performance significantly on the adapter; where before it was pushing about 30-40Mbit out the adapter, it is now 50-60Mbit.* So if you've got one of these motherboards with forcedeth ether, especially in a server, try increasing your max_interrupt_work parameter for MUCH better performance and stability. - P

1 0

[arch-dev-public] AUFS
by Paul Mattal 30 Aug '07

30 Aug '07

Every so often I try again to figure out how to make AUFS coexist happily with Arch, and I usually end up failing. So I'm asking for some help puzzling this one out. AUFS requires a 3-line kernel patch, which appears to expose one function which is needed by AUFS to enable proper interaction with NFS: http://aufs.cvs.sourceforge.net/*checkout*/aufs/aufs/lhash.patch When the unionfs patches are applied, this patch cannot be cleanly applied! Though they don't directly conflict, they modify adjacent lines so patch can't find the right place to patch. What I'm trying to figure out is some way we can have both unionfs and aufs as options against kernel26 without having to recompile the kernel, in some way that will be feasible to maintain long-term. Any ideas? Anyone else interested in using AUFS know anything about this? We use to do root-on-nfs diskless workstations against a common base root filesystem, allowing individual workstations to modify their own root filesystem using a writeable aufs layer. Unionfs is specifically deficient when used in combination with nfs, and aufs is proving quite superior. Even if you haven't any ideas, thanks for listening! - P

2 1

[arch-dev-public] switch to more up-to-date util-linux and kbd?
by Roman Kyrylych 28 Aug '07

28 Aug '07

Hi! Today I've noticed a message in lkml about util-linux-ng. A quote: "The util-linux-ng is a fork of the original util-linux project. The goal of the util-linux-ng is a transparent and reliable development that follows the Linux kernel and Linux distributions". Home page: http://userweb.kernel.org/~kzak/util-linux-ng/ Highlights of the first release: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/347 Changes look interesting IMO. On util-linux-ng news archive I've also found a thread about updated kbd: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/326 which can be obtained from there: ftp://ftp.altlinux.org/pub/people/legion/kbd/ (note that kbd.git is outdated compared to tarballs) What do you think about this? -- Roman Kyrylych (Роман Кирилич)

2 3

[arch-dev-public] Call for help.
by Travis Willard 27 Aug '07

27 Aug '07

Hey guys, Can anyone out there take a look at http://bugs.archlinux.org/task/7886 and try to help this guy out. His system isn't booting properly anymore and it seems that, in trying to help, I only made it worse. If anyone can offer assistance, I'd be pretty grateful. -- Travis

1 0

[arch-dev-public] netcfg2 beta - Revamped network profiles
by James Rayner 26 Aug '07

26 Aug '07

Looking for testers for netcfg2, which will replace the current netcfg/profile system. This is pretty much a rewrite of the current scripts, making them more intelligent, easier to use, maintain, and closes up many bugs that have been lingering for far too long. In addition, many feature requests have been implemented too[1]. There' still some left, they'll come after this is stabilised and implemented. Packages and source are available here: http://src.iphitus.org/netcfg-release/ Please make sure you get the latest release. Documentation is still short. The example configs in /etc/network.d/ should be sufficient to get most people started. Daemon is now a seperate rc.d/net-profiles, and the rc.conf array has been renamed to NETWORKS=(). James [1] http://wiki.archlinux.org/index.php/Network_Scripts#New_Features [2] http://bbs.archlinux.org/viewtopic.php?id=36384

1 0

[arch-dev-public] Gimp-2.4 beta to current?
by Tobias Kieslich 24 Aug '07

24 Aug '07

Hi, I like to bring gimp-2.4 (rc1) to current. the 2.3.x is fairly stable for a while and I actually use it exclusively. Any objections? -T

4 5

[arch-dev-public] absence from 23.8 - 15.9
by Tobias Powalowski 23 Aug '07

23 Aug '07

Hi guys, im on vacation the next days, don't know if i have an inet connection on those days. have fun and keep arch rockin. I orphaned quite some packages last weekend so feel free to adopt them, the workload is too high for me and it's better to have experts on the packages then just bumping the releases. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] Major error with kernel26ck
by Tom K 22 Aug '07

22 Aug '07

Hi all. I would like to apologise for a fairly spectacular mess I have made with kernel26ck. The gory details are as follows. During the 2.6.22 test period, I built a kernel26ck package with the SLUB memory allocator enabled, for my own use. I submitted this package to extra in error, and compiled all external module packages against it. When I was building the current version, 2.6.22.3.ck1-1, I noticed my mistake, and changed back to the SLAB allocator, as used in the stock kernel. However, I did not appreciate the significance of this change at the time. Shortly after the SLAB-enabled package was released, I received reports that some of the existing module packages did not work with it. To solve this, I rebuilt all the *-ck modules against the new kernel version. I incorrectly assumed that the problem had been caused by incompatibility between the final -ck patchset release, 2.6.22-ck1, and the 2.6.22.3 update from kernel.org. To avoid further problems, I decided to announce the retirement of kernel26ck. I would like to thank Andy for identifying the correct cause of the problem i.e. the change from SLUB to SLAB. Andy is also of the opinion that we should either continue to update the package as long as it is in our repos, or else remove it now, and he cites today's 2.6.22.4 update, which provides a security update, as a good example of this. Taking all of the above into consideration, I now intend to continue maintaining kernel26ck until we move to the 2.6.23 kernel, at which time I will remove it from extra. I will amend Arch News accordingly. Once again, my apologies to all for this screw-up, and my thanks to Andy for letting me know. Regards Tom.

3 3

[arch-dev-public] base group
by Roman Kyrylych 22 Aug '07

22 Aug '07

Hi! IIRC this was mentioned some time ago, but I don't remember why it was not implemented. Why don't we have the "base" package group? IMO it would be nice if user would be able to do pacman -S base to get all base packages installed (e.g. in chroot or when installing from another distro). -- Roman Kyrylych (Роман Кирилич)

5 10

[arch-dev-public] License cleanup
by Travis Willard 21 Aug '07

21 Aug '07

Hey guys, You may have noticed I added license information to a handful (~27ish) packages in [extra] - this email is just to keep you informed as to what I'm doing. Right now, I'm just adding license fields where I can. For many of them, I'm simply searching Gentoo's package search and adding the licenses that come up there. If the package in question isn't in Gentoo's tree, I've been looking at the website and downloading sources. For custom licenses, I'm even adding the command at the end of the build() function to install the license to the proper directory. What I'm NOT doing: . Rebuilding any of these packages - I doubt users would appreciate needing to redownload their whole systems to get updated license information only. . Updating any of these packages to newest version - I've already come across a couple that are definitively out of date, one whose sources I couldn't even download to add the proper license-installation instruction into the build() method. I'm not updating these - the point of what I'm doing is to add licenses, not make our entire repo uptodate. Maybe that'll come later. ;) In any case, I think I'm done for tonight; I'm feeling pretty tired. If anyone wants to join me in this crusade, check out my thread entitled "Useful Scripts", grab the script that checks for bad licenses, and give it a run in your cvs dir for extra or unstable or community (making sure to run cvs update first!) - that'll give you a niiiice long list of packages that need tending to. -- Travis

3 8

[arch-dev-public] make nvram world-readable?
by Damir Perisa 20 Aug '07

20 Aug '07

i'd like to change the nvram device permissions rule in udev.rules we provide. at the moment the line in /etc/udev/rules.d/udev.rules is the following: KERNEL=="nvram", NAME="misc/%k", SYMLINK+="%k" what leads to [damir@Apollon dev]$ ls -la /dev/misc/nvram crw-rw---- 1 root root 10, 144 2007-08-17 18:40 /dev/misc/nvram being not accessible otherwise than root. and i want to change it to KERNEL=="nvram", NAME="misc/%k", SYMLINK+="%k" MODE="0666" so that any app or user can read nvram. this is needed by some tools for some hardware (e.g. thinkpads and buttons). alternatively i would allow only group to read it and have a group called nvram. what do you think? i know that everybody having a thinkpad is changing permissions to nvram device on arch boxes the one or other way... lets settle this the right way at the root ;) thanx + have a nice weekend, Damir (from the new laptop - almost running as i want it *smile*)

4 5

[arch-dev-public] new pam 0.99.x in testing
by Tobias Powalowski 19 Aug '07

19 Aug '07

Hi please try new pam in testing it wasn't updated since ages and i cleaned up the whole PKGBUILD. Report issues immediatly. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] backport of symlink fix for pacman?
by Jan de Groot 17 Aug '07

17 Aug '07

Every day we get new bugreports of perl not working because a symlink got overwritten. This is a bug in pacman that has been fixed according to git, but there's still no new release with this fix. Any drawbacks of applying http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=7a42e24400499873c 3b9e1e2315edc808d753734 to the current version of pacman?

3 3

[arch-dev-public] qemu-kvm updates
by Roman Kyrylych 17 Aug '07

17 Aug '07

Hi! We decided that we provide kvm modules that are shipped in kernel, which is good in terms of stability. But what about the userspace? Our qemu contains qemu-kvm from kvm-28 which is the same version as in .22 kernel. Will qemu-kvm version 35 work with kvm module version 28? If yes then I think it probably would be better to have more up-to-date userspace. Can anyone test this and/or say is this a good idea or not? -- Roman Kyrylych (Роман Кирилич)

2 1

[arch-dev-public] testing and xf86-video-intel
by Jason Chu 15 Aug '07

15 Aug '07

I'm trying to update my system and it can't find xf86-video-intel. It's looking for version 2.1.0-3, but the package is 2.1.1-1. I thought the db-testing scripts were supposed to fix things like this... I sure hope that it was used in this case... I've re-added 2.1.1-1 to the testing db. Jason

1 0

[arch-dev-public] New initscripts in testing
by Dan McGee 15 Aug '07

15 Aug '07

I pushed a new initscripts package to testing tonight to try to fix these two bugs: http://bugs.archlinux.org/task/4316 (Status messages malformed when using serial console) http://bugs.archlinux.org/task/7294 (base/initscripts: Make isatty a little more useful.) I fixed the second one by doing away with isatty entirely in favor of the bash test option -t. This shouldn't affect anything but the output, but let me know if you see any issues before I push it to current. -Dan

1 0

[arch-dev-public] Missing files on ftp: extra (i686)
by Eric Belanger 14 Aug '07

14 Aug '07

==> Generating Text Package List... notice: Missing luola-1.3.0-2.pkg.tar.gz in ftp site notice: Missing sdl_gfx-2.0.16-1.pkg.tar.gz in ftp site notice: Missing mplayer-plugin-3.45-1.pkg.tar.gz in ftp site Please fix. Thanks, Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

[arch-dev-public] Accidental Absence
by Jeff Mickey 13 Aug '07

13 Aug '07

So, a couple things have happened that make being active on the internet hard. 1) I moved into a new place. It's rockin'. Let me know if you wanna stop by. 2) This new place doesn't have internet, yet. 3) My laptop's wall wart broke last night. The little led doesn't come on. My other computer doesn't have a working monitor currently. I'll try to keep you updated from work. -- . : [ + carpe diem totus tuus + ] : .

3 2

[arch-dev-public] Long Absence
by Varun Acharya 13 Aug '07

13 Aug '07

Hi everyone, We're organizing a fifteen day event at the University, which will only get over first week of October. Lots of preparation needs to be done, and so getting online is going to be difficult if not impossible. I'll help out when I can. Thanks, Varun

1 0

[arch-dev-public] Amarok 1.4.7 compiled fine
by Damir Perisa 13 Aug '07

13 Aug '07

Monday 13 August 2007, Harald Sitter wrote: | The tarball for 1.4.7 is now available for packaging. Please | report any issues, so that we can delay the release and prepare a | fixed tarball in case it is necessary. Estimated release day is | Thursday. amarok-base and amarok-engine-xine 1.4.7 built successfully for arch - running fine. i'm just listening music with it right now ;-) | IMPORTANT: don't publish anything in public download locations | (e.g. repositories) until Thursday morning UTC (around 6, I'd | say). Also it would be quite cool to give us download | locations/information so that we can provide them at release time. why is waiting till thursday so important? its 4 days and i already got 10 emails of people reporting that amarok 1.4.7 is out... somehow users get such infos faster than even packagers *smile* may i commit the pkgs to the repository in arch already? if you say no, i will wait till thursday. greetings, Damir ArchLinux -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

1 1

[arch-dev-public] libgpod soname bump
by Aaron Griffin 12 Aug '07

12 Aug '07

so.1 -> so.2 I'm pretty sure I got all the packages. If I screwed up your packages, let me know. The following were touched: kipi-plugins gtkpod rhythmbox amarok-base did not appear to need recompilation, but I actually have no idea how to use an ipod with it, as all I have is a broken ipod shuffle. But it didn't crash - if anything needs to be done with amarok, let me know. Thanks

3 4

[arch-dev-public] Internal bug tracker
by Aaron Griffin 12 Aug '07

12 Aug '07

Eliott added an "Internal dev" bugtracker category for bugs related to our internal tools / processes. It's private, so feel free to log "zomg security hole in XYZ" stuff there 8) Thanks Aaron

1 0

[arch-dev-public] Repository rebuilding
by Jan de Groot 10 Aug '07

10 Aug '07

As some of us have noticed, there's a new toolchain in current now. One of the new features is GNU hashing for library symbols. This should speed up linking libraries together. To get full advantage of this hashing, the ideal thing would be to have everything built using GNU hashing on your system. I would suggest a full repo rebuild for this. Another reason for a full repo rebuild would be the bugs we get regarding old packages. Last week we had such a package which had been imported in the repositories 3 years ago and needs libstdc++5 to function now. I looked at it and it doesn't even build with the current compiler we have. This would be the ideal opportunity to get rid of packages that don't compile anymore, or to get them fixed. Compared to operation libtool-slay we had over a year ago, this operation is much more work, but we won't have to pass through testing: the rebuilds don't break anything and the packages remain compatible with eachother. What do we think of this idea?

12 33

[arch-dev-public] nvidia for 2.6.23-rc*
by Tom K 09 Aug '07

09 Aug '07

Hi all. In the course of building the current -mm release, I came across a Gentoo patch for nvidia with 2.6.23-rc kernels. I don't have nvidia myself, but a user has now confirmed that it's working as expected. The patch is in CVS for the unstable/nvidia-mm package. T.

1 0

[arch-dev-public] CD covers for ISO releases
by Roman Kyrylych 09 Aug '07

09 Aug '07

When Voodoo was released we have this thread: http://archlinux.org/pipermail/arch-dev-public/2007-April/000423.html And official CD cover was http://bbs.archlinux.org/viewtopic.php?pid=242736#p242736 made by Elasticdog. Then PJ updated his Voodoo covers and made a nice collection for Duke: http://www.geocities.com/kinortkele/archlinux-duke.tar.gz http://www.geocities.com/kinortkele/archlinux-duke-cdlabel.tar.gz AFAIR we didn't have official CD cover for Duke, and we don't have it for Don't Panic yet. It would be very nice if we had CD covers released at the time of ISO release. Both Elasticdog's and PJ's designs look nice. We should pick one of them and update it (let authors do this if they won't mind) few days before official ISO release. So CD distribution sites and magazines will have what to print on CDs. ;-) -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] mirror list on download page
by Roman Kyrylych 09 Aug '07

09 Aug '07

Well, the mirror list on our download page is outdated. prdownloads.sourceforge.net still has 0.7.1! I think many package mirrors also provide isos, so I suggest to take a mirror list from pacman and strip those mirrors that provide packages only. -- Roman Kyrylych (Роман Кирилич)

2 4

[arch-dev-public] 2007.08 Don't Panic Isos release
by Tobias Powalowski 08 Aug '07

08 Aug '07

Hi Arch community, 5th August, 23:00 CEST (Central European Summer Time) Arch Linux Don't-Panic 2007.08 ISO release Get Archlinux ISOs in /iso/2007.08/{i686,x86_64} on your favorite mirror. http://wiki.archlinux.org/index.php/Mirrors or http://www.archlinux.org/download/ Please don't forget to check md5sums. It's mostly a 2.6.22.x Iso with some fixes to last Linuxtag Isos. Changelog to last Duke-Linuxtag2007 installation ISO: - kernel 2.6.22.1 usage - fixed: update mkinitcpio for new .22 firewire layout - fixed: update hwdetect for new rtc_sys and firewire stuff - Memory requirements bumped to 128MB! - Serial console support in install environment - USB Keyboard issues fixed Setup changes: - fixed: "" around CONSOLEFONT and CONSOLEMAP - fixed: dhcp rc.conf entry - fixed: not generated glibc locales for fixed bugs reference: http://bugs.archlinux.org/task/7410 I would like to thank you all, who assisted in testing and of course finding/fixing bugs, you users/devs simply rock. Happy installing and have fun. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

8 40

[arch-dev-public] Announce 2007.08
by Tobias Powalowski 05 Aug '07

05 Aug '07

Hi i would like to announce 2007.08 this evening, would be cool if someone could create some torrents/metalinks and update the homepage to fit to new 2007.08 isos. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-dev-public] Don't Panic Release Isos
by Tobias Powalowski 04 Aug '07

04 Aug '07

Hi i generated new Don't panic isos, i'll test them tomorrow and if they work i'll put them to 686 ftp to let the servers sync. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-dev-public] projects.archlinux.org - "Official" projects only?
by Travis Willard 02 Aug '07

02 Aug '07

Hey all, In a recent forum thread[1] someone kept suggesting they move yaourt development to projects.archlinux.org -- I was under the impression that was for arch "official" projects only, and I replied as such, but I'd like to make sure I have my facts straight. Can people like the devs of yaourt add their projects to projects.archlinux.org? Or is it for stuff like pacman, pacbuild, namcap, etc... only? Thanks. Travis [1] http://bbs.archlinux.org/viewtopic.php?id=35772

4 5

[arch-dev-public] Absence
by Thomas Bächler 02 Aug '07

02 Aug '07

I will be gone 04. - 11.08. Have a nice week.

1 0

[arch-dev-public] new flac
by Paul Mattal 02 Aug '07

02 Aug '07

New flac is up in [current]. This is a major version update, so packages linked against may need to be bumped/rebuilt. - P

8 18

[arch-dev-public] x86_64 testing: missing pkg
by Andreas Radke 02 Aug '07

02 Aug '07

==> Generating Text Package List... notice: Missing xf86-video-sis-0.9.3-2.pkg.tar.gz in ftp site please fix it. and what about these packages? U extra/emulators/qemu/70-kqemu.rules U extra/emulators/qemu/PKGBUILD U extra/network/madwifi/kernel-2.6.22.patch U extra/network/madwifi-utils/kernel-2.6.22.patch U extra/system/pm-utils/PKGBUILD U extra/system/pm-utils/pm-utils.install madwifi has to be untagged from testing. can qemu and pm-utils move? Andy

1 0

[arch-dev-public] makedepends
by Paul Mattal 01 Aug '07

01 Aug '07

So flac (in [current]) has a makedepend on xmms (now in [community]). In this instance, this seems okay, since if xmms one day goes away, we remove that makedepend and the only bad effect is that there's no xmms plugin.. which is fine if there's no xmms! But couldn't this be a problem in general? Do we have any rules about makedepends across repositories? - P

4 3

[arch-dev-public] [projects@lists.froscon.de: [FrOSCon-Projects] Erste Infos bzgl. Projektraum auf der FrOSCon]
by Christoph Neuroth 01 Aug '07

01 Aug '07

Hi guys, so, exam time is over and so is my little vacation, so I can forward you a mail from the FrosCon team. summary of the important parts (too lazy to translate it all ;)): * we will have free wireless, but they are not sure if it will work all the time so they try to also provide a ethernet connection. however we will need to bring our own switch and cables * they would like to hear how many people will attend. Last thing I remember was alex, andi, jan, pierre and me. Please send me a mail if you definitely plan to come so I can order the free as in beer tickets for you ;) otherwise you'll have to pay (I think its like 5 bucks a day, so not that big a deal...) * we can sleep in the project room (don't forget a sleeping bag), but only the night saturday to sunday. alternatives here: http://wiki.froscon.de/wiki/Accommodation chris ----- Forwarded message from projects(a)lists.froscon.de ----- Date: Fri, 27 Jul 2007 10:12:29 +0200 To: projects(a)lists.froscon.de Cc: Mailingliste zur Organisation der FrOSCon <orga(a)lists.froscon.de> From: projects(a)lists.froscon.de Subject: [FrOSCon-Projects] Erste Infos bzgl. Projektraum auf der FrOSCon Liebe Projektraumverantwortlichen, Wir möchten Euch gerne darauf hinweisen, dass Eure Projektnamen auf unserer Konferenzhomepage http://www.froscon.de unter dem Menüpunkt Aussteller > Projekträume eingetragen wurden. Falls zu Eurem Projektnamen noch kein Logo vorhanden sein sollte oder dieses Euren Wünschen nicht entsprechen sollte, bitten wir Euch uns ein passendes Logo zuzuschicken, damit wir es auf unserer Homepage einfügen können. Was das Netz angeht, so steht Euch ein WLAN zur Verfügung. Ob dieses dem Besucheransturm standhält ist jedoch unklar. Wir bemühen uns daher, jeden Projektraum zusätzlich mit kabelgebundenem Netz auszustatten. In jedem Fall werden wir nur eine Netzdose zur Verfügung stellen können. Entsprechende Kabel und Unterverteilungen (Switch/Hub) sind daher selbst mitzubringen. Dankbar wären wir auch über eine Auskunft, mit wievielen Personen Ihr die Projekträume betreut. Die Namen der Teilnehmer bräuchten wir bis spätestens 2 Wochen vor der Konferenz. Falls Ihr uns diese Informationen nicht zukommen lasst, ist es uns nicht möglich, Eintrittskarten für Euch zu hinterlegen. Daher müsstet Ihr in diesem Fall leider Besucherkarten erwerben. Sollten einzelne von Euch bereits Speaker, Medienpartner, Helfer etc. sein benötigen wir diese Namen nicht mehr. Für die Verteilung der Projekträume benötigen wir noch eine Information von Euch: Möchtet Ihr ein eigenes Vortragsprogramm auf die Beine stellen? Wenn ja benötigen wir euer Programm bis spätestens zum 09.08.2007, wenn Ihr möchtet, dass es mit in das offizielle Programmheft kommt. Wir können es auch gerne mit in unser Online-Programm einbinden. In diesem Fall benötigen wir, neben Titel und einem kurzem Abstract, noch den Namen und die E-Mailadresse des Speakers. Ein Bild des Speakers wäre auch nett, ist aber kein Notwendigkeit. Des Weiteren benötigen wir 1-2 Ansprechpartner denen wir einen Schlüssel für den Raum aushändigen können. Bitte bringt dafür einen Personalausweis oder ähnliches mit. Ansonsten darf der Wachdienst die Schlüssel nicht aushändigen. Übernachtungsmöglichkeiten in der FH können wir nur von Samstag auf Sonntag anbieten. Für diese sind dann ein Schlafsack und eine Isomatte mitzubringen. Es wäre super, wenn Ihr als Schlafplatz euren Projektraum nutzen würdet. Teilt uns dann bitte nur mit, wieviele Leute übernachten, damit wir das Frühstück entsprechend planen können. Weitere Übernachtungsmöglichkeiten findet ihr unter http://wiki.froscon.de/wiki/Accommodation . Wir würden uns über eine baldige Antwort sehr freuen. Mit freundlichen Grüßen, Volker und das gesamte FrOSCon Organisationsteam _______________________________________________ Projects mailing list Projects(a)lists.froscon.de https://management.froscon.de/mailman/listinfo/projects ----- End forwarded message -----

5 4

[arch-dev-public] Useful scripts
by Travis Willard 01 Aug '07

01 Aug '07

Hey guys, Just threw together a couple of useful scripts, and I figured I may as well share. Note of warning!! Do not use these scripts on any PKGBUILDs you don't trust! They source every PKGBUILD to obtain the information - if a single PKGBUILD has rm -rf ~ you'd lose your home directory. You've been warned. ;) (of course you could run it in a sandbox as well, but yeah.) find-deps: This one finds all PKGBUILD files located in any subdirs of $(pwd), and finds any and all packages that depend on the command line argument. Very useful when searching for packages that might need a rebuild when you're updating a lib - just run it in your cvs directory and it'll go and find everything that lists your pkg as a dep. find-bad-licenses: This one also finds all PKGBUILD files located in any subdirs of $(pwd), and analyses all entries in the license array. If the license isn't one located in /usr/share/licenses/common, and it doesn't start with 'custom', then the package and its invalid license are output to stdout. Also, if no license is defined, it outputs this info to stdout as well. At the moment, it doesn't check the validity of custom licenses, but it does its job well; I've also attached the list it generates when run against extra/community/unstable. It's a long list - almost 2k invalid/non-existent licenses. I intend to go through what repos I have access to (extra, unstable, community) sometime in the near future (probably within the next couple of months) and clean up this license situation - we really need to get consistent with these things. Anyway, if you can get any use from my scripts, please do. ;) -- Travis

5 7

[arch-dev-public] Multiple Kernels in Repos
by James Rayner 01 Aug '07

01 Aug '07

Forking off the thread before... It's arrogant and hopelessly short sighted, to assume that one kernel will be enough. If we went that way, then that would provide *more* reason for DKMS anyway. As the amount of people compiling custom kernels would skyrocket, thus making DKMS even more useful. Arch has had more than one kernel for years. And there's no downside to having more than one, provided that they are sufficiently maintained. DKMS would make maintenance far far easier and tidier, while making the user's life a bit easier too. I'd be willing to pick up suspend2/tuxonice if we went to DKMS too. (didnt brain0 drop that, or am i making things up?) James

2 1

[arch-dev-public] External Kernel Modules - DKMS
by James Rayner 31 Jul '07

31 Jul '07

There was a short discussion not long ago on the TUR mailing list regarding external kernel modules. It was suggested that they be setup using dkms, which will easily allow one package, for multiple kernels. Having looked at the dkms setup suggested, and the few example modules in the AUR (search dkms), this might be a good idea, and make it much simpler to support a range of different kernels. Contrary to what andyrtr said, the DKMS system looks quite good, and would fit well. James

10 11

[arch-dev-public] An introduction to gooeydo
by Phil Dillon-Thiselton 31 Jul '07

31 Jul '07

Following a minor disagreement about how best to create .desktop files to launch apps with root privs, James and I came up with gooeydo (gui-do - ge' it?). You can read all about it here: http://thewrecker.net/?page_id=199 As an example of the purpose consider gparted and wifi-radar - both require root privs but are most often just run by users. I used sudo in my .desktop file for wifi-radar, while James used gksu in gparted. Because I don't have gksu on my system gparted won't appear in the menu. We think gooeydo nicely addresses the problem by ensure that a suitable "run as root" apps is used in all cases. Cheers, Phil

6 21

[arch-dev-public] Main site downtime
by Simo Leone 30 Jul '07

30 Jul '07

Eliott and I are going to shuffle around some stuff on the main site tomorrow, so it might be down for a few minutes at random. If I'm feeling creative I'll take a static snapshot of the homepage and put that up in the meantime, or perhaps that "there's nothing wrong with archlinux.org" image that was floating around back when we had dragon ;) In any case, if anything breaks yell at me (or him or both). -S

5 10

[arch-dev-public] missing package in current 'ngrep'
by Tobias Powalowski 27 Jul '07

27 Jul '07

==> Generating Text Package List... notice: Missing ngrep-1.45-2.pkg.tar.gz in ftp site greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] Flyspray tweaks
by Aaron Griffin 27 Jul '07

27 Jul '07

Hey guys, I turned on two nifty flyspray features for the hell of it, if they were off for a reason just let me know and they can go off quickly. a) dokuwiki syntax. This makes things pretty b) wiki links to wiki.archlinux.org For instance add [[The Arch Way]] into a bug report and it will link to the wiki page. Cheers, Aaron

2 7

[arch-dev-public] intellinuxwireless.org / Archlinux packages and links
by Thomas Bächler 24 Jul '07

24 Jul '07

Good morning, I noticed on http://intellinuxwireless.org/index.php?n=Downloads that you have Archlinux and our packages listed. I just wanted to update you on our status: 1) You have links to our ftp directory, which doesn't really make sense, as no Archlinux user downloads the packages there - they are automatically downloaded by our package manager pacman once an installation is requested, and they are available in the addons/ directory when downloading the installation iso. So you should rather provide links to our homepage. 2) There are now iwlwifi packages in our repos. This is a list with updated links: ipw2100: driver: http://www.archlinux.org/packages/4197/ (our kernel package) firmware: http://www.archlinux.org/packages/10815/ ipw2200: driver: http://www.archlinux.org/packages/4197/ (our kernel package) firmware: http://www.archlinux.org/packages/10816/ ipw3945: driver: http://www.archlinux.org/packages/10884/ ucode: http://www.archlinux.org/packages/10886/ daemon: http://www.archlinux.org/packages/10887/ mac80211: http://www.archlinux.org/packages/4197/ (our kernel package) iwlwifi: driver: http://www.archlinux.org/packages/13157/ ucode (3945): http://www.archlinux.org/packages/13158/ ucode (4965): http://www.archlinux.org/packages/13159/ 3) We would like to distribute your firmware/daemon packages (the ones above) on our installation CDs (or maybe DVDs) in the future. Are there any licensing issues we need to consider? Thanks for your efforts and good night Thomas Bächer Archlinux developer

1 1

[arch-dev-public] kernel26-suspend2 / kernel26-tuxonice
by Thomas Bächler 23 Jul '07

23 Jul '07

Hi tur- and dev-lists, as mentioned in the dev meeting, there is no interest from my end to keep maintaining kernel26-suspend2 (or tuxonice, which is its new name), due to a lack of time and machines to use it with. ise said he would maybe maintain it, but I haven't seen much from him lately. Due to the package cleanup efforts, maybe some TU wants to maintain it in community again. If nobody steps up, I will delete it along with suspend2-userui (or tuxonice-userui). I will keep hibernate-script though, it is very useful for other things than suspend2 as well.

2 1

[arch-dev-public] wireless modules up for grabs
by James 23 Jul '07

23 Jul '07

I've got a pile of different wireless modules, and they're probably better maintained by someone who has the hardware, or is keeping better track of the kernel scene then I am now. I'll keep maintaining them, but if anyone wants them or thinks they can do a better job, lemme know, and I'll orphan them for you. * ipw3945 - only needs to be maintained until iwl3945 is stable (not yet). * madwifi - as it's never going to be merged, yet it's common hardware, maybe move this to [current]? * at76c503a-cvs * tiacx - there's kernel patches in -mm, these are probably better as the external module is infrequently updated. * rt2500 - had hardware for this, but it's bust now. * rt2x00-* - will be in 2.6.22 from wireless-git? Cheers, James -- iphitus // Arch Developer // iphitus.loudas.com

3 6

[arch-dev-public] kernel 2.6.22 movement to current on monday?
by Tobias Powalowski 22 Jul '07

22 Jul '07

Hi i don't see showstoppers anymore, please correct me if im wrong, i talked to thomas on thursday, we can move it in on monday evening CEST. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] wireless modules up for grabs
by Phil Dillon-Thiselton 20 Jul '07

20 Jul '07

I've got a madwifi card I can use with i686 and x86_64, so i can take that unless anyone has any objections? kth5?

3 3

[arch-dev-public] missing packages [current] 686
by Tobias Powalowski 20 Jul '07

20 Jul '07

Hi notice: Missing fetchmail-6.3.8-3.pkg.tar.gz in ftp site notice: Missing xf86-input-joystick-1.2.2-1.pkg.tar.gz in ftp site notice: Missing xf86-video-nv-1.0.1.4-1.pkg.tar.gz in ftp site please fix this immediatly, thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-dev-public] The core of Arch Linux - repo reorganization
by Pierre Schmitz 19 Jul '07

19 Jul '07

Hi all, reading the last dev meeting log I realized that we need a clean concept to organize our package repositories. The problem: We have two official repositories: [current] and [extra]. Historically [current] should fit on a cd-r and includes packages preferred by Judd (and maybe some other "early" devs). [extra] should include everything else. Today nobody really know why a package is in current or extra. In addition to this we have some dependencies from current into extra and some non-free packages in current. This makes distribution on a cd/dvd quite difficult. Any last but not least: There is no easy way to install packages from a cd after the system is set up. So I do not think we need to worry about cd-r size. The solution: Imho the only solution is to drop those repos and set up new ones with a clear definition what should be included. This is only a fist proposal. A concrete package list has to be worked out later. [core] This repo will include those packages which have to be installed on every arch system regardless if its a server, workstation or notebook. This category will be similar (but not the same) as the current base category. It should contain all packages that are needed for a basic installation and it should be able to connect to the internet. (including all networking modules, ssh etc.) Furthermore it must include all tools and libs that are needed to rebuild and maintain the repo. So we need gcc, abs, csup, devtools etc. in [core] [core] should have some stricter policy when someone wants to update, add or delete packages. Major updates should pass a set of tests first. Minor and security updates could pass immediately. Addition or Deleting of packages should be discussed on ml before. And of course this repo should not depend on anything else (including makedepends) [extra] Everything else (like xorg, KDE etc.) will go into a "new" [extra] repo. This will be like the extra repo we currently have. But I would recommend the following policies: * only include "stable" software (meaning no alpha, beta, svn, git etc. branches). We should use [unstable] for those. * packages which are only used by very few users might be moved to [community] (see package cleanup) [non-free] As mentioned above it would be a good idea to move all non-free packages to a separate repo. This way we wouldn`t have any problems with distributing core+extra on a dvd. Of course no other package from any other repo should depend on one from non-free. [testing] and [unstable] are special and imho they don`t need further discussion. ;-) Step by step: 1) decide which packages should be in the [core] repo (check dependencies etc.) 2) move everything else into extra 3) cleanup extra; move packages into non-free, community or even aur 4) make sure there are no broken dependencies (including makedepends). It should look like this: [core] <- [extra] ^----------^----[non-free] ^----------^----[unstable] ^----------^----[community] Ok this is only a first proof of concept and a lot of work has to be done; bu what do you think of this idea? Pierre -- archlinux.de

7 7

[arch-dev-public] i will be back
by Damir Perisa 18 Jul '07

18 Jul '07

Dear all, long it is since i was really active here and this was mainly because of my master thesis and other duties. as my i686 is dying, i will replace it with a C2D tablet soon (as soon as lenovo ships it *smile*). lets see who is faster: me finishing my master thesis or lenovo shipping my laptop. so or so, when both events happen, i will first have to figure out how to run arch on a thinkpad x61t and then i hope i will join the arch64 team as well. of course only if you 64bit guys let me :) thanx to you all for seeing after my pkgs + have a nice weekend, Damir -- Damir Perisa Master Student Biozentrum, University of Basel Department Biochemistry / Focal Area Infection Biology Klingelbergstrasse 50-70 CH-4056 Basel, Switzerland

2 1

[arch-dev-public] kernel 2.6.22 showstoppers
by Tobias Powalowski 18 Jul '07

18 Jul '07

Hi is it right that only ndiswrapper needs to be fixed? could someone please confirm this, thanks here bug for reference: http://bugs.archlinux.org/task/7598 greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] Please build and test testing/madwifi on i686
by Alexander Baldeck 17 Jul '07

17 Jul '07

Could somebody please take care of that? Thanks a bunch, -U

2 3

[arch-dev-public] Definition of non-free for repo-reorg
by James Rayner 14 Jul '07

14 Jul '07

If we do separate "non-free" and "free" in the new repo layout, what will be the definition of "non-free"? Will anything closed source be non-free (acroread, nvidia)? or only things that have license/patent/distribution issues, like codecs? Will we just follow debian's definition and tests? James

10 20

[arch-dev-public] i686: missing packages
by Andreas Radke 13 Jul '07

13 Jul '07

==> Generating Text Package List... notice: Missing bluez-libs-3.12-1.pkg.tar.gz in ftp site notice: Missing fetchmail-6.3.8-3.pkg.tar.gz in ftp site notice: Missing xf86-input-joystick-1.2.2-1.pkg.tar.gz in ftp site notice: Missing xf86-video-nv-1.0.1.4-1.pkg.tar.gz in ftp site ANdyRTR

2 1

[arch-dev-public] kvm-modules package
by Thomas Bächler 13 Jul '07

13 Jul '07

With 2.6.22, we have had numerous reports that kvm locks up or doesn't load. On the other hand, according to Attila (http://bugs.archlinux.org/task/7598) we can use the kvm version shipped with 2.6.22. This would be easier and it is better tested than the one we build externally. Are there any reasons for keeping kvm-modules separately?

3 2

[arch-dev-public] GPL v3
by Dan McGee 12 Jul '07

12 Jul '07

Since some software we are going to package soon will be released under GPL v3 instead of GPL v2 or later, should we add this license as a separate one named "GPLv3" in the licenses package and begin using this in the license field? This seems like the easiest solution to me, rather than go back and change every occurrence of GPL to GPLv2. Thoughts? This isn't a very extreme change, but something that we need to consider and I didn't want to make the change without a bit of feedback first. -Dan

5 9

[arch-dev-public] will DVD size be the limit for our official repos?
by Andreas Radke 12 Jul '07

12 Jul '07

for x86_64 we now have [andyrtr@server64 ~]$ du -sh /home/andyrtr/mirror/packages/extra/ 3,6G /home/andyrtr/mirror/packages/extra/ [andyrtr@server64 ~]$ du -sh /home/andyrtr/mirror/packages/current/ 486M /home/andyrtr/mirror/packages/current/ i686 is ~100MB bigger. do we want to limit the amount of both repos to fit on a DVD (singlelayer)? this might become hard as pkg size usually raises each release. maybe we can go over that limit but would have keep out packages (e.g. i18n) from DVD releases. opinions? Andy

9 14

[arch-dev-public] stellarium update
by Damir Perisa 12 Jul '07

12 Jul '07

can somebody with a highspeed-internet connection update stellarium for me? extra - science - stellarium 0.8.2 -> 0.9.0 its 34mb of source and probably 20mb of pkg afterwards. thanx Damir -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

2 3

[arch-dev-public] New toolchain stuff in testing
by Jan de Groot 11 Jul '07

11 Jul '07

Hi all, Andy and I uploaded a new toolchain to testing. This includes a new binutils, a new gcc and a new glibc. On AMD64, the old stable 2.17 binutils doesn't function correctly in all cases with gcc 4.2 and glibc 2.6 (I was waiting for a binutils 2.18 release, but it's not coming within the next month I'm afraid). One big new feature in the new binutils is the support for GNU hashing, which is, according to Redhat, 50% faster in symbol lookups when doing dynamic linking. The GNU hashing is incompatible with the older hashing. There's a way inbetween: supporting both hash styles. The gcc in testing enforces both hash styles in the resulting linked binary. This means the size increases (I've seen libstdc++.so.6 and libc.so.6 getting increased by 10-20KB on a 1-2MB sized binary), but we maintain compatibility with other distributions and with our current "old style" glibc whenever something gets built with this toolchain. this is also the road taken by Debian. As long as binutils 2.17.50.xx isn't a so called stable release, we will keep this duplicate hashing style around, we have to decide what to do after the 2.18 release of binutils. (gcc-fortran will follow later tomorrow btw). Have fun testing this new toolchain, please report any bugs you find in flyspray.

3 4

[arch-dev-public] more repo reorg - take 2
by Paul Mattal 11 Jul '07

11 Jul '07

So the discussion so far suggests to me that I was wrong; in fact, it would not be easy to maintain any sort of [lite] or [full] that was limited in any way amongst the entire group. We will no longer have a set of packages of any predictable size we can carry around. One point still being missed about base vs. support: right now we are sloppy. We assume that certain packages are installed because they are in base or just because they are important. We should either: a) make our dependencies complete and not rely on such things OR b) have some group of packages that users should assume will break things if they remove. I think a) is better. So I amend my suggestion: [core]: has 2 categories - base, support base is by default fully installed when Arch is installed (base category pkgs also in base group for easy depends) support is by default not installed when Arch is installed only package dependencies require base pkgs to be installed (means we must fix our dependencies) draws from existing base category + drivers/utilities needed for installs minimize size stringent review/discussion for changing base, less so for support [main]: everything else Also, this can be done now because it's relatively easy. - P

1 0

[arch-dev-public] New /arch/db-* scripts
by Thomas Bächler 11 Jul '07

11 Jul '07

I started writing new database scripts to replace the old db-*/updatesync-many/pkgdb2 scripts. The reason are support for the new pacman 3 naming scheme and fixing some design issues. The old scripts use PKGBUILDs a lot for their operation and don't check the package file for consistency with the PKGBUILD (only the filename). They also move every file from the staging dir, regardless of whether the package will be added in any repository. And they recreate much of the functionality from updatesync, sort of reinventing the wheel. My new draft has a cleaner design, but some new problems appear. It performs the following steps: 1) Check every file in the staging/add dir using a small libalpm-based tool and obtain the pkgname, pkgver, pkgrel and architecture. Compare the arch specified in the commandline with the arch from the package (this step is missing in the old scripts). Find the PKGBUILD and compare pkgname, pkgver and pkgrel with the values from the package. If all checks are okay, add the package to a list. If additionally, a force flag is set in the PKGBUILD, add it to a "force-list". 2) Check every file in the staging/del dir and obtain its pkgname. Add this package to a delete list. 3) Lock the database 4) Move all packages and force-packages to the ftp dir, add them with repo-add. 5) Pass the package files to a pkgdb2-like tool to add them to the web interface. 6) Delete all package from the delete-list with repo-remove. 7) Pass the package names to a pkgdb2-like tool to remove them from the web interface. 8) Release the database lock. The problems I run into are these: a) In step 4) I can't determinte the filename of the old package and remove it from the ftp. I could scan for certain filename schemes, but take into account that the package filename could be anything now, the script doesn't care. We could however rely on our current filename scheme to find/remove the dupes (who would go through the trouble to rename his package to sth like wrongname-notapackage.zip.bz8 anyway?). b) The same thing counts for step 6). But we mv our packages to the staging/del anyway so the script won't have to remove them from the ftp. c) This is the biggest problem currently. In step 5), due to the new script design, I don't have any data from the PKGBUILD any more and don't want to go find it again. That means I only use data from the package file itself to add it to the mysql db. The package file lacks the "package category" and "source" which are in the web interface. I could only solve this by either removing this data from the web interface or adding it to the package file. d) The web interface doesn't support different architectures, so only data for the i686 packages is shown. That is a bad thing imo, but once data for more architectures is added, we need to be more careful about removing things from the web interface, as one architecture might lose a package that the other still keeps. I'd appreciate any comments on this, especially to problem c).

6 8

[arch-dev-public] repo reorg
by Paul Mattal 11 Jul '07

11 Jul '07

I support reorganizing, but like the fact that a single full CD can give me a pretty useful system if I'm a disconnected install. I also support using more repos rather than fewer, since with repoman the repos will become less of a hassle to manage. I support wide driver support, but don't think wireless drivers need to be installed on every box! So let me take a shot at a scheme: [core]: installed whenever Arch is installed draws from existing base category minimize size free/unencumbered only stringent review/discussion for changing [support]: drivers/utilities needed for installs included on core install cd [lite]: fits on cd with installer free/unencumbered as much function as we can pack into 1 cd stringent review/discussion for changing [full]: everything else this should continue to fit on 1 of some medium (now DVD) Nice aspects of this include that people who want a totally free system can rely on lite providing that, core can be really small, and people can have all the drivers they need at install time. - P

6 7

Re: [arch-dev-public] [arch-dev] newsletter?
by Jason Chu 10 Jul '07

10 Jul '07

On Mon, Jun 25, 2007 at 11:41:20AM -0700, Jason Chu wrote: > On Mon, Jun 25, 2007 at 09:17:24AM -0700, eliott wrote: > > Anything happening with the newsletter lately? > > Looks like there hasn't been one in a month or two.. > > Good point. I don't write it, I just write the devland section. The other > Jason writes it. I'll send him an email. > > Jason I heard back from Jason a little while ago. He hasn't had time during the summer to write the newsletter. He said he probably will have enough time at the beginning of August. I'm sending this to the public list too. If anyone reading this wants to help with the newsletter (writing all the sections except Devland), send me an email. Let's see if we can find more support so that one person can take some time off! Jason

1 0

[arch-dev-public] Absence
by Roman Kyrylych 10 Jul '07

10 Jul '07

Hi! As you all know I wasn't very active recently due to technical issues. Now it's time for personal issues.... I'll be totally absent starting from today and up to approximately 10th of July. I may have access to Internet on 7th and/or 8th, so I'll try to watch for bugtracker then, and if devmeeting will be on 8th - will try to attend to it (small chance though). Bye. -- Roman Kyrylych (Роман Кирилич)

1 1

[arch-dev-public] Kernel 2.6.22 in testing
by Thomas Bächler 10 Jul '07

10 Jul '07

This is a copy of my mail to the [arch] mailing list: Good morning, just a few minutes ago, the 2.6.22 kernel has been submitted to the testing repository. Please test it and report any bugs that might occur, so we hopefully can move it to current within a week. This kernel will also be the basis of the "Archlinux 2007.07 Don't panic" snapshot. For any changes in 2.6.22, see this site: http://kernelnewbies.org/Linux_2_6_22 I'd like to emphasize two changes: We re-added the rt2x00 drivers which (thanks to the mac80211 stack being merged in 2.6.22) now compile again and seem to work for me (rt2500pci). The mac80211 stack also allows us to ship the iwlwifi driver for intel 3945 and 4965 users. The driver for the 3945 is not as stable as ipw3945 yet, so people should not switch to it yet. However, it is the only driver for the 4965 wireless chipset. Both i686 and x86_64 now include the option for Intel Microcode updates which has been requested several times. I am going to add microcode_ctl to the repos, until then it is available from the AUR. Happy testing and good night Thomas

2 4

[arch-dev-public] rc-kernels for x86_64
by Thomas Bächler 04 Jul '07

04 Jul '07

Hi, I built 2.6.22-rc5 and modules for x86_64. I used the same PKGBUILDs that tpowa used and built all modules that he has in his repos (except the ones that are not available in arch64 repos, like fcpci and ltmodem those won't build anyway). Because of some header changes in 2.6.22, fglrx is also missing, it doesn't build on x86_64 right now. If anyone is interested, please send me a fix. Get the packages here: [kernel] Server = http://www.archlinux.org/~thomas/rc-kernel-x86_64 This repository also contains iwlwifi packages for intel 3945 and 4965 wireless. It is quite unstable as far as I can tell, but it is the only driver for the 4965 (for the 3945, you should use the ipw3945 package for now). @tpowa: If you want to add iwlwifi to yours too, here are the PKGBUILDs: http://www.archlinux.org/~thomas/iwlwifi/

3 5

[arch-dev-public] Moving eclipse-ecj from testing to extra
by Jan de Groot 02 Jul '07

02 Jul '07

Hi all devs, Last night I committed a new gcj package to extra, but forgot to move the eclipse-ecj package from testing to extra. Could someone do this one, as I'm at my job currently and have no time to move it now. Thanks.

2 1

Re: [arch-dev-public] [tur-users] tightvnc-1.3.9-1 prob
by Paul Mattal 02 Jul '07

02 Jul '07

Jason R Begley wrote: > There is a problem with tightvnc-1.3.9-1 with the font path and path to > x11, rgb. Here is output of problems: I apparently bolloxed this one up by uploading a stale package file from my development. There's a tightvnc-1.3.9-2 up now which should be better. - P

1 0

[arch-dev-public] Inactivity
by Varun Acharya 01 Jul '07

01 Jul '07

I need to write my SOP and get my papers organized, so I won't be active for the next 3 or 4 days. Varun

1 1

[arch-dev-public] Archlinux on Froscon conference?
by Jan de Groot 30 Jun '07

30 Jun '07

Hi all, Yesterday we got a leaflet from Froscon for their conference in end August ( http://upcoming.yahoo.com/event/129392/ (their own website is down ATM)) We could opt for a developer room during that conference to hack on archlinux. There's more projects over there, so it's also a chance to meet upstream development hackers to solve things we can't solve, or to have a talk to them about your favourite program they're hacking on. The conference takes place on saturday and sunday 25/26 august 2007. If we would make a reservation for a developer/hacker room, at least Me, Andy and Alexander will go. I would like to know who else would be able to get to Bonn that weekend to see if it's useful to have a reservation.

5 12

[arch-dev-public] Fw: Linux+ DVD magazine/ offer of cooperation
by Judd Vinet 28 Jun '07

28 Jun '07

Does anyone want to do this? I don't think I have the time or the best knowledge of Arch current events to write it. - Judd Begin forwarded message: Date: Thu, 28 Jun 2007 14:21:58 +0200 From: Karolina Rybak <karolina.rybak(a)software.com.pl> To: jvinet(a)zeroflux.org Subject: Linux+ DVD magazine/ offer of cooperation Hello, I'm Karolina and I'm the product manager for Linux+ DVD magazine. I'm preparing the upcoming issue of Linux+, that will be in sale in October. Would you like to contribute to the news section for this issue? I would be greatful if you could write about 2300 characters+one screenshot for this section about what is new in Arch Linux. Please let me know whether you would like to contribute and give the latest news on release or upcoming projects (for October). I look forward your reply best regards Karolina Rybak -- Linux+ DVD Karolina Rybak Product Manager /////////////////////////////////////////////// Software Media LLC 1461 A First Avenue, # 360 New York, NY 10021-2209 USA phone number: 1-917-338 - 3631/ +48 22 427 35 34 fax: +48 22 887 10 11 www.lpmagazine.org/en http://www.buyitpress.com/en/

1 0

[arch-dev-public] 2.6.22-rc4-git3 please test!
by Tobias Powalowski 27 Jun '07

27 Jun '07

Hi just to inform all developers, the new kernel can be downloaded from this adress: http://www.archlinux.org/~tpowa/rc-kernel/ or as repo [kernel] http://www.archlinux.org/~tpowa/rc-kernel/ All developers that have modules and hardware are invited to test the already provided ones. Broken: wlan-ng26 tomkx please try to find a fix ;) I need your feedback on this task, to avoid broken modules in the future. Known to work: fcpci,fcpcmcia,intel-536ep, nvidia-9x and nvidia-71x thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

7 11

[arch-dev-public] nfs-utils 1.1.0
by Tom K 26 Jun '07

26 Jun '07

This has been around for a few weeks, and is described as a "fairly significant new release". So standard practice would be to put it in testing, wait for bug reports, fix them , move to current - right? Except for one thing - who runs testing on a NFS server? I know I don't. I've built it (against current) and installed it here, and all's fine so far, but mine is a very straightforward setup. Would I just put out a call for testers, who can then pacman -U it from somewhere? Or are there better ways to handle this? T.

2 5

[arch-dev-public] Package database consistency check
by Thomas Bächler 26 Jun '07

26 Jun '07

I rewrote my package database consistency check script. It now reads all data directly from the db.tar.gz files (it doesn't read the filename attribute name yet, and still assumes pkgname-pkgver-pkgrel.pkg.tar.gz). It checks whether all packages in the db are present and have correct md5sums. The script is now in arch/scripts/check-package-db-consistency.sh in CVS. Here is the result: Checking current i686 ... Checking current x86_64 ... Checking extra i686 ... Package "/home/ftp/extra/os/i686/ion-3rc_20070506-1.pkg.tar.gz" missing. Package "/home/ftp/extra/os/i686/tmda-1.1.11-1.pkg.tar.gz" missing. Checking extra x86_64 ... Checking unstable i686 ... Checking unstable x86_64 ... Checking community i686 ... Checking community x86_64 ... Checking testing i686 ... Checking testing x86_64 ... Package "/home/ftp/testing/os/x86_64/xf86-video-unichrome-0.2.6-4.1.pkg.tar.gz" has wrong md5sum (file: "23d1a54367e3340dc7d89cfb48230a6b", database: "04d77dff29205c19c89245deb3a7fb6a")

3 2

[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

[arch-dev-public] curl rebuild TODO, archstats only left!
by Tobias Powalowski 19 Jun '07

19 Jun '07

Hi in order to move in the stuff fast would be great if Simo or anyone else would fix archstats, it doesn't compile anymore with latest curl. please fix this soon that we can start moving in the stuff to current/extra thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 3

[arch-dev-public] Devices >2TB
by Paul Mattal 19 Jun '07

19 Jun '07

Anyone know if our standard kernels are capable of seeing/handling devices that are >2TB in size? I know you need 48-bit LBA to do this, but clearly 48-bit LBA is supported on the machines I'm using and in our kernel. The 2TB limit, as I understand it, comes from something *somewhere* being limited to a 32-bit address. Is it the kernel, or perhaps my SATA controller somehow? Or the sata_nv driver? The setup is that I'm hooking up a hardware-raid-enclosure external cabinet up via the ESATA port to the SATA controller built into the NVidia NForce 430 chipset on the motherboard. We can't see more than 2TB. Thanks for any helpful hints that people may know! - P

2 3

[arch-dev-public] DB rebuilds
by Dan McGee 19 Jun '07

19 Jun '07

I just threw up a pacman release (3.0.5) that fixes the following issue (http://bugs.archlinux.org/task/7338) conflicts lines from packages were not correctly added to a sync DB, causing issues when it comes to replacing stock packages with an -svn version, for example. Two things this likely affects: 1. If version 3.0.4 of pacman is installed on al.org, we should probably upgrade to 3.0.5 to get the fixed repo-add script (which is used by gensync, which may be used by our other scripts?) 2. The community DB should probably be rebuilt completely to ensure all the conflicts lines are now present, if this is a problem. Questions on this? Let me know if I wasn't clear about anything here. -Dan

2 2

[arch-dev-public] reverse staging idea
by Paul Mattal 18 Jun '07

18 Jun '07

Since I know there have been complaints about packages remaining in the ftp directories when new ones are uploaded, how about we modify the /arch/db-* update scripts run by the devs to move old versions of updated packages into ~/staging/<repo>/old? This makes the default behavior that they stick around but aren't cluttering the ftp directory. Just an idea I had that I didn't want us to lose. - P

6 9

[arch-dev-public] Away for a while, the hunt for funds
by Alexander Baldeck 18 Jun '07

18 Jun '07

Hey all, as you may have noticed I've stepped back from my enthusiasm a little on and after Linuxtag. This is primarily because I'm a little short on cash these days. Several things aren't going as well as I would like them to. Anyways, I'm on a job hunt atm which is probably taking most of my time during the next few days. On the other hand, if anyone has hints you're welcome to forward contacts. ;) I will work on the most cirtical packages as much as I can but if something takes to long, feel free to bump/fix/drop them. Cheers, Alex

4 3

[arch-dev-public] ABS cleanup
by Dan McGee 18 Jun '07

18 Jun '07

I used the following two home-grown scripts in the past few days to clean out ABS- it doesn't do it all, but it does get rid of directories without a PKGBUILD which was the original intent. It should help make an ABS checkout a bit faster as people aren't pulling needless files, although I'm sure there are still many checked in patches that are no longer needed. Arch 64 guys may want to give these a go after a few modifications and see what shows up. -Dan #!/bin/bash # # findstale - find directories in ABS tree without a PKGBUILD # cwd=$(pwd) for dir in $(find -type d); do if [[ "$dir" != *local* ]]; then cd "$cwd" if [ ! -f "$dir/PKGBUILD" ]; then nodir=1; cd "$dir" for node in $(ls); do [ -d "$node" ] && nodir=0 done if [ $nodir -eq 1 ]; then echo "$dir" #for file in $(ls); do # echo " $file" #done #echo fi fi fi done #!/bin/bash # # cleantags - clean up CVS tags in a given directory # cwd=$(pwd) for line in $(cat $1); do cd $cwd/$line ls /var/abs/extra/$line | xargs cvs tag -d CURRENT done

1 0

[arch-dev-public] community-64 broken
by Pierre Schmitz 16 Jun '07

16 Jun '07

Hi, the community.db.tar.gz file of community is still outdated resulting in a more or less broken repository. Packages are newer than the db entries. Is there anybody who can fix this? (or tell me how to do it?) Pierre

4 5

[arch-dev-public] java licensing issues
by Jan de Groot 15 Jun '07

15 Jun '07

Hi developers and users, As we all know, there's a distribution restriction on sun java. Today we asked at the Sun booth about possibilities for distributing java with our distribution. This solution would come down to entering a process which can take quite some months to get a final approvement. This means that until we would have such a solution, any Sun java we distribute is illegal. This would mean that jdk and jre can't have a place in our distribution at least for the upcoming few months if we choose to apply for a license. If we don't choose to apply for a license, it won't come back either. I would opt for not applying for a license, as it will license us to distribute it, but disallows all forks, livecds or even unofficial architectures of archlinux to do it. As we have GNU java right now supporting java 5.0, I would suggest approving GNU java as the prefered JDK and moving jdk/jre to unsupported. We are allowed to distribute build scripts, but users have to download the java binary themselves and build a package out of that. We leave it up to the user to have a non-free java, we won't force anything (java-environment and java-runtime will always stay runtime dependencies instead of depending on java-gcj-compat). At the final end of this mail I would like to have a word about the so called OpenJDK that was released as GPL: Though this Open JDK has been released as source, the sun provided binary JDK at this moment is anything but GPL. The problem with openjdk is that it needs jdk to get built (gcj is not enough). Also, the released sources are not complete because sun has licensing restrictions with 3rd parties themselves. This means we can't switch to Sun's free OpenJDK yet. At this moment Redhat has plans to stop further active development of gcj in their distribution and put their manpower in openjdk, to get it built with free tools and to extend the missing parts with pieces from other javas like GNU java. When this project is usable enough to replace java-gcj-compat as we have it now, it will enter the distribution and become the blessed Java SDK/runtime.

5 8

[arch-dev-public] away for a while
by Andreas Radke 12 Jun '07

12 Jun '07

do never inline skating without protectors - i broke my right hand yesterday. fuck :( i won't be able to do anything important for Arch for while :-/ Cya Andy

7 6

[arch-dev-public] ion3 in extra: licensing issues
by Jan de Groot 12 Jun '07

12 Jun '07

I see codemac upgraded ion3 in extra yesterday, which forces us to release any upgrade to the package to be available within 3 weeks after an official release. The is unacceptable, and looking at the discussion with the author of this piece of software on the tur-users list, we should remove it.

9 12

[arch-dev-public] Package Cleanup: Part II
by Aaron Griffin 11 Jun '07

11 Jun '07

http://wiki.archlinux.org/index.php/Package_Cleanup So the initial burst made a smallish dent, but there's still a lot more to do, which I'd like to get to this weekend. If anyone want to help out, that'd be great. In addition, please voice your opinions about a few things (I haven't heard a lot of developers talk about this, so I've left it alone: * Move desktop related stuff to extra? (possibly keep only xorg in current?) * Move wireless/network modules to current? (they're that important IMO) * Rename current to "core" ? * Anything else? Here's a handful of instructions for moving things, just to be complete. == Move to unsupported == cd repo/category/pkgname tar czf pkgname.tar.gz * /upload to the AUR/ cvs tag -d CURRENT cvs tag -d CURRENT-64 (possibly testing as well if it's there) cvs rm -f * cvs commit == Move from current to extra == cp -r current/category/pkgname extra/category/pkgname rm -rf extra/category/pkgname/CVS cd current/category/pkgname cvs tag -d CURRENT cvs tag -d CURRENT-64 (possibly testing as well if it's there) cvs rm -f * cvs commit cd extra/category/ cvs add pkgname cd pkgname (use extrapkg or any other means to get it in the repo) Thanks, Aaron

7 23

[arch-dev-public] Next Developer Meeting
by James 08 Jun '07

08 Jun '07

So here's for another developer meeting. We've got a ton of things to discuss, there's already a few stagnant threads on this ML that need picking up. I'm happy to work out an agenda, and progress reports on things would be good too, as well as checking on what we've done since the last meeting. I'd like to try something different with this one. I think we need to really discuss things, and to do this properly, i'm of the opinion, that text doesn't cut it. I propose, we meet on Saturday, 2nd June, same time as the last meeting, cept this time we use teamspeak. VOIP for the uninitiated. AFAIK it has text support for those without microphones... but a cheap standard, even name brand snd-usb-audio headset costs next to nothing. https://www.archlinux.org/wiki/Meeting%205/ James -- iphitus // Arch Developer // iphitus.loudas.com

19 45

[arch-dev-public] Fwd: Goals / Mission Statement
by Aaron Griffin 08 Jun '07

08 Jun '07

Below is Essien's response to this thread.... ---------- Forwarded message ---------- From: Essien Ita Essien <me(a)essienitaessien.com> Date: May 31, 2007 7:33 PM Subject: Re: [arch-dev-public] Goals / Mission Statement To: Aaron Griffin <aaronmgriffin(a)gmail.com> My own goals are kinda selfish... but then aren't we all? 1. Like others... I want a lean, clean and mean system that is transparent and has a compact API (yes... distros have APIs... for Arch... its /etc/rc.conf) Which leads to: 2. A distro that helps and actively encourages distro builders to base on it for serious applications. which leads to: 3. Provide easy to use tools for extending working with ArchLinux and derived distros... with increased emphasis on the derivation tools. Basically, I'm saying promote stuff like archboot, devtools to first class citizens like pacman and makepkg. 4. Even though the distro has a clean and transparent API, we should still have scripts to manage and administer base system, so we should either provide them or foster and environment where such are provided. For instance, I have a script which i deploy on my servers to do stuff like: service httpd [start | stop | status] which i'd like to extend to do: service httpd [autostart-on | autostart-off] I'm sure a lot more have little utilities for doing stuff like that... if those kind of utilities are made 'First Class Citizens' under a parent project, more of them would automagically surface. I'm not sure if these are all actual goals or implementation details... but i'd guess there's a little of both in the above extremely selfish list. :) Keep up the good work. Cheers, Essien > > _______________________________________________ > arch-dev-public mailing list > arch-dev-public(a)archlinux.org > http://archlinux.org/mailman/listinfo/arch-dev-public >

1 1

[arch-dev-public] curl bump - rebuilds
by Andreas Radke 07 Jun '07

07 Jun '07

curl update to 7.16.2 brings a .so name bump. i've put it already into testing for x86_64. here's a list what i could collect for (possible) rebuilds: from "finddeps" script: php xine-ui vorbis-tools gnupg raptor wmweather git darcs xmoto bzflag moc came gmpc grip gnash bidwatcher audacious-plugins streamtuner libofa motion icecast centericq freepops openoffice-base (it starts fine delay this, a new release is expected for 12th june) ooodi2 archstats clamav gnupg2 from pacman -Qi on my system: entericq clamav claws-mail-extra-plugins darcs freepops gnash gnupg gnupg2 grip libofa openoffice-base php raptor rtorrent streamtuner vorbis-tools xine-ui and from running ldddd on my main system: /usr/bin/php /usr/bin/grip /usr/bin/puid /usr/bin/xine /usr/bin/darcs /usr/bin/gnash /usr/bin/terminatorX /usr/bin/sigtool /usr/bin/rtorrent /usr/bin/streamtuner /usr/bin/centericq /usr/bin/freepopsd /usr/bin/ogg123 /usr/bin/gparser /usr/bin/clamdscan /usr/bin/rapper /usr/bin/freshclam /usr/bin/gprocessor /usr/bin/php-cgi /usr/bin/clamconf /usr/bin/clamscan /usr/sbin/clamd /opt/kde/bin/juk /opt/kde/bin/amarokcollectionscanner /opt/kde/bin/amarokapp /usr/lib/gnupg/gpgkeys_hkp /usr/lib/gnupg/gpgkeys_curl /usr/lib/liblrdf.so.2.0.0 /usr/lib/audacious/General/libscrobbler.so /usr/lib/audacious/General/libcurl.so /usr/lib/libtunepimp.so.5.0.3 /usr/lib/libgnashbackend-cvs20070529.so /usr/lib/libclamav.so.2.0.3 /usr/lib/apache/libphp5.so /usr/lib/claws-mail/plugins/rssyl.so /usr/lib/claws-mail/plugins/vcalendar.so /usr/lib/claws-mail/plugins/clamav_plugin.so /usr/lib/claws-mail/plugins/gtkhtml2_viewer.so /usr/lib/libgnashgeo-cvs20070529.so /usr/lib/gnupg2/gpg2keys_curl /usr/lib/gnupg2/gpg2keys_hkp /usr/lib/tunepimp/plugins/vorbis.tpp /usr/lib/tunepimp/plugins/mp3.tpp /usr/lib/tunepimp/plugins/mp4.tpp /usr/lib/tunepimp/plugins/mpc.tpp /usr/lib/tunepimp/plugins/tta.tpp /usr/lib/tunepimp/plugins/flac.tpp /usr/lib/tunepimp/plugins/wv.tpp /usr/lib/tunepimp/plugins/wav.tpp /usr/lib/tunepimp/plugins/speex.tpp /usr/lib/tunepimp/plugins/wma.tpp /usr/lib/libraptor.so.1.1.0 /usr/lib/libgnashplayer-cvs20070529.so /usr/lib/libgnashserver-cvs20070529.so /usr/lib/libgnashamf-cvs20070529.so /usr/lib/libgnashbase-cvs20070529.so /usr/lib/libgnashgui-cvs20070529.so /opt/kde/lib/kde3/libamarok_void-engine_plugin.so /opt/kde/lib/kde3/libamarok_smb-device.so /opt/kde/lib/kde3/libamarok_mtp-mediadevice.so /opt/kde/lib/kde3/libamarok_xine-engine.so /opt/kde/lib/kde3/libamarok_ifp-mediadevice.so /opt/kde/lib/kde3/libamarok_massstorage-device.so /opt/kde/lib/kde3/libamarok_njb-mediadevice.so /opt/kde/lib/kde3/libamarok_generic-mediadevice.so /opt/kde/lib/kde3/libamarok_nfs-device.so /opt/kde/lib/kde3/libamarok_ipod-mediadevice.so /opt/kde/lib/kde3/libamarok_daap-mediadevice.so /opt/kde/lib/libamarok.so.0.0.0 Somebody wants to setup a ToDo list in our Wiki? Ok, have fun on rebuilding your packages. It shouldn't take that long. Andy

2 1

Re: [arch-dev-public] [arch-dev] personal staging dirs wanted
by Aaron Griffin 06 Jun '07

06 Jun '07

On 6/4/07, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On 6/3/07, Jason Chu <jason(a)archlinux.org> wrote: > > On Sun, Jun 03, 2007 at 08:56:48PM +0200, Andreas Radke wrote: > > > for i686 every dev has personal staging dirs at gerolde. x86_64 uses > > > only on common. that should be changed. uploading all to one may break > > > the db if a dev wants to hold some of his packages back until he has > > > uploaded all of one set. > > > > > > in general every dev should have access + personal staging > > > directories to both official supported architectures. x86_64 devs > > > could easily build for i686 in a chroot. > > > > > > can we change this quickly and adopt the devtools pkg? > > > > > > Andy > > > > I think it's a reasonable request. There's no history of x86_64 devs > > screwing up anything for i686, which was our main concern at the beginning. > > > > Aaron, can you handle this? > > Yeah, I can do that - writing it down to do tonight (~6 hours from now, perhaps) Done, eric updated devtools, so all you x86_64 guys need to login to gerolde, and create: ~/staging/arch64/ ~/staging/extra64/ ~/staging/unstable64/ ~/staging/testing64/ And voila! In the future, when we move over to the -ARCh suffixed packages, the '64' on those dirs won't be needed anymore.

2 1

[arch-dev-public] The code of mac is back.
by Jeff 'codemac' Mickey 06 Jun '07

06 Jun '07

After a short *cough* haitus, I would now like to say I am back "full time". As full time as possible for an Open Source developer that is. When I said I'd be taking time off, I had no idea what good timing that was. Life went to hell in a handbasket rather quickly for me, and just now am I starting to feel "recovered". Hopefully my packages haven't gotten too out of date, or someone has kindly repackaged them for me. I'd like to thank anyone who has done this. Happy Hacking // codemac -- .: [ + carpe diem totus tuus + ] :.

4 3

[arch-dev-public] Fwd: [list@suppentopf.net: official mirror]
by Aaron Griffin 05 Jun '07

05 Jun '07

---------- Forwarded message ---------- From: Christian Berendt <list(a)suppentopf.net> Date: Jun 5, 2007 4:04 PM Subject: [list(a)suppentopf.net: official mirror] To: aaron(a)archlinux.org Hi, I have sent this mail to the pub-dev list, but it was rejected. Can you redirect it to the list, I think you can write there :) Thanks! Bye, Christian. ----- Forwarded message from Christian Berendt <list(a)suppentopf.net> ----- Date: Tue, 5 Jun 2007 20:59:55 +0000 From: Christian Berendt <list(a)suppentopf.net> To: arch-dev-public(a)archlinux.org Subject: official mirror Hi! My name is Christian, I'm new to arch linux, an ex-Gentoo-user. I'm studying computer sience at the RWTH Aachen in Germany and live there in one of the student hostels. There I have the room to host a mirror for this project with a connection to the DFN (our university network in Germany). It's a connection with 100mbit, I think this is ok ;) The point is the hardware, I only have an old P3-600 with <512MB of RAM. The hdd is no problem, I can put an SATA controller and a hdd with 200GB into it. So is this interessting for you or is the hw to slow? At the moment I'm mirroring the extra-repository and test the performance the next few days. At next week I can install the hardware in our computer room. Bye, Christian. ----- End forwarded message -----

2 1

[arch-dev-public] Emacs rebuild 22.1
by Dan McGee 05 Jun '07

05 Jun '07

I just built the new version of emacs with a revamped PKGBUILD and threw it up in the testing repo for anyone interested in trying it out. Please let me know (on the list) if you notice any problems with it before it gets moved out of testing and into extra. -Dan

2 3

Re: [arch-dev-public] Next Developer Meeting
by Jeff Mickey 05 Jun '07

05 Jun '07

Wrong address... On 6/5/07, Jeff Mickey <j(a)codemac.net> wrote: > On 6/5/07, Roman Kyrylych <roman.kyrylych(a)gmail.com> wrote: > > I'm fine with any date. > > But can we please speak about time in UTC/GMT timezone? > > Does "at noon EST" == 17 UTC? > > Noon EST = 12 EST = 16 UTC, because UTC isn't on daylight savings ( > summertime period, whatever ). Convert to your own local time from > that. > > Sorry about the father's day thing, I totally forgot. Which reminds > me, I need to find a card or something... > > > // jeff > -- > . : [ + carpe diem totus tuus + ] : . > -- . : [ + carpe diem totus tuus + ] : .

2 1

[arch-dev-public] Random tests.
by eliott 05 Jun '07

05 Jun '07

Just some random information, that I thought I would share. I was taking a look at how much traffic different protocols take to accomplish 2 things. 1) Sync the abs tree with a fresh pull 2) Perform a 'sync-check' (test to see if there are any new changes) with no updates available. http://stdout.cactuswax.net/cactus/tests.txt I was using fresh checkouts, so I don't have any other data other than what appears above. I would like to test some of the protocols against trees that have updates, git repos with more history than fresh imports, and for potential degradation as size increases. I don't know if I will get around to it though. If anyone else is interested in testing such things, then let me know. I would be very interested in the results.

2 1

[arch-dev-public] KVM & Paravirtualization
by Alexander Baldeck 03 Jun '07

03 Jun '07

Hey all, some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it: 1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong 2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package? 3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball 4) split KVM into kvm-qemu & kvm-modules? I have not yet tried to enable options like suggested in [2] yet but will do so soon. What do you think? Cheers, -H [1] http://bugs.archlinux.org/task/7331 [2] http://bugs.archlinux.org/task/7337

6 6

[arch-dev-public] [networking] autowifi
by Thomas Bächler 02 Jun '07

02 Jun '07

With my new laptop and working wireless, I am now able to announce the "autowifi" scripts I wrote a few weeks ago. Requirements: - wpa_supplicant - wifi driver that is supported by wpa_supplicant - dhclient Features: - Automatically select the best network (done by wpa_supplicant) and configure it according to configuration files (done by autowifi) - wifi configuration via wpa_supplicant.conf - dhcp,static or "custom" network configuration via /etc/autowifi/networks/ - default configuration for unknown networks (if a network is not configured, the default behaviour is using dhcp) - same configuration for networks whose essid matches a regex - once configured, it works completely without user interaction, but it _can_ be controlled by wpa_gui (or any other wpa_supplicant client), so that you can access networks without changing wpa_supplicant.conf. I am still unsure whether and how this can be integrated into James' netcfg, that's a question that I'd rather let him answer. That said, autowifi is VERY simple. It doesn't reinvent the wheel by using wpa_supplicant for selecting networks - parsing iwlist outputs doesn't work very well, does it? As all wifi drivers will be moved to mac80211 in the near future, wpa_supplicant-support will not be a restriction anymore. I tested it on iwl3945 and rt2x00-git. The latter has problems scanning and shows very few networks, therefore didn't work very well. I couldn't test it with iwl3945 in an environment with many wireless networks yet, but I trust it works better. HOWTO: - Install the package from http://www.archlinux.org/~thomas/autowifi-svn/ or from svn at http://projects.archlinux.org/svn/autowifi/ - Create /etc/wpa_supplicant.conf and configure all your networks (you can configure anything here, open, WEP, WPA-PSK, WPA-EAP and so on). - Read /etc/autowifi/regex and map ESSIDs to profile names if necessary. - Read /etc/autowifi/networks/example and configure /etc/autowifi/networks/default and /etc/autowifi/networks/profilename if necessary. If you only use dhcp on all networks, no configuration is necessary here. - Adjust the interface and config file name in /etc/conf.d/autowifi properly. - /etc/rc.d/autowifi start (can of course be done via rc.conf) Possible bugs: In my first test, dhcp wouldn't work when I changed networks, maybe I need to delete the dhclient lease file. Any feedback is welcome Thomas

3 6

[arch-dev-public] Flyspray's default project
by Roman Kyrylych 01 Jun '07

01 Jun '07

Is is just me, or Flyspray really shows Pacman project by default? AFAIR it started more than a week ago. That causes users to report bugs in wrong project. Please someone with admin rights fix this. -- Roman Kyrylych (Роман Кирилич)

4 5

Re: [arch-dev-public] nfs-utils 1.1.0
by Tom K 01 Jun '07

01 Jun '07

RedShift wrote: > Tobias Powalowski wrote: >> Am Freitag 01 Juni 2007 schrieb Tom K: >>> RedShift wrote: >>>> I run an NFS server at home, I have no problems testing this for you. I >>>> run arch x86-64 on the server, but a quick makepkg should be no >>>> problem? >>>> >>>> Glenn >>> Thanks Glenn. Yes, x86_64 should not be a problem. You'll find >>> everything you need here: >>> >>> http://www.archlinux.org/~tom/packages/nfs-utils/ >>> >>> If you do have any build problems, I can ask one of the 64 devs to check >>> it out. Otherwise, let me know how you get on after the upgrade. >>> >>> Regards >>> Tom. >>> > > /etc/rc.d/netfs reports failed, but when I look at the mounts no NFS > volumes are mounted anymore. So mount must be returning a non-fatal, but > non-zero exit code. Anyone know how you can echo the return value of a > command from the shell? (bash) > > Glenn > Thanks again. netfs is working as designed on both my clients here, so I have nothing I can work on to debug that. Anything relevant in the server logs? T.

1 0

Re: [arch-dev-public] nfs-utils 1.1.0
by Tom K 01 Jun '07

01 Jun '07

RedShift wrote: > I run an NFS server at home, I have no problems testing this for you. I > run arch x86-64 on the server, but a quick makepkg should be no problem? > > Glenn > Thanks Glenn. Yes, x86_64 should not be a problem. You'll find everything you need here: http://www.archlinux.org/~tom/packages/nfs-utils/ If you do have any build problems, I can ask one of the 64 devs to check it out. Otherwise, let me know how you get on after the upgrade. Regards Tom.

2 1

[arch-dev-public] Goals / Mission Statement
by Aaron Griffin 01 Jun '07

01 Jun '07

Hey all, This has been brought up a few times by Andy, but it seems it's fallen on deaf ears recently. I want to make sure we get this done this time. One of our recent "growing pains" we've had is that there is a certain sense of direction that is unclear. We don't have a clear set of "goals" defined. So lets do that now. Our dev wiki (for the benefit of the subscribed users) contains some ideas which are rather raw. I will strip the names to make things anonymous. Below you will find the points listed in our dev wiki. What I want to do, right now, is flesh this out. We need to define ourselves a clear set of goals. It's important to note that a goal is not "make sure packages go to testing" - that's an implementation detail. A goal is something more ethereal, such as "provide stable, up-to-date software". I would like all of you to read through these (feel free to add your own) and try and list 3-5 of these that you feel are important. On Thursday, I'd like to compile a list of the responses, and we can go through and cherrypick our goals from this subset from everyone - yes this includes those of you without write access to this list. Email me directly, if you want to remain anonymous. Please look these over, and reply with anything you feel is important. Thanks, Aaron ----------------- Dev Wiki Entries ----------------- * Provide the latest software as is practical, while aiming to achieve a reasonable level of stability * Not be dependent on any graphical interface for any system function * Remain a lightweight, general purpose distribution that is simple in it's implementation * Continue to be a strongly community oriented distribution * Provide a good set of reliable and modern Linux technologies for desktop, server and portable PCs * Be equally suitable for home, educational, small business and corporate use * Provide a solid base for creating custom Arch (ISOs and repos) variants for users specific purposes * Remain a "install once, run forever" distribution * Provide good i18n and l10n support * Simple design. Reasoning: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan * Vanilla. As few patches as is reasonable to make things play together in the ways necessary, and then primarily as stopgap solutions until things get fixed upstream. This creates predictability and allows smart people with general GNU/Linux knowledge to pick up Arch instantly. It also keeps us from maintaining more and more custom patches over time. * Easy packaging with pacman. The SINGLE thing that will probably keep me from ever leaving Arch is how simple it is to create packages with Pacman. The thought of ever having to write another RPM spec file or something else as obtuse or complicated or ill-conceived as that makes me want to toss my lunch. When I find new software on the Web to help me do my work, I can have it packaged and integrated into my bag of tricks usually in less than an hour. As a result of this simplicity, we have a Community who understands what's going on and can be productively helpful and supportive of each other. * Binary distribution. Unlike Gentoo, we can download and install Firefox on a reasonably fast machine with a reasonably fast link in less than a minute. Also, we test and certify binaries, so quirks of people's machines don't bugger up their compile processes. The result is that after a pacman -Syu, on any machine, most things just work. * This might not be exactly where or what we are, but someone once called Arch a "meta distribution". That is, it gives you tools and a very nice base with which you can do whatever you want. I think this also coincides with 2 of the "goals" I would like to see - that is, (a) like Andy said, we provide a very nice base system and not much more, and (b) "Slackware with pacman" - we get likened to Slackware enough, and I think the simplicity that slackware strives for is ideal for us as well. * I say focus more on the core packages.. the underlying fundamentals. Push the addons higher into the stack. I liken Arch to one of the BSD's, oddly enough. The BSD team focuses on handling the core. They deal with things that come about when the system goes from poweroff to running a base network os. Then ports managers handle the packages that lay on top of this core system. Just a thought.

6 7

[arch-dev-public] problem with community repo db files
by eliott 30 May '07

30 May '07

There is some problem with the script that updates the community db file. I couldn't figure out exactly what the breakage is..other than the script itself not working. As a temporary measure, I manually regenerated the i686 and x86_64 repo db's.

3 3

[arch-dev-public] glibc-2.6/gcc-4.2.0 migration status
by Jan de Groot 29 May '07

29 May '07

Hi all, gcc-4.2.0 and glibc 2.6 have been in testing for a while now. I haven't received many bugs for this one and we still have some small todos open. Please test these packages very carefully, as these packages are very important for everyones system. I added a bug-catcher in flyspray: http://bugs.archlinux.org/task/7295 Please add new bugs for anything new you find that isn't linked to that one. If possible, link it to this bug-catcher. I hope to see gcc 4.2.0 and glibc 2.6 in current very soon after the bugs on that list are fixed.

4 3

[arch-dev-public] [drotschm@linuxtag.org: [LT07-Pro-Announce] Infomail #7, May 28, 2007]
by Christoph Neuroth 28 May '07

28 May '07

24 hours till plane leaves MUC :) see you guys ----- Forwarded message from Wolfgang Drotschmann <drotschm(a)linuxtag.org> ----- Date: Mon, 28 May 2007 16:23:50 +0200 From: Wolfgang Drotschmann <drotschm(a)linuxtag.org> To: projects-announce(a)linuxtag.org Subject: [LT07-Pro-Announce] Infomail #7, May 28, 2007 Dear Projects, we are busily sorting out things at the site, thus just a quick infomail about o Booth Setup o Additional Tables and Chairs o How to Contact the Project's Office o Project Check-in Here we go... 1. Booth Setup LinuxTag and Messe Berlin spent a lot of ressources (time and money) in the fair and the presentation of Free Software Projects. Additionally, there is less space available for the booths this year. Thus the concept of "booth islands" and open design should be seen as a chance to abandon the habit of building up the booth nearly completely. Less can often mean more. Please keep in mind the view of a "normal" visitor. Too much furniture debases this concept. Together with you, Project Committee and Messe Berlin wants to do a inspection after construction on Tuesday evening. 2. Additional Tables and Chairs We'll have very few additional tables (and chairs) to distribute at setup time. At dismantling time please leave them at your booth, we'll collect them separately. 3. How to Contact the Project's Office You can reach us by phone via the Front Desk. Ask for Marko or Wolfgang. The number is: +49-30-3038-7550 4. Project Check-in Please send someone of your setup group to register the project at the Front Desk. There you will receive a "Welcome Package", including your exhibitor passes and a coupon for the social event tickets. See you tomorrow :-) Regards, Susanne Pfeifer, Wolfgang Drotschmann & Marko Jung Project Committee LinuxTag 2007 ----- End forwarded message -----

1 0

[arch-dev-public] 2007.05 Duke Linuxtag2007 ISOs released
by Tobias Powalowski 28 May '07

28 May '07

Hi Archlinux Community, 28th May, 22:00 CEST (Central European Summer Time) it's done final 2007.05 Duke Linuxtag2007 ISOs for i686 and x86_64 are ready :) Get Archlinux ISOs in /iso/2007.05-Linuxtag2007/{i686,x86_64} on your favorite mirror. Download_Wiki: http://wiki.archlinux.org/index.php/Mirrors or Download_Homepage: http://www.archlinux.org/download/>Download_Homepage Please don't forget to check md5sums. It's a little update to our latest ISO, to provide people who visits us at Linuxtag2007 booth :) the latest and greatest Archlinux stuff. Changelog to last Duke installation ISO: - kernel 2.6.21.3 usage Setup changes: - some minor text changes - selection to copy installation network setup to final installed system (bugs fixed) - selection of primary pacman sync server added (bugs fixed) for fixed bugs reference: http://bugs.archlinux.org/task/6767 Feedback about 2007.05 Duke installations is here: http://bbs.archlinux.org/viewtopic.php?pid=251210#p251210 I would like to thank you all, who assisted in testing and of course finding/fixing bugs, you users/devs simply rock. Happy installing and have fun. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] Duke CD covers
by Roman Kyrylych 28 May '07

28 May '07

Hi! In the Non-official CD-cover [Duke & Voodoo] thread PJ posted updated version of his cover design: LightScribe CD/DVD cover: http://www.geocities.com/kinortkele/archlinux-duke-cdlabel.tar.gz Normal CD/DVD cover: http://www.geocities.com/kinortkele/archlinux-duke.tar.gz Deutch language is available too! I think it will be very nice if they will be used on our CDs on LinuxTag! There is also current official design made by Elasticdog, but it was not yet updated for Duke (also, PJ's design looks better on lightscribed disc). -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] Absence: 28/05 - 11/06
by James Rayner 27 May '07

27 May '07

I'll be busy for at least this week, probably this fortnight. Busy with university exams, tests and assignments. I'll only be checking my inbox, not mailing lists and forums until I have time, so if you need me, send me a direct email. On return, i'll be pushing to have my network scripts merged, the current plan to merge them is on this page, but consider it a rough draft till I return. http://wiki.archlinux.org/index.php/Network_Scripts Cheers James

1 0

[arch-dev-public] back from vacation
by Varun Acharya 25 May '07

25 May '07

Hi all, Just got back from vacation, and am still fighting some crazy jet lag. Will get back to arch over the weekend. Thanks ganja_guru

2 1

[arch-dev-public] ISP problems, severely curtailed activity
by Tom K 24 May '07

24 May '07

Hi all. My ISP has decided to fsck up my DSL, so I'm on dial-up until they fix it. This means that I will only be online for a few short periods every day, long enough to check mail basically, and I will definitely not be uploading any packages. If anyone wants to update any of mine before I'm back, please feel free. All the best Tom K.

1 1

[arch-dev-public] Linuxtag: Final booth plan
by Christoph Neuroth 23 May '07

23 May '07

So, finally the Linuxtag guys and Messe Berlin finished the booth planning. We have a little bit more space now (4 instead of 5 projects on ~35m^2). http://www.linuxtag.org/2007/tmp/aufplanung/final/LinuxTag2007-12-20 Mandriva ansi.jpg http://www.linuxtag.org/2007/tmp/aufplanung/final/LinuxTag2007-12-20 Mandriva gf.jpg Not included in the plan is one table (80x160cm) for each of the projects. So we need to organize some tablecloth so we can use the tables to hide our stuff under it and make the booth look cleaner. only one week to go :)

3 3

[arch-dev-public] Crunch time
by Jason Chu 22 May '07

22 May '07

Things are heating up at work. We're going to be putting in lots of overtime to get from where we are now to our launch this summer. It would be unfair for me to not tell you guys that I'll probably be a lot less able to do random stuff. I'm still committed to my part of the repoman/archrepos stuff. I don't usually update packages, but I don't think there's much technical that's holding up any of my updates right now. Feel free to update any of mine that you want. I'm doing my best to keep up with the mailing lists and I'll still be on jabber often (probably even more often). If you have anything to say to me, I'll respond. I just can't commit a lot of time. Mid-august is when I expect to have moderately more free time. Jason

2 1

[arch-dev-public] [drotschm@linuxtag.org: [LT07-Pro-Announce] Infomail #6, Mai 21, 2007]
by Christoph Neuroth 21 May '07

21 May '07

No caffeine injection device allowed this year. bummer. no other big news. will be a lot of fun anyway :) cya in berlin. chris ----- Forwarded message from Wolfgang Drotschmann <drotschm(a)linuxtag.org> ----- Date: Mon, 21 May 2007 21:52:03 +0200 From: Wolfgang Drotschmann <drotschm(a)linuxtag.org> To: projects-announce(a)linuxtag.org Subject: [LT07-Pro-Announce] Infomail #6, Mai 21, 2007 Dear Projects, for final preparations we want to inform you about: o Booth Plans o Storage Space o Packing List o Exhibitor/Construction Passes o Cruising the Area of Messe Berlin for Delivery and Unloading o Arrival at LinuxTag o Construction and Dismantling o Parking Space o Conference Network and Booth Cabling o Accommodation o Tickets for the Social Events o Project Lightning Talks o 1st official LinuxTag project meeting Again, there's much to read for you :-) 1. Booth Plans Last week we had a long and hard working session with our partners at Messe Berlin about booth construction. Marko did a tremendous job by updating almost all booth plans. Please find the final booth plans at http://www.linuxtag.org/2007/tmp/aufplanung/final/ and draw necessary information for your presentation. Those which are mising will appear tomorrow May 22th. Plans for Hall 12 http://www.linuxtag.org/2007/tmp/aufplanung/LinuxTag2007-Halle-12.pdf and Hall 14.1 http://www.linuxtag.org/2007/tmp/aufplanung/LinuxTag2007-Halle-14.1.pdf show you the final layout of the fair. If you miss something at your booth, you can order it directly from Messe Berlin using the following form: http://www.linuxtag.org/2007/fileadmin/linuxtag/downloads/aussteller/mappe/… English version of this document available on request. 2. Storage Space Where possible we tried to integrate coops (Germans would say Kabüffchen as a diminutive [1] of Kabuff) at the booths. We urge projects to share this space with other close-by projects. The overall plans of the halls tell you that there will be storage rooms (read "Lager" in the plan) available for all projects. We will assign few keys to persons who will be in charge for access for these rooms. Additionally there will be a wardrobe where all of you can deposit coats, luggage and stuff like that without cost. Please ask all your booth colleagues to store their private stuff there. 3. Packing List "My name is Open Events Foundation, and in my suitcase I pack..." --- maybe you know this little kindergarten play ;-) As an old veteran, you will have at least the following items in your equipment box: o tableclothes for the infocounters and tables (in colors that fit to your booths colours) o poster o flyers o nameplates for your booth staff o power extension cords and power multiplier sockets o LAN - network cables (long, short, Crossover) - switches Power and Internet will be provided by LinuxTag and Messe Berlin for the project booths. You don't have to worry about these. However, you'll need to take enough extension cords and power multiplier sockets with you. We cannot provide them in a proper number for all projects. If you use a cable drum for distributing power, please make sure not to connect any computers or monitors to it unless you've pulled off the entire cable. If you plan to present special hardware, like several servers, which will consume very much power, please contact us. Please leave the following things at home: o wireless access points You are not permitted to operate your private wireless LAN. Please take this serious. There will be several site surveys to ensure this. Please read more about networking later on. o coffeemakers, kettles and cooking stuff 4. Exhibitor/Construction Passes If you have not received construction passes yet, we urge you to get in touch with us! You can pick up exhibitor passes only on Monday, 28th, and Tuesday, 29th, at the Project Office. Concerning status of your ordered pases please visit the vCC. Deadline for further orders for exhibitor and construction passes is Wednesday, May 23rd. 5. Cruising the Area of Messe Berlin for Delivery and Unloading Messe Berlin seems to be nearly a planet of its own. If you arrive there for delivery with your vehicle, use gate 9 only to enter the area, then follow signage to hall 12. For a rough orientation please see this map: http://www.linuxtag.org/2007/de/community/projects/infomail-6.html#c3261 Make sure to have a deposit of 50,- EUR in cash ready at hand. For cars it allows you to drive on the area for two hours, lorries have three hours. For details please have a look at the "Verkehrsleitfaden" at http://www.linuxtag.org/2007/fileadmin/linuxtag/downloads/aussteller/mappe/… 6. Arrival at LinuxTag As mentioned above, you can only enter the fairground with a valid 'setup exhibitor pass' or an official 'exhibitor pass'. If you come by car to LinuxTag, please see Cruising the Area of Messe Berlin for Delivery and Unloading above. If you have any trouble finding the right entrance or finding your booth, please call the Project's Office and ask for help. We will announce the official phone numbers during this week. Your project manager should step by at the Project's Office as soon as possible to inform us about your arrival, to pickup the prepared welcome package -including your exhibitor passes and social event tickets- and get the latest news from Marko or Wolfgang. The office is located at the bridge to the ICC. Please notice: Messe Berlin handles this very strict. If you stay longer than 120 minutes with your car within the fairground the deposit will be lost. 7. Construction and Dismantling Wednesday, 30th, LinuxTag will open its doors. There will be a kind of opening ceremony, and most likely some VIP will come for this and visit the fair. We all want to give a good impression, so your booth does need to be ready at this morning! We ask you to set up your booth on Monday, 28th, or Tuesday, 29th. With two whole days (from 7 am to 10 pm) we have enough time to sort things out, and are not in a hurry while visitors come to visit your booth. We all aim and hope for a successful event. However, everybody will be glad after days of hard work at the booth when the exhibition ends. While understanding to start with dismantling to get on the way home, we don't want you to start with this process too early. Please try to put yourself in visitor's shoes - most of them would be surprised, to phrase that cautious, at the fact that everybody starts to tear down their booths while the exhibition hasn't ended. We ask you kindly to keep this in mind. Dismantling of the booth has to wait until 6:00 pm on Saturday, June 2nd. This can be done without hurry on Sunday, 3rd, from 7:00 am to 10:00 pm, too. 8. Parking Space We recommend P3 at 'Hammerskjöldplatz'. More space is at P10. Motor trucks should be driven to P12 (near AVUS). If all fails, there is P14 at the 'Deutschlandhalle'. Again, please see the map from above. 9. Conference Network and Booth Cabling Please be advised to take network cables of different length with you. You will also need some switches for the inner-booth network. We will provide an uplink at each isle or at least at a neighbours booth. These uplinks will are marked with a red flash-symbol in the detailled booth plans. Additionally we will install a single twisted pair cable through the false bottom from the uplink to each point marked with a red cross. Please lay all your cables along your booth's walls and never lay a cable so that a visitor may stumble accross it. Unlike last event, this year LinuxTag is not responsible for the network. It is set up by T-Systems, contractor of Messe Berlin. T-Systems will provide a separate LAN for all projects. This will be a private Class B network, where about half of the IPs are distributed using dhcp with realtively long leasetime (1 day). The other half of the address space will be distributed using peg-dhcp where each booth/project will get at least its own 256 static addresses (see rfc-2322 for further details). There are always some experts, which provide their own dhcp service to all other projects, which results in a big network mess. To be on the sure side, we advice you to use your peg-dhcp address pool for your booth's systems. Please notice: the whole network will be behind a NAT router and some ports (many unencrypted protocols like telnet, pop3, imap or smtp) to the Internet will be blocked. Please use their encrypted pendants (ssh, pop3s, imaps, submission/smtps). If you need a public IP, please contact us immediately and give us a reasonable explanation, why you will need this. Please use the wired network for your booth, because the public wireless LAN will be only available at some points of interest, like the conference hall or the hackcenter. It is not allowed to operate your own wireless network at your booth. In any case we ask you not to connect visitors to the project's network. They can use the wireless network or visit the hackcenter. Please let us recapitulate the three don'ts: o bind a dhcp-server to the project's network (we already have one ;-) o operate a wireless network o connect visitors to the project's network A detailled information sheet with all facts about the network can be found in the project's welcome package. 10. Accommodation Please share hints -for accommodation or in general- by using the LinuxWiki [2]! 11. Tickets for the Social Event When we asked you to order some sponsored and threrfore cheaper tickets for the Social Event (details at LinuxNacht [3]) in advance, we asked you to do this in reasonable amounts. Because we have only a certain and limited amount of reduced tickets at our disposal we have to wait for pre-orders of all interested projects. If we get more orders than we have tickets at hand, we will have to distribute those in a fair manner to you projects. Deadline for pre-ordering sponsored tickets is Thursday, May 24th. 12. Project Lightning Talks A novel feature of this year's conference program is a track called "Project Lightning Talks", PLT for short. This is an opportunity to present your project's exhibited highlights quickly and without much overhead nor lengthy preparation. Each slot is just 15 - 20 minutes and should highlight your most exciting exhibit. The PLTs take place at the open Forum directly between halls 12 and 14.1 and are a excellent way to attract visitors to your booths. We have a total of 14 slots, which are assigned first come, first served. If you are interested in a slot, please send a message to our colleagues of the conference team at vp(a)linuxtag.org including: o a short title of your presentation, o one or two paragraphs of description, o who is presenting (including name, email, and affiliation). The tracks are scheduled o Wednesday, May 30th, 12 - 15 and 16 - 18 o'clock, and o Saturday, June 2nd, 13 - 16 o'clock. We have a small stage, a projector, microphone all prepared. Please bring a notebook, or arrange one with your booth neighbours. 13. 1st Official LinuxTag Project Meeting The Projects Committee wants to meet all of you Project Managers in person. What? - let's talk in a relaxed atmosphere about o Feedback Organisation 2007 o Feedback Booth Construction o Handling of 'Commercial Projects' o Constitution of a Projects Advisory Council o Date and location of LinuxTag 2008 o Ideas, wishes and schedule for LinuxTag 2008 When? - Wednesday, 30th, 18:30 - 20:00 Where? - room Workshop 1 (ICC-B/R44) That's it for now. Do not hesitate to contact us at projects in case of qestions of praise! Regards, Susanne Pfeifer, Wolfgang Drotschmann, Marko Jung & Martin Schulte Project Committee LinuxTag 2007 [1] http://en.wikipedia.org/wiki/Diminutive [2] http://linuxwiki.de/LinuxTag2007 [3] http://www.linuxtag.org/2007/en/besucher/linuxnacht.html ----- End forwarded message -----

1 0

[arch-dev-public] Fun with updatesync
by Paul Mattal 21 May '07

21 May '07

I'm getting these sorts of errors from the AUR update script, which is I think what's keeping the AUR updates from completing: ==> ERROR: could not find ekg-1.7-1-i686.pkg.tar.gz - aborting Do I need to use the old version of updatesync or is there some way to tell the new pacman 3.0 updatesync to look for old-name-style packages? I think this broke right around the update to pacman 3 on gerolde, so this make some sense. - P

2 1

[arch-dev-public] gcc 4.2 in testing
by Jan de Groot 20 May '07

20 May '07

GCC 4.2 made it to testing. I don't expect compatibility problems for gcc itself, but I do expect gcj and fortran programs to break: libgcj and libfortran bumped soname. This means all fortran apps that link against libfortran will need a rebuild and that all apps that have been compiled to native code with gcc-gcj will need a recompile. These programs will get recompiled soon. For gcc-gcj, I don't expect any program to use native code, the only one I've seen for now is gjdoc, which is already built with it. The new GNU hashing style supported by gcc 4.2.0 isn't included, our binutils and glibc don't support it. I've read something about 2MB bigger libraries because of another extra hashtable added to every lib, so I don't feel much for backporting or switching to a 2.17.xx binutils release now. Happy testing!

3 2

[arch-dev-public] Community repo db problem?
by eliott 19 May '07

19 May '07

Looks like community is having the same problem current was. http://bugs.archlinux.org/task/7212 http://bbs.archlinux.org/viewtopic.php?id=33194

1 0

[arch-dev-public] New firefox not in the db
by Aaron Griffin 18 May '07

18 May '07

http://bbs.archlinux.org/viewtopic.php?id=33157 Just figured this was worth mailing out here. Could someone fix this if they get a chance?

3 2

Re: [arch-dev-public] Package Cleanup: Part II
by Travis Willard 18 May '07

18 May '07

On Fri, 18 May 2007 14:38:22 -0500, Aaron Griffin wrote > The core thing won't happen for a bit though, as it's a bit more > complex than everything else, but I figure if we can move non-core > packages out of current, the rename will be fairly easy. Wouldn't, then, everyone have to change pacman.conf to refer to core/os/i686? Or are we going to symlink it? If we're symlinking it, what's the point of the name change in the first place? :P Is this another one of those 'push it into a new pacman package, then wait a year and hope everyone's upgraded' kind of issues? (on a side note, I really have to start remembering to set my webmail to use the archlinux.org address when I send these things from here - I keep getting blocked awaiting approval 'cause I forget. :P) -- Travis

2 1

[arch-dev-public] linuxpowertop.org patches
by Jan de Groot 18 May '07

18 May '07

Morning, Given our recent firefox SSL problems, and now this one with pidgin: http://bbs.archlinux.org/viewtopic.php?id=33136 I won't include any linuxpowertop patches anymore, I will remove the one from pidgin at least. I wonder if these guys from linuxpowertop.org test their patches, removing a "useless" timer that isn't useless breaks things it seems.

2 1

[arch-dev-public] broken firefox 2.0.0.3-2
by Paul Mattal 17 May '07

17 May '07

The patch introduced in this version breaks my ability to talk to my standard https webserver. The first one or two gets go fine, but after that, nothing.. from same or other https servers, until I restart firefox. Anyone else seeing this large problem? Why are we including this new patch? Is it intended to go in upstream? - P

3 2

[arch-dev-public] 2007.05 Duke ISOs released
by Tobias Powalowski 17 May '07

17 May '07

Hi Archlinux Community, 17th May, 16:10 CEST (Central European Summer Time) it's done final 2007.05 Duke ISOs for i686 and x86_64 are ready :) Get Archlinux ISOs in /iso/2007.05/{i686,x86_64} on your favorite mirror. Download_Wiki: http://wiki.archlinux.org/index.php/Mirrors or Download_Homepage: http://www.archlinux.org/download/>Download_Homepage Please don't forget to check md5sums. Torrents are already up and seeded. Metalink packages will be prepared soon. Changelog to last Voodoo installation ISO: - pacman3 usage - kernel 2.6.21.1 usage Setup changes: - soundcards are now also ordered by hwdetect - rsync has been added to installation environment - proxy support during ftp installation - selection to copy installation network setup to final installed system - selection about keeping package cache during cd/ftp installation - selection of primary pacman sync server added - fixed grub installing on software raid devices Bug collector of fixed showstoppers is here: http://bugs.archlinux.org/task/6767 Feedback about 2007.05 Duke installations is here: http://bbs.archlinux.org/viewtopic.php?pid=251210#p251210 I would like to thank you all, who assisted in testing and of course finding/fixing bugs, you users/devs simply rock. Happy installing and have fun. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 4

[arch-dev-public] Old gtkmm package removal
by Jan de Groot 17 May '07

17 May '07

Looking at http://bugs.archlinux.org/task/7180 : We imported these packages (gtkmm1, gtkmm2.2) because we had apps that required it (I remember packaging gtkmm2.2 for passepartout which never made it to our repositories). I already cleaned gtkmm2.2 and libsigc++2, the one left here is gtkmm1 and its dependency libsigc++: [jan@laptop pacman]$ grep gtkmm1 */*/depends extra/ickle-0.3.2-1/depends:gtkmm1 [jan@laptop pacman]$ grep libsigc++ */*/depends | grep -v sigc++2 extra/gtkmm1-1.2.10-2/depends:libsigc++ extra/libicq2000-0.3.2-3/depends:libsigc++ extra/libuta-0.4.4-1/depends:libsigc++ [jan@laptop pacman]$ grep libicq2000 */*/depends extra/ickle-0.3.2-1/depends:libicq2000>=0.3.2 [jan@laptop pacman]$ grep libuta */*/depends [jan@laptop pacman]$ [jan@laptop pacman]$ pacman -Ss ickle extra/ickle 0.3.2-1 ickle - a icq2000 client First, we have ickle, which requires gtkmm1 and libsigc++. Then we have libuta, which is a library used by nothing. Given the fact that gtk1 and especially gtkmm1 is very old and unmaintained, I would like to remove them from the repositories or move them to unsupported. According to archstats, there's 2 users having ickle installed, where we have lots of users who have a different ICQ client installed (gaim/pidgin, kopete and possibly others). What's our opinion on this? Purge or move all these packages?

2 1

[arch-dev-public] Master Server (gerolde.archlinux.org) reboot scheduled for today.
by Dale Blount 16 May '07

16 May '07

It's been a long time coming - we really need to reboot gerolde and apply updates. It's been good to us for 7 months :) Approx 1:30 EDT today I will -Syu and reboot gerolde. Please refrain from uploading packages / updating around this time so it is not interrupted. Kexec should kick in and only require about 60 seconds for a reboot if all works well. Are there any known issues with django and the new python? Or flyspray and the new php? Anything else like that? Thanks, Dale

9 21

[arch-dev-public] Unused websites?
by eliott 16 May '07

16 May '07

Greetings, I was taking a look at the list of websites that AL provides this evening. I ran across a few sites that I had actually forgotten! Arch Artwork Gallery - art.archlinux.org Development Blog - blog.archlinux.org Just curious how much traffic these sites get, and if it would be reasonable to drop them or not. I know I haven't made much use of them in the past. My thinking is as follows: Art.archlinux.org -- This site doesn't seem to get much use. Most of the screenshot action is in the forums, in the screenshot threads. I have seen a few wallpaper threads rolling around in the forums too. blog.archlinux.org -- Not sure how visible this is, and how used it is. I *do* see posts on it, but hardly ever any comments. I do not know how much community engagement it has. If it is just "one more place for noise", perhaps we could just drop that, and post those type of news items on the front page along with other news. Thoughts? Ideas?

6 12