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

Re: [arch-dev-public] test
by Aaron Griffin 16 May '07

16 May '07

On 5/15/07, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On 5/15/07, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > > gerolde reboot, testing the ml > > > > Away we go, mailman upgraded.... anything borked? > Omg brokens?

2 1

[arch-dev-public] test
by Aaron Griffin 15 May '07

15 May '07

gerolde reboot, testing the ml

1 0

[arch-dev-public] FTP (re)organization
by Thomas Bächler 15 May '07

15 May '07

While discussing with Dale about where to put the new isos, the issue of the ftp organization came up: Right now, we have subdirectories, 0.1, ..., 0.8 and current is a symlink to 0.8. This is bad for several reasons. It suggests that we have a "release", which we don't. And everytime we release a new version, we move 0.X to 0.Y, and re-set the current symlink, that means the mirrors will re-pull all the current packages (which they already have, but download anyway). I suggest doing this for cleanup: - rm current; mv 0.8 current (I know this will cause the same problem as described above, but at least it will be the last time) - rm release - remove all isos from current/iso/* and replace them with the new ones (this means we won't keep the old isos, but do we need them?) - ln -s current/iso iso-download so that people can find the isos more easily on the mirror. Any objections/suggestions?

10 23

[arch-dev-public] duke isos i686 ready for testing
by Tobias Powalowski 14 May '07

14 May '07

Hi guys just to inform you new duke isos are hosted here meanwhile: http://www.archlinux.org/~tpowa/duke-isos/ they are not tested yet at all, will do some tests tomorrow, if you have time try to break them here is the changelog: Hi Arch community, Arch Linux Duke 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 system - selection about keeping package cache during cd/ftp installation - selection of primary pacman sync server added greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 13

[arch-dev-public] bugtracker vs package cleanup
by Roman Kyrylych 13 May '07

13 May '07

Because many packages will be moved to Community I'd like to point few things regarding our bugtracker: 1) there is some amount of open bugreports for packages that are moving to Community/Unsupported. 2) there will be more packages in Community which means there will be larger amount of bugs in them (summarized). Maybe it's a time now to create a new project in Flyspray for Community packages, and give all TUs permissions to assign/edit/close bugs in that project? Besides of a bit better tracking of bugs in Community packages this will allow to move those open bugreports for Community packages to new Flyspray's project. Or should Community packages continue to use AUR comments for reporting and discussing bugs? Opinions? -- Roman Kyrylych (Роман Кирилич)

5 7

[arch-dev-public] we want to give x86_64 a new direction
by Andreas Radke 13 May '07

13 May '07

after beeing an official port as a 100% i686 clone with a common cvs we have seen that we can handle the workload with only 2 man in not a bad way but with tons of hours of rebuilding and uploading the packages. but we don't want that anymore. it's simply too much workload and a task we are tired to do. bringing on new packagers is harder than expected. repo cleanups and a possible not to far away start of pacbuild/repoman will not drop down the workload we would need. i686 devs are not able to handle 32bit stuff very well so i don't count on crossbuilds anymore. that's one reason. the other one is beeing an i686 clone depending on its (not well defined) goals makes me sick. i miss any freedom in my work. at least the poor i686 testing procedure is something i don't want to follow anymore. i got more and more afraid how chaotic the developement is going on whithout the possebility to change it. now i see things start changing what is very good. but it seems most devs want to keep i686 the compromise of beeing bleading edge + at least some stability. i haved proved to build a system almost from scratch to the quality we now have. we are no more behind i686. a big part of that goes to the i686 devs and their most times simple and working packages and the easiness to port them. the Arch tools are great. but my personal goals have changed. together with Daniel we have found a few people that would support us if can go our own way. We have worked out some initial goals: - we want Arch x86_64 the more conservative sister distribution of Arch - less bleading edge - still a rolling system with up to date packages - strict rules how packages go through a testing cycle - we expect a significant lower workload due to longer update cycles and less post-release-fixing of broken stuff - only provide a basic core repo by the devs - setup some basic addon repos - open the addon repos to be maintained by the community and reviewed/released by the developers untill community members have proved to do it the same way. that's something where we are not sure where i686 wants to go and if we will adopt it. - it would not be prepared to have an x86 port. but only one x86(i586?) dev would be enough to rebuild that distro with some help by an automated build system. All in all it would be nothing significant different from the port we now have but packages would be more selected and hit the repos later to ensure the improved stability. we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers. the first step that would need to be done is to splitout our scm. i cannot image to keep working with a common scm. that's what now makes it the clone we don't want to have any longer. if you agree to give us that freedom back, i already have one good candidate for becoming a new x86_64 developer and several community members promised to help out. they all like our goals. at least that we will have some. AndyRTR

5 9

[arch-dev-public] -ARCH package extension
by Paul Mattal 13 May '07

13 May '07

Since pacman 3, makepkg builds: foo-2.9-1-i686.pkg.tar.gz instead of the old foo-2.9-1.pkg.tar.gz What is our migration path for using that in all the repos? More specifically: * How do we tell pacman to start using the new syntax when looking for packages? Do we need to, or do the repo db files take care of that? * How do we synchronize the update of devtools and aurtools? * How do we control/manage the propagating all that via mirrors, since all the filenames will change and each mirror will essentially want to do a full re-download? * Do we announce some time for a flashover and tell devs not to update packages during that time? Maybe someone's already figure this all out, but it would be nice to know how this is going to be handled so we can decide what to do to plan ahead. - P

6 12

[arch-dev-public] thoughts about next release
by Roman Kyrylych 13 May '07

13 May '07

Hi! As Tobias said: "kernel 2.6.21 series is now in testing, it will be the kernel series for next release". According to the schedule published by Paul repositories reorganization will be finished not earlier than in the middle of Summer. And in this announcement http://www.archlinux.org/news/308/ we said that "When the next kernel 2.6.22 is released, we will push out a new ISO image". So, here's how I see variants for next release: 1) release new ISOs based on 2.6.21, using the current scheme (ftp+base+current) additional possible changes: * provide snapshot of extra (and community?) for download via BitTorrent * FTP reorder as described here: http://www.archlinux.org/mailman/private/arch-dev/2007-March/005087.html 2) wait until 2.6.22 (hopefully it will be released after repositories reorganization) or even a bit longer and release new ISO set: core & ftp as CDs and main(extra) + community snapshots as DVDs. Changes that should be done in any case: * remove release version and codename from /etc/issue * remove /etc/arch-release * call new release as "ISO release" or "snapshot" instead of "Arch release" * make users understand that there's no such thing as "release" in Arch Linux. :-) -- Roman Kyrylych (Роман Кирилич)

6 12

[arch-dev-public] pr0n on flyspray!
by Roman Kyrylych 13 May '07

13 May '07

Please ban this user: http://bugs.archlinux.org/user/1906 He just posted a comment with attached pr0n file here: http://bugs.archlinux.org/task/6757#comment16273 (already deleted by me) -- Roman Kyrylych (Роман Кирилич)

2 2

[arch-dev-public] Package cleanup - implementation
by Aaron Griffin 12 May '07

12 May '07

This is a note for the developers. If you haven't seen the busy thread on the general list regarding package cleanup, this wiki page should cover everything: http://wiki.archlinux.org/index.php/Package_Cleanup Before the end of the weekend, I'm going to move most of these packages based on what is there. There are a few that are questionable, however, so please voice you opinions if you don't want things touched. Thanks Aaron

6 11

[arch-dev-public] mkinitcpio 0.5.14
by Thomas Bächler 12 May '07

12 May '07

I released mkinitcpio 0.5.14 today. Here is a short, incomplete changelog: - drops you into a fallback shell if the root device couldn't be found - modprobe is now in /sbin instead of /bin. As this is consistent with the main system, we do not have to change it back before calling kinit. Therefore kernel module autoloading can still be done while kinit is running, may fix some rare issues. I also updated klibc-udev, mdadm, cryptsetup and lvm2 to use the new path and added a symlink in /bin just to be sure - a small bugfix to allow shared objects to be used in BINARIES (came up when archboot tried to add portmap, which according to file is not an executable, but a shared object, wtf?). - more bug fixes (and bugfixes to fox bugfixes) This should be on the Duke iso, too. Have fun Thomas

1 0

[arch-dev-public] Driver Maintainers
by Alexander Baldeck 12 May '07

12 May '07

Hey all, as you may have noticed I picked up X.org from Jan to take some load off of his shoulders. I'm very proficient in doing the whole X.org thing since I've done so over a phase of like 3 years in a professional environment. Then again, testing quickly became a problem. I can't possibly come up with all the hardware to actually more than just build-install-test most in x11-drivers. I would suggest that we assign TUs who have these chipsets as testers or even maintainers. We could even drive this further with other packages where we didn't do so yet: * lirc * madwifi * wlan-ng aso. It would further go into the direction of packaging divisions and raise quality of our packages. Opinions? Ideas how this can be implemented without changing our system to much and everybody still being fine with it? Cheers, -I

4 6

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

11 May '07

Here we go... oh, and remember: theres the IRC meeting tomorrow afternoon... ----- Forwarded message from Wolfgang Drotschmann <drotschm(a)linuxtag.org> ----- Date: Fri, 11 May 2007 14:08:57 +0200 From: Wolfgang Drotschmann <drotschm(a)linuxtag.org> To: projects-announce(a)linuxtag.org Subject: [LT07-Pro-Announce] Infomail #5, May 11, 2007 Dear Projects, we have details about the booths, and... but please read on! o Deailed Booth Planing o Cruising the Area of Messe Berlin for Delivery o Setting up the Booth o Security / Insurance o Advertisement at Sponsored Booths o Application for Sub-Exhibitors o Project Workshops / BoFs o Key Signing o Accommodation o Social Event Thank you for your logos and stuff - we fed it into the pipeline for the catalogue. 1. Detailed Booth Planing Thank to our partner Messe Berlin we have detailed views of quite a number of islands and booths. Those which are mising will appear about noon of May 14th. You can review these sketches here: http://www.linuxtag.org/2007/tmp/aufplanung/ Please tell us until May 15th, 2007 (via mail to projects(a)linuxtag.org) what you think - is everything all right? 2. Cruising the Area of Messe Berlin for Delivery You will see - Messe Berlin is a far and wide area, nearly a planet of its own. If you arrive there for delivery with your vehicle, make sure to have a deposit of 50,- EUR in cash ready at hand. It allows you to drive on the area for one hour. We will send you more detailed information about delivery and unloading with the next Infomail. 3. Setting up the Booth 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. 4. Security / Insurance Let us remind you to take care for your stuff at the booths and islands. We try our best to organise a lockable storage room for your hardware and other things which need not to be at the stand. Please give us time to the middle of next week, when we have a meeting with our partners at Messe Berlin. However you can contract insurance for hardware and stuff, including transportation at your own cost, provided by the "Ausstellungsgut-Versicherung". You can find this document here: http://www.linuxtag.org/2007/fileadmin/linuxtag/downloads/aussteller/mappe/… Generally speaking it may be a good idea to scan through the list of services and order forms, offered by Messe Berlin: http://www.linuxtag.org/2007/en/expo/expo-service.html 5. Advertisement at Sponsored Booths For LinuxTag organization it gets harder to decide for some projects whether it will get a booth (sponsored by LinuxTag) or we have to charge them for it because of its strong commercial background. This decision is not easy to make and differs in each case, but we try to make it fair for everybody. Therefore we have to insist on a special agreement with the projects exhibiting at a booth free of charge: advertising for associated companies is not allowed at project booths sponsored by LinuxTag! It is not allowed to display brochures or price lists or hang-up posters for affiliated companies. Of course you can still present your projects flyers, brochures, DVDs or other promotional material with logos from sponsors. If your company wants to get promoted at your project booth, please encourage it to contact us for information about sponsoring options. Several companies already used this option to advertise at affiliated project booths. If you have any questions, even after reading the FAQ entry, about advertising at your booth feel free to contact us. 6. Application for Sub-Exhibitors While looking at the FAQ... If you plan to host another project at your booth, you need to ask us beforehand. This is usual business at fairs. As long this does not have a commercial background we don't see much problems here. By asking us for permission this project will get known to a wider public, because we require information about this sub-exhibitor to put this on our website, like the other projects, too. 7. Project Workshops / BoFs We still have quite some slots left for workshops. What's up? Keep in mind that LinuxTag has to book rooms for this, the ultimate deadline will be reached next week: Wednesday, May 17th, 2007. 8. Keysigning Party Maybe a good chance to meet people, but definitely perfect to strengthen your Web of Trust! The party will be on Friday, June 1st, at 14:00. Please see http://www.linuxtag.org/2007/en/community/keysigning.html for all the details. Alexander Wirt will organise this event. If you want to participate, please read carefully his instructions for sending in key-ids and such. As usual, the party will be conducted using Len Sassaman's efficient group key signing method. 9. Accommodation We are very sorry but there is no gym available far and wide in the whole urban district. If you belie us, please tell us so. Please insert hints about recommendable accommodation and any other interesting stuff into the LinuxWiki, initiated by Sven Guckes. 10. Social Event We will have a get-together! LinuxNacht will begin on Thursday, May 31th, 2007, from 7:00 p.m. on, at the Umspannwerk in Kreuzberg. For more details please follow this link: http://www.linuxtag.org/2007/en/visitors/linuxnacht.html Community members will have the opportunity to buy sponsored tickets (15 EUR per ticket). Don't wait too long, because we only have a limited number of those! You can order them by sending a mail to the usual projects address and tell us the number (reasonable amounts only). Booked tickets should be available (in return to money) at the projects office on Monday, 28th, 2007. Hey, the event gets closer and closer! Do you feel it, too, geting more and more fidgety ;-) Regards, Susanne Pfeifer, Wolfgang Drotschmann, Marko Jung & Martin Schulte Project Committee LinuxTag 2007 ----- End forwarded message -----

