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

[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