- Arch-general - lists.archlinux.org

[arch-general] Banshee needs an update
by Alec Hussey 19 Apr '08

19 Apr '08

Hello, I was glad when you guys (or Jan de Groot, whichever) decided to push the banshee alpha out to extra. However, it is missing many pretty essential features and it now far behind the releases put out by the banshee developers. I think that either we need to keep up or provide two seperate versions of the package until a final release of 1.0 is made. Thanks! Alec Hussey

8 11

[arch-general] Mcpp in extra has no maintainer
by Grigorios Bouzakis 19 Apr '08

19 Apr '08

As subject. It is also out of date.I assume its kth5's package since it is a dependency to xorg-server-utils. Greg

1 0

[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 11 Apr '08

11 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 07 Apr '08

07 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] arch and xen = awesome
by Arvid Ephraim Picciani 07 Apr '08

07 Apr '08

btw. something positive: anyone following the xen mailing list? half of the problems are becouse somone fucked something really badly downstream. like an automatic kernel install script that overwrites your grub config, becouse it is oh so much smarter then a human. wuuush production server gone. yay. arch doesn't have those problems. guess why? thanks for all those years of assuming humans are smarter then scripts! -- best regards Arvid Ephraim Picciani

2 1

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

07 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. > 2) I'd like to remove the (hardcoded) line /usr/bin/setterm -blank 15 > from rc.sysinit. > > Can I get opinions on these? > Thomas, Having read your last e-mail you are right, I should have *pointed out* my opinion instead of going omgwtf. The thread resulted in savagery - nowhere near civilized. I apologize for that. I will try and keep my e-mails more professional. Glenn

3 2

[arch-general] graphviz needs to come out of testing for gnome-2.22 upgrade
by Neil Darlow 07 Apr '08

07 Apr '08

Hi, graphviz-2.18 is a dependency of anjuta and currently it's stuck in testing. Looking at its repo information it appears to be maintainerless. Could someone please progress it out of testing. Thanks. Regards, Neil Darlow

1 0

Re: [arch-general] [arch-dev-public] initscripts changes
by Giovanni Scafora 06 Apr '08

06 Apr '08

2008/4/6, Thomas Bächler <thomas(a)archlinux.org>: > 2) I'd like to remove the (hardcoded) line /usr/bin/setterm -blank 15 from > rc.sysinit. +1 here. -- Giovanni Scafora Arch Linux Trusted User (voidnull) http://www.archlinux.org linuxmania(a)gmail.com

1 0

[arch-general] RIT.EDU New Mirror
by Lee R. Burton 06 Apr '08

06 Apr '08

http://mirror.rit.edu/archlinux Supports ftp and rsync as well, I would like to make it an official mirror. (do you all do push mirroring?) Located Rochester, NY, USA ~200mbps, Academic backbone No IPV6 yet... Is there any other information needed? --- Lee Burton lburton(a)mrow.org 301 910 0246

4 5

[arch-general] How to create archlinux install CD?
by Karolina Lindqvist 05 Apr '08

05 Apr '08

I have a new i586 machine and want to install archlinux i586 on it. So I want to recreate the archlinux install CD. But how do i do it? I have unpacked the install ISO, and is replacing all the packages, but when it comes to inird.img, the instructions in the wiki do not work. I cannot mount the unzipped inird.img. What should I do? file say that it is a cpio archive, but how do I unpack and mount it? And then, what is lowcore.img? Of course I could do it by booting debian, or something, and then replacing it with archlinux, but actually having an archlinux install CD would be pretty handy for my i586 machines.

6 6

[arch-general] initscripts-splash
by Elia Yehuda 04 Apr '08

04 Apr '08

