March 2008 - Arch-general - lists.archlinux.org

[arch-general] ArchISO FTP Installer - Testers Needed
by Simo Leone 12 Apr '08

12 Apr '08

Hey everyone, I'd like to begin testing some preliminary work with the arch livecd system. You can find a livecd rigged up to work as an ftp installer at: http://dev.archlinux.org/~simo/archiso_tests/arch-ftp-live-1206519468.iso This ISO consists of our current installer scripts and a functioning arch livecd containing most of the base package set. It uses the grub boot loader, which is likely to be changed to isolinux in the near future. At this point, it's an i686-only thing, but an x86_64 version will be coming soon. If you've got some time to kill, please give the iso a whirl. You'll find the installer and its documentation in its usual home at /arch/ on the livecd system. It'd be nice to have this tested on a large variety of systems if possible. **I need feedback on the following regarding ISO bootup** - Did the grub loader work as expected? - Did it pick up and load the module for your network hardware? - Did it pick up and load the modules for your disk controllers? - Any kernel panics, freezes, that sort of ugly stuff. Please keep in mind that this is not intended to be production quality at this point, and it's a very early version, so there are still a lot of sharp edges that need to be smoothed out. Thanks for your help, -Simo offtopic: archiso_tests also contains a hacky xfce4 livecd image you might want to play around with, although it's a little oldy moldy.

12 16

Re: [arch-general] signoff kernel26-2.6.24.3-6
by RedShift 08 Apr '08

08 Apr '08

