- Arch-general - lists.archlinux.org

[arch-general] 2008.04-RC Images are out
by Simo Leone 18 Apr '08

18 Apr '08

Crosspostingissocool http://www.archlinux.org/news/389/ Enjoy.

7 6

[arch-general] libmms update in extra
by Dragonlord 16 Apr '08

16 Apr '08

Hi, I've made a new package in AUR - mimms, which depends on libmms from extra repo. But libmms is flagged out of date and mimms needs the new version to compile and run. Can someone please update the libmms PKGBUILD in extra? There is no maintainer for libmms, so, if this package isn't needed by any other packages, you can also move it to unsupported and I'll take care of it. mimms with the libmms v0.4 works fine, just a bit testing from my side. Thanks D

1 0

[arch-general] Way of flaging out of date?
by gan lu 13 Apr '08

13 Apr '08

In my opinion, Arch is the best distro can really do bleeding edge with stablility, thank devs for their excellent work. However due to some reasion (saying shortage of time, man power, instersts etc), some applications can't be updated in time. We can certainly flag it out of date in the web page easily, but is there a way we can record when it was flaged at the first time and count how many people (useres) want to flag it (like enable people to vote, but of course only send a remind email at the first/person )? Just my idea, I am not a programmer so don't blame me not to do it real by myself.

4 6

[arch-general] Transition to the new perl policy
by Ondřej Kučera 12 Apr '08

12 Apr '08

Hello, I was trying to figure out why something doesn't work with a certain perl module and even though later I found out that the problem is somewhere else, I noticed that there still are some files and directories in /usr/lib/perl5/site_perl/current. The packages responsible for this (on my machine) are: perl-compress-zlib perl-parse-recdescent perl-term-readline perl-io-compress-base perl-io-compress-zlib perl-compress-raw-zlib Is this considered a bug, shoud I file a bug report? If so, one for each package, or just on report listing them all? Also, there are these following five files that no package owns. error: No package owns ./x86_64-linux-thread-multi/DCOP/Object.pm error: No package owns ./x86_64-linux-thread-multi/auto/DCOP/DCOP.bs error: No package owns ./x86_64-linux-thread-multi/auto/DCOP/DCOP.so error: No package owns ./x86_64-linux-thread-multi/auto/DCOP/.packlist error: No package owns ./x86_64-linux-thread-multi/DCOP.pm This really confuses me because I never (and I mean really never) install anything any other way than via pacman. It is perhaps related to http://bugs.archlinux.org/task/8466, although I'm not sure how come they're without an owner now. Maybe it is because they used to be in site_perl/5.8.8 (and site_perl/current was only a symlink), whereas now they're in site_perl/current which is a regular directory now (and kdebindings still "owns" them in site_perl/5.8.8). Ondřej -- Cheers, Ondřej Kučera

3 4

[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

[arch-general] Previous JRE package release needed.
by ndlarsen 11 Apr '08

11 Apr '08

Hey all. Due to internet banking issues I am in need of the previous package release of JRE. Anyone who might have it? Regards ndlarsen

3 4

[arch-general] eclipse crashes with jre-6u5
by Maik Beckmann 10 Apr '08

10 Apr '08

Just a note for those using eclipse: - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6614100 This issues isn't one with 6u3. A workaround suggested at the page linked to above is to create a file called .hotspot_compiler containing this exclude org/eclipse/core/internal/dtree/DataTreeNode forwardDeltaWith I will test the workaround first. If it really work I'll report here. If it doesn't, I'll use abs to downgrade to 6u3. Best, -- Maik PS: Don't consider me as a java pro. I use eclipse for C++,Fortran and LaTeX.

1 1

Re: [arch-general] [arch-dev-public] initscripts changes
by RedShift 08 Apr '08

08 Apr '08

Thomas Bächler wrote: > I am hacking initscripts and can't quite decide on two issues: > > 1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. What's wrong with putting that in fstab? What if I don't want to have that mounted? So instead of modified fstab I'd have to mess with rc.sysinit everytime the initscripts get upgraded? This is the same discussion as with moving lo to rc.sysinit instead of leaving it in rc.conf. Uterly pointless. Glenn > 2) I'd like to remove the (hardcoded) line /usr/bin/setterm -blank 15 > from rc.sysinit. > No argument here. > Can I get opinions on these? >

27 52

[arch-general] Hardcoded or not
by gan lu 08 Apr '08

08 Apr '08

I put my words here but it's just my opinion: 1. Arch's devs are great and cute. 2. I am against to hardcoded-things. 3. If possible, I prefer what has been hardcoded in file system mounting should put int one file: fstab. 4. Should I open a bug tracker for the discussion.

2 1

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