1 0

[arch-dev-public] Archlinux [current] status
by Tobias Powalowski 11 May '07

11 May '07

Hi something is really going wrong at the moment. People claim for having other interests or not time for doing the packaging work. I start here only with [current] first. Jan quit doing maintenance of important parts of our distro and probably also of doing quite some update tirades through current. Let me stress this, from my point of view Jan and me did the most [current] updates the last weeks, even if we didn't use the software for our own stuff, correct me if im wrong. We have inactive package maintainers, no doubt. Judd, Dorphell, Aurelien, Gregor, Woody, Arjan It's time to cleanup [current]. Orphan all packages of Judd, Dorphell, Aurelien, Gregor 1 week of time to grab what packages you wanna have. Keep in mind it's your job then to test and ensure that the package works! Please one of the enablers do this, or give me the permission to orphan them. After that period, look whats left if noone feels responsable for a package make a list of possible drops or try to find one on ML who wants to maintain it. It's better to have 1 maintainer for just 1 package who is active and knows the package well, then 1 who just cross updates because he saw the version bump. come on guys participate it's the base of our distro! Without it Arch cannot work. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

9 17

[arch-dev-public] Away for a while
by Tobias Kieslich 11 May '07

11 May '07

Hi, as of Monday evening I will be away from the computer for most of my time as I go visiting home for two weeks. So I shall be back for the developer meeting. Just update my packages a needed I will also get rid of a couple of my packages that I don't use at all and maintain not really very well. They will be about 30-40 By the same time, if everyone agrees, I can pickup officially the xfce stuff since Aurelien seems to be very inactive. -T

3 4

[arch-dev-public] Beginning: arch projects
by Aaron Griffin 11 May '07

11 May '07

So I've been trying to get together this "arch projects" interface for some time now. In essence, the "interface" is is a chunk of python modules to help with creation of projects in a similar vein as code.google.com and repo.or.cz. I have made a *ahem i-suck-at-css ahem* python cgi overlay, but that's still incomplete. For now, however, I've begun the backend setup. This will live here: http://projects.archlinux.org/ For now, this is all kinda manual - but if you want a repo or project setup, I can do that. In the future, developers will be able to create this stuff themselves and add other users from the community to the access list (without needing a shell account on gerolde). I've been trying to finish this up in between everything else, and it's slow going, but almost there. The initial release won't have any sort of bug tracking support, because I'd rather not write my own - I'd much rather integrate an external bug tracker into the mix... but that gets complicated. I know I keep saying "soon" and I said "1 week" about 3 weeks ago... but a lot of other things keep getting in my way. This is more a "heads up" mail, and to point out that if you want some crap on gerolde, I'm beginning to setup the infrastructure. Aaron

1 1

[arch-dev-public] Core Issue in Multiple Architecture
by Paul Mattal 10 May '07

10 May '07

So here's what I see as the most important counterfactor to Arch growing comfortably into a multi-architecture distro: HOW do we make it easy for OLD devs to TEST easily on MULTIPLE platforms? Building we have covered, at least in the long term. But time has shown that deploying packages without proper testing is not smart. This means (I think) at LEAST installing the package and running at least one program that is part of the package; for some packages, I know I put them up on one of my servers and let them run for a few days before pushing them to [extra]. So the next time I build the next release of dovecot, how can we make it easy for me to test it? So far, I see no good solution. What doesn't seem fair is to expect the devs who signed on with x hours of time to give per week to maintaining i686 packages to maintain packages on other architectures if it will require: 1) more hardware purchases 2) significantly more time Remember, we're all here scratching our own itches. I agree that the idea of multiple architectures is a nice one, but if I have to put in 2x hours per week maintaining packages when I already can barely find the x hours per week I need to maintain the ones I have, it's just not possible for me to take this on. So I see two solutions: 1) See if more developers come along for other architectures. This isn't something we can "make" happen, unless someone's got a rich uncle who's willing to pay them! We should make it clear we're looking for help, and if people want to help, they'll come. 2) Reduce that 2x to something smaller. This *is* something within our control.. we can try to solve the technical problems which currently make it hard to develop for multiple architectures. This is meant as a starting point for further discussion, and also a means of conveying, for instance, why I haven't started building for x86_64. I'm not even running an x86_64 box, even though most of my computers are Athlon64s. Since I have to choose between developing and testing on one or the other, the barrier is very high. Let's try to make it lower. - P

3 3

[arch-dev-public] Repoman Update: 5/9/07
by Paul Mattal 10 May '07

10 May '07

I wanted to update everyone on current progress on the Repoman project! You can review the project manifest from my April post: http://archlinux.org/pipermail/arch-dev-public/2007-April/000524.html The big objectives for the past week were: * getting 7 people on board for the project: sysadmin, publicist, 3 developers, 2 community members * getting the development box up and working * spread the word about the project PEOPLE So far we have 3 people on board! Better than I expected, actually-- good people are the hardest thing to find. Tom Killian - PUBLICIST Dan McGee - DEVELOPER Alexander Baldeck - DEVELOPER For now, I will act as sysadmin, but we're still looking for another developer and some community members to agree to be part of the project! Please read the project manifest from above and let me know if you are interested. DEVELOPMENT BOX After a small fight with the 0.8 installer and RAID, we now have a development box home for repoman. It's at repoman.mattal.com for now unless/until we decide to make it repoman.archlinux.org. TomK, Dan, and Alexander, send me your preferred username and a temporary password privately, and I'll set you up shell accounts. We also have a source code repository. It currently lives on another box, which has an SSL certificate, so it may stay there for at least a while: https://subzero.elys.com/svn/repoman/ This is world readable. Right now it only contains some notes and musings, but later it will hold our source code. Alexander and TomK, send me an htpasswd -n line and I'll give you commit access. Feel free to add things as you see fit. I hereby ask Aaron, King of Mailman, to create a repoman(a)archlinux.org mailing list for our group, using me as owner. Let's start with one list until we should happen to need more. Once that's in place, I'll stop doing updates on this list and start doing them there. SPREAD THE WORD We should all continue to spread the word about the project. I'd especially still like to find one more developer and a sysadmin immediately. We may involve some of the other devs informally and give them svn commit access as it makes sense, but I think having a core team of three developers PLUS me will put us in a good situation for starting. TomK, can you spread the word in the forums and the IRC and elsewhere where we may not have covered? We should probably also have a webpage for the project.. if you can tool up some simple HTML, I'll install apache on the server and you can drop it in. Finally, we should all continue to think about the SCM system, as it will be the underpinnings for repoman. It's been a busy week for me, so I need to go catch up on the google group exchanges. It seems like svn is winning, and it's mostly about the details of how to arrange things. Thanks! - P

2 1

[arch-dev-public] pacman upgrade issue (was: ArchLinux [current] status)
by Aaron Griffin 09 May '07

09 May '07

On 5/9/07, Jason Chu <jason(a)archlinux.org> wrote: > On Wed, May 09, 2007 at 12:52:31PM -0500, Aaron Griffin wrote: > > Jason, can you take this task on? I want to > > a) figure out a solution to the pacman upgrade issue > > b) deal with the package cleanup > > So I don't have huge amounts of time to spare at the moment. > > I am also lacking in time. Can you explain the pacman upgrade issue a > little better (there was a bug report about it at one point, right?)? > > I will make sure something gets done, but I doubt I'll be the one to do it. Here we go. I was about to move pacman 3 to current last night and realized there is a minor show-stopper in the upgrade path. The way pacman 2.X works, when it finds an upgrade for itself, it removes _ALL_ additional targets from the list and adds pacman. At this point, deps have already been resolved. So, the new pacman depends on libdownload and libarchive. Clearing out the target list also removes these. So pacman will download pacman3, then try to install it, and fail because dependencies are missing. This is not a critical issue, as one can easilly -S those two, but it is not clean. When this moves to current, there will be many people with problems, and not everyone checks the news items / reads the forums. The use case will go as follows: pacman -Syu "New pacman is available, upgrade? [Y/n]" Y ...download pacman 3... Whoops, cannot find dependencies "libdownload" or "libarchive", failing "Hmmm, wtf?" pacman -S libdownload libarchive pacman -Syu Again, this is not critical, not fatal, and not a big deal, it is just messy. I want to figure out if there is some good way to do this, but I do not think so.

8 20

[arch-dev-public] going to start a new ArchLinux?
by Andreas Radke 09 May '07

09 May '07

congratulation. we have won! our gcc-gcj is broken due to a major feature addon the developer made right before he orphaned it. we (Hussam who does i686 rc packages and me) are no more able to build OpenOffice.org standing a few days before the 2.2.1 release candidate. this is not to blaim that developer but for any other developer and all users not using the testing repo. but this is only the peak of all the chaotic "development" as we call it. untill now we used have one ArchLinux tree now having two architectures officially supported (i686+x86_64) based on simplicity and pacman repo manager as its basic parts. Having the latest stable package version was the goal. we have put more and more packages into the current+extra repos. important packages we want to test for a while in our "testing" repos. sadly it's not worth the name. almost nobody uses it. even not all developers as highly recommended. continously we put packages with major issues into the stable repos. we from the x86_64 port are only 2 guys rebuilding and maintaining ~2500 packages. we have not the power and possebility to change anything important. from my point of view we have passed a point where this concept won't work anymore. we have a poor developement infrastructure compared to other distributions. we slow down our package release process due to many developers beeing busy with other things (real life and more). but then we force us to push things very quickly into the repos to satisfy our own old goals. well. not more with me beeing responsible for the Arch x86_64 port. some ways are possible: 1) improve the infrastructure and increase the manpower of developers and packagers for all supported dramatically. we are trying that for over a year now without any noticable real success. 2) dramatically lower the work(=less binary packages) for the devs to give them time for making packages of a better quality. doubt came up as Arch should remain a supported binary distribution in most parts. 3) new goals for ArchLinux: accept to have not well tested packages when we want to keep the update speed or accept a lower speed on update to get new packages better tested. 4) split the goals we have! let's have one more conservative stable rolling rellease tree for higher quality and one on the bleading edge front accepting it might break sometime. I've brought it up several times: i'm no more willing to be the dump rebuild monkey. wha i suggest is a mix of 3) and 4). there is only one working other distribution based on pacman out claiming having a stable tree. I've talked to several devs and users and they can imagine that a stable distribution by ArchLinux can become a successor. I'm going to start a new project based on what we now call ArchLinux for a new more stable but easy to maintain distribution. I would like to do this for ArchLinux. But I have also no problem if you totally dislike that and say it's a NoGo under the name of ArchLinux. Everybody who wants to help out or has something to say may post here or contact me on one of my instant messenger accounts you find in the forum. AndyRTR

2 1

Re: [arch-dev-public] [arch] Archlinux [current] status
by Dan McGee 08 May '07

08 May '07