Hey all, as been advised before to use the new functions.d functionality i've wrote a splashy functions file which seems to work pretty well. one problem though - since the /etc/rc.d/functions file only expose the source_functions function and doesn't actually execute it, all the functions.d/* files will be ignored unless the source_functions is specifically being called to. this raise a problem with progressing the progress-bar when starting the daemons in rc.multi - since i was trying to keep the initscripts intact and not change any of the scripts, ive recreated add_daemon in my functions.d/splashy file which does increment the progress bar, but functions.d/splashy will be ignored since all the daemon scripts simply source /etc/rc.d/functions but dont call the source_functions. the only solution i could find was to call source_functions within /etc/rc.d/functions itself which means whenever /etc/rc.d/functions is being sourced, source_functions will be called too. i would like to know the cons for this behavior and whether this shouldn't be the default behavior anyway. also, if someone has a better alternative to make rc.multi/daemons be aware of splashy or the functions.d/* files i'll be glad to hear. Blessings, z4ziggy

1 0

[arch-general] HP C3180 connected using usb no longer works
by Neil Darlow 04 Apr '08

04 Apr '08

Hi, My HP C3180, connected using usb, has recently stopped working. I'm not sure if it's related to recent changes in udev. lsusb -vv gives: Bus 002 Device 007: ID 03f0:5611 Hewlett-Packard PhotoSmart C3180 ls -l /dev/usbdev2.7 gives: crw-rw-rw- 1 root lp 189, 134 2008-04-04 19:40 /dev/usbdev2.7 My groups setting is: sys tty lp wheel network video audio optical storage scanner camera power users neil I am using udev-119-1, foomatic-db-hpijs 20080211-1 and cups-1.3.7-1 on i686. Any suggestions as to where to look for debugging this would be appreciated. I recall having to do this once before. Regards, Neil Darlow

1 0

[arch-general] ArchISO FTP Installer - Round 2
by Simo Leone 04 Apr '08

04 Apr '08

First off, thanks for the feedback last week. Most of the issues were minor and not-too-technical, so they weren't too tricky to iron out. Another batch of images has been generated with suggested improvements, they can be found at: http://dev.archlinux.org/~simo/archiso_tests/installer/ This time, there are ISO and USB images for both architectures. Once again, I'm looking for testers. So if you have some time to kill, please give 'em a spin and let us know how it goes. Generally speaking the live system should be able to: a) boot and b) connect to a network. If for some reason you can't get it to do one of those, I'm especially interested in hearing about it. If no major issues can be identified with these, the next batch will be a full-blown core-ftp-i686-x86_64-usb-iso release. Early and Often, as they say. Thanks for your help! -- Simo Leone Archlinux Developer PS: For the interested, changelogs and code repos: http://code.neotuli.net/gitweb/?p=archiso.git;a=shortlog;h=refs/heads/ftp-i… http://projects.archlinux.org/git/?p=archiso.git;a=summary

1 0

[arch-general] phpPgAdmin package appears broken in latest update
by alec.hussey＠madsoft.org 02 Apr '08

02 Apr '08

Hey everyone, The other day I did a system upgrade and upgrade to the latest phpPgAdmin. However, after the ugrade had finished there was nothing left in /home/httpd/html/phpPgAdmin other than conf/config.inc.php.pacsave. And removing then reinstalling the package does not resolve the problem. Then I figured it may have moved directories and didnt specify that during the upgrade but the only results returned are: /home/httpd/html/phpPgAdmin /home/httpd/html/phpPgAdmin/conf /home/httpd/html/phpPgAdmin/conf/config.inc.php.pacsave Not exactly sure what happened here but it seems as if the package has become broken. Maybe if anyone else has a better idea they could let me know. Thanks! -Alec Hussey

3 2

[arch-general] [English] New Distro - Can't Read German
by pyther 01 Apr '08

01 Apr '08

I need you guys to recommend a new distro. Unfortunately I made a terrible mistake by taking Spanish two years ago (didn't learn much, but still...). This means I do not know German I will be unable to read man pages and what not! I am looking for an ENGLISH distro that is as similar to Arch Linux as possible. Any help would be great! Thank you, Pyther

29 41

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

01 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

[arch-general] Custom kernel compile fails
by CtM 01 Apr '08

01 Apr '08

Happy April everyone! I was just wondering if anyone else was having issues building a recent custom kernel. I find that it fails on the make command. Here is the output I get: LD .tmp_vmlinux1 kernel/built-in.o: In function `getnstimeofday': (.text+0x205d3): undefined reference to `__umoddi3' kernel/built-in.o: In function `getnstimeofday': (.text+0x205f6): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x20718): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x20736): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x209e6): undefined reference to `__umoddi3' timekeeping.c:(.text+0x20a06): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x20d5a): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x20d7a): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x211f6): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x21216): undefined reference to `__udivdi3' make: *** [.tmp_vmlinux1] Error 1 I have tried kernel 2.6.24 and 2.6.24.4 on two different machines with two different cpu's (one intel dual core and one AMD 64 bit). I've tried using my previous config (make oldconfig) and also tried without it. I even ran make clean && make mrproper on the new extracted kernel directory before attempting to build it. Usually upgrading a kernel is very routine for me, but this time it isn't working. All kernel sources were downloaded from kernel.org as usual for me. Any ideas would be appreciated. Thanks, CtM

4 3