Re: [arch-general] Shouldn't pacman restart dovecot after update?
On 08/02/2010 11:59 PM, Nicolas D wrote: On Tuesday 03 August 2010 06:52:45 J. W. Birdsong wrote: Great point; but we could at least mention **Restart Dovecot with #/etc/rc.d/dovecot restart** (or some such msg) in the dovecot.install file.Because we know EVERYONE reads the pacman msg(s) after an install. Regardless I think that is the solution best hoped for. David perhaps a bug/feature request asking for same?? Why should a message be printed ? If you've installed dovecot, and you see a dovecot update, you should know you have to restart this service after the upgrade. Well sometimes the stupid ones among us don't always catch that dovecot is being updated when it is one of 73+ updates that take place. But we 'do' always catch the failure to copy to sent -- later :p Seriously, one KISS thing that really works for Arch is having the little 1-line notes that are printed during update like: snip ( 6/73) upgrading perl [] 100% - The directories /usr/lib/perl5/current, /usr/lib/perl5/site_perl/current, /usr/lib/perl5/site_perl/5.10.1, and /usr/share/perl5/site_perl/5.10.1 will be removed from @INC in a future release. - The directory /usr/bin/perlbin/site will not be added to $PATH in a future release. ( 7/73) upgrading enlightenment [] 100% snip (69/73) upgrading system-tools-backends [] 100% == Daemon method deprecated. Now is starting automatically at login == Remove stbd from DAEMONS list snip Having a little ** don't forget to restart dovecot would be nice to have. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Unificate login credentials in Arch's website
On Mon, 2 Aug 2010 23:46:41 -0300, Martín Cigorraga martosurf7...@gmail.com wrote: I don't know if this was addressed before, I'm sorry to say this and you'll probably hate me but it's something that get my attention: the authentication in Arch's website is, at least, very unefficient. At worst, it's directly against Arch's Way, I think (I'm not the best guy to say this, just giving my first steps in Arch). Why should someone need to register at least three times, one for the forums, one for the wiki and one for the AUR? Shoudn't be sufficient with just one-time login/registration? And what about editing own nick or password? You know, at any time you may want to uniform all your passwords to a master one or just change it from the default you get when registered. I would like to know if there's any specific reason to have three separate accounts for the same website sections. Regards, Martín In fact I already wrote a Plugin for MediaWiki to authenticate at the forums. I am using this at archlinux.de (yes, pretty simple and there is no ldap or whatever) So, enabling this at archlinux.org would just involve a small config change. However: the migration is most likely unsolvable. People might have registered different accounts on wiki or forums; or different people have registered the same account the first on the wiki the other one on the forums etc. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] Interesting tidbit from other distros latest releases - kde3 is still there and maintained.
On 3 August 2010 07:50, David C. Rankin drankina...@suddenlinkmail.com wrote: Guys, This is just a point of interest more than anything else. Many of you know I came to Arch from suse and one of the reasons was suse announced plan to eliminate kde3 in its 11.2 release in early 2009. Arch had chakra and it worked great so Arch was a great logical choice. It seems that some desktops can't be replaced or removed that easily. Going against a solid year of policy to the contrary, suse's 7/15/10 new release (11.3) included a kde3 repository that will be available and maintained at least until 11.3 EOL. (usually 18 months) The only discussion on the suse list was the fact that the cost of offering kde3 is basically zero and other than a few updated libs (poppler-qt3, libpng, libjpeg), etc.., kde3 is static requiring nothing more than a few hundred meg of storage at this point. More resources are spent building and offering LXDE, openbox, etc. than kde3 required so it made sense to continue the desktop as an offering. What's that got to do with Arch? If Novell has come to the conclusion that it makes business sense to continue kde3 for the time being, then it may at least be something the Arch devs want to talk about and at least try to figure out the why? part of Novell's continuation of kde3 in case there is anything that Arch wants to do to maintain its offerings comparable with distro X, Y or Z. I have no information there. Currently kdemod3 is still in really good shape for Arch, but with the loss of Jan, I don't know what that means for the continuation of its hosting on the charkra servers. That might at least be worth knowing. None of this needs any type of reply, but with kde4 still in a massive state of flux (i.e. you can't even get to your kabc categories at present), at least having Arch know what it's thoughts or wishes are in this area before be faced with any changes, may just help the distro be ready for what ever comes along. Food for thought for the powers that be -- all others, just hit 'del'. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com You may want to take a look at the Trinity project [1] (unfortunately the website is down now) if you didn't already. It's a maintained fork of KDE 3. [1] http://trinity.pearsoncomputing.net/
[arch-general] [signoff] kernel26 2.6.34.2-1
Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Image my installed Arch into a USB pendrive
2010/8/3 Martín Cigorraga martosurf7...@gmail.com
Hi,
is possible to image my current Arch system into a USB pendrive and use it
from there?
Many thanks!
Martín
It is possible you will have to reformat your pendrive to use filesystem
other than fat, using the journaling filesystems will wearout the pen
drive fast so ext2 or pisssibly ?nilfs2? are the ones to go whit.
Also you shouldn't use any swap in usb sticks as it will also wear it out
, I assume that you alredy know that ubs sticks are much slower than hds.
But here is what have to do:
1. sudo mkfs -t ext2_or_some_other_fs /dev/sdx1
2. sudo mount /dev/sdx1 /mnt
3. sudo cp -a /{bin,boot.etc.home,lib,media,opt,root,sbin,srv,usr,var} /mnt/
4. edit the /mnt/etc/fstab and /mnt/grub/menu.lst to use the new root
partion /dev/sdx1
you SHOULD use uuids instead of the devise names
5. sudo grub-install /dev/sdx
6. sudo mkdir /mnt/{dev,sys,proc}
7. sudo mknod -m600 /mnt/dev/console c 5 1
sudo mknod -m644 /mnt/dev/null c 1 3
sudo mknod -m644 /mnt/dev/zero c 1 5
and now you should be redy to boot off
Re: [arch-general] Image my installed Arch into a USB pendrive
On Tue, 3 Aug 2010 10:43:03 +0300
jesse jaara jesse.ja...@gmail.com wrote:
2010/8/3 Martín Cigorraga martosurf7...@gmail.com
Hi,
is possible to image my current Arch system into a USB pendrive and
use it from there?
Many thanks!
Martín
It is possible you will have to reformat your pendrive to use
filesystem other than fat, using the journaling filesystems will
wearout the pen drive fast so ext2 or pisssibly ?nilfs2? are the ones
to go whit. Also you shouldn't use any swap in usb sticks as it will
also wear it out , I assume that you alredy know that ubs sticks are
much slower than hds. But here is what have to do:
1. sudo mkfs -t ext2_or_some_other_fs /dev/sdx1
2. sudo mount /dev/sdx1 /mnt
3. sudo cp
-a /{bin,boot.etc.home,lib,media,opt,root,sbin,srv,usr,var} /mnt/ 4.
edit the /mnt/etc/fstab and /mnt/grub/menu.lst to use the new root
partion /dev/sdx1 you SHOULD use uuids instead of the devise names
5. sudo grub-install /dev/sdx
6. sudo mkdir /mnt/{dev,sys,proc}
7. sudo mknod -m600 /mnt/dev/console c 5 1
sudo mknod -m644 /mnt/dev/null c 1 3
sudo mknod -m644 /mnt/dev/zero c 1 5
and now you should be redy to boot off
check out http://larch.berlios.de/, I think that tool is written for
just this use case.
Dieter
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Tue, 03 Aug 2010 01:00:09 -0500 David C. Rankin drankina...@suddenlinkmail.com wrote: Well sometimes the stupid ones among us don't always catch that dovecot is being updated when it is one of 73+ updates that take place. But we 'do' always catch the failure to copy to sent -- later :p Seriously, one KISS thing that really works for Arch is having the little 1-line notes that are printed during update like: No useless little 1-line notes only ment for braindead users.. i only want to see what i need to see. Dieter
Re: [arch-general] Image my installed Arch into a USB pendrive
check out http://larch.berlios.de/, I think that tool is written for just this use case. Dieter Doesent larch just create a new arch linux install, if i understood Martín he wants to move his whole current system to usb.
Re: [arch-general] Unificate login credentials in Arch's website
On Tue, Aug 3, 2010 at 08:30, Pierre Schmitz pie...@archlinux.de wrote: On Mon, 2 Aug 2010 23:46:41 -0300, Martín Cigorraga martosurf7...@gmail.com wrote: I don't know if this was addressed before, I'm sorry to say this and you'll probably hate me but it's something that get my attention: the authentication in Arch's website is, at least, very unefficient. At worst, it's directly against Arch's Way, I think (I'm not the best guy to say this, just giving my first steps in Arch). Why should someone need to register at least three times, one for the forums, one for the wiki and one for the AUR? Shoudn't be sufficient with just one-time login/registration? And what about editing own nick or password? You know, at any time you may want to uniform all your passwords to a master one or just change it from the default you get when registered. I would like to know if there's any specific reason to have three separate accounts for the same website sections. Regards, Martín In fact I already wrote a Plugin for MediaWiki to authenticate at the forums. I am using this at archlinux.de (yes, pretty simple and there is no ldap or whatever) So, enabling this at archlinux.org would just involve a small config change. However: the migration is most likely unsolvable. People might have registered different accounts on wiki or forums; or different people have registered the same account the first on the wiki the other one on the forums etc. One way to solve it would be to add a fourth set of credentials :-) For instance OpenID. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On 3 August 2010 09:39, Tobias Powalowski t.p...@gmx.de wrote: Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org I get following error on x86_64: (1/1) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) kernel26: /lib/modules/2.6.34-ARCH/modules.devname exists in filesystem kernel26: /lib/modules/2.6.34-ARCH/modules.softdep exists in filesystem but it may be due to the experiments with kernel26-rc I did earlier today.
Re: [arch-general] Unificate login credentials in Arch's website
2010/8/3 Magnus Therning mag...@therning.org One way to solve it would be to add a fourth set of credentials :-) For instance OpenID. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe I also think having OpenID would be create,
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
Am Dienstag 03 August 2010 schrieb Lukáš Jirkovský: On 3 August 2010 09:39, Tobias Powalowski t.p...@gmx.de wrote: Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org I get following error on x86_64: (1/1) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) kernel26: /lib/modules/2.6.34-ARCH/modules.devname exists in filesystem kernel26: /lib/modules/2.6.34-ARCH/modules.softdep exists in filesystem but it may be due to the experiments with kernel26-rc I did earlier today. pacman -Qo yourfiles to see which package owns those files. -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Tue, Aug 3, 2010 at 08:52, Dieter Plaetinck die...@plaetinck.be wrote: On Tue, 03 Aug 2010 01:00:09 -0500 David C. Rankin drankina...@suddenlinkmail.com wrote: Well sometimes the stupid ones among us don't always catch that dovecot is being updated when it is one of 73+ updates that take place. But we 'do' always catch the failure to copy to sent -- later :p Seriously, one KISS thing that really works for Arch is having the little 1-line notes that are printed during update like: No useless little 1-line notes only ment for braindead users.. i only want to see what i need to see. I doubt I'm as knowledgeable on Linux systems as you, so I'd rather like seeing a bit more messages than you need to see. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Re: [arch-general] Image my installed Arch into a USB pendrive
Am 03.08.2010 09:43, schrieb jesse jaara:
It is possible you will have to reformat your pendrive to use filesystem
other than fat, using the journaling filesystems will wearout the pen
drive fast so ext2 or pisssibly ?nilfs2? are the ones to go whit.
Also you shouldn't use any swap in usb sticks as it will also wear it out
, I assume that you alredy know that ubs sticks are much slower than hds.
The costs of USB drives are so low that wearing one out isn't a big
problem. Still, if you really don't want a journal, create ext4 without
a journal - ext2 is ancient and much slower than ext4.
But here is what have to do:
1. sudo mkfs -t ext2_or_some_other_fs /dev/sdx1
2. sudo mount /dev/sdx1 /mnt
3. sudo cp -a /{bin,boot.etc.home,lib,media,opt,root,sbin,srv,usr,var} /mnt/
cp -ax /* is shorter
4. edit the /mnt/etc/fstab and /mnt/grub/menu.lst to use the new root
partion /dev/sdx1
you SHOULD use uuids instead of the devise names
5. sudo grub-install /dev/sdx
These things fail a lot with grub sadly, I recommend syslinux.
6. sudo mkdir /mnt/{dev,sys,proc}
7. sudo mknod -m600 /mnt/dev/console c 5 1
sudo mknod -m644 /mnt/dev/null c 1 3
sudo mknod -m644 /mnt/dev/zero c 1 5
and now you should be redy to boot off
You want to add usb support to mkinitcpio if you actually want to boot this.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On 3 August 2010 10:24, Tobias Powalowski t.p...@gmx.de wrote: Am Dienstag 03 August 2010 schrieb Lukáš Jirkovský: On 3 August 2010 09:39, Tobias Powalowski t.p...@gmx.de wrote: Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org I get following error on x86_64: (1/1) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) kernel26: /lib/modules/2.6.34-ARCH/modules.devname exists in filesystem kernel26: /lib/modules/2.6.34-ARCH/modules.softdep exists in filesystem but it may be due to the experiments with kernel26-rc I did earlier today. pacman -Qo yourfiles to see which package owns those files. -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org It wasn't owned by anything. But since it works fine on a different computer with i686 I guess it was my fault. Sign off i686. Sign off x86_64. (except for the minor glitch when updating which was most likely my fault). Lukas
Re: [arch-general] Unificate login credentials in Arch's website
On Tue, 3 Aug 2010 11:23:49 +0300 jesse jaara jesse.ja...@gmail.com wrote: 2010/8/3 Magnus Therning mag...@therning.org One way to solve it would be to add a fourth set of credentials :-) For instance OpenID. I never understood why there is a need for openid when there are client ssl certificates. I never got why ssl client certs never took off. But maybe that's just me. Dieter
Re: [arch-general] Unificate login credentials in Arch's website
On Tue, Aug 3, 2010 at 09:35, Dieter Plaetinck die...@plaetinck.be wrote: On Tue, 3 Aug 2010 11:23:49 +0300 jesse jaara jesse.ja...@gmail.com wrote: 2010/8/3 Magnus Therning mag...@therning.org One way to solve it would be to add a fourth set of credentials :-) For instance OpenID. I never understood why there is a need for openid when there are client ssl certificates. I never got why ssl client certs never took off. But maybe that's just me. Because it's a bit of a usability pain. It works fine when the SSL cert is tied to a client *machine*, not so well when the SSL cert is tied to a *user*. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Tue, 2010-08-03 at 01:00 -0500, David C. Rankin wrote: Well sometimes the stupid ones among us don't always catch that dovecot is being updated when it is one of 73+ updates that take place. But we 'do' always catch the failure to copy to sent -- later :p Seriously, one KISS thing that really works for Arch is having the little 1-line notes that are printed during update like: The point is that people don't read, so adding an update notice is not a solution either, as people will miss that also.
Re: [arch-general] Unificate login credentials in Arch's website
On 08/03/2010 11:58 AM, Magnus Therning wrote: On Tue, Aug 3, 2010 at 09:35, Dieter Plaetinckdie...@plaetinck.be wrote: On Tue, 3 Aug 2010 11:23:49 +0300 jesse jaarajesse.ja...@gmail.com wrote: 2010/8/3 Magnus Therningmag...@therning.org One way to solve it would be to add a fourth set of credentials :-) For instance OpenID. I never understood why there is a need for openid when there are client ssl certificates. I never got why ssl client certs never took off. But maybe that's just me. Because it's a bit of a usability pain. It works fine when the SSL cert is tied to a client *machine*, not so well when the SSL cert is tied to a *user*. /M This was raised multiple times. But like the package signing none of this users _want_ to actually work on this. -- Ionuț
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Mon, 2010-08-02 at 22:39 -0600, Tavian Barnes wrote: Imagine the story with a different daemon: SSH. You ssh into your box, su, and pacman -Syu. Halfway through the upgrade, openssh gets updated, which automatically restarts the server, which SIGHUPs pacman, which is left in an inconsistent state. OpenSSH is designed to keep its connection alive during restarts. You can even stop sshd without losing connection, as long as the rc.d script is not buggy (we had a buggy script that would kill all child processes too a while ago...)
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Tuesday 03 Aug 2010 at 09:28 Magnus Therning wrote: No useless little 1-line notes only ment for braindead users.. i only want to see what i need to see. I doubt I'm as knowledgeable on Linux systems as you, so I'd rather like seeing a bit more messages than you need to see. I have to admit that the recent dovecot update caught me out too for a few minutes, until I realised that I'd had no new email for an eerie amount of time. But I don't think it's quite as simple as there shouldn't be messages like this or that it's about linux experience. In my experience, some packages are affected differently than others when they are upgraded while running. Here are three different examples in my anecdotal experience (details may be incorrect): - Dovecot: a running instance appears to totally break and need restarting. - KDE: session needs restarting to run the new desktop, but the old one will carry on running happily, possibly causing the occasional problem. Newly launched apps are the new version (can lead to further problems). - Firefox: everything seems fine to carry on fine. Restart the instance at your leisure. With a particular package, you've no idea which category this falls into. Sure, you could apply the safest approach of always restarting everything that's upgraded, but that's not always practical. IMO it would be nice to have short indicators when something is likely to severely break until restarted. I don't think that's overkill, it's just helpful. Cheers, Pete.
[arch-general] Unload module after printer startup
Hi list I've a hp 1020 printer. In order to work, the module usblp must not be loaded. So, i remove that from DAEMONS section at /etc/rc.conf When i boot Arch, that works fine. The module is not loaded, and the printer works. But when i turn off, and then turn on the printer, the usblp module is loaded, and the printer doesn't print. How can i prevent this loading ? I guess it's a udev rule, but i don't know how to configure it. Please, anybody can give a hand on this ? Thanks !
[arch-general] Arch Linux in Linux-Magazin 09/2010 (German Edition)
Hi, for those who wanted to be alerted: My short writeup on Arch Linux for Linux-Magazin (German Edition) is freely available online: http://www.linux-magazin.de/Heft-Abo/Ausgaben/2010/09/Frische-Ware Best Regards, Mathias
Re: [arch-general] Unload module after printer startup
On 08/03/2010 11:12 AM, Mario Daniel Carugno wrote: Hi list I've a hp 1020 printer. In order to work, the module usblp must not be loaded. So, i remove that from DAEMONS section at /etc/rc.conf When i boot Arch, that works fine. The module is not loaded, and the printer works. But when i turn off, and then turn on the printer, the usblp module is loaded, and the printer doesn't print. How can i prevent this loading ? I guess it's a udev rule, but i don't know how to configure it. Please, anybody can give a hand on this ? Thanks ! Check the wiki on how to blacklist the IPv6 module and try something similar for usblp, however I don't know if that will do what you want. Right now I can't remember anything else. -- Mauro Santos
Re: [arch-general] Unificate login credentials in Arch's website
On Tue, 3 Aug 2010 09:58:15 +0100 Magnus Therning mag...@therning.org wrote: On Tue, Aug 3, 2010 at 09:35, Dieter Plaetinck die...@plaetinck.be wrote: On Tue, 3 Aug 2010 11:23:49 +0300 jesse jaara jesse.ja...@gmail.com wrote: 2010/8/3 Magnus Therning mag...@therning.org One way to solve it would be to add a fourth set of credentials :-) For instance OpenID. I never understood why there is a need for openid when there are client ssl certificates. I never got why ssl client certs never took off. But maybe that's just me. Because it's a bit of a usability pain. It works fine when the SSL cert is tied to a client *machine*, not so well when the SSL cert is tied to a *user*. Still, unified logins is a problem we're having for years. and many people have 1 main pc. If browser programmers would implement a small and easily accessible account manager which uses client ssl certificates (and web server/application developers would make client ssl certificates a bit more userfriendly) then we would have a much better and cleaner unified login system then openid, as far as i can see. Dieter
Re: [arch-general] Unload module after printer startup
On Tue, Aug 03, 2010 at 12:25:48PM +0100, Mauro Santos wrote: On 08/03/2010 11:12 AM, Mario Daniel Carugno wrote: Hi list I've a hp 1020 printer. In order to work, the module usblp must not be loaded. So, i remove that from DAEMONS section at /etc/rc.conf When i boot Arch, that works fine. The module is not loaded, and the printer works. But when i turn off, and then turn on the printer, the usblp module is loaded, and the printer doesn't print. How can i prevent this loading ? I guess it's a udev rule, but i don't know how to configure it. Please, anybody can give a hand on this ? Thanks ! MODULES=(... !usblp ) --
Re: [arch-general] Arch Linux in Linux-Magazin 09/2010 (German Edition)
On Tue, Aug 3, 2010 at 1:20 PM, Mathias Huber mhu...@linux-magazin.de wrote: Hi, for those who wanted to be alerted: My short writeup on Arch Linux for Linux-Magazin (German Edition) is freely available online: http://www.linux-magazin.de/Heft-Abo/Ausgaben/2010/09/Frische-Ware Best Regards, Mathias super article! but isn't this part outdated (with xorg 1.8): Wer hätte etwa gedacht, dass die USB-Tastatur nach dem X-Start nur funktioniert, wenn vorher schon der Hal-Daemon läuft? stop the press! ;P .andre
Re: [arch-general] Unload module after printer startup
Thanks for the help I don't use backlist because in the wiki says so. In http://wiki.archlinux.org/index.php/CUPS_printer-specific_problems#LaserJet_1020 i can read: Ensure that the usblp module is not blacklisted in the MODULES array of /etc/rc.conf Just in case, I'll try it anyway. Thanks 2010/8/3 vlad v...@uni-bonn.de: On Tue, Aug 03, 2010 at 12:25:48PM +0100, Mauro Santos wrote: On 08/03/2010 11:12 AM, Mario Daniel Carugno wrote: Hi list I've a hp 1020 printer. In order to work, the module usblp must not be loaded. So, i remove that from DAEMONS section at /etc/rc.conf When i boot Arch, that works fine. The module is not loaded, and the printer works. But when i turn off, and then turn on the printer, the usblp module is loaded, and the printer doesn't print. How can i prevent this loading ? I guess it's a udev rule, but i don't know how to configure it. Please, anybody can give a hand on this ? Thanks ! MODULES=(... !usblp ) --
Re: [arch-general] Unificate login credentials in Arch's website
On Tue, 3 Aug 2010 13:32:36 +0200, Dieter Plaetinck die...@plaetinck.be wrote: Still, unified logins is a problem we're having for years. and many people have 1 main pc. If browser programmers would implement a small and easily accessible account manager which uses client ssl certificates (and web server/application developers would make client ssl certificates a bit more userfriendly) then we would have a much better and cleaner unified login system then openid, as far as i can see. The point of OpenID is that it leaves the choice of the authentication method to the user. For instance, you could use OpenID with SSL certs if you choose a provider like https://certifi.ca/. -- catwell
Re: [arch-general] Unload module after printer startup
Hello, On Tue, Aug 03, 2010 at 09:52:05AM -0300, Mario Daniel Carugno wrote: Thanks for the help I don't use backlist because in the wiki says so. In http://wiki.archlinux.org/index.php/CUPS_printer-specific_problems#LaserJet_1020 i can read: Ensure that the usblp module is not blacklisted in the MODULES array of /etc/rc.conf Just in case, I'll try it anyway. Thanks There's clearly described what you have to do. ... Ensure that the CUPS daemon is running and added to the /etc/rc.conf file: # /etc/rc.d/cups start File: /etc/rc.conf DAEMONS=(... cups crond ...) Now plug in the USB printer and turn it on. The printer will whirl, pause, then whirl once more as the firmware is uploaded. Now remove the usblp module: # rmmod usblp Note: The usblp module must be removed after the firmware is loaded to the printer, and before any printing job is submitted. As I understand it there is no way to automatize this. --
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
Am 03.08.2010 10:51, schrieb Evangelos Foutras: I get following error on x86_64: (1/1) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) kernel26: /lib/modules/2.6.34-ARCH/modules.devname exists in filesystem kernel26: /lib/modules/2.6.34-ARCH/modules.softdep exists in filesystem but it may be due to the experiments with kernel26-rc I did earlier today. I get this too (on x86_64; didn't check on i686), when trying to upgrade from 2.6.34.1-1. Also, no package owns those two files, but the rest of the /lib/modules/2.6.34-ARCH/modules.* files are owned by kernel26 2.6.34.1-1. module-init-tools got updated recently, it tends to create new files on 'depmod' that we don't track yet. This is unfortunate, it means some users need to -Sf a kernel update every now and then. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Arch Linux in Linux-Magazin 09/2010 (German Edition)
Hi Andre, but isn't this part outdated (with xorg 1.8): Wer hätte etwa gedacht, dass die USB-Tastatur nach dem X-Start nur funktioniert, wenn vorher schon der Hal-Daemon läuft? you're right. That was when I installed Arch with X.org 1.7.6 while I was researching the article. But it is an example of dependencies and the like that you have to be aware of with Arch. Best, Mathias
Re: [arch-general] Unload module after printer startup
Yes, that's all i do to configure the printer. Now I want to automatize the removal of the module after i turn on the printer. If there's a rule that loads the module when the printer is turned on, I guess there must be a way to catch that rule to disable the module loading. 2010/8/3 vlad v...@uni-bonn.de: Hello, On Tue, Aug 03, 2010 at 09:52:05AM -0300, Mario Daniel Carugno wrote: Thanks for the help I don't use backlist because in the wiki says so. In http://wiki.archlinux.org/index.php/CUPS_printer-specific_problems#LaserJet_1020 i can read: Ensure that the usblp module is not blacklisted in the MODULES array of /etc/rc.conf Just in case, I'll try it anyway. Thanks There's clearly described what you have to do. ... Ensure that the CUPS daemon is running and added to the /etc/rc.conf file: # /etc/rc.d/cups start File: /etc/rc.conf DAEMONS=(... cups crond ...) Now plug in the USB printer and turn it on. The printer will whirl, pause, then whirl once more as the firmware is uploaded. Now remove the usblp module: # rmmod usblp Note: The usblp module must be removed after the firmware is loaded to the printer, and before any printing job is submitted. As I understand it there is no way to automatize this. --
Re: [arch-general] Unload module after printer startup
On 03.08.2010 15:47, Mario Daniel Carugno wrote: Yes, that's all i do to configure the printer. Now I want to automatize the removal of the module after i turn on the printer. If there's a rule that loads the module when the printer is turned on, I guess there must be a way to catch that rule to disable the module loading. Use MODULES=(... !usblp ) in /etc/rc.conf (already mentioned by vlad). This prevents the module from being loaded. Wieland signature.asc Description: OpenPGP digital signature
Re: [arch-general] Unload module after printer startup
On 08/03/2010 02:47 PM, Mario Daniel Carugno wrote: Yes, that's all i do to configure the printer. Now I want to automatize the removal of the module after i turn on the printer. If there's a rule that loads the module when the printer is turned on, I guess there must be a way to catch that rule to disable the module loading. 2010/8/3 vlad v...@uni-bonn.de: Hello, On Tue, Aug 03, 2010 at 09:52:05AM -0300, Mario Daniel Carugno wrote: Thanks for the help I don't use backlist because in the wiki says so. In http://wiki.archlinux.org/index.php/CUPS_printer-specific_problems#LaserJet_1020 i can read: Ensure that the usblp module is not blacklisted in the MODULES array of /etc/rc.conf Just in case, I'll try it anyway. Thanks There's clearly described what you have to do. ... Ensure that the CUPS daemon is running and added to the /etc/rc.conf file: # /etc/rc.d/cups start File: /etc/rc.conf DAEMONS=(... cups crond ...) Now plug in the USB printer and turn it on. The printer will whirl, pause, then whirl once more as the firmware is uploaded. Now remove the usblp module: # rmmod usblp Note: The usblp module must be removed after the firmware is loaded to the printer, and before any printing job is submitted. As I understand it there is no way to automatize this. -- Ok I see your problem, you could try to do what someone suggests in the thread referenced in the wiki: You would have to guarantee the sequence load usblp/call hplj1000 script/unload usblp. IMHO to avoid race conditions, it would be better to incorporate load/unload usblp into the hplj1000 script itself: load usblp before the script looks for an lp* device, and unload usblp after the firmware has been successfully copied. If that proves to work then let the packager know about the workaround and maybe submit a patch. One last thing, try not to top post, it makes reading the thread harder. -- Mauro Santos
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On 03/08/10 09:51, Evangelos Foutras wrote: 2010/8/3 Lukáš Jirkovskýl.jirkov...@gmail.com: On 3 August 2010 09:39, Tobias Powalowskit.p...@gmx.de wrote: Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org I get following error on x86_64: (1/1) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) kernel26: /lib/modules/2.6.34-ARCH/modules.devname exists in filesystem kernel26: /lib/modules/2.6.34-ARCH/modules.softdep exists in filesystem but it may be due to the experiments with kernel26-rc I did earlier today. I get this too (on x86_64; didn't check on i686), when trying to upgrade from 2.6.34.1-1. Also, no package owns those two files, but the rest of the /lib/modules/2.6.34-ARCH/modules.* files are owned by kernel26 2.6.34.1-1. I also get this, if it's safe to pacman -Sf this, wouldn't it be a good idea to put up a news item,(as i think someone suggested earlier) to stop the forum getting flodded with posts and also to let people know (it is the kernel after all). Just a thought.
Re: [arch-general] Unload module after printer startup
On Tue, Aug 03, 2010 at 07:12:40AM -0300, Mario Daniel Carugno wrote: I've a hp 1020 printer. In order to work, the module usblp must not be loaded. So, i remove that from DAEMONS section at /etc/rc.conf When i boot Arch, that works fine. The module is not loaded, and the printer works. But when i turn off, and then turn on the printer, the usblp module is loaded, and the printer doesn't print. How can i prevent this loading ? I guess it's a udev rule, but i don't know how to configure it. Please, anybody can give a hand on this ? I can't give you the details but it shoul be possible. You'll have to do some reading on writing udev rules, there are resources on the web about that. AFAIK you can run arbitrary scripts from udev. Find the udev rule that loads the modules when the printer is switched on, and modify it so it calls a script (probably in the background) that loads the module (modprobe), waits for some seconds (sleep) and the removes the module (rmmod). Ciao, -- FA There are three of them, and Alleline.
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On 3 August 2010 03:04, Jan de Groot j...@jgc.homeip.net wrote: On Mon, 2010-08-02 at 22:39 -0600, Tavian Barnes wrote: Imagine the story with a different daemon: SSH. You ssh into your box, su, and pacman -Syu. Halfway through the upgrade, openssh gets updated, which automatically restarts the server, which SIGHUPs pacman, which is left in an inconsistent state. OpenSSH is designed to keep its connection alive during restarts. You can even stop sshd without losing connection, as long as the rc.d script is not buggy (we had a buggy script that would kill all child processes too a while ago...) Huh, I did not know that, cool. Still, the example works if you replace ssh with some hypothetical service that doesn't gracefully handle restarts. Or the worse case where the restart fails and you only notice 4 days later. -- Tavian Barnes
Re: [arch-general] Arch Linux in Linux-Magazin 09/2010 (German Edition)
Am 03.08.2010 13:20, schrieb Mathias Huber: Hi, for those who wanted to be alerted: My short writeup on Arch Linux for Linux-Magazin (German Edition) is freely available online: http://www.linux-magazin.de/Heft-Abo/Ausgaben/2010/09/Frische-Ware Best Regards, Mathias Hello, thank you for your article and your link. Die Arch-Community ernennt TUs nach öffentlicher Diskussion auf der Mailingliste. That is not quite correct. New TUs are elected by the other TUs, not by the community. But yes, the discussion is open to all. Regards Stefan, TU
Re: [arch-general] Arch Linux in Linux-Magazin 09/2010 (German Edition)
Hello Stefan, That is not quite correct. New TUs are elected by the other TUs, not by the community. But yes, the discussion is open to all. oh, that is indeed a difference. I'll print an erratum in the next issue. Best, Mathias
Re: [arch-general] Image my installed Arch into a USB pendrive
2010/8/3 jesse jaara jesse.ja...@gmail.com: check out http://larch.berlios.de/, I think that tool is written for just this use case. Dieter Doesent larch just create a new arch linux install, if i understood Martín he wants to move his whole current system to usb. It depends what he wants. larch puts the system into squashfs + aufs, creating a 'live' system (it can also do this from an existing installation). This is compact and runs pretty quickly from USB stick, but making changes persistent is not as straightforward as with a 'normal' installation. If that's what he wants, fine, but it sounded like he might rather be looking for a plug-in 'normal' installation, in which case the other suggestions would be more relevant.
[arch-general] Fwd: *** Dark Ones August Party ***
Let me know if any of you are already getting this, and I'll take you off the forward. ~celti -- Forwarded message -- From: Marg Grady marg1...@gmail.com Date: Tue, Aug 3, 2010 at 08:55 Subject: *** Dark Ones August Party *** To: J.L. Ali wolfg...@cox.net THE DARK ONES PRESENT: AUGUST PARTY – “ARABIAN NIGHTS” Join the Dark Ones for our August Party extravaganza... Escape to where East meets West... Where fantasy comes alive... and where you can enjoy the poolside cool on another hot August night... Caravans cross the desert, majestic camels transport Sultans and Rogues alike, all converge on the oasis of Shadowhaven ... What draws them all here, this night of nights? Is it the promise of fine food and drink? Or the manipulations of evil Djinn from the depths of Hell? Only one way to find out... hop on your magic carpet, camel or caravan and come to the Dark Ones Arabian Nights Party. Also, The DarkCon Promotions Caravan will be there -- don't miss out on the special membership rates at the Bazaar in the DarkCon Pavilion! A limited number of VIP Memberships are now available for sale (deposits accepted) while they last... Site: Oasis Shadowhaven -- 8726 N 48th Ave, Glendale, AZ 85302 Date: Saturday, 08/28/10 Site opens: 7 pm Party Starts: 8 pm Anthem: Midnight Bar Closes: 2 am Site Closes: 3 am Costume Theme Ideas: Harem Dancer, Snake Charmer, Sultan/Sheik, Djinn/Devil from Hell, Medieval Garb. **NEW** -- Donations for the party can now be made ONLINE! Go to http://www.darkones.org/Resources/MARKETPLACE/tabid/96/Default.aspx -- CHOOSE “August Party – Arabian Nights Event” Each registration is a $12 donation to the event. Buy as many as you want :) (There is no cost to attend the party, but your donations make it all possible.) There will be NO Kids Keep, so children should be sent elsewhere or risk being sold into slavery. Please do nothing to attract the local watch, as no one wants to be caned. We will of course need help with Set Up / Break Down and money to pay for the planned debauchery... please contact Ozzy to offer donations of Time or Money at wolfg...@cox.net Thank you, and see you at the Party, with bells on! :)
Re: [arch-general] *** Dark Ones August Party ***
Oh, hell. I totally clicked on the wrong contact. Please ignore this, people, and I'm sorry for the noise. ~celti
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 06:39 Tavian Barnes wrote:
Because of KISS? Pacman is a package manager, not a system administration
tool.
This has nothing to do with package manager or not because dpkg or rpm can do
this without a problem.
Imagine the story with a different daemon: SSH. You ssh into your
box, su, and pacman -Syu. Halfway through the upgrade, openssh gets
updated, which automatically restarts the server, which SIGHUPs
pacman, which is left in an inconsistent state.
I have never had problems with a ssh session if i update ssh on my opensuse
server and the specfile has this inside:
%postun
%restart_on_update sshd
%{insserv_cleanup}
It is okay if you say KISS is the goal but inside of a *.install file you could
do the same as in a specfile of a rpm package and no one would call rpm a
system administration tool.-)
And before one of the arch devs could misunderstood my lines: I can live
perfectly that we the users do this by ourselves instead that the packaging
comsumes more and more time.
See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 08:00 David C. Rankin wrote:
Well sometimes the stupid ones among us don't always catch that
dovecot is
being updated when it is one of 73+ updates that take place. But we 'do'
always
catch the failure to copy to sent -- later :p
If the count of updates is your problem than this idea could be something for
you:
# cat /etc/cron.daily/pacman.updates
#!/bin/sh
{
/usr/bin/pacman -Sy
echo
/usr/bin/pacman -Sup
} | /usr/bin/mail -s $(hostname -s): Arch Updates YourUser
No question, this is more simple than perfect. -)
See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 11:14 Peter Lewis wrote: I have to admit that the recent dovecot update caught me out too for a few minutes, until I realised that I'd had no new email for an eerie amount of time. This is not nice no question but how will you solve changes in the config file which be not backward compatible? In such a case it would be better to stop instead of restart the daemon. I think nothing would be better than to look what for updates be there and to stop a daemon manual or in the case of KDE step to runlevel 3 before the update. But this be nothing more than my 2c. See you, Attila
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On 03-08-2010 16:14, Simon Stoakley wrote: On 03/08/10 09:51, Evangelos Foutras wrote: 2010/8/3 Lukáš Jirkovskýl.jirkov...@gmail.com: On 3 August 2010 09:39, Tobias Powalowskit.p...@gmx.de wrote: Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. greetings tpowa -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org I get following error on x86_64: (1/1) checking for file conflicts [] 100% error: failed to commit transaction (conflicting files) kernel26: /lib/modules/2.6.34-ARCH/modules.devname exists in filesystem kernel26: /lib/modules/2.6.34-ARCH/modules.softdep exists in filesystem but it may be due to the experiments with kernel26-rc I did earlier today. I get this too (on x86_64; didn't check on i686), when trying to upgrade from 2.6.34.1-1. Also, no package owns those two files, but the rest of the /lib/modules/2.6.34-ARCH/modules.* files are owned by kernel26 2.6.34.1-1. I also get this, if it's safe to pacman -Sf this, wouldn't it be a good idea to put up a news item,(as i think someone suggested earlier) to stop the forum getting flodded with posts and also to let people know (it is the kernel after all). Just a thought. I'd indeed appreciate if a news item was generated with a little more detailed explanation of how to handle with the error. Because so far I don't understand from both this and arch-dev-public's thread on the same matter.
Re: [arch-general] Shouldn't pacman restart dovecot after update?
Okay, i recognized that i wrote too much under this little thread so set it on read if this is too much for you.-) The best compromise what i have seen is what zypper (package management tool for opensuse) do in a case if libs or a daemon get changed. After upgrading in such a case you get a warning that some apps point to deleted files and that with a zypper ps you can get the list of them. The list itselfs looks like this (from my memory): PID | user | file | libs 101 | user1 | app1 | PATH/lib21.so.21 ||| PATH/lib22.so.22 99 | daemon | daemon | PATH/lib11.so.11 ||| PATH/lib11.so.11 201 | root | app2 | PATH/lib31.so.31 ||| PATH/lib31.so.31 So the nice thing is that you even know if a logout or a restart of a daemon or a reboot solves it. And the best is that you get the information not as the output of the 73'st package from 125 packages, you get it at the end where the attention could (or should be) the best. I don't know if the rpm database helps here more than the one from pacman or how this is realised. But at the end the most important point (which is even valid): The question is even how much is the effort to realize such a luxury solution and is it this worth. That is why i never wrote a feature request instead i think this idea is very nice.-) See you, Attila
Re: [arch-general] Shouldn't pacman restart dovecot after update?
Am Tue, 03 Aug 2010 21:40:20 +0200 schrieb Attila vodoo0...@sonnenkinder.org: Okay, i recognized that i wrote too much under this little thread so set it on read if this is too much for you.-) ... I must admit, that I didn't read this completely. It's so simple and every Linux user should or must know this. If a daemon or any other software is updated it must be restarted either to use the new version or to get it working if the running version broken by the update. And the config files need to be checked and customized after every update. That's a common and necessary task of a Linux admin which doesn't need and in my opinion shouldn't be done by the package manager, because the package manager can't decide which config files I need or want to adjust and when I can and want to restart which daemon. Restarting daemons automatically by the package manager can break a lot and can do a lot more harm. And there are definitely no messages from the package manager needed. Just KISS and just a common and usual work of an admin. It just belongs to the basic knowledge. If a production server is updated then the users have to be informed before the update. Heiko
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On Tue, Aug 03, 2010 at 10:35:02PM +0200, Heiko Baums wrote: It's so simple and every Linux user should or must know this. If a daemon or any other software is updated it must be restarted either to use the new version or to get it working if the running version broken by the update. And the config files need to be checked and customized after every update. That's a common and necessary task of a Linux admin which doesn't need and in my opinion shouldn't be done by the package manager, because the package manager can't decide which config files I need or want to adjust and when I can and want to restart which daemon. Restarting daemons automatically by the package manager can break a lot and can do a lot more harm. I agree, And there are definitely no messages from the package manager needed. Well, that depends. If a user is upgrading a package X explicitly then he/she is probably anticipating the consequences, and has prepared for them. If X is updated as a side effect that could be different, and a warning would be good thing. Just KISS and just a common and usual work of an admin. It just belongs to the basic knowledge. Again agreed. But some changes are quite invasive. Going from Xorg 1.7 to 1.8 without being prepared for it can hit you where it hurts. It happened to me just a few days ago (all is OK now). Ciao, -- FA There are three of them, and Alleline.
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On 03-08-2010 21:35, Heiko Baums wrote: Am Tue, 03 Aug 2010 21:40:20 +0200 schrieb Attilavodoo0...@sonnenkinder.org: It's so simple and every Linux user should or must know this. If a daemon or any other software is updated it must be restarted either to use the new version or to get it working if the running version broken by the update. And the config files need to be checked and customized after every update. That's a common and necessary task of a Linux admin which doesn't need and in my opinion shouldn't be done by the package manager, because the package manager can't decide which config files I need or want to adjust and when I can and want to restart which daemon. Restarting daemons automatically by the package manager can break a lot and can do a lot more harm. An argument can be made that this approach makes a rolling release less attractive to users who have invested heavily in the supported repositories. I heard this much just recently from a former Arch user; The possibility of an an unpdate resulting in a post-update maintenance nightmare to get the machine up and running again can be a little scary. But I do agree with you. I just don't think that waving the KISS principle as a weapon achieves much. It's a tool. And it has its disadvantages. Users must be aware of them. If a user keeps the machine updated regularly and follows a tight upgrade schedule, they will have to deal with only minor incidents once and a while. And all easy to handle. Stop daemon, start daemon. On the other hand, if a user decides to update their machine once every two months, they must understand that it is not the rolling release system that is at fault. It's them for not understanding what's the point of a rolling release.
[arch-general] package name foo vs libfoo (eg. clutter vs libclutter)
Hello, this may be a minor issue, but it's bugging me so much that i had to write it here. and please link me to any previous discussion if this was asked before, i was kinda lazy to really search and http://wiki.archlinux.org/index.php/Arch_Packaging_Standards didn't mention anything about it. is there any rule on how to name packages ? lets take clutter as an example. it's named clutter everywhere in upstream, git, tarball, docs etc. but, it only builds libraries, and names those libclutter* (and really is only usable as library) so why are these (or only this?) packages named foo and not libfoo ? cheers .andre ps. im here to fix, not flame :)
Re: [arch-general] Shouldn't pacman restart dovecot after update?
Am Tue, 3 Aug 2010 22:48:48 +0200 schrieb f...@kokkinizita.net: Well, that depends. If a user is upgrading a package X explicitly then he/she is probably anticipating the consequences, and has prepared for them. If X is updated as a side effect that could be different, and a warning would be good thing. Before the system is updated by `pacman -Syu` pacman shows you every package which will be updated and asks you if you really want to update. If someone is too lazy to read this list it's his own problem. And I doubt that someone who is too lazy to read pacman's package list will read the post install messages. Nevertheless such messages are not necessary because it's just basic knowledge and every Linux admin must know that daemons have to be restarted after updating. It's even better to stop the daemon before it's upgraded. Again agreed. But some changes are quite invasive. Going from Xorg 1.7 to 1.8 without being prepared for it can hit you where it hurts. It happened to me just a few days ago (all is OK now). I had no problem with the X upgrade. But I read the news on the homepage before I updated it. ;-) This explained everything I needed to know. Well, of course, every update can break something, but usually it's not a big issue. I'm using Linux since several years now, even if I'm still not omniscient, first SuSE, then Gentoo, now Arch Linux, and I never had any serious breakages. I even didn't made any backups of my old kernels before a kernel update. And I never had a problem with a kernel update. Well, I once had one serious issue but that was totally my fault, but I knew that this could happen before I did what I did. So not an issue at all. Heiko
Re: [arch-general] package name foo vs libfoo (eg. clutter vs libclutter)
On 03.08.2010 23:21, Andre Osku Schmidt wrote: Hello, this may be a minor issue, but it's bugging me so much that i had to write it here. and please link me to any previous discussion if this was asked before, i was kinda lazy to really search and http://wiki.archlinux.org/index.php/Arch_Packaging_Standards didn't mention anything about it. is there any rule on how to name packages ? lets take clutter as an example. it's named clutter everywhere in upstream, git, tarball, docs etc. but, it only builds libraries, and names those libclutter* (and really is only usable as library) so why are these (or only this?) packages named foo and not libfoo ? cheers .andre ps. im here to fix, not flame :) Arch, unlike other distros, names packages after what upstream names their software. Thus, clutter is named clutter because upstream calls it that. libinfinity is named libinfinity because upstream calls it that. Prepending lib to everything also seems silly to me. Some lib packages might not purely be libs. For instance, one of my packages, ogre, is mainly a lib for 3D development but it has a lot of stuff (media, docs, samples, tutorials) that regular libs do not. What should it be called in the lib scheme? libogre (Debian does that) or just ogre? sdkogre perhaps? If we just name it ogre, we will have no problems at all and people will easily be able to find the package they are searching by just following the name upstream gave to their stuff. This also goes hand in hand with the philosophy of living close to upstream. -- Sven-Hendrik
[arch-general] kernel26 2.6.34.2-1 ALSO hardlocks my box on boot??
Guys, I still have this problem where the changes to the kernel for kernel26 2.6.34 cause my box to hardlock on boot! It happens every time after the kernel has booted once after the initial build of the initramfs with mkinitcpio. It is frustrating has hell. I opened bug 20200 which was closed yesterday for some reason and this bug is NOT fixed. I am continuing to run on the LTS kernel which works fine, but whatever changes were made to the kernel between LTS and 2.6.34 introduced a bug that causes the boot process to hardlock my box at the message: Configuring console for UTF-8 mode I suspect the lockup actually occurs at the line or two before where it loads modules, but I haven't a clue how to determine exactly what is causing this? This is serious stuff, if it is causing my Toshiba laptop to hardlock on boot, it is going to catch others and ... having your box hardlock on boot is somewhat difficult to overlook. If it were not for the fact that I also loaded the LTS kernel and have an alternative to boot into, Arch Linux would not run on my laptop at all. What do we need to do to get this fixed?? I have sent Andreas a message to reopen the bug for the reason The bug continues to hardlock my box on boot, but failing that -- what else do I need to do? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] kernel26 2.6.34.2-1 ALSO hardlocks my box on boot??
On Tue, Aug 3, 2010 at 6:09 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: what else do I need to do? out of curiousity have you tried building your own kernel and bisecting it? or mailing the lkml? -- Caleb Cushing http://xenoterracide.com
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On Tue, Aug 3, 2010 at 9:24 PM, Dan McGee dpmc...@gmail.com wrote: On Tue, Aug 3, 2010 at 2:39 AM, Tobias Powalowski t.p...@gmx.de wrote: Latest kernel is in testing, please signoff for both arches. I already have .35 prepared, a fast signoff would be great. This completely broke wireless for me on my laptop. b43 driver, i686 architecture. The wlan0 device would show up, but then you couldn't do much of anything with it. 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) Subsystem: Hewlett-Packard Company Device 365e Interesting, because the driver hasn't changed at all since the base 2.6.34 was released: dmc...@galway ~/projects/linux-2.6 (master) $ (find -name b43*) | xargs git diff v2.6.34..v2.6.34.2 | cat no output here The diff on drivers/net/wireless didn't look odd either; specific (other) drivers changed but nothing that sticks out as affecting b43. -Dan
Re: [arch-general] kernel26 2.6.34.2-1 ALSO hardlocks my box on boot??
Am Tue, 03 Aug 2010 17:09:52 -0500 schrieb David C. Rankin drankina...@suddenlinkmail.com: Guys, I still have this problem where the changes to the kernel for kernel26 2.6.34 cause my box to hardlock on boot! It happens every time after the kernel has booted once after the initial build of the initramfs with mkinitcpio. It is frustrating has hell. I opened bug 20200 which was closed yesterday for some reason and this bug is NOT fixed. Bug reopened. You didn't gave an answer for some days. Please make sure to divide it into either KMS/module loading is broken or your Compiz is fucked up. As written in the bugreport I had to manually put all needed graphics related modules into the rc.conf file. Now it boots almost every time for me. You can boot with debug command in the kernel append line to get more feedback when modules get loaded. -Andy
Re: [arch-general] [arch-dev-public] [signoff] kernel26-lts 2.6.32.17-1
Am Mon, 2 Aug 2010 21:31:09 +0200 schrieb Andreas Radke a.ra...@arcor.de: Upstream update, please signoff. http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.17 -Andy Bump. It's a security related update. -Andy
Re: [arch-general] Shouldn't pacman restart dovecot after update?
On 08/03/2010 04:14 AM, Peter Lewis wrote: With a particular package, you've no idea which category this falls into. Sure, you could apply the safest approach of always restarting everything that's upgraded, but that's not always practical. IMO it would be nice to have short indicators when something is likely to severely break until restarted. I don't think that's overkill, it's just helpful. Cheers, Pete. Dieter, I get what you are saying and I agree. I don't want to see a multitude of little 1-liners winking by every time I upgrade, but both Magnus and Pete have a point. The general body of Arch users probably need to see a bit more info than you do (no doubt I do), but Pete really puts in into context. For those apps where an upgrade is likely to render the app broken until a restart, then I think that a one-liner is called for to help all of us that aren't full time devs know what packages *must* be restarted after update so that critical apps don't remain broken until something has risen to the level of a problem. I look at this discussion is just a good thought process at how Arch can be made more robust. Here setting the Arch standard for 1-liners and limiting them to what you need to see + 1-liners for apps that will be rendered inoperative as a result of an update just makes sense. I'm sure the list of apps that would need 1-liners from breakage after update are less than 10 so it wouldn't add much chatter at all to the upgrade messages. For things like MTA's, web-servers and the like adding them would just make Arch that much better. Maybe the Arch Santa will slip a few into his bag of presents this year. I've been good -- I promise :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 22:35 Heiko Baums wrote: That's a common and necessary task of a Linux admin which doesn't need and in my opinion shouldn't be done by the package manager, because the package manager can't decide which config files I need or want to adjust and when I can and want to restart which daemon. Restarting daemons automatically by the package manager can break a lot and can do a lot more harm. Here i'm be with you but this problem with restarting daemons has more to do that we all enjoy this rolling releases under archlinux. In a case of a distribution which does this not you can do this without a problem in a lot of cases. And there are definitely no messages from the package manager needed. Before i saw this feature with the warning in zypper i would say here yes too but now i found this very useful because in the case of gui apps or the gui itself it is not even clear for me what for libs been used. I'm running opensuse on my laptop too and i'm often suprised after an update what for litte apps use what for libs. But no question, it would more say it is nice if it is there but not a thing what is absolutely necessary or that it is unacceptable that we users do this by ourselves. See you, Attila
Re: [arch-general] kernel26 2.6.34.2-1 ALSO hardlocks my box on boot??
On 08/03/2010 11:49 PM, Andreas Radke wrote: Bug reopened. You didn't gave an answer for some days. Please make sure to divide it into either KMS/module loading is broken or your Compiz is fucked up. As written in the bugreport I had to manually put all needed graphics related modules into the rc.conf file. Now it boots almost every time for me. You can boot with debug command in the kernel append line to get more feedback when modules get loaded. I apologize for not getting back sooner, but at times my real life calls and I have to push linux to the side for a week or two. I'll have a bit of time this week and next to help as much as I can. What I really need is a list of what I can get off my box to help track this down. Heck, I don't even mind configuring the router to get the smart folks in and giving an account if that would help. Since this bug occurs before logging is available, that makes it doubly-hard for me to know where to even begin with this one. I've already run tests with both configurations of KMS early/late and posted the results to the bug report, but what more I need to do is where I'm drawing a blank. I'll start with debug appended to the kernel line and post the results back at the bug report. We'll go from there. The big issue/mystery is why in the heck the box hardlocks on boot starting with the 2nd boot after initramfs is compiled. At least I know that is the issue that needs to be addressed first to find out where the bug is. I'm a great set of hands at the keyboard -- it's knowing what to type that's the problem :p Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Shouldn't pacman restart dovecot after update?
Am Wed, 04 Aug 2010 00:06:53 -0500 schrieb David C. Rankin drankina...@suddenlinkmail.com: On 08/03/2010 04:14 AM, Peter Lewis wrote: With a particular package, you've no idea which category this falls into. Sure, you could apply the safest approach of always restarting everything that's upgraded, but that's not always practical. IMO it would be nice to have short indicators when something is likely to severely break until restarted. I don't think that's overkill, it's just helpful. Cheers, Pete. Dieter, I get what you are saying and I agree. I don't want to see a multitude of little 1-liners winking by every time I upgrade, but both Magnus and Pete have a point. The general body of Arch users probably need to see a bit more info than you do (no doubt I do), but Pete really puts in into context. You seem to want to use a distribution made safe for less skilled users. Why do you keep wasting our time suggesting to make Arch something it's not meant to be??? If Arch doesn't fit you needs you shouldn't use. If package updates and restarting a daemon is hard to handle for you should really think about this. You seem to hold the record in the last months for silly questions about updating and using our distribution. If you think you need a list of packages to remember where you should interact, go on and create one your own. -Andy
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 22:59 Mario Figueiredo wrote: An argument can be made that this approach makes a rolling release less attractive to users who have invested heavily in the supported repositories. I heard this much just recently from a former Arch user; The possibility of an an unpdate resulting in a post-update maintenance nightmare to get the machine up and running again can be a little scary. I don't think that the principle of rolling releases support such mistakes more than as you use another distribution. You only move the timepoint more in the future but if such a distribution do the step from at example A to B than you have to do this nightmare search of changed config files for all packages. That's all because mistakes are even possible instead no one wants to make them. I think, and this is more my experience, that you will get a lot of more stories about updates in archlinux which runs without a problem instead the list of packages was enormous. See you, Attila
Re: [arch-general] Interesting tidbit from other distros latest releases - kde3 is still there and maintained.
On 08/03/2010 02:31 AM, Lukáš Jirkovský wrote: You may want to take a look at the Trinity project [1] (unfortunately the website is down now) if you didn't already. It's a maintained fork of KDE 3. [1]http://trinity.pearsoncomputing.net/ Thank you Lukáš, I will definitely take a look. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Shouldn't pacman restart dovecot after update?
At Dienstag, 3. August 2010 23:50 Heiko Baums wrote: I hadn't had any post-update maintenance nightmares yet. Well, not nightmares. I want to know what is done and what happens on my system. Otherwise I would recommend a different distro. But to be honest I had a lot more post-update nightmares with SuSE, because YaST has always overridden my configurations. This can't happen with Arch due to the .pacnew files. Only for the stats: In the case of updating packages Yast, and im suprised that you use this more than zypper, don't touch changed config files because opensuse, and every other rpm basesd distribution, do the same as archlinux with *.rpmsave and *.rpmnew files. As i said in the other posting, i don't think that any packager on this planet do mistakes with intent but they be even possible because we are all only humans. -) See you, Attila
Re: [arch-general] Mailman update
New version is in testing without a homedir for the mailman user. Please try to upgrade from last version in our extra repo. Tell us if I broke something. -Andy signature.asc Description: PGP signature