Kludging a few emails together here. > Am Dienstag, 8. Mai 2007 22:30:59 schrieb Tobias Powalowski: > > Hi > > something is really going wrong at the moment. > > People claim for having other interests or not time for doing the packaging > > work. > > I start here only with [current] first. > > Jan quit doing maintenance of important parts of our distro and probably > > also of doing quite some update tirades through current. > > > > Let me stress this, from my point of view Jan and me did the most [current] > > updates the last weeks, even if we didn't use the software for our own > > stuff, correct me if im wrong. I for one do not have access to [current]. I would be plenty willing to help out with maintenance there, although I am not as keen on adopting packages. More on this below. > > We have inactive package maintainers, no doubt. > > Judd, Dorphell, Aurelien, Gregor, Woody, Arjan > > > > It's time to cleanup [current]. > > Orphan all packages of Judd, Dorphell, Aurelien, Gregor > > 1 week of time to grab what packages you wanna have. > > Keep in mind it's your job then to test and ensure that the package works! > > Please one of the enablers do this, or give me the permission to orphan > > them. This could make sense, however I would like to state that a single maintainer of a package may be the wrong way to think about this, even before we do any kind of repository reorganization. If two people want to maintain a package, that should not be an issue as long as people don't have problems when people touch "their" packages. By the way, a lot of Judd's packages are marked out of date- someone should take a look at some of these and update if necessary. > > After that period, look whats left if noone feels responsable for a package > > make a list of possible drops or try to find one on ML who wants to > > maintain it. It's better to have 1 maintainer for just 1 package who is > > active and knows the package well, then 1 who just cross updates because he > > saw the version bump. I might disagree with part of this- a roving maintainer that knows and can test the packages he is updating is still a good thing. On 5/8/07, Pierre Schmitz <pierre(a)archlinux.de> wrote: > Well, I see the point. Perhaps there too much packages in [current] and > [extra] for too few devs. (compare: there are less packages in [community] > but we have more active TUs than Devs) I brought up this exact point a while back and it died on the ML: <http://archlinux.org/pipermail/arch-dev-public/2007-April/000517.html> > I don`t see any problem in stripping down [current] and [extra] to only those > packages which are really used. E.g. there are some experimntal ones like > beryl, several unstable kernels like ck, beyond, mm etc. which will do well > in [community]. I agree with this- extra is gigantic right now. Anything that we no longer feel belongs in extra should get announced to the TU list, where anyone can claim it if they use it. If not, drop it down to unsupported. > Perhaps there should be a guideline which package has to be part of the core > distribution. For example: if a TU becomes a DEV he often moves all his > packages to extra. Esspecially for Arch64 this causes some problems because > we TUs wont be able to help by porting those packages. I don't think that this should be the norm. On 5/8/07, Andreas Radke <a.radke(a)arcor.de> wrote: > Am Tue, 8 May 2007 14:33:04 -0700 schrieb Tobias Kieslich <tobias(a)justdreams.de>: > > 4. Arch64 is a 2 man show, Andy and ise. There should be some more > > support for them. I really think we should add some people here. ISE, > > write a mail to Jason to get access to current. Andy, Ise, how many > > people do you want and do you have suggestions? > > we both already have cvs access to all repos. we are still not allowed > to maintain packages. we are not listed in the dashboard. but if this > would change we would have to decide how to make i686 devs rebuild the > packages that are maintained by x86_64 devs. I tacked this on as a postscript in one of my other emails and no one responded. I feel like we should not exclude our x86_64 devs from maintaining packages. This requires a few changes in thought: 1. When you are the maintainer of a package, you are in charge of the package as a whole in addition to your own architecture. This means seeking out patches if necessary, etc. 2. People need to release a little control sometimes and not treat a package as their own. It is the community's package, any capable dev should be able to decide what is best for the package. If there is disagreement, then bring it up on the ML. > also i got dissapointed by some fresh x86_64 users we brought up here > that left us quicker than we thought. This should be a big role in deciding future dev/TU consideration, hopefully, especially for those brought on as package maintainers. -Dan

1 0

[arch-dev-public] [opening] Koffice maintainership
by Alexander Baldeck 08 May '07

08 May '07

Hey all, I took over many packages including X.org and thus my number of maintained packages went up to 280. So, I have a few packages to give away that are basicly the Koffice environment. I don't do the office kind of thing all that often anymore. Then again, I don't want to orphan them, nor do I want them to be moved to the AUR. Also, it would be nice if there was somebody new to maintain them. Send me a mail and we can talk about it. List of Packages: koffice koffice-doc koffice-l10n-ca koffice-l10n-cs koffice-l10n-cy koffice-l10n-da koffice-l10n-de koffice-l10n-el koffice-l10n-en_gb koffice-l10n-es koffice-l10n-et koffice-l10n-eu koffice-l10n-fi koffice-l10n-fr koffice-l10n-hu koffice-l10n-it koffice-l10n-ja koffice-l10n-lv koffice-l10n-ms koffice-l10n-nb koffice-l10n-nl koffice-l10n-pl koffice-l10n-pt koffice-l10n-pt_br koffice-l10n-ru koffice-l10n-sk koffice-l10n-sl koffice-l10n-sr koffice-l10n-sv koffice-l10n-tr koffice-l10n-uk koffice-l10n-zh_cn koffice-l10n-zh_tw

1 0

[arch-dev-public] pacman 3 to current
by Dan McGee 08 May '07

08 May '07

If there are no objections in the next half-day or so, we (Aaron and I) would like to push pacman 3 to current. This is the only possible showstopper I know of that is not fixed in 3.0.3: <http://bugs.archlinux.org/task/7063> It is easily patched on the package building end, rather than release a 3.0.4 release. Let us know ASAP if this shouldn't happen tonight. -Dan

2 1

[arch-dev-public] Beyond is discontinued.
by James 07 May '07

07 May '07

It was fun while it lasted, but it's come down to this. I simply no longer have the time, or motivation to develop beyond. Uni and life are taking up more of my time, and I'd rather spend what time i have at the computer pursuing things of interest. I no longer see the point in beyond, and have not used for any extended period for months. I'm sick of the kernel. It's crap. Every release breaks something new, and every release is as poorly tested as the last. (not you tpowa, I mean upstream -- you do a good job with what you're given by them) The stable tree, isn't stable. I want something that works and won't break. This email was not sent on a whim, I've thought about this for a while, and have realised, that there's not going to be a decent release in the near future and i'd prefer to not lead people on any further. Honestly, I don't think I've put out a good release in over 6 months. It's hard to drop a successful 2 year old project. I didn't want this to happen, but unless someone steps up to maintain beyond, it's now discontinued. Sorry guys. James Addendum: z4ziggy & dtw: kernel26 now has unionfs and squashfs. It's also somewhat more stable and reliable than beyond ever was. Consider it the successor. I know it doesn't have fbsplash... but you could build a patched version, and if you only add fbsplash, it should retain compatibility with the modules. Beyond name & maintainership: I still hold these, please email me personally if you're interested in taking over. I don't want some stupid ricer full of omgoptimised using the beyond name. Users: sorry guys. Maybe someone else will step up? I don't plan to put any of the other patch sets in the repository in place of beyond. If someone else maintains beyond to an acceptable standard, maybe i'll update it. -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2 1

[arch-dev-public] [objectives] Package triage on current + extra (archstats)
by Dan McGee 07 May '07

07 May '07

I know we weren't supposed to rush into the objectives here before settling on the goals, but I think this is an important one to examine, especially with a change in the repository structure happening in the coming months. How many of the devs are using archstats, let alone users? After looking at it a bit more today, I realized this could be a great asset to finding areas where devs should be spending their time with regard to package maintenance. It would also help us out greatly when it comes to determining which packages should no longer be maintained by us and dropped back to the TU level and/or unsupported. However, a few things need work: 1. The current website <http://www.archlinux.org/~simo/archstats/index.php> is in dire need of an overhaul. Using the old website theme is the least of our worries- things like the package listing are at this point rather unusable and only suck 223 MB of memory in Firefox once fully loaded. I have a lot of ideas for this here- enable breakdown by pkgname only (so it actually looks like people are running kernel26), limit number of results on the page unless someone actually selects to see them all, etc. 2. The archstats database. It contains several one-time system updates, and several systems that haven't updated since 2005 or earlier. This is clearly junk data, and to make archstats useful we should probably just start fresh, and find a way to cut down on spurious commits, which leads into... 3. The archstats program itself. In the last week, I've had no problems with it, but have had problems before (some of the spurious commits above were definitely my fault). Configuration should probably be editable in a conf file (the current /etc file has a big fat warning saying do not edit by hand- this seems not the Arch Way). Setting it up as a cron job is straightforward, but if we want people to use it we should probably think of a way to make it even easier. Comments on any of this? I know its yet another project idea to be thrown out there, but this one could prove very helpful and in the long run vastly reduce dev maintenance of package when we realize very few users are actually using a package and it should be maintained elsewhere. -Dan

5 9

[arch-dev-public] lingering x86_64 mythtv bug
by Paul Mattal 05 May '07

05 May '07

Can the Arch64 folks compiling mythtv have a look at this bug? It seems only to be a problem in the Arch64 binary package. http://bugs.archlinux.org/task/5944 - P

1 0

[arch-dev-public] Linuxtag: Staff meeting Saturday 12th 4pm CEST
by Christoph Neuroth 05 May '07

05 May '07

Hi, anyone who wants to help making Linuxtag a nice event again, please try to make it to Freenode/#arch-lt on Saturday 4pm Berlin time so we can discuss remaining topics, as there are: * Arrival/Departure schedules (someone needs to set up and dismantle the booth) * Poster printing * Organizing some shirts with arch logos so vistors know who they can talk to * CD Burning, CD sleeves * other needed stuff Feel free to bring up any other topics you can think of. Also please make sure that I have your full name so I can order exhibitor passes for you. Currently, I ordered passes for Alex, Andreas, Tobias and Jan. And finally if you need some tickets for your friends to be able to visit the fair, I have been given 24 e-tickets that I can share. As in the last years, I will need the full name and a valid email address to send them to you. chris

3 2

[arch-dev-public] On vacation
by Varun Acharya 04 May '07

04 May '07

I'm taking a big long break from 5th-24th May, during which I probably wont have access to even an internet connection. 32bit TU's please help out with community64 if you can .. the difflist is here http://www.archlinux.org/~andyrtr/pkg_diff.html. Thanks, Bye, Varun

1 0

Re: [arch-dev-public] [arch-dev] [goals] i18n
by Jason Chu 04 May '07

04 May '07

On Thu, May 03, 2007 at 11:18:15PM +0200, Andreas Radke wrote: > i'm against offering any localization from the devs. it's a big amount > of packages we don't know how important they are or better how often > they are used*. Is there some way we can find this out instead of just guessing one way or the other? > arch is developed and documented primarly in english and so we should > concentrate to offer a good en_US.utf8 base. nothing more from the core. I don't see why we can't also have good i18n support. > i suggest to lay i18n packages back into the community's hand. those > packages are often easy to maintain but a hell of work for the > rebuilders. Don't the people who maintain these packages have scripts that will just build them all? Jason

1 0

[arch-dev-public] [goals] i18n
by Dan McGee 03 May '07

03 May '07

And why was this on arch-dev and not the public list? Forwarding it there. ---------- Forwarded message ---------- From: Dan McGee <dpmcgee(a)gmail.com> Date: May 3, 2007 6:03 PM Subject: Re: [arch-dev] [goals] i18n To: Development Discussion for Arch Linux <arch-dev(a)archlinux.org> On 5/3/07, Andreas Radke <a.radke(a)arcor.de> wrote: > i'm against offering any localization from the devs. it's a big amount > of packages we don't know how important they are or better how often > they are used*. > > arch is developed and documented primarly in english and so we should > concentrate to offer a good en_US.utf8 base. nothing more from the core. > > i suggest to lay i18n packages back into the community's hand. those > packages are often easy to maintain but a hell of work for the > rebuilders. > > Andy > > > > *we should improve archstat to show summarized output for the amount of > one pkgname. that could help a lot for our wanted repo cleanup. Quick thoughts on this, and not sure of the full implementation but it seems like a good idea in my head. Why don't we have an [i18n] repo, just as community and extra are repos? This should be administered under a separate set of permissions, so those that update these packages are not necessarily either TUs or Devs, but other users that have taken on the responsibility of maintaining localization packages. Key to this is some kind of permissions based thing- perhaps a certain user should only be able to modify FR localization packages, for instance. The system should support that, and it seems like pre-commit hooks in nearly all VCS systems should be able to enforce these permissions on a package or repo-level basis. This is another topic though. -Dan

1 0

[arch-dev-public] Linuxtag: Project Description German Translation needed
by Christoph Neuroth 03 May '07

03 May '07

Hi guys, I'm very short on time right now, so it would be good if some other native German speaker could translate our description into German. It will be published on the linuxtag website and in the official printed LT Journal. I used a slightly shortened version of the archlinux.org/about text: >Arch Linux is a general purpose linux distribution that can be molded to do just about anything. It is fast, lightweight, flexible, and most of the parts under the hood are quite simple to understand and tweak, which can make it a good distro to "learn the ropes" on. We do not provide any configuration helper utilities (ie, you won't find linuxconf in here) so you will quickly become very proficient at configuring your system from the shell commandline. > >Arch Linux uses the Pacman package manager, which couples a simple binary package format with an easy-to-use build system, allowing the users to easily manage and customize their packages, whether they be official Arch packages or the user's own homegrown ones. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution. > >Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community. > >Arch Linux uses a "rolling release" system which works like this: We have two versions of our core package set at any given time, Current and Release. The Current repository always contains the latest and greatest versions of packages. As soon as a package is updated it is part of the Current repository, so this is the one to follow if you want to stay very up to date. chris

1 0

[arch-dev-public] new gcc compiler in testing, better java support now
by Jan de Groot 01 May '07

01 May '07

A new compiler snapshot has been uploaded to testing. Lots of new things, many bugfixes, etc. The most important thing here is that gcc-gcj uses eclipse-ecj to compile itself and all programs compiled with gcj. This makes gcc-gcj completely java 5.0 compatible. This package also includes a web plugin, which is far from completed though. This is important for AMD64 users, as Sun doesn't provide one in the official jre package. As a downsides of all these patches, libgcc_s.so now exports a GCC_4.2.0 symbol that wasn't in older releases. Be very careful with this one when building packages for extra/current or community with these compilers, as binaries that link in this versioned symbol will fail to run on older libgcc_s.so libraries. If all is fine with these new compilers, I'll move them into current and extra in a short while. Happy compiling!

2 2

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

01 May '07