Simo Leone wrote: > On Mon, Mar 24, 2008 at 07:28:13PM +0100, Tobias Powalowski wrote: >> Users are happy with the new ISOs, just read the Forum thread about it. >> > You know what. I don't care if the users are happy with the new ISOs. > That's right, I finally said it. > _I DON'T CARE_ > > I don't care because _I_ am not happy with them. As someone who can see > that from a technological standpoint, it's a marvel that they even work, > that is, as a software developer, I'm ashamed to be associated with such > a shoddy product. > > I've offered alternatives, hell I've spent a lot of time offering > alternatives, built on more solid software enginerring principles > than "Users are Happy", but no one around here, save Dan and Aaron, who > just happen to be code contributors, seems to give a damn. What's up > with that? > *** Prelude *** This discussion was started when tpowa was asking for a signoff on the kernel26 package, which includes patches for an out-of-tree kernel module for a certain wireless card. *** What Dan McGee said *** I have an Eee, I managed to pull off an FTP install just fine. I compiled the driver by hand, just as has always been the case for out-of-tree driver with Arch if there is not already a separate package for it. I did this 22 months ago for my zd1211 wireless stick before it was in the mainline kernel, and I had *0 days of desktop linux experience* at that time (on my own machine). 0 days. And now we bend over backwards for someone needing a driver? Ugh. I thought April fools and the rename to Newb Linux wasn't for another week. -Dan *** My response *** I find myself in 100% agreement on Simo's and Dan's opinion. I've warned for this situation before (see the bug tracker). An example should be taken from CRUX, they've held true to their principles and said screw those who don't agree. And they're right, otherwise we're just on the road to the next Ubuntu. Lots of software is patched nowadays, even for very stupid things most of the old user base wouldn't have cared about. And when PKGBUILDs starts to grow to the point they need scrolling and comments to be clarified, that's just going the wrong way. (Hint, kernel26 PKGBUILD). I wanted to steer clear of personal attacks but unfortunately, tpowa has been a large contributer to the "lets adapt to the community"-style. I'm sorry to say it, but that's how I experience it (because of his work on kernel26 and qt) - and it needs to be said! Arch used to be different. I wouldn't be very surprised if Judd raised eyebrows on what's been going on lately. Notice the large influx of new users. The fact alone that a topic has been started for a stable package repository *and people are willing to contribute to this*, shows the kind of users we're getting: the wrong ones. There has been an ongoing discussion on the bug tracker whether or not post uninstall scripts should stop daemons upon removal. These ideas come from users that are either inexperienced, or trying to mold Arch in something its not. And what about dependencies in initscripts... wtf? Any sane user can find them out for themselves and put them in the right order in rc.conf. What if someone doesn't want this behaviour? For example I don't want dbus and hal started, but what if the kdm rc.d script will do this for me? It ends up with a pretty big mess. Let alone the complexity that is added to the initscripts. What Arch needs, is to say NO to things. There will always be users that disagree, can't use some package because it doesn't fit them. Especially the kernel, all these half-baked largely untested patches for things only a few people (or even just 1) use is a threat to the stability of the kernel package. I've had my share of hardware that didn't work for me, these issues are solved by either compiling your own kernel, replacing the hardware or simply waiting for the next kernel release. But adding largely untested and nobody-knows-where-it-came-from patches to the kernel is *evil*. Another example is the addition of the uucp group by default to /etc/groups. The number of users that use dailup and faxing is *so limited*. And they can just as well addgroup themselves. But meanwhile, all the other users have to take this uucp crap on a default install. And don't say they can groupdel afterwards, Arch is supposed to be slim BY DEFAULT. If people need to start removing crap after they've installed Arch, then something is definitely wrong. What Arch needs is to have strict guidelines on PKGBUILDs and kick out any developers that don't have the same idea. A proposition: * Patches are unacceptable unless in the case the software wouldn't work *at all* (Hint, qt PKGBUILD) * Pre and post install/remove actions should be kept at a minimum. Assume the user is smart (quite the opposite of the current trend). Everybody can read the manpage to adduser and addgroup. Post install echos pointing out small hints to get going quickly is acceptable * Stress the fact that users must read pacman's output and the news. Alot of problems on IRC are related to the fact that people are lazy and don't read pacman's output _at all_. That's their own damn fault * No handholding (like, no automatic stopping of daemons upon pre remove, adding of groups, etc...) * Bugs and other issues that come from upstream, _should be fixed upstream_. If people do have problems with a certain issue, they can abs and makepkg themselves. (See rule 1) * No branding or "Arch defaults". It only makes the PKGBUILDs more complex, and ruins the idea of the software coming in its original form from the authors Another point of interest may be that many people used to find gnome coming "ugly" by default (I don't know if this still the case). So what? Selecting your own theme is just a few mouse clicks away. Arch should never come with a fscked up KDE or Gnome profile like Ubuntu and others do. In fact, packages should *always* come with the defaults shipped by upstream. That being said, there's no such thing as one size fits all. There will *always* be users that "fall out of the boat" (a Dutch expression). But the fact is, because of Arch's simplicity, Arch can be made to work for these people in a very easy way. But when you have a kernel26 PKGBUILD that's 320 lines long, that simplicity is gone. The users should adapt to Arch, not the other way around. Glenn

21 37

[arch-general] Dropping ipw3945 from core
by Thomas Bächler 02 Apr '08

02 Apr '08

After I discovered that my problems with the new Intel driver where related to dhclient and fixed the bug, I am now successfully using iwl3945 on my machine. It seems to be working perfectly, so I am considering dropping ipw3945 from core/support with the 2.6.25 release (so there will be no new package versions after ipw3945-1.2.2-8). This is intended as a warning, but also as a question: Is there anyone who cannot use iwl3945 instead of ipw3945?

11 15

Re: [arch-general] [arch-dev-public] licenses: GPL permutations
by Loui 01 Apr '08

01 Apr '08

On Sun, 30 Mar 2008 17:20:37 +0300 "Roman Kyrylych" <roman.kyrylych(a)gmail.com> wrote: > 2008/3/30, Paul Mattal <paul(a)mattal.com>: > > What is the right way to list all the various contortions you can now > > have of GPL in the license array? There's: > > > > GPL - any version of GPL > > GPL2 - only version 2 > > GPL2+ - version 2 or later > > GPL3 - version 3 only > > GPL3+ - version 3 or later > > > > These are all substantively different (except the last two.. for now) so > > how do we express these? Should we actually create common licenses GPL2+ > > and GPL3+ which reference the other two, and make GPL reference them > > all? Do we need a GPL1 and GPL1+? > > This issue was discussed in past > (I'm lazy to search for exact thread(s), sorry). > The current scheme is: > GPL - GPLv2 "or, at your opinion, any later version" > GPL2 - GPL2 only (e.g. Linux kernel) > GPL3 - GPL3 "or, at your opinion, any later version" > I don't know of a single project with GPLv1 or GPLv3-only license. > I don't like all these "this version or later" boondongles. Why don't we just keep things KISS and let people explicitly state what licenses are permissable. GPL1, GPL2, GPL3. Put one, or more of those in your licenses array and it's crystal clear what you mean.

