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

[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