News from the LT guys. I will discuss the mail with alex the next days. Right now I'm just too wasted to think ;) ----- Forwarded message from Wolfgang Drotschmann <drotschm(a)linuxtag.org> ----- Date: Mon, 30 Apr 2007 18:25:46 +0200 From: Wolfgang Drotschmann <drotschm(a)linuxtag.org> To: projects-announce(a)linuxtag.org Subject: [LT07-Pro-Announce] Infomail #4, April 30, 2007 Dear Projects, after further brainstorming, research, meetings, negotiations, some tee and beer we have some news for you: o Booth Plans o Booth Furniture o Posters o Power and Internet Connectivity o Setting up and Dismantling Your Booth o Exhibitor Passes o Deliveries o Catalogue / Project Logo o Project Workshops o Accommodation o eTickets So you see, it's a lot of stuff. 1. Booth Plans Finally we have finished the booth planning for the Free Software Projects. You can find the preliminary plans on our website. They are for your eyes only - please do not distribute them! o Hall 12: http://www.linuxtag.org/2007/tmp/aufplanung/LinuxTag2007-Halle12-20070430.p… o Hall 14.1: http://www.linuxtag.org/2007/tmp/aufplanung/LinuxTag2007-Halle14.1-20070430… This year we do not have this much space as the year before. It was a really hard job to fit every project into this plan and we have tried to do our best. 2. Booth Furniture First we have to apologize that you have still to be patient, but Messe Berlin is working very hard on the details of your booth's equipment. One reason for this: we will have much better furniture at the booths this year. There will be (all dimensions are height x width x depth): * Infopoints (2.5 m x 1 m x 1 m): The infopoints have a 2.5 m high and 1 m wide postwall in the middle. At each side, there is a circular desk, which has its deepest point with 0.5 m. * Infocounter (1 m x 1 m x 0.5 m): The infocounter is a normal sales counter, which may be used for presenting giveaways, merchandising, etc. * Podests (narrow) (1.3 m x 0.5 m x 0.5 m): This podests are a kind of counter, but a little bit higher, so they are ideal for putting an LCD display or laptop on it. * Podests (wide) (1.3 m x 1 m x 0.5 m): This podests are a kind of counter, but a little bit higher, so they are ideal for putting two LCD displays or laptops on it. As we from the project committee talked to every project we were able to contact by phone, we assigned some of this stuff to your booth depending on its size and your provided information in the vCC. Please do not send us mails about what will be at your booth: we will provide you detailled plans until May 10th. Then there will be a short timeslot for discussing your change requests. 3. Posters Please prepare at least one large poster (A1 or A0) to be placed on the walls of your booth or infopoint, so that visitors understand what the booth is all about, or what the particular machine in front of them intends to demonstrate. Without posters or other similar stuff the booth will probably look a bit deserted and not that interesting at all. There are just very few booths which have all four sides open and therefore have no wall to put posters on. This projects will have the Infopoints (see above) at their booth. They should prepare for each side of the infopoint a poster. You can use adhesive tape to fix the posters on the walls. If you plan to demonstrate fancy hardware at your booth, it is very helpful to describe these particular pieces of hardware in a poster or a large sign, so that visitors recognise its value or notice that it is extraordinary. 4. Power and Internet Connectivity 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 be advised to take long network cables with you. You will also need some switches for the inner-booth network. If you share your booth with other projects, you probably should plan the booth cabling together with them. 5. Setting up and Dismantling Your Booth You can setup your booth the two days before LinuxTag opens its doors. On Monday, May 28th, and Tuesday, May 29th, you setup and decorate your booth from 7 am to 10 pm. The earlier you arrive and begin with this the better for all to solve eventually arising problems here. We hope that the booth basics are ready for you when you arrive. Otherwise, please stand nearby, and make sure to have a guard at your stuff. Because LinuxTag will be opened on Tuesday, May 30th, by some officials there is no way to setup your booth this day, it has to be done before. As usual it is not permitted to start dismantling your booth on Saturday, June 2nd, before the show officially closes. Please do not start packing your equipment befor 6:30 p.m. You also can dismantle your booth on Sunday, May 3rd, from 7 am to 10 pm. To get into the exihibtion halls during setup, we will send you special exhibitor passes, which are only valid for the setup and dismantling time. We will send them to our project contact person. Please update your postal address until Friday, May 4th. 6. Exhibitor Passes The exhibitor passes for project booth members will continue to be free of cost for a reasonable amount of booth personnel. However, they are not meant as a means for regular visitors to save the entrance-fee. Hence, please don't abuse this, and don't add random visitors as booth staff if they don't belong to your booth. For this matter we already sent you some eTickets. You can order the exhibitor passes for each accepted project using the vCC. Please login at the virtual Conference Center and click in the Main menu on "Project" and then in submenu on "Projects". Each accepted project will find a button "Order exhibitor passes". After you ordered the passes, we will have a look at the list and approve them. Otherwise you will get an email from us. The deadline for ordering exhibitor passes is May 21st. 7. Deliveries It is possible to send packaged stuff to LinuxTag independent of your own arrival. However, Messe Berlin is a very large area, and if nobody knows about the packages, these cannot be taken care of properly. Please ensure that they will not be delivered before May 25th, as nobody's there before. Please read the following thoroughly: * At all times parcel post can be send to the parcel service of Messe Berlin which can be ordered using form B3+4 at our exihibitor service sites. Advantages are: it will arrive on schedule, parcel is covered by insurance. * You can send parcel post in little amounts (quantity and size) to us ---that is Messeleitung LinuxTag Projektbüro, please see address later on--- but only May 25th (Friday) or 26th (Saturday). Please keep in mind that via this way parcel will not be insured. Hence, please tell us who sends the packets, who should receive the stuff, and what kind of content is in. The Project Team will act as dispatcher anyway, but can only accept and dispatch stuff properly when the team knows about it. For this reason, send us an email (to projects(a)linuxtag.org) with this subject: Parcel Post for Project $projectname (#boothno). Please send packages to Messeleitung LinuxTag Projektbüro c/o Messe Berlin GmbH ICC Pressegeschoss Messedamm 22 D-14055 Berlin Germany Please put on the package (but not to the address field) the project name, the booth number, a contact person and a phone number (cellular). * Starting with May 29th (Tuesday), you can receive parcel straight at your booth. You have to make sure that there's somebody who accepts the packet. Please only use the address given here, and please inform us about the deliveries you expect. If you choose to send it to your booth, use this formula for the address: PROJECTNAME HALL, BOOTHNUMBER c/o Messe Berlin GmbH Messedamm 22 D-14055 Berlin Germany 8. Catalogue / Project Logo We are currently providing the official fair catalogue. Therefore we will take the information from the vCC. Please have a look at the following fields: * Project Name * Press Contact * Descriptions (short, long) Additionally we need your logo in an vector format (EPS, PDF) and as bitmap (JPG or PNG at most 400 kB). Please send it via email to projects(a)linuxtag.org, and please use this subject "Project Logos for $PROJECTNAME". It is very important that you use the correct subject line. Deadline for the logo and the vCC information is on Monday, May 7th. 9. Project Workshops There are still opportunities to have a Project Workshop. Use your vCC account to place submissions with category "Project Workshop" in our vCC. Extended closing date is May 14, 2007. 10. Accommodation The city has an enourmous, nearly innumerable number of accommodation facilities. Because we have to organise many things virtually, it's hard for us to give you foolproof advice on this score. However, we hope that Sven Guckes, our local scout, can provide us with further recommendations within next week about a number of hostels. We have heard from several projects that they already have made arrangements here. We want to ask you to exchange information if you have special arrangements, you can make your accommodation provider happy if you book him out together with your fellows. Although we had started to look for a gym, things went on very tough. We are sorry for this. We look for volunteer who finds a gym for the community, or who can help Sven. First and good information for traveling to Berlin and Messe Berlin has been collected here: http://www.linuxtag.org/2007/de/besucher/anreise.html A number of service providers for accommodation has been listed here: http://www.linuxtag.org/2007/de/besucher/hotels-packages.html 11. eTickets Like last year, we will send each project a bunch of eTickets, which you should spread amoung your project community. The tickets are quite the same like last year, but one ticket is now valid for the whole LinuxTag event. So you do not have to collect more of them. Because we encountered some trouble last year, we urge you to activate your eTicket account immediately after you got the mail from the system: the invitations are only valid for 48 hours and the tickets will be lost afterwards. So, you will hear from us until May, 10th! Regards, Susanne Pfeifer, Wolfgang Drotschmann, Marko Jung & Martin Schulte Project Committee LinuxTag 2007 ----- End forwarded message -----

1 0

[arch-dev-public] kernel 2.6.21 series hits testing
by Tobias Powalowski 30 Apr '07

30 Apr '07

Hi kernel 2.6.21 series is now in testing, it will be the kernel series for next release so please test this stuff well before it can go into current repository. Changes: - latest alsa hg stuff added - updated patches to fit for .21 kernel - Recent Changes: http://kernelnewbies.org/Linux_2_6_21 have fun and report Showstoppers: http://bugs.archlinux.org/task/6875 thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

5 8

[arch-dev-public] Getting to New Arch SCM Layout and Repo Management
by Paul Mattal 30 Apr '07

30 Apr '07

All, Arch needs to move forward. The question: how? Moving forward at high speed is desirable, but we need first make sure we're not pointed towards a cliff and that our safety cables are attached and in good working order. I am setting my sights on exactly one aspect of this problem: SCM and repo management and getting us from where we are into the new system we all want to have. BACKGROUND For the purists, there is a sentiment I would like to acknowledge, because it's one that's been bugging me. I believe that the most often overlooked and underrated "Arch Way" design choice was to support i686 only. A single common denominator makes everything a lot simpler-- we just solve one problem and we solve it very well. Development resources are not spread thin and are highly focused on the same end. I am not the purist I once was. There's a vital and important segment of the community that needs 64-bit support, we can't just drop i686 support, and anyone has to acknowledge that i686 won't be around forever. To survive in the long haul, Arch will need to support more than just the i686 architecture. With some weight then, knowing we're setting out *against* the Arch Way, but along a trail that *must* be blazed, we consider the landscape. GOAL Using an open design and implementation process, we will implement a new system for managing Arch repositories and PKGBUILD materials. I will provide a box with Internet access for this project we can use as our home. It will be completely separate from the main Arch servers. If our system proves itself, it will be presented to the main Arch development team as the new standard for repo management. Main design choices I am making (to be amended as we go along): 1) The system will be able to manage an arbitrary number of repositories for multiple architectures efficiently. 2) Use of the system will not require a shell account on the server. 3) Multiple instances of the system will be easily deployable on a single server. 4) It will be trivially easy to create and destroy repositories, to copy or move packages between repositories, or to place a package in more than one repository. 5) It will be easy for developers with SCM access to efficiently incorporate patches and input from community members. 6) The system will allow anyone with SCM access to register as a maintainer for a package. 7) All functions of the system will be primarily accessible from a simple commandline interface. 8) The system will be itself deployed as an Arch package and be easy to set up. 9) The system will be sufficiently documented in a functional, if not beautiful, fashion. SCHEDULE By May 15: Anyone with another SCM system or layout to suggest should do so in the Arch-repos group. Your goal is to persuade Jason your system is the best one. Discussion of all those systems will then take place over the following two weeks. By May 7: I will bring 7 key people on board to work on this project. Drop me an email if you're interested in joining the team! Initially, I know we will need: SYSADMIN - An existing Arch developer who will manage the Linux box I provide and the accounts for the SCM system. This person should have at least a small amount of time each day to handle management tasks related to the project. PUBLICIST - I am committed to organizing this project, and will continue to post status to the arch-dev-public list for all to see. However, not everyone looks here. We need someone who will deliver the news about this project and the status as it progresses to the forums, the IRC channel, and the other mailing lists. This won't be a time-consuming job, but will require someone who has knowledge and facility with all the communications channels used in the Arch community and who can focus on getting the word out. DEVELOPERS - There will be some straight-up development work needed to get us from the SCM system and layout to an actual management system for repos. We may benefit from some work already done by others (pacman3, AUR, main site repo management tools) but we will need to do some original coding here. I will be somewhat involved in the design and coding, but will choose three (3) people to help with development. ANYONE is a potential candidate.. send me and email and tell me why you'd make a good candidate. Focus on good ideas you have for the system, languages you're comfortable in, how much of Getting Things Done (GTD) you've implemented for yourself, and amount of time you'll have to give to the project in June and July. COMMUNITY MEMBERS - I will choose two (2) members of the community who specifically are NOT developers or TUs (yet!) but who are interested in helping maintain the packages in our new system. These people will NOT be given SCM access, so as to help us evaluate how easy it is for community members to contribute and for developers to incorporate their contributions. Please contact me directly if you're interested in this job. These two people will specifically be identified as having the time to spend time helping us design our system in May and test our system during the month of July. On May 20: I will ask Jason to choose the best SCM system and layout he's seen. If at that point it does not meet this project's goals, we will minimally modify it to meet them. May 20-31: The developers and I will figure out the number, kind, and properties of the tools we will develop and divide up the work. This is the real remaining design step. JUNE: During June, the developers and I will build the system and get it ready for initial deployment. The source will be open to for anyone to observe and contribute, but we 4 will have commit access. JULY: On July 1, we will launch the system and put some real packages in it. At that time, we will need MAINTAINERS to join the project. We will deploy the system with REAL packages and REAL maintainers, just a small number of them. Any developer or TU wishing to participate will be allowed to contribute *AT MOST 4 PACKAGES OF RELATIVELY SMALL SIZE* to the test system and they will begin to be maintained in our system. It will be up to the individual developer or TU to decide if they will propagate the PKGBUILD changes from our system back into the official repos. AUGUST: In August, we will evaluate how we have done. If all has gone well, we will hand our system to the Arch development community with a recommendation to enhance and deploy it for main site and AUR repo management. I hope you will all consider joining me for this potentially exciting project! Let's get something done. - P

