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

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

23 Apr '07

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

2 1

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

22 Apr '07

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

2 2

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

21 Apr '07

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

4 4

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

21 Apr '07

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

1 0

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

20 Apr '07

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

5 6

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

20 Apr '07

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

2 1

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

20 Apr '07

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

1 0

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

20 Apr '07

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

5 8

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

20 Apr '07

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

4 10

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

20 Apr '07

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

1 0