Arch-general December 2008

arch-general@lists.archlinux.org

94 participants
78 discussions

Re: [arch-general] [arch-dev-public] request for toolchain signoffs
by Andreas Radke 14 Dec '08

14 Dec '08

I've pushed a glibc 2.9-2 to testing. I have added all changes made in Fedora's FC10 2.9-3 rpm. They have included some minor fixes and a workaround for the name resolving issue. This should fix our FS #12215. Now we need to know if there are still DNS problems. If it's solved I'd like to push it quickly to core. New gcc versions are not far away... -Andy

1 0

[arch-general] Dovecot imap processes pinning CPU
by David Rosenstrauch 14 Dec '08

14 Dec '08

In recent days, dovecot's "imap" processes keep getting stuck. Each time I check my server there's a bunch of "imap" processes (sometimes 2 of them, sometimes 4, sometimes 6) that are using all of the box's CPU. And worse, there's no way to kill the processes either (neither kill -15 or kill -9 works), which means that I wind up having to reboot the box every time this happens. REALLY irritating. I don't normally even *see* the imap processes in htop, as I think they're pretty short lived. And I'm not sure what they're looping trying to do. My debugging skills on Linux are a bit weak, and so I don't know how to look at the process and see what it's doing. Also, not sure what's changed on my system to cause this, as this is definitely a recent problem. Maybe the upgrade to Thunderbird 2.0.0.18 (since I usually use T'Bird to access my email). I don't seem to run into this problem when I use Squirrelmail. Anyone have any idea what the problem might be? Or, if not, then suggestions on how I might be able to debug the situation myself? TIA, DR

4 8

[arch-general] pysol/python broken?
by Javier Vasquez 13 Dec '08

13 Dec '08

Hi all, I'm trying to run pysol, but as soon as I get to load a game, pysol crashes: Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/pysollib/app.py", line 529, in mainloop self.runGame(id, random) File "/usr/lib/python2.5/site-packages/pysollib/app.py", line 626, in runGame self.menubar.updateFavoriteGamesMenu() File "/usr/lib/python2.5/site-packages/pysollib/tile/menubar.py", line 884, in updateFavoriteGamesMenu self.updateGamesMenu(submenu, games) File "/usr/lib/python2.5/site-packages/pysollib/tile/menubar.py", line 809, in updateGamesMenu menu.delete(0, 'last') File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 2670, in delete if c in self._tclCommands: TypeError: argument of type 'NoneType' is not iterable Traceback (most recent call last): File "/usr/bin/pysol", line 32, in <module> sys.exit(main(sys.argv)) File "/usr/lib/python2.5/site-packages/pysollib/main.py", line 374, in main app.mainloop() File "/usr/lib/python2.5/site-packages/pysollib/app.py", line 529, in mainloop self.runGame(id, random) File "/usr/lib/python2.5/site-packages/pysollib/app.py", line 626, in runGame self.menubar.updateFavoriteGamesMenu() File "/usr/lib/python2.5/site-packages/pysollib/tile/menubar.py", line 884, in updateFavoriteGamesMenuJavier. -- Javier self.updateGamesMenu(submenu, games) File "/usr/lib/python2.5/site-packages/pysollib/tile/menubar.py", line 809, in updateGamesMenu menu.delete(0, 'last') File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 2670, in delete if c in self._tclCommands: TypeError: argument of type 'NoneType' is not iterable Before that, when just running pysol, there were other errors regarding no having a sound device, which is OK since I don't, :) However these other errors when loading any game make pysol crash... Thanks Javier.

2 3

[arch-general] bug in pacman? or something else?
by Sentinel 13 Dec '08

13 Dec '08

Hello, Is this a bug, or pacman can not correctly figure out the version of heimdal? Or maybe I am missing something...? I installed wireshark but with a workaround. I edited the PKGBUILD end deleted the heimdal dependency. As I have the correct version of heimdal installed it was built successfully (that is why the output below wants to reinstall wireshark). Bud I don't think this workaround is realy KISS. root@sentinel:/home/sentinel# pacman -S wireshark warning: wireshark-1.0.4-3 is up to date -- reinstalling resolving dependencies... error: cannot resolve "heimdal>=1.2.1", a dependency of "wireshark" error: failed to prepare transaction (could not satisfy dependencies) :: wireshark: requires heimdal>=1.2.1 root@sentinel:/home/sentinel# pacman -Q heimdal heimdal 1.2-2 Tom