5 8

[arch-dev-public] License array format
by Dan McGee 29 Apr '07

29 Apr '07

I don't know if this is a rehash of an old topic, but it hasn't come up in a while so I want to stir the pot. We need some standardization when it comes to licenses, which are still not in all of the official packages. (OpenSSH is missing one!) Roman and I were discussing on IRC how the license array should look, and this example came up: license=('custom:BSD' 'custom:MIT' 'GPL') A few issues to discuss with regard to this example: 1. A license like the GPL does not change its text depending on the package, while ones such as BSD and MIT do. Thus we definitely need to be including these customized licenses when we package these. 2. For packages that have their own license (no other package will use it), do we use 'custom' or 'custom:packagename'? 3. For packages that use a BSD style license (and all other licenses like MIT), do we use the custom:prefix? Roman and I have differing opinions here. I think we should use the custom: prefix to indicate in pacman -Qi output that a license has been installed by the package and is not a common license already on the system. Roman thought that the custom: was unnecessary and looks ugly. Thoughts? I'd like to standardize this and get it on the wiki licenses page. <http://wiki.archlinux.org/index.php/Licenses> -Dan

3 3

Re: [arch-dev-public] [arch-dev] Getting to New Arch SCM Layout and Repo Management
by Paul Mattal 29 Apr '07

29 Apr '07

Dan McGee wrote: >> 6) The system will allow anyone with SCM access to register as a >> maintainer for a package. > > So if I read this right (or at least the way I was thinking), there > can be multiple maintainers for a package? I think this is the right > route to take- strict ownership of a package seems unnecessary. This is correct, though when I re-read this goal I realized I need to make that clearer! The idea is that anyone with SCM access can register as a maintainer (really a "regular contributor") on this package, so that when group thinking or decision making needs to happen for the package, you know who to coordinate with. This encourages more people to become involved in more packages that interest them. It also discourages people from holding onto ones they have grown tired of, which I believe is an equally important effect. > One of the things I noticed after being "inducted" as a dev was the > sparsely documented and slightly cobbled together toolchain. I think > if we are switching to a new system and layout, we should do it right > from the beginning and make the tools easy to understand, documented, > and able to work anywhere- not just on gerolde. In addition, pacman, > developer, and server side tools should work in harmony. Exactly my intent. You are a perfect fit for a developer on this project. The goal is, indeed, to make this the seamless equivalent of pacman for doing the other half. In fact, I was thinking we might want to call the most visable commandline tool "repoman". Very glad to have someone active on pacman development aboard, since the two really are halves of the same puzzle. My goal for next week is to get the box up and running, and to continue to flesh out some thoughts. My sandbox for this so far for this is at: https://subzero.elys.com/svn/repoman/trunk/ If you would like commit access, send me (privately) an htpasswd -n line. Welcome aboard! - P

1 0

Re: [arch-dev-public] [tur-users] Ion3 trademark infringement
by Thomas Bächler 29 Apr '07

29 Apr '07

Tuomo Valkonen schrieb: > The package "ion3-darcs" [1] on AUR is infringing on the Ion3 > trademark. It is not Ion3 anymore, as it modifies the installed > program in such a manner (by applying the Xft patch), that it > can not be considered the original product anymore, but a > competing one. The package must be renamed so that it can not > be confused with Ion3(tm), or the Ion project. If this is not > done, there may be legal repercurssions. > > [1]: http://aur.archlinux.org/packages.php?do_Details=1&ID=10622 This thread has just been brought to my attention and I am posting this to the tur and arch development mailing list. I suggest that we drop the modified ion version from AUR. I also strongly suggest that we remove ALL ion-related packages from AUR and official repos, as well as all other packages that have been released by the author. Arch always tries to provide the best and latest for its users. In doing so, we cannot afford getting sued. So if a package author THREATENS us, then there is no place for his/her software in our distribution and the only possible response is to not provide it any more, no matter how good it is. I am really disappointed that people have to resort to these kinds of actions, and I am sorry that I feel obligated to the proper reactions.

1 0

[arch-dev-public] Building and uploading with pacman 3
by Dan McGee 28 Apr '07

28 Apr '07

This is just a quick note for devs regarding pacman 3 (specifically makepkg) package naming. We eventually are switching to a scheme where the arch is tacked on to the package name, and makepkg 3 names packages this by default. However, this breaks backwards compatibility with pacman 2.9.8 and down, so we cannot do this in the official repos yet. Here is one way to quickly fix this (as a bash function): makeoldname() { mv $1 "${1%-*.pkg.tar.gz}.pkg.tar.gz" } JGC also suggested that you can just edit makepkg for now and have it output the old-style name. Finally, what is a good timetable for changing the uploaded package names? If we treat pacman a bit special and always name it without an arch, people will always be able to upgrade to it, and from there do a full sysupgrade. -Dan

1 0

[arch-dev-public] Sizes of repos and maintainers
by Dan McGee 25 Apr '07

25 Apr '07

First, let's get a few numbers out there. Sizes of official repos: current: 563 extra: 2019 community: 1196 Number of "maintainers": Devs: 27 TUs: 25 The second set of numbers is harder to pin down. For devs, I took the number from the devs page; someone who has been here longer could better state the breakdown between architectures or between active and passive. For TU's, I grabbed it from the AUR front page, once again not knowing how many are active. Given the above numbers, and this repeats what has been stated elsewhere by Alexander, devs have roughly 95 packages each ((563+2019)/27) to maintain if the load was distributed evently. Because we know it is not, Alexander came up with a figure of 16 active maintainers, giving each dev 156 packages. Thats a lot, and it leaves very little room or time for devs to do anything besides package maintenance. Compare this to the TUs workload. Each TU should have roughly 48 packages to maintain, a much more reasonable number and either 1/2 or 1/3 of what a dev is expected to do. This also gives them some time to patrol the AUR and check packages that haven't made it into community. Two proposals to let sit in the pot: 1. Downsize extra to a more reasonable size, and move some of the maintenance to TU's by shifting packages to community. This would likely require a few more TUs being "hired on". 2. Redefine what it means to be a dev. Have a three-tiered system of sorts, with increases in permissions to change things as you move up the ladder. This would basically stick another group between Devs and TUs that could help maintain the huge number of packages we have in extra. This would likely require a few more TUs being hired and some TUs shifted to higher levels of responsibility. Yes, radical ideas, but don't shoot me for them. Comments appreciated. -Dan

4 5

Re: [arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Tom K 25 Apr '07

25 Apr '07

David Rosenstrauch wrote: > Tom K wrote: >> David Rosenstrauch wrote: >>> Tom, >>> >>> I use EncFS pretty extensively, so I can assist you with testing if >>> you need. >>> >>> DR >>> >> >> Thanks David. >> >> Get it here for now: >> http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz >> PKGBUILD and patch here: >> http://www.archlinux.org/~tom/packages/openssl/ >> >> I've asked the original reporter for details on the known >> OpenSSL/Blowfish problem, for inclusion in Arch News etc. >> >> T. > > Hi Tom. I just upgraded and tested. > > It's basically like Valient's mail said - the encrypted directory that I > made with the broken version of openssl-0.9.8e was now unreadable with > the new fixed version: > > [darose@davidrlin pr]$ encfssh .d2 d2 > EncFS Password: > Error decoding volume key, password incorrect > encfs failed > > But, like I did when we upgraded to the broken version in the first > place (http://archlinux.org/pipermail/arch/2007-March/013925.html) I > just deleted the bad encrypted directory and then recreated it. (I keep > the contents in a RCS, so it's easy for me to just pull them from there > again.) In retrospect, hat wasn't necessarily the correct thing for me > to do. Other people commented that they just remained downgraded on > openssl-0.9.8d. That avoided the bug, and let them keep using their > existing encrypted directories. But since recreating the directory was > no big deal, that worked for me. > > Anyway, after I whacked and recreated the directory, encfs seems to be > working fine. I'm able to unmount the encrypted directory and then > mount it again without a problem. > > So I think the fix is fine. Only caveat is that, like Valient said, > anyone who's created any encrypted directories using the broken version > will need to whack them and start again. You might want to reference > Valient's email and/or this Arch email thread > (http://archlinux.org/pipermail/arch/2007-March/013924.html) in whatever > communication you send about the issue. > > Hope this helps. Any further questions, or need me to do any more > testing, please feel free to write back. > > DR > > Many thanks for the comprehensive reply, David. I'm still waiting to hear from Valient regarding his tests, but I'll put the fixed package into testing anyway, with appropriate accompanying messages. T.

1 1

[arch-dev-public] Fwd: Consensus on network scripts
by James 24 Apr '07

24 Apr '07

oops, this one didnt make the ML, my bad. Anyone got any other comments? If I put these to a poll everyone would vote for their inclusion? Otherwise.. please say :) It's unfair otherwise if I don't get a chance to fix problems or respond to complaints. James ---------- Forwarded message ---------- From: James <iphitus(a)gmail.com> Date: Apr 21, 2007 8:32 AM Subject: Re: [arch-dev-public] Consensus on network scripts To: David Rosenstrauch <darose(a)darose.net> On 4/21/07, David Rosenstrauch <darose(a)darose.net> wrote: > James wrote: > > Yes, laptops are moved between wireless networks, but this does not > > mean that static configuration is inappropriate. My laptop for > > example, has long moved between home, and school/uni and a coffee shop > > I frequent. Three, unchanging networks. Most users of wireless have > > networks they frequent often like this. > > > > Look at my scripts, they're not as complex and error prone as you'd > > think. Most distros *do* have wep support in their scripts, and I see > > no reason why wpa shouldn't be afforded that same level of support. > > Arch is a different distro to "most other distributions". > > > > NetworkManager is not a solution. It's gui dependent. To use it, means > > loading up either KDE or Gnome. This is a ridiculous dependency for > > network connectivity. Developing a command line based client would > > be... nice. But, I don't have the experience to develop it, and arch > > needs better network scripts two years ago. > > Hi James. Was just reading through your email with interest. > > I also use my laptop for roaming ... and often start up the network from > the command line, instead of a UI. > > But I'm just wondering: what do you feel is wrong with arch's current > wifi network scripts? I use them (i.e., with /usr/bin/netcfg --menu) > and they don't seem to give me any problems. The current scripts: - Messy codebase, as features have been hacked in over time, without much plan or thought to the big picture. - Config syntax is messy and inconsistent. - All the logic and code is in netcfg, so nothing can be used outside of it. - As a result of the last, netcfg is *big*. Having everything in one file, as anyone knows, is nasty. - Using bash files as a configuration mechanism can be awkward, take a look through and you'll see lines of mass 'unset's trying to clear out variables. - Negligible error checking. You get failed connections that uh don't fail? - Are very difficult to track down why a profile has failed, and what could cause connection problems. - netcfg only deals with simple wireless configurations, these scripts are generic and can tackle any type of connection, given a lib/netcfg/connection/ script is written for them. My scripts are based on the current ones, but the above are all fairly big problems, albeit, many internal, so fixing and improving them, ended up becoming a rewrite of the scripts. There's other things I thought might be best to change too, like moving all network scripts to a separate package, and separating out the initscripts. > I usually just use knetworkmanager for connectivity. But on the > occasions that I need to use it from the command line, netcfg seems > quite adequate. I just set up a new profile, and then select it from > the netcfg menu. > > What do you think needs to be urgently improved about this process? It's a fine process, I just hope to bring our network scripts to a higher level of functionality, make them easier to use, more reliable, and easier to deal with when things go wrong. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

1 0

[arch-dev-public] Short hiatus
by Travis Willard 23 Apr '07

23 Apr '07

Hey guys, Well, school's done for me. Like, done-done. I'll get my diploma in June, whee! Honours Co-op Bachelor of Math, Computer Science. Anyway, enough tooting my own horn - with a couple weeks off before I start work (my first full-time, heh) the wife and I are doing a quick trip to visit people we haven't seen in a long time. We're leaving tomorrow (Monday) and won't be back until at least Saturday - so for at least that long I won't be available for what developer-work I do. I've updated what packages I can - fglrx just released a new version, and I'll hopefully get to that update before I go to bed tonight, and smb4k is out of date but berlios.de's down right now so I can't update that - might be a good thing though if somebody's going to move kde to /usr soon; wouldn't want to overlap with their work. Anyway, see you in one to two weeks. :) -- Travis

2 1

Re: [arch-dev-public] [arch] kernel 2.6.20.7, acpi changes and alsa bumped to 1.0.14rc3
by James 22 Apr '07

22 Apr '07