7 11

[arch-general] problem with courier-imap-4.3.1-1-i686
by Jason R Begley 31 Mar '08

31 Mar '08

I can't get some mail clients to connect to courier-imap-4.3.1-1-i686 after reecnt upgrades... Was working file with courier-imap-4.2.1-2-i686, I have rolled back without problems. Only error I could find in the log was imapd-ssl: couriertls: accept: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher Maybe only compiled for ssl3 and my clients need <V3?? Thanks, Jason

2 2

[arch-general] Installation: after first reboot ext3 superblock mount time in future
by Gerhard Brauer 31 Mar '08

31 Mar '08

Hello, i've noticed this meanwhile quiet often after many installations. Currently after a test with 2008.03-0.3, but also with older ISOs: After install and first reboot i got such fsck notice during rc: ,---- | /dev/sda3: Superblock last mount time is in the future. FIXED | /dev/sda3 has gone 49710 days without being checked, check forced. `---- Here¹ you could download a screenshot from such a situation where also a reboot is required after fsck. Cause this is the *first* reboot after installation users will get a bad impression about Arch. First i thought this comes from vmware, but i also get it in virtualbox and i've seen this also during real installations. I have a suspicion: During (c)fdisk and formatting the disks current locale and timezone is set to US values (don't know at the moment the initial settings presented in rc.conf). During configuration i set my locale and timezone always to de_DE.utf8 and Europe/Berlin. And when first reboot is made that from umounting / there is a time difference that could cause such and flag it on ext3 partition? Or with the order in rc scripts? Maybe also that the hwclock is changed during/after installation... Have others also seen such? ¹ http://users.archlinux.de/~gerbra/screen.png -- Don't drink and root!

8 20

[arch-general] Something screwy with colour terminal output at shutdown
by Neil Darlow 31 Mar '08

31 Mar '08

Hi, Since the last initscripts update (I think) my colour terminal output at shutdown is messed-up. Use of colour at startup is correct but at shutdown the following is shown: 1) The preceeding :: appear dim-yellow 2) Daemon names don't appear 3) Daemon shutdown noise (e.g. postgresql's server stopped output) appears dim-grey It's not a big problem, I could just set USECOLOR="no" but if anyone knows a quick fix to make it work again, I would prefer that. Regards, Neil Darlow

2 2

[arch-general] html messages on this list.
by Arvid Ephraim Picciani 30 Mar '08

30 Mar '08

please stop sending broken html from dialup machines. I can't believe arch-general is the only list where people do that. Even the default sa from the arch packges filters those with up to 8 points. Seriously,... archers should be able to read RFCs and setup their MUA correctly. -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani

3 2

[arch-general] Current FTP/HTTP install broken
by Gerhard Brauer 29 Mar '08

29 Mar '08

Hello, at the moment it seems that doing installation by ftp/http source is broken for the current ISOs 2007.08-2. We got several posts on archlinux.de and i see also on archlinux.org: http://bbs.archlinux.org/viewtopic.php?pid=345662 Also some new comments in old bugreport: http://bugs.archlinux.org/task/8898 Problems seems some missing filelists in some packages (ex. glibc) and that there are 3 /mnt/.CHANGELOG files conflicting in glibc, initscripts and perl. These stops the installation of all/most base packages and so if user go further in install/configuration all config files are empty. Will these be fixed before the new ISO go official? Bye Gerhard -- DSSP - Deutschland sucht den Super Papst Casting mit Fliege

6 11

[arch-general] Warning on php-apc update
by Pierre Schmitz 26 Mar '08

26 Mar '08

Dear PHP user, the update from php-apc to Version 3.0.17 includes a security fix: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1488 But it seems that the other changes of that new version are introducing several problems which will cause php to crash. It seems to be quite random but I have seen phpMyAdmin triggering those crashes a lot. I would recommend to disable APC until this is fixed. My current plan is to downgrade APC to 3.0.16 again and try to backport the security patch only. Greetings, Pierre PS: this bug-report seems to be related: http://pecl.php.net/bugs/bug.php?id=13505 -- archlinux.de

1 1