5 5

[arch-general] Missing Deluge plugins
by Mordechai Peller 12 Dec '08

12 Dec '08

After a upgrading Deluge (I think it was to 1.0, but I'm not sure) I lost all plugins except Blocklist and Labels. Any suggestions? Thanks.

2 1

Re: [arch-general] [arch-dev-public] Replace syslog-ng with rsyslog
by Ghost1227 12 Dec '08

12 Dec '08

Aaron Griffin wrote: > On Fri, Dec 12, 2008 at 1:40 AM, Thomas Bächler <thomas(a)archlinux.org> wrote: > >> Aaron Griffin schrieb: >> >>> http://bugs.archlinux.org/task/12314 >>> >>> Just want to know what you guys think about this. The biggest concern, >>> from a lot of people, appears to be that syslog-ng is dual licensed, >>> so patches may get denied because they are already in the pay version. >>> >> I didn't look at rsyslogd, but I am actually happy with syslog-ng. So unless >> we have a REAL reason for switching (and some bitchy licensing concerns are >> not a real reason to me) I vote -1. >> >> >> > > http://www.rsyslog.com/doc-rsyslog_ng_comparison.html > I hadn't seen that before, but I must admit, I'm intrigued... I'll be looking into rsyslog more.

1 0

[arch-general] arch release schedule
by Dieter Plaetinck 12 Dec '08

12 Dec '08

Hi all, Any estimation when the next arch release will be? Or will it be announced on this mailing list a few days before? that would be good enough too. The reason I'm asking is AIF has again undergone many changes. I could start working now on a usable, reasonably stable alpha release without lvm/dm_crypt support, or if there's more time I can try to stabilize those features as well. Like Aaron said, it would be nice to have aif as an alternative, experimental installer on the installcd, I would like to synchronize my schedule a bit with the next release. Dieter

9 9

[arch-general] customized ArchLinux install CD with speech support
by Chris Brannon 10 Dec '08

10 Dec '08

I am happy to announce the first release of a modified ArchLinux CD for i686 with speech support. The .iso should be almost equivalent to the FTP installer, with one exception: it starts speaking at boot. One may obtain the image via HTTP or via BitTorrent. Download URL: http://cmb.tysdomain.com/talking-arch-ftp.iso Torrent: http://members.cox.net/cmbrannon/talking-arch-ftp.iso.torrent Note that it is a trackerless torrent, and it won't work with older clients. Thanks to Tyler for hosting the downloadable image. The following list of steps is a brief guide to installing ArchLinux with speech. I haven't tested the install process, because my machines are all occupied. If anyone has trouble with it, send me a private email. The instructions assume that your root partition will be mounted on /mnt. Change /mnt to something else if this assumption doesn't hold. 1. Use the installer on the CD, as per the beginner's guide. 2. Install the alsa-utils and espeak packages: pacman --root=/mnt -S alsa-utils espeak 3. Install the speakup and espeakup packages. These are not yet available in the community repository. There are two ways to install them, depending on how much you trust me. Alternative 1: Use the binary packages from my website. I promise that the speakup package will always match the kernel version available from the official repos. Append the following two lines to /etc/pacman.conf and /mnt/etc/pacman.conf: [blind] Server = http://members.cox.net/cmbrannon/blind/i686 Install the packages from my custom repository: pacman --root=/mnt -Sy speakup espeakup Alternative 2: Build the packages from source, using the PKGBUILDs available from unsupported. For convenience, the URLs are: http://aur.archlinux.org/download/speakup/speakup.tar.gz http://aur.archlinux.org/download/espeakup/espeakup.tar.gz If I were going to choose this option, I would probably chroot into the newly installed ArchLinux system in order to build the packages. 4. Customize /mnt/etc/rc.conf: Add speakup and speakup_soft to the MODULES array. Add alsa and espeakup to the DAEMONS array. We also need to save the state of the sound card, so that it will be retrieved on reboot. Execute the command "alsactl store" and copy the file /etc/asound.state to /mnt/etc/asound.state. When you boot the system from the hard disk, it should start speaking. -- Chris Disclaimers: I am in no way associated with ArchLinux. This CD image is not an official release. It is provided solely for the convenience of myself and other blind / visually impaired users. It comes with absolutely no warranty. Download and use at your own risk. -- Chris

5 5

[arch-general] Kernel PKGBUILD proposition: Ease custom kernel compilation.
by Nicolas Bigaouette 09 Dec '08

09 Dec '08

Hi all! Since a couple of years of using Arch, I often wanted to compile a custom kernel, as many others did. There is many, many, many! forum threads about that, a couple of wiki pages too, with questions and howtos. Many efforts has been put to create new PKGBUILDs[1-2] to ease the effort of this. Unfortunately, these PKGBUILDs suffer from some drawback: 1) They are placed on a wiki which can be edited by everybody. This mean it is not a trusted place to store a PKGBUILD, specifically one as vital as the kernel's. 2) They tend to be forgotten and not updated anymore. This can lead to an unbootable kernel, rendering all this useless. 3) They do not take advantage of the devs' work: They are the best one to trust for a quality PKGBUILD. They also have all the feedback from Arch users, bug reports, etc. They know what has changed in the kernel and what needs to be adapted for the installation, for example new "provides=()". A PKGBUILD from a wiki page or a forum post might be good at the time of post, but be outdated just days latter... 4) They build a kernel which is way different then the stock one, for example because they don't have the same patchset. Users most often wants to build a custom kernel just to try it, change some configurations, add one or two patch, optimize for their own machines, etc. Maily, they just want to take the existing one, change a couple of things, and be ready. One also wants to install this kernel side by side with the stock one, at least until his own kernel is stabilized and running as wanted. Actually, Arch's stock kernel does not allow that. What I propose is some simple modifications to the PKGBUILD so users can try to compile their own kernel based on the original, trusted, working and approved one. With theese modifications, one only needs to add a "kernel name" to the pkgname: "pkgname=kernel26-mykernel" for example. Nothing else is needed to compile a custom kernel. The created package would sit without problem side by side with the stock kernel. Also, if the pkgname is kept to "kernel26", then the stock -ARCH kernel will be built. This approach has many advatanges: 1) The patch is relativelly small: not much is changed in the original PKGBUILD. 1) Nothing changes for the devs. They continue to provide a quality kernel to Arch users. 2) Users who wants to compile a custom kernel can just sync abs, change the pkgname and install a new kernel, in the KISS philosophy. They know that if they just change the name, they will have the same package so they can easily test whatever feature/patch/bug solution/optimization they want. 3) Because one only needs to change the pkgname, they use the devs' high quality, tried and truth PKGBUILD. When a new kernel is out, they can sync the devs' modifications easily. 4) Bugs affecting the kernel can be easily tested for solutions. Affected users just need to compile a "-testing" kernel where a patch is applied, install it and see if it works, without having to risk breaking his system by replacing -ARCH kernel with an unbootable one. 5) Better feedback to the devs since the users would be using (almost) the same PKGBUILD as the original one. 6) Simplify a lot all these "custom kernels" threads and wiki posts. I did "maintained" such a patch for myself because I wanted to keep in sync with the original PKGBUILD. After posting it on the forum[3], I got some positive feedback. People reporting back said they liked the simplicity and the effectiveness of the method. They also positively tested it with different configuration. The patch should be applied to revision 19747 for i686 or 19749 for x86_64. It modifies the PKGBUILD and also slightly the kernel26.install and kernel26.preset file. I am thus reporting this to be include in the official file. I think it would be a great addition to an already great distro. I am open to discussion on the subject. I hope I am posting this on the right mailing list and that it can be included! :) Sincerely, big_gie [1] http://wiki.archlinux.org/index.php/Kernel_Compilation_with_ABS [2] http://wiki.archlinux.org/index.php/Custom_Kernel_Compilation_with_ABS [3] http://bbs.archlinux.org/viewtopic.php?id=37579

6 7

[arch-general] foo & bar
by Grigorios Bouzakis 09 Dec '08

09 Dec '08

http://ftp.ntua.gr/pub/linux/archlinux/extra/os/

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-general December 2008