On 4/15/07, Tobias Powalowski <t.powa(a)gmx.de> wrote: > Hi folks, > the new kernel has acpi modules as much modularized as possible, it was > requested due to some people having problems with the monitoring modules in > the kernel. > > I have written a small wiki about the acpi modules, you need to add them to > your MODULES=() array in rc.conf. > Why wasnt this put into testing first at least? As we can see from the thread in [arch], we've already come across one person whose fan is controlled via acpi... and had an overheat as a result. Secondly, is modularising them really a solution? - You could have tracked down which one exactly is causing the problem, and modularised that - Or heaven above, file a bug upstream at LKML. - If this is a real problem, then other distros would have done the same, and you should have found their autodetection scripts before doing this here. this is going to annoy more people than it is going to fix problems for, and this is unacceptable when there's other solutions available. and... what was the bug? can't find it on the bug tracker. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

2 2

[arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Judd Vinet 21 Apr '07

21 Apr '07

Begin forwarded message: Date: Tue, 17 Apr 2007 23:32:26 -0700 From: "Valient Gough" <valient(a)gmail.com> To: jvinet(a)zeroflux.org Subject: OpenSSL 0.9.8e has serious bug I've had reports from a couple users of Arch Linux that EncFS is unable to access their existing encrypted filesystems after upgrading Arch packages. The problem is that OpenSSL 0.9.8e has a known problem with Blowfish encryption which makes it incompatible with any other versions of OpenSSL. EncFS users will not be able to read filesystem which use Blowfish with key length > 128 bits, and if they create a new filesystem when using OpenSSL 0.9.8e, then they will not be able to access their filesystem when using the next release of OpenSSL with that bug fixed. See: http://cvs.openssl.org/chngview?cn=15978 regards, Valient

4 4

[arch-dev-public] DistroWatch blurb
by Roman Kyrylych 21 Apr '07

21 Apr '07

Just wanted to remind the old topic http://bbs.archlinux.org/viewtopic.php?id=16767 because IMHO our DistroWatch blurb is still not as good as it could. For example it has "i686-optimized" but doesn't mention x86_64. There was http://wiki.archlinux.org/index.php/New_distrowatch_blurb where some nice proposed descriptions were collected, but it's deleted now (don't know when it happened). Suggestions? -- Roman Kyrylych (Роман Кирилич)

1 0

[arch-dev-public] Arch project management?
by Jason Chu 20 Apr '07

20 Apr '07

A lot of people have been saying that quality control in Arch has gone down the crapper (gotten worse, for the non-native english speakers). Obviously we can't test everything on everyone's machine or even test all the features of all of our packages, so what can we do? Someone suggested that we have someone who manages quality control. I don't like thinking of it as a procedural problem, so I'm going to phrase it differently. I think we need someone who makes sure that things don't get forgotten, by the developers and by the community. Someone to prod the devs and the community to test things and make sure things don't get lost. Roman already does this very very well for the bug tracker. Since we hired a bug hunter, bugs get addressed^H^H^H^H^H^H^H^H^Hassigned very quickly. What if we had the same thing for the larger/more important packages, like kernel26, glibc, apache, everything in core? The idea isn't to just throw process at the problem, but to be a little more organized in our package verification. I don't care how the organizer does it either, just as long as they make sure that people are happy with changes before they go into current/extra. I'm not suggesting any of the developers do this either, we need someone new who isn't maintaining packages, already busy with Arch developer stuff, and is active in the community. Everyone has 1 week to get their comments in before I start looking. Jason

5 6

[arch-dev-public] very outdated mirror(s)
by Roman Kyrylych 20 Apr '07

20 Apr '07

Hi! I'd like to discuss issues with mirrors being very out-of-date. ftp://ftp.nethat.com/pub/linux/archlinux/ was last updated on 2007-03-27 Can there be some way to make tracking such things easier? For example, Ukrainian mirror has {current,extra,unstable,testing,community}.lastsync files with content like: community synced at: 04/20/07 01:10 -- Roman Kyrylych (Роман Кирилич)

2 1

Re: [arch-dev-public] [Fwd: Fw: OpenSSL 0.9.8e has serious bug]
by Tom K 20 Apr '07

20 Apr '07

Valient Gough wrote: > > Hi Tom, > > I don't know if there is any tracking of OpenSSL bugs. While testing > out user reports of 0.9.8e incompatibility, I narrowed it down to an > OpenSSL problem and sent a simple test case to the OpenSSL mailing list. > > http://www.mail-archive.com/openssl-users@openssl.org/msg48671.html > > I haven't dug through OpenSSL to determine the entire extent of the > problem. I believe it causes Blowfish to use 128-bit encryption no > matter what key length you specify. > > Valient > Thanks for getting back to me. I would be grateful if you could test my patched build, available here: http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz PKGBUILD and patch here: http://www.archlinux.org/~tom/packages/openssl/ T. P.S. I've already posted this on our public dev list, but as you may not be a subscriber, I'm sending it to you directly also.

1 0

[arch-dev-public] Consensus on network scripts
by James 20 Apr '07

20 Apr '07

Hey, http://wiki.archlinux.org/index.php/Network_Scripts I've been pushing these repeatedly, with only meager interest shown by others. Given a little bit of documentation, I think they're almost ready for me to unleash and publicise for further testing. That said.... before I put the time into writing the docs, closing some known bugs, and publicising them more, I'd like to know what everyone thinks and get some 'approval' for them. Some sort of OK, we'll adopt and implement these given A, B and C are done. I don't know what the process is for this, nor do I think we've ever had/needed one as discussion should be fine, so bear with me. I realise that not everyone wants to install these and try them, so I'll just outline the major outward changes in order of what might cause debate. New features and improvements are listed on the wiki. - All network scripts moved from 'initscripts' to 'network', a separate package - /etc/rc.d/network retains ALL functionality that it has had previously, except it's wireless. - /etc/rc.conf network syntax remains, except it's wireless. - All wireless functionality now exists within the profiles. - /etc/network-profiles is no more, moved to /etc/network.d - profile syntax has changed, now using an ini format. See wiki for examples. - completely rewritten and cleaned up netcfg - netcfg menu support separated out from netcfg - network profiles moved from /etc/rc.d/network to /etc/rc.d/net-profiles Beyond that.... the changes are internal. Some minor cleanups and bugfixes in /etc/rc.d/network, and the rest of the changes are within netcfg and the Arch profile system. If you're interested in testing... there's details on the wiki, i've got a repo up in my public_html on archlinux.org. Feel free to put bugs on the tracker, or send via email. Patches to latest git are always welcome. Anything to say, add, suggest, please do, +1's great, +>1's better, -1's only with a good fair explanation. Thanks! James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

5 8

[arch-dev-public] Updating base /etc files
by Aaron Griffin 20 Apr '07

20 Apr '07

This is split from the "iputils and traceroute" discussion on arch-dev, moving it to the public list, and splitting things out. The issue is that our stock /etc/services and /etc/protocols files suck. Here's what I'd like to do - rip these files out of the iputils package and stick them in the 'filesystem' package. We can then grab updated files from NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/ As proposed in this bug report: http://bugs.archlinux.org/task/6194 I would also like to suggest one more file be updated, but am unsure if it should be part of the filesystem package: /etc/mailcap mailcap is actually really useful for things like firefox, which falls back to there if some of those goofy gnome services aren't running (I don't use them, so it cripples firefox here unless I use a ~/.mailcap) There is a huge problem with this, though, and that would be the fact that we'd have to add/remove entries to it to do things successfully... however, if we don't want to do this, we could at least provide entries for all out base packages (for instance, less and tar). - Aaron

4 10

[arch-dev-public] new screen with pty group set
by Aaron Griffin 20 Apr '07

20 Apr '07

Hey all, just a "heads up" The screen package in testing has the "pty group" set to 5, which is our "tty" group in /etc/group This was requested via IRC, but i don't know if it would have a greater impact I'm unaware of, so I pushed it to testing for the time being. Please let me know if it all works for you.

1 0

Re: [arch-dev-public] Fw: OpenSSL 0.9.8e has serious bug
by Tom K 20 Apr '07

20 Apr '07

David Rosenstrauch wrote: > Tom, > > I use EncFS pretty extensively, so I can assist you with testing if you > need. > > DR > Thanks David. Get it here for now: http://www.archlinux.org/~tom/packages/openssl-0.9.8e-3.pkg.tar.gz PKGBUILD and patch here: http://www.archlinux.org/~tom/packages/openssl/ I've asked the original reporter for details on the known OpenSSL/Blowfish problem, for inclusion in Arch News etc. T.

1 0

[arch-dev-public] [Fwd: [drotschm@linuxtag.org: [LT07-Pro-Announce] Infomail #3, April 19, 2007]]
by Alexander Baldeck 19 Apr '07

19 Apr '07

News from Linuxtag! :) -------- Original Message -------- Subject: [drotschm(a)linuxtag.org: [LT07-Pro-Announce] Infomail #3, April 19, 2007] Date: Thu, 19 Apr 2007 15:11:07 +0200 From: Christoph Neuroth <christoph.neuroth(a)gmx.net> To: Alexaner Baldeck <kth5(a)archlinuxppc.org> Gute Neuigkeiten! Zu Punkt 1: Wir haben einen 24m^2 Stand zusammen mit T2SDE (fork von ROCK Linux) und mandrivauser.de chris ----- Forwarded message from Wolfgang Drotschmann <drotschm(a)linuxtag.org> ----- Date: Thu, 19 Apr 2007 11:03:12 +0200 From: Wolfgang Drotschmann <drotschm(a)linuxtag.org> To: projects-announce(a)linuxtag.org Subject: [LT07-Pro-Announce] Infomail #3, April 19, 2007 Dear Projects, this is probably the most awaited mail you'll have received this week ;-) We would like to inform you about: o Booth Size, Layout and Equipment o Completion of vCC Record o Insurance o Beverages o Exhibitor Passes o Project Workshops o Banners for Your Website So you see, it's a lot of stuff. 1. Boot Size, Layout and Equipment This year we will try some new concepts and ideas for the free software project exhibition. The main idea is to get rid of the 5-10 sqm sized booths and to create an open, communicative ambience. Therefore we merged thematically related projects to a bigger booth - we occasionally use the word 'island' here :-) We talked to a number of you in the last days. If you share your booth with other projects, you can find them in the vCC [1]. To get the equipment for each booth planned, we urge you to check for your vCC entry regarding equipment you'll bring with you. Please updated the 'Equipment' field as soon as possible. Which brings us to... 2. Completion of vCC Record One advantage of a central data source is... well, you can get all the data you need from there. LinuxTag's source is the vCC. We use the information you fed into it to automagically generate the bits of information the visitor wants to know. Which are: o Project Title o Descriptions {en,de} x {long,short} Please complete or proof-read your vCC record! 3. Insurance LinuxTag cannot apply for an additional insurance to cover all projects and their equipment. Therefore, you should be very careful with the equipment you are going to use. If breaks, it's broken. You should also not leave small parts of value at the booth if there are no staff members at the booth, or when you are outside the exhibition (i. e. during the evening and morning). It should be sufficient to place movable parts in a box at the back of the booth. You should also not place larger items (like monitors and boxes) in the front of the booth in a way so that they can be carried away easily. Obeying to these basic rules should help you not loose any of your equipment. 4. Beverages If your project plans to hand visitors fluids of one kind or another, please ensure that this doesn't turn your booth into a beverages bar. This would actually cause a lot of problems because there's a default caterer and that company is the only one that is allowed to sell beverages at the exhibition center. They will get angry and try legal tricks (like asking for Korbgeld, see Wikipedia.de [2]) if they feel somebody is poaching in their territory. It is no problem to provide a cup of coffee or a glass of water to visitors inside the booth when talking to you and staff. Things just shouldn't spread. 5. Exhibitor Passes The exhibitor passes for project booth members will continue to be free of cost for a reasonable amount of booth personnel. However, they are not meant as a means for regular visitors to save the entrance-fee. Hence, please don't abuse this, and don't add random visitors as booth staff if they don't belong to your booth. For this matter we'll receive some eTickets later on. You can now order the exhibitor passes for each accepted project using the vCC. Please login at the virtual Conference Center and click in the Main menu on "Project" and then in submenu on "Projects". Each accepted project will find a button "Order exhibitor passes". After you ordered the passes, we will have a look at the list and approve them. Otherwise you will get an email from us. You'll need either normal entrance tickets or exhibitor passes for entering LinuxTag. You can get exhibitor passes on Tuesday at the LinuxTag office for the registered project staff. You can either get a single pass for your own, or the whole bunch for the entire project (or a mixture). If you fetch the passes for the entire project, please make sure that the other project members know this and know a way to get to the passes after the show has opened. Since our office is located behind the regular entrance, this won't work the same way when the show is going on. If you arrive after LinuxTag has already started, you'll have to either get a normal entrance ticket or ask your colleagues to provide you with an exhibitor pass from the inside. 6. Project Workshops Like last year we wait for your suggestions for project workshops! We'll reserve a number of rooms for this. It was well received by visitors in 2006, and most probably, because it will be on display for visitors again, will have a good number in audience this year, too. With you we'll use this "Workshop Rooms" to jointly organise a "projects to projects programme" or "developer to developer programme". Main purpose for these rooms is to provide attending projects an opportunity to talk to other developers (not necessarily from the same project) and to go into detail for a larger group than what would be possible at the booth. Please note: all workshops will be open to the public and will be announced so. In special cases we can make an exception, but we would like to discuss this in detail with you, if you think a session should be non-public. LinuxTag provides presentation equipment and probably Internet connectivity for all rooms. Normally a slot is 60 Minutes (don't forget to reserve some minutes at the end so the next workshop can be prepared!), if your workshop takes longer leave us a note within your abstract. Also do so, if you have a preference for a certain day. You can neglect the licence because it is not planned to distribute your submission (like a paper for the conference programme). But please do not forget to choose the language for your workshop submission. English may be your language of choice, but it is a valuable information for an interested visitor. Submissions can be placed -guess what!- in our vCC, please use your vCC account, and please choose category "Project Workshop" for your proposal here. Deadline is the April 27, 2007. 7. Banners for Your Website If you want to show your commitment to this years LinuxTag, or point visitors of your website to your booth, why not use a banner we prepared already for you? Please choose from the items over here: http://www.linuxtag.org/2007/de/expo/banner.html Please send us a short notice including links to the pages where you have placed the banners. Next Infomail will discuss... o ...how to provide us with your logo in an open vector format (PDF or EPS or SVG) and bitmap (JPG or PNG), o ...the whereabouts of deliveries, o ...booth security, storage for your equipment and luggage, o ...the size of the infopoints, and o ...accomodation. Please stay tuned! Regards, Susanne Pfeifer, Wolfgang Drotschmann, Marko Jung & Martin Schulte Project Committee LinuxTag 2007 [1] http://www.linuxtag.org/vcc/cc.pl?rm=projects [2] http://de.wikipedia.org/wiki/Korbgeld ----- End forwarded message -----

2 1

[arch-dev-public] 2.6.21-rc6-git2 please test!
by Tobias Powalowski 19 Apr '07

19 Apr '07

Hi just to inform all developers, the new kernel can be downloaded from this adress: http://www.archlinux.org/~tpowa/2.6.21/ or as repo [kernel] http://www.archlinux.org/~tpowa/2.6.21/ All developers that have modules and hardware are invited to test the already provided ones. I need your feedback on this task, to avoid broken modules in the future. Only broken one is ivtv at the moment and i haven'T build the unstable modules. If you find a fix for ivtv don't hesitate to put it here. 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

5 5

[arch-dev-public] List of public rsyncable mirrors
by Jason Chu 18 Apr '07

18 Apr '07

I've had a couple of people ask now about what rsync servers they should use. I don't remember there being a public list so now I'm asking. Can we create a public list of mirrors people should be syncing from organized by country? Jason

4 5

Re: [arch-dev-public] [arch] kernel 2.6.20.7, acpi changes and alsa bumped to 1.0.14rc3
by Dan McGee 18 Apr '07

18 Apr '07

On 4/18/07, Dan McGee <dpmcgee(a)gmail.com> wrote: > On 4/15/07, Tobias Powalowski <t.powa(a)gmx.de> wrote: > > Hi folks, > > the new kernel has acpi modules as much modularized as possible, it was > > requested due to some people having problems with the monitoring modules in > > the kernel. > > > > I have written a small wiki about the acpi modules, you need to add them to > > your MODULES=() array in rc.conf. > > > > http://wiki.archlinux.org/index.php/Acpi_modules > > I just found this to be an AWFUL idea. My computer just died due to > overheating. It was fine after I let it cool off- and rebooted and > loaded the thermal module as quick as I could. > > We can't do this to everyone's machine because of a few people- this > could fuck over a lot of people (excuse the language). I know it just > cost me the better part of an hour, and I haven't even found which > modules I actually need yet! > > There has to be a better way than this. Not happy right now. Ok, now that both the computer and I have cooled off (haha), I'll try to explain the issue a bit better. :) 1. I rebooted into the new kernel having added no new modules to my MODULES line in rc.conf. 2. I was sitting in X when I noticed everything start to slow down. A lot (processor underclocking more than likely). I do a few more things and boom...whole system goes down. 3. Wondering what happens, I press the power button on the box, which does nothing. 4. Thinking hardware issue, I unplug and replug the power cord. The power button works this time, but the computer only stays on for about 3 seconds before dying again. I open it up and can feel the heat wave from the processor. I let it cool for a while. 5. I reboot with the case open. When the BIOS kicks in, all fans are running. When the kernel takes over, all fans stop. Processor is still overly warm at this point. 6. Go to a console, type sensors, and am astounded to see my processor is at 62 C. Never seen it this high before. modprobe a few of the modules (processor, button, fan, thermal). As soon as I do thermal, the fans start spinning again. Processor temp eventually drops to normal (37 C or so). kth5 on IRC noted that it seems like a hardware issue, but I don't believe it could be given that everything normally works fine- the only thing that changed here was ACPI not being in the kernel proper. It looks like the BIOS hands off all responsibility to the kernel as soon as it is loaded, so not having this module really hurts. Tpowa, can you please list these problems? I feel this new issue could strike a lot more people that have similar situations to me, as opposed to the few that were affected before. I don't feel as if a typical Arch user should be required to have certain modules loaded at boot time- this stuff is meant to be in the kernel. How do other distros package and deal with this? Thoughts or comments? -Dan

1 0

[arch-dev-public] Linuxtag '07 - situation slightly changed to the better
by Alexander Baldeck 17 Apr '07

17 Apr '07

Hey all, I hope none has forgotten about this years' Linuxtag here in Berlin/Germany. Delmonico - the one in charge for keeping the communication running between us and the Linuxtag staff - has not received any updates whatsoever since for about 2 weeks. Nevertheless, our booth has been approved. We will have a chance to present ourselves again this year but further details about how much space we get and thus how many people we may take on the team, we don't know yet. Once Delmonico is able to report anything he will do so. Anyways, for those who have a longer way to the event and would like to participate I have organized a room in Bootlab where I can accommodate about 5 people. Sleeping bags are of course mandatory. ;) This brings me to the next topic, I'd like to see who actually plans to joins our ranks here. Here because I would like to see at least TUs or even better Devs before bringing in regular users. This is generally a better way to entertain the crowd with people knowing exactly what they're talking about. Well then, hands up guys! :) Cheers, -R

4 3

[arch-dev-public] games group
by Jan de Groot 17 Apr '07

17 Apr '07

Hi all, I'm currently busy with the movement of gnome from /opt/gnome to /usr. One of the last packages I need to do is gnome-games, which is everything but fun. Current situation: - gnome-games package, many games, different ones for every major release - several score files per game, created by postinstall/postupgrade with root:user permissions, writable by user, created as 660 files. - score files can change in any release Now a games group would come in handy: - forget about the post_install and score files - install game binaries setgid games - users can't cheat anymore because they can only write score files by executing the game I would propose to add a games group and a directory called /var/games or /var/lib/games with root:games ownership and 775 rights.

8 8

[arch-dev-public] Absence from Duties
by Jeff 'codemac' Mickey 16 Apr '07

16 Apr '07

As many of you may have heard, 32 members of the Virginia Tech community, and 1 asshole of a human have left this world. I will not be able to tend to my duties as a developer for an unspecified period of time for intensley personal reasons. I hope that none of you ever have to experience this. // codemac -- .: [ + carpe diem totus tuus + ] :.

2 1

[arch-dev-public] Oh Em Gee, I'm back
by Aaron Griffin 16 Apr '07

16 Apr '07

"Wait, you were gone?" Yeah yeah, I've been kinda AWOL for around a week. Some times real-life hits you like a ton of bricks... I'd go into it, but it's not real interesting, and nothing major happened. It's just the fact that I've been working quite a lot recently, and have suffered from computer burn-out. But I realized something. If I let this get me down, I'll pretty much never get anything done. It's kinda like lifting weights. When you start off, you do a small amount, and get sore, then repeat, and eventually the original weight is easy. That's what I need to force myself into. The more you do, the more you *can* do. But I'm digressing. Anyway, I have a huge amount of emails to go through (~30 or so, not counting flyspray emails) tonight, so if there's anything important that I should be looking at, feel free to ping me so I can get it first and get up to speed. -- Aaron

1 0

[arch-dev-public] x86_64: improving default CFLAGS
by Andreas Radke 16 Apr '07

16 Apr '07

http://bbs.archlinux.org/viewtopic.php?id=27139 after some discussions in this thread we want to change our default compiler flags. we want to make use of the SSE3 extensions most x86_64 cpus have. to not break backward compatibility for those few early cpus that lack SSE3 extensions we want to do it with -mtune. this is how we want to set it for the future: CFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe" CXXFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe" some testing is still required. i would like to put a modified version of pacman to testing right after it has moved to current. when everything is ok we would ask the pacman devs to change it to the default makepkg.conf. please discuss. Andy (for i686 are also some speedups possible but that's not my task)

5 7

Re: [arch-dev-public] [tur-users] Community repo cleanup completed
by Travis Willard 14 Apr '07

14 Apr '07

On Sun, 15 Apr 2007 02:42:15 +0800 "Callan Barrett" <wizzomafizzo(a)gmail.com> wrote: > On 4/15/07, Eric Belanger <belanger(a)astro.umontreal.ca> wrote: > > Hi everyone, > > > > The community repo cleanup is completed. > > > > The current orphans will remain in community and have been > > fixed/updated. I've added myself to the notification list so I'll > > be aware of any comments. There are still orphans which are > > dependency to other TU's packages. I haven't touch these as I > > assume the corresponding TU will eventually adopt them and maintain > > them. Here's the updated list: ..snip.. > > wizzomafizzo: you just uploaded a bunch of xfce-svn packages. I > > guess that xfce-svn is moving from unstable to community, right? > > Don't forget to adopt them. > > Yep, all xfce-svn packages have been uploaded to community and I'm > quite sure I've adopted them all now. Please tell me if I missed any, > though. > > Thanks. > Does this mean the xfce-svn packages in unstable should be removed? Shadowhand is definitely no longer doing this? -- Travis

3 2

[arch-dev-public] CD cover for Voodoo
by Judd Vinet 12 Apr '07

12 Apr '07

Hi guys, OSDisc emailed me -- they need a CD cover for the new release. Something snazzy like our old ones that are still up on the art[1] page. Anyone have some graphics chops? - J [1] http://www.archlinux.org/art/

5 8

[arch-dev-public] missing packages [extra]
by Tobias Powalowski 12 Apr '07

12 Apr '07

notice: Missing koffice-l10n-bg-1.5.2-1.pkg.tar.gz in ftp site notice: Missing ipw3945-beyond-1.1.3-3.pkg.tar.gz in ftp site notice: Missing devtools-0.3.4-1.1.pkg.tar.gz in ftp site notice: Missing waimea-0.5.1-3.pkg.tar.gz in ftp site -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-dev-public] missing packages [current]
by Tobias Powalowski 12 Apr '07

