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

[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