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

[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