12 Apr '07

==> Generating Text Package List... notice: Missing esd-0.2.37-3.pkg.tar.gz in ftp site notice: Missing libgnomecanvas-2.14.0-2.pkg.tar.gz in ftp site notice: Missing gtk-engines-2.10.1-1.pkg.tar.gz in ftp site -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

Re: [arch-dev-public] [pacman-dev] Adding new users/groups
by Dan McGee 09 Apr '07

09 Apr '07

On 4/7/07, Roman Kyrylych <roman.kyrylych(a)gmail.com> wrote: > 2007/4/7, Andrew Fyfe <andrew(a)neptune-one.net>: > > What's the procedure for adding new system users/groups to the system. > > There's a lot of install scripts that add users/groups with specific > > ids, is there a list somewhere of all the names/ids used to stop 2 > > different packages from trying to use the same id? > > Developers have such list. > Why do you need this and why ask on pacman-dev? ;) The better question- why is this not a public list? -Dan

2 2

[arch-dev-public] Problems in 0.8
by James 08 Apr '07

08 Apr '07

Just posting this here, seeing if anyone has any other big problems noticed in 0.8 I caught this one on the forums, http://bbs.archlinux.org/viewtopic.php?id=31244 For a particular modern chipset, 2.6.20.4 doesnt even boot, making the 0.8 install CD useless for many. Given that 2.6.21 is at rc6, are we going to make a release at 2.6.21 as planned? Otherwise... it might be nice to just rebuild 0.8 as 0.8.1 with the newer kernel for these users. -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

1 0

[arch-dev-public] Move from /opt to /usr
by Tobias Kieslich 06 Apr '07

06 Apr '07

Hi, this is an old issue and I just talked to Jan about that. We both are all for that and will move gnome and xfce. Jan said kde needs some more investigation. It'll save us a whole lot of trouble in the long run. As far as xfce4 is concerned, 4.4.1 is expected to be there around the 9th of April. And I plan on using this to move over the whole repository. Just one more guess, when moving on to a newer repos layout, can we rename xfce4 to xfce, it's somewhat less limiting :P -T

4 5

[arch-dev-public] coreutils 6.9 + fakeroot + makepkg serious bug
by Thomas Bächler 05 Apr '07

05 Apr '07

While rebuilding some packages, namcap issued some warnings: beryl-core W: File (usr/man/man1/) does not have the world readable bit set. beryl-core W: File (usr/man/man3/) does not have the world readable bit set. When I look at the $startdir/pkg, everything is fine though. I narrowed it down to the following simple test case: [01:54:30][thomas@gollum shm]$ fakeroot bash-3.2# ls -lF insgesamt 0 bash-3.2# mkdir foo bash-3.2# ls -lF insgesamt 0 drwxr-xr-x 2 root root 40 2. Apr 01:54 foo/ bash-3.2# chmod 700 foo/ bash-3.2# ls -lF insgesamt 0 drwxr-xr-x 2 root root 40 2. Apr 01:54 foo/ bash-3.2# exit [01:55:02][thomas@gollum shm]$ ls -lF insgesamt 0 drwx------ 2 thomas users 40 2. Apr 01:54 foo/ [01:55:03][thomas@gollum shm]$ As you can see, the chmod has no effect inside the fakeroot environment, which causes a 'cp -a' in makepkg to behave incorrectly and may cause other similar bugs during makepkg. Downgrading coreutils from 6.9-1 to 6.7-1 solves this problem. I have no idea where to start, but this should be adressed quickly as it may break many packages. For everyone who is going to test, I found the old package here: ftp://ftp.tu-chemnitz.de/pub/linux/sunsite.unc-mirror/distributions/archlinux/current/os/i686/coreutils-6.7-1.pkg.tar.gz @Romashka: If you read this, I think your exaile build bug is also related to this, please confirm.

2 2

[arch-dev-public] New wireless and network scripts.
by James 05 Apr '07

05 Apr '07

Hey The network profile's that i've been working on for far too long, have now been uploaded and put into a git repository on archlinux.org. To get it, git clone http://archlinux.org/~james/projects/network.git To make a package, run package.sh for the meantime. There will be a proper PKGBUILD and a custom repository for it shortly. There's a few known bugs, and not enough documentation, however I've put enough basic information to get you going on the wiki: http://wiki.archlinux.org/index.php/Network_Scripts There's undoubtedly other bugs and hiccups, and i'm calling on you to test. If you find a bug, let me know. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

5 14

[arch-dev-public] status of xfce-svn
by Roman Kyrylych 04 Apr '07

04 Apr '07

Hi! We have xfce-svn group in Unstable repo, that was maintained by Shadowhand until he resigned as a maintainer. Because packages are not maintained now users fill bugreports about non-working packages. Is there a need in xfce-svn now? If noone is interested in maintaining them then I propose to remove them. -- Roman Kyrylych (Роман Кирилич)

3 6

[arch-dev-public] Bug Day
by Roman Kyrylych 04 Apr '07

04 Apr '07

Hi! I would like for the next Bug Day to happen on 14th of April. The reason for this is to reduce the amount of old reports and feature requests. We should clear outdated reports, fix/implement those that already have patches provided or are trivial to fix/implement, discuss the pros & cons of implementing some feature requests, look at reports assigned to inactive/resigned devs. If you cannot take part in the Bug Day, then choose any day when you'll have free time to do this work and plase notify other devs so they would know to take a closer look at your reports too. Please all users help us too. There are bugrepors that are probably already fixed but developers may not be aware of this because of lack of user feedback. Please review all bugs that were reported by you if they still are valid. If report are old enought and no further information from reporter is provided then developers will most likely close such bugs assuming they are fixed. We cannot fix bugs without your feedback. Join us at #archlinux-bugs channel on irc.freenode.net during 14th of April. As we leave in different timezones not all devs will be available at the same time, but feel free to report your issues to any dev available on-line. Also please check your mailboxes that may contain notifications about comments made by devs and other users. I would like to hear any proposals about possible improvements to the Bug Day effectiveness. P.S.: this is my first official announcement so don't beat me hard if something is wrong. :-P -- Roman Kyrylych (Роман Кирилич)

3 4

[arch-dev-public] Fixing docbook for iputils
by Aaron Griffin 02 Apr '07

02 Apr '07

Just a call for comments. I think our docbook package is broken - either that or we need much more DTDs. The reason being is that we're using a wickedly outdated iputils (newest one here: http://www.skbuff.net/iputils/) and the newer packages generate their man pages from docbook - which flat out fails. Also, according to neri, gimp-help also fails to build for similar reasons. I guess I'm writing this for two reasons: 1) As a 'heads-up' that a new iputils package is in the works, which will cover 3 other changes in addition to the version upgrade. 2) maybe some docbook pro will help me out here, as it seems like a real headache to mess with. Thanks, Aaron

1 0

[arch-dev-public] moving to pacbuild
by Aaron Griffin 01 Apr '07

01 Apr '07

This is one of those things that's not gonna get done until someone does it. For a trial (until we determine if it hurts us), I want to try and install pacbuild on gerolde. I think, however, it needs a good ol' -Syu, which I'll probably leave in more capable hands (though we need to make sure we don't break django with python2.5, heh). It should be easy to setup and apple daemon on there, then we need to get some build machines together. I have one here I can use, and can probably be sneaky about it and use one of the arch machines at work. We'd still need some x86_64 build machines, but that can't be all that hard. If there's a problem with putting this on gerolde at this stage, I _could_ open up my home machine for a while. Jason, is there anything blocking us from using pacbuild right now? - Aaron

4 5

[arch-dev-public] Berkeley DB change proposal
by Jan de Groot 01 Apr '07

01 Apr '07

Hi all, I'm about to make a slight change to evolution-data-server: build with system DB. Advantages: instead of having 4 copies of DB linked into a running evolution-data-server process (takes 4x600KB of memory), have only 1 copy of it running, which takes 1x600KB, saves 1800KB memory for having your gnome clock applet reading information from your evolution calendar Downside: Building with system-db breaks all datafiles, because they would need to get upgraded Workaround: Install a copy of DB 4.1.25, which is shipped internally in evolution, build with that Current workaround: - build a copy of DB 4.1.25 - install it in ${startdir}/src/build-db41 - make EDS configure script detect it there - make LDFLAGS+="-R/opt/gnome/lib/evolution-data-server-1.2" - install EDS as usual - install the libdb-4.1.so file in the location provided in LDFLAGS Very very very hacky, and we'll end up with quite some libdb-4.1.so files in the future if this goes on. Given the trouble we have with major upgrades of DB all the time, I would suggest a different approach to the DB package. Currently, DB contains some utilities, a versioned library and some generic include files. IMHO we should change that and put each DB package in a versioned pkgname: db4.1: /usr/bin/db4.1_* /usr/lib/libdb-4.1.so /usr/lib/libdb-4.1.a /usr/include/db4.1/*.h db4.5: /usr/bin/db4.5_* /usr/lib/libdb-4.5.* /usr/include/db4.5/*.h db: /usr/bin/db_* as symlinks to most recent DB package /usr/lib/libdb.* as symlinks to most recent DB package /usr/include/*.h as symlinks to most recent DB package This would: - throw away all bug reports we get on DB upgrades, old DB pkg stays installed, all new pkgs get compiled against the new DB version - make it very easy to compile packages with specific DB versions - Allow users to actually do something with on-disk DB files when it belongs to an older version. _______________________________________________ arch-dev mailing list arch-dev(a)archlinux.org http://www.archlinux.org/mailman/listinfo/arch-dev

1 0

[arch-dev-public] Uniform handling of webservers
by Aaron Griffin 31 Mar '07

31 Mar '07

Moving this discussion off of the private list, mainly because it wasn't resolved - I think Tobais' points here should be addressed. ---------- Forwarded message ---------- From: tobias(a)justdreams.de <tobias(a)justdreams.de> Date: Mar 25, 2007 1:11 PM Subject: Re: [arch-dev] Uniform handling of webservers To: Development Discussion for Arch Linux <arch-dev(a)archlinux.org> > Since this discussion kinda went away... I'm gonna bring it back up > (hooray gmail stars keeping me on task!). Hi, most people agree on /srv/www , but we have different opinions on how we wanna lay out the basic structure. Let's try to summary the ideas and concerns. I use apache and lighttpd to illustrate the issues: 1. shall we continuing using nobody as primary www user(group) or now when we unify things go and create a dedicated wwwuser with a reasonable set of permissions? 2. shall we create subdirs /srv/www/{httpd,lighttpd} per webserver as some people suggested? Web administration is an administrators job - not a package managers. 3. If we create subdirs, shall we have some magic that routes localhost automatically $wwwhome of the latest installed webserver? Do we wanna have magic at all? 4. Subdirs per webserver leave us with the issue, that we do not have a distinct directory, where we can install apps like phpMyAdmin per default to work out of the box. This is bad IMHO. The issue can be partially resolved by aliases or vhosts, but this requires both user interaction and some config tweaking, as lighttpd does not support easy *.conf handling with the vhost handling as apache does. There might be a way, but I have to investigate that. Also, this might mean that we will have to create special handlings per possibly installed webserver in the phpmyadmin.install post_insall(), I would like to get away without it! -T

4 4

[arch-dev-public] Updating the licenses package
by Aaron Griffin 30 Mar '07

30 Mar '07

Hey all, I actually just came across this page here: http://www.opensource.org/licenses/alphabetical I think we should go through and add some more common ones to the licenses packages (it's text, it'll compress well). This comes up because we probably need an update for the Python license anyway. Maybe we can even add all of them? Only problem is they don't seem to export plain text, so we can't really automate it... ewww. - Aaron

4 8

[arch-dev-public] 0.8 torrents
by Aaron Griffin 30 Mar '07

30 Mar '07

I created the torrents for the iso images, and put them on the ftp earlier today, so they should start hitting mirrors soon. I also placed them up on linuxtracker.org: I'm currently seeding all 6, though quite poorly - I need to open some more ports but my silly router doesn't accept ranges (one at a time is nasty). A few other people (Thomas, Dan, stonecrest maybe, etc) are also seeding some of them. Due to our recent bandwidth shenanigans, we should probably suggest the torrents over ftp download. Perhaps when neotuli updates the download page, we can move it around so the torrents appear to be the first choice? /me shrugs Enjoy the torrents - Aaron

5 6

[arch-dev-public] Final python 2.5 rebuild list set
by Jason Chu 29 Mar '07

29 Mar '07

I've finally finished creating the python 2.5 todo list. This is the list as of about 4 days ago, so some of these packages have already been rebuilt. If one of your packages has been rebuilt, feel free to just mark it as completed. http://archlinux.org/todo/40/ I've sent this email to arch-dev-public and arch-dev, just in case some developers aren't on arch-dev-public yet. If you're not on there, now's a good time to add yourself. Jason

1 0

[arch-dev-public] All setup
by Aaron Griffin 29 Mar '07

29 Mar '07

Ok, so I fixed a few mailman issues (bad img URLs, some urls having 'www.' and some without, mailman urls with and without 'www.' showing different MLs, etc) and switched this list to "anyone can subscribe" - users are moderated by default, which means they can't post to the list. I'll keep my eye on the admin queue for now, and make sure approve all our developers as they sign up - send me an email if I didn't get to you, and I'll do it asap. Is everything good? Would anyone mind if I announced this list to the public? - Aaron

3 3

[arch-dev-public] iputils & traceroute packaging
by Dan McGee 29 Mar '07

29 Mar '07

Quick question for whoever is responsible: Why on earth do we have a separate traceroute package that is not a part of base? This seems to fit much better being in the iputils package, although I am not familiar with the sources of these packages and why they are developed separately. $ pacman -Ql traceroute traceroute /usr/bin/traceroute traceroute /usr/man/man8/traceroute.8.gz $ pacman -Ql iputils iputils /bin/ping iputils /bin/ping6 iputils /etc/protocols iputils /etc/services iputils /usr/man/man8/arping.8.gz iputils /usr/man/man8/clockdiff.8.gz iputils /usr/man/man8/ping.8.gz iputils /usr/man/man8/rarpd.8.gz iputils /usr/man/man8/rdisc.8.gz iputils /usr/man/man8/tftpd.8.gz iputils /usr/man/man8/tracepath.8.gz iputils /usr/man/man8/traceroute6.8.gz iputils /usr/sbin/arping iputils /usr/sbin/clockdiff iputils /usr/sbin/rarpd iputils /usr/sbin/rdisc iputils /usr/sbin/tftpd iputils /usr/sbin/tracepath iputils /usr/sbin/tracepath6 iputils /usr/sbin/traceroute6 What I find really weird is the inclusion of traceroute6 in iputils. This all came up while going about "fixing" this bug: <http://bugs.archlinux.org/task/6725> I don't want to make mtr setuid unless we are going to make traceroute suid. mtr > traceroute > ping, so it should be at no higher of a level than the one below it. What should we be installing programs like this as? I think it makes sense to have ping and traceroute available to a user, so maybe they should all be SUID, currently traceroute6 is not. Comments and thoughts appreciated. -Dan

1 0

Re: [arch-dev-public] Test
by Jason Chu 29 Mar '07

29 Mar '07

On Thu, 29 Mar 2007 10:34:49 -0500 "Aaron Griffin" <aaronmgriffin(a)gmail.com> wrote: > hey all, respond if you get this (there's 4 of you). Response. Jason

2 1