[arch-general] Re: My end-user $0.02 on /etc/rc.conf splitting.
The 23/07/12, Kevin Chadwick wrote: Did you read this before posting. It's obvious that reviewing the config files and getting the source and finding the bug in C is much easier of course and can be fixed immediately by anyone without another OS or machine. Did you read this before posting. It's obvious that when a service is failing, everybody first think it's because of the init process and try to fix the bug in the /sbin/init C sources. 'silently failing', only if it's meant to. A running software does exactly what was written from all the involved sources. What next? -- Nicolas Sebrecht
[arch-general] linux 3.5-1 - No volume groups found
Hi, after upgrading to linux 3.5-1 yesterday my computer no longer boots. :( The following error is displayed: No volume groups found I have to run lvm vgchange -a y before I can continue booting. -- Herbert
Re: [arch-general] linux 3.5-1 - No volume groups found
On Tue, Jul 24, 2012 at 4:40 PM, Herbert J. Skuhra hsku...@eumx.net wrote: Hi, after upgrading to linux 3.5-1 yesterday my computer no longer boots. :( The following error is displayed: No volume groups found I have to run lvm vgchange -a y before I can continue booting. What do you get running lvm vgchange -a y ? If this still fail to load the mapper, it's not likely to boot. -- Herbert -- Preston M. Linuxer using Arch/Ubuntu, Pythoner, Geek -- Blog: http://apt-blog.net
[arch-general] Delete the package magicassistant-gtk-multi 1.2.5.2-0
Hi, Since the package I was maintening (magicassistant-gtk-multi 1.2.5.2-0) is now a doublon of (magicassistant-gtk 1.2.5.2-2), can you please merge the comment and delete it. Thanks,
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 4:38 PM, Nicolas Sebrecht nsebre...@piing.fr wrote: The 23/07/12, Kevin Chadwick wrote: Did you read this before posting. It's obvious that reviewing the config files and getting the source and finding the bug in C is much easier of course and can be fixed immediately by anyone without another OS or machine. Did you read this before posting. It's obvious that when a service is failing, everybody first think it's because of the init process and try to fix the bug in the /sbin/init C sources. Its a common fallacy some seem to hold that the only way to fix/debug/customize systemd is to edit the sources. Obviously those who believe so have no idea what .service files are.
[arch-general] Systemd with encrypted Btrfs
Hello all, After all the intense discussions about systemd I decided to try it out and see for myself. I tried it out on my desktop and was quite impressed by it - it was much faster than the earlier initscript. Further when I would background a daemon (say the network daemon) in rc.conf, I would have to wait for a while even after I logged in for the network to start, whereas in systemd I find the necessary daemons have already started by the time I login. However I ran into a couple of problems running it on my laptop: 1. I have an encrypted swap that randomly generates a new passphrase everytime I reboot, but systemd asks me for a passphrase every time I boot. On pressing enter or entering any random characters it proceeds normally. This is more of an annoyance than a real problem. 2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: fsck: fsck.btrfs: not found fsck: Error 2 while executing fsck.btrfs for /dev/mapper/myvolume and this stops the whole boot process. I have to disable that partition on fstab to get systemd to boot properly. Once the boot process is complete, I can see that the decryption has proceeded normally (from systemctl -a) and can remount it normally in a manual fashion. I initially thought that creating fsck.btrfs as a symlink to btrfsck might do the job, but that doesn't work either. Does anybody have any experience successfully mounting (encrypted or not) btrfs partitions using systemd? Thanks, Aurko
Re: [arch-general] Delete the package magicassistant-gtk-multi 1.2.5.2-0
Op dinsdag 24 juli 2012 09:52:34 schreef Tanguy ALEXIS: Hi, Since the package I was maintening (magicassistant-gtk-multi 1.2.5.2-0) is now a doublon of (magicassistant-gtk 1.2.5.2-2), can you please merge the comment and delete it. Thanks, Could you please send this requests to aur-general mailinglist in the future. Also please add the links to the packages: https://aur.archlinux.org/packages.php?ID=59032 (magicassistant-gtk) the packages are merged. Thx --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Systemd with encrypted Btrfs
On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy roy.au...@gmail.com wrote: 2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: fsck: fsck.btrfs: not found The problem seems to be that simply there is no such fsck.btrfs. It simply does not exist, yet. There is a btrfsck, but it is not yet ready for general use, IIRC. My solution for this is simply: # ln -s /bin/true /sbin/fsck.btrfs HTH -- Rodrigo
Re: [arch-general] Systemd with encrypted Btrfs
Hi, Thanks for the quick reply. I wasn't aware of the changes in crypttab syntax with systemd; but changing it the way you described it did the trick for swap. You're right, on digging deeper (logs) I found that the fsck had failed earlier as well but I never noticed it as the boot process wasn't interrupted. I didn't face it again after setting passno. to 0. I had heard about btrfs being released without a proper fsck in place but I thought that was long ago and that btrfsck was ready for general use. Rodrigo: I already solved it, but thanks for your reply anyway. -aurko On Tue, Jul 24, 2012 at 3:09 PM, Tom Gundersen t...@jklm.no wrote: On Tue, Jul 24, 2012 at 10:58 AM, Aurko Roy roy.au...@gmail.com wrote: 1. I have an encrypted swap that randomly generates a new passphrase everytime I reboot, but systemd asks me for a passphrase every time I boot. On pressing enter or entering any random characters it proceeds normally. This is more of an annoyance than a real problem. Note that systemd does not support Arch's traditional crypttab syntax, so you might need to adjust your crypttab file. The format is described in man crypttab. I have a similar setup to what you describe and my crypttab line is: # cat /etc/crypttab swap/dev/sda2 /dev/urandomswap 2. I have an encrypted btrfs partition which it unlocks normally, but while trying to mount says: fsck: fsck.btrfs: not found fsck: Error 2 while executing fsck.btrfs for /dev/mapper/myvolume and this stops the whole boot process. I have to disable that partition on fstab to get systemd to boot properly. Once the boot process is complete, I can see that the decryption has proceeded normally (from systemctl -a) and can remount it normally in a manual fashion. I initially thought that creating fsck.btrfs as a symlink to btrfsck might do the job, but that doesn't work either. There is no fsck.btrfs binary yet, and btrfsck does not support the expected interface. Until a proper fsck.btrfs exists you should mark your partition as not wanting to be fsck'ed in fstab (i.e. set passno, the last argument, to 0). Does anybody have any experience successfully mounting (encrypted or not) btrfs partitions using systemd? I would have thought you'd get a similar failure also with initscripts? Though in that case boot would not pause. -t
Re: [arch-general] Systemd with encrypted Btrfs
On Tue, Jul 24, 2012 at 12:10 PM, Aurko Roy roy.au...@gmail.com wrote: You're right, on digging deeper (logs) I found that the fsck had failed earlier as well but I never noticed it as the boot process wasn't interrupted. I didn't face it again after setting passno. to 0. I had heard about btrfs being released without a proper fsck in place but I thought that was long ago and that btrfsck was ready for general use. I have been using btrfs as my rootfs on all my machines for a couple of years and never seen a corruption that required fsck, so I don't know how well (or not) btrfsck actually works. I would assume it would not be too bad, as it is shipped by at least Oracle. The problem though is that it does not implement the correct API for integration with regular fsck, so it can only be called manually and not automatically on boot. -t
Re: [arch-general] Systemd with encrypted Btrfs
Hi, Thanks for the clarification. Also I was wondering if there was any reason why Arch doesn't have the rc-local.service in systemd by default. There was some stuff I ran in rc.local (reducing brightness, proxy authentication) but it seems there is no rc-local service in systemd. I am working on copying content from fedoras rc-local.service and trying to get it to work on my laptop. -aurko On Tue, Jul 24, 2012 at 3:46 PM, Tom Gundersen t...@jklm.no wrote: On Tue, Jul 24, 2012 at 12:10 PM, Aurko Roy roy.au...@gmail.com wrote: You're right, on digging deeper (logs) I found that the fsck had failed earlier as well but I never noticed it as the boot process wasn't interrupted. I didn't face it again after setting passno. to 0. I had heard about btrfs being released without a proper fsck in place but I thought that was long ago and that btrfsck was ready for general use. I have been using btrfs as my rootfs on all my machines for a couple of years and never seen a corruption that required fsck, so I don't know how well (or not) btrfsck actually works. I would assume it would not be too bad, as it is shipped by at least Oracle. The problem though is that it does not implement the correct API for integration with regular fsck, so it can only be called manually and not automatically on boot. -t
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, 24 Jul 2012 04:54:08 +0200, Anthony ''Ishpeck'' Tedjamulia archli...@ishpeck.net wrote: On Mon, Jul 23, 2012 at 05:57:46PM +0200, Tom Gundersen wrote: Is debian switching That remains to be seen. If Debian intends to continue support for Hurd and KfreeBSD they can't move to systemd -- which relies on Linux kernel features to work. That debian has a disincentive is not the same as Arch having a disincentive, tho'. I would rather we use DJB's daemontools as process 1 but I know exactly how these arguments tend to go. http://wiki.debian.org/systemd#Installation We talked about it on Debian mailing list, IICR Debian will switch, but I might be mistaken. - Ralf
Re: [arch-general] Systemd with encrypted Btrfs
Hi, On 24 July 2012 11:25, Aurko Roy roy.au...@gmail.com wrote: Thanks for the clarification. Also I was wondering if there was any reason why Arch doesn't have the rc-local.service in systemd by default. Have a look at the initscripts-systemd package, it contains rc-local and rc-local-shutdown service files.
Re: [arch-general] rc.local.shutdown equivalent in systemd
On Tue, Jul 24, 2012 at 4:31 AM, James Nelson jnl...@gmx.com wrote: On 07/23/12 20:10, Manolo Martínez wrote: [Unit] Description=Unload module before shutdown Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=multi-user.target Haven't tried it, might not work, no guarantees, etc.. Shouldn't it be just [Unit] Description=Unload module before shutdown [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=shutdown.target Without multi-user.target or Before=?
Re: [arch-general] Systemd with encrypted Btrfs
Hi, Yeah it works fine with the initscripts-systemd package but I had replaced that with the systemd-sysvcompat package for a pure systemd setupd. I was wondering if there is a reason why they've discontinued support for rc.local in that. AFAIK Fedora has a pure systemd setup (I may be wrong there) but still support rc.local. Perhaps I'm missing/misunderstanding something. Thanks, aurko On Tue, Jul 24, 2012 at 3:57 PM, Damien Churchill dam...@gmail.com wrote: Hi, On 24 July 2012 11:25, Aurko Roy roy.au...@gmail.com wrote: Thanks for the clarification. Also I was wondering if there was any reason why Arch doesn't have the rc-local.service in systemd by default. Have a look at the initscripts-systemd package, it contains rc-local and rc-local-shutdown service files.
Re: [arch-general] rc.local.shutdown equivalent in systemd
On Tue, Jul 24, 2012 at 12:38 PM, Rodrigo Rivas rodrigorivasco...@gmail.com wrote: On Tue, Jul 24, 2012 at 4:31 AM, James Nelson jnl...@gmx.com wrote: On 07/23/12 20:10, Manolo Martínez wrote: [Unit] Description=Unload module before shutdown Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=multi-user.target Haven't tried it, might not work, no guarantees, etc.. Shouldn't it be just [Unit] Description=Unload module before shutdown [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=shutdown.target Without multi-user.target or Before=? Better put Before= if it is important that the module is properly removed before the machine is shut down. Btw, you should probably file a bug against whatever module requires this... -t
Re: [arch-general] Systemd with encrypted Btrfs
On Tue, Jul 24, 2012 at 12:40 PM, Aurko Roy roy.au...@gmail.com wrote:
Yeah it works fine with the initscripts-systemd package but I had
replaced that with the systemd-sysvcompat package for a pure systemd
setupd. I was wondering if there is a reason why they've discontinued
support for rc.local in that. AFAIK Fedora has a pure systemd setup (I
may be wrong there) but still support rc.local. Perhaps I'm
missing/misunderstanding something.
Fedora still have quite a bit of legacy stuff (probably even more than
what we do). I'd argue that rc.local{,.shutdown} is legacy, and that
people would be better off by either writing .service files, or fixing
whatever bugs are being worked around (which is mostly the use-case)
properly.
Even if you use systemd-sysvcompat support, you are of course free to
copy the rc-local serivce files from the initscripts-systemd pacakge
and put them in /etc/systemd/system/
-t
Re: [arch-general] Systemd with encrypted Btrfs
Hi,
Thanks for your answer. In the end I decided to stick with
systemd-sysvcompat with my own rc-local.service (since I didn't need
the other stuff in the initscripts-systemd package). I must say I'm
starting to like systemd despite the minor hiccups due to changes in
conventions.
-aurko
On Tue, Jul 24, 2012 at 4:17 PM, Tom Gundersen t...@jklm.no wrote:
On Tue, Jul 24, 2012 at 12:40 PM, Aurko Roy roy.au...@gmail.com wrote:
Yeah it works fine with the initscripts-systemd package but I had
replaced that with the systemd-sysvcompat package for a pure systemd
setupd. I was wondering if there is a reason why they've discontinued
support for rc.local in that. AFAIK Fedora has a pure systemd setup (I
may be wrong there) but still support rc.local. Perhaps I'm
missing/misunderstanding something.
Fedora still have quite a bit of legacy stuff (probably even more than
what we do). I'd argue that rc.local{,.shutdown} is legacy, and that
people would be better off by either writing .service files, or fixing
whatever bugs are being worked around (which is mostly the use-case)
properly.
Even if you use systemd-sysvcompat support, you are of course free to
copy the rc-local serivce files from the initscripts-systemd pacakge
and put them in /etc/systemd/system/
-t
Re: [arch-general] python needs /usr/include/?
On Sat, Jul 21, 2012 at 01:01:45PM +0200, Christian Hesse wrote: Rodrigo Rivas rodrigorivasco...@gmail.com on Sat, 2012/07/21 00:36: On Sat, Jul 21, 2012 at 12:25 AM, Rodrigo Rivas rodrigorivasco...@gmail.com wrote: On Fri, Jul 20, 2012 at 8:32 PM, Christian Hesse l...@eworm.de wrote: Hello everybody, I am creating live media and want to reduce size. After removing /usr/include/ wicd fails to start because of a missing header file. I suggest it's a bad idea to castrate packages from files. Either way around, you will break pacman's heart. If you want to reduce size, remove packages as a whole from the media or deliver custom, slimmed down builds. Eg. python2 with only what wicd needs to run smoothly. Just my context-free 2 cents. cheers! mar77i
Re: [arch-general] rc.local.shutdown equivalent in systemd
On 07/24/12 at 12:44pm, Tom Gundersen wrote: On Tue, Jul 24, 2012 at 12:38 PM, Rodrigo Rivas rodrigorivasco...@gmail.com wrote: On Tue, Jul 24, 2012 at 4:31 AM, James Nelson jnl...@gmx.com wrote: On 07/23/12 20:10, Manolo Martínez wrote: [Unit] Description=Unload module before shutdown Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=multi-user.target Haven't tried it, might not work, no guarantees, etc.. Shouldn't it be just [Unit] Description=Unload module before shutdown [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=shutdown.target Without multi-user.target or Before=? Better put Before= if it is important that the module is properly removed before the machine is shut down. Thanks. I need to read a lot more about systemd, it seems. Btw, you should probably file a bug against whatever module requires this... There is. It's the one linked to and described in [this forum thread](https://bbs.archlinux.org/viewtopic.php?id=113985). It's been closed as solved, but yesterday I had a couple of faulty shutdowns, reminiscent of the ones I used to have before removing ehci_hcd, so I don't know. Manolo --
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Systemd is larger than init, so for embedded it may well quadruple boot time. What utter bullshit. Please, Kevin, if you are going to throw around numbers, do some measurements first. You keep picking on other subjects too at one tiny part without considering all that I have said. /sbin/init 32K actually larger than I thought considering it's job was designed so tightly bound. /bin/systemd 800K (26 times as large) I have an embedded board sitting right here that can run Linux and has 64K of SRAM by default. As I have said you are talking about Linux systems that are nearer the top smaller end of the embedded and actually my Android probably takes longer to boot than my desktop, maybe when I get time as Sony aren't providing updates as they promised I will mod cyanogen to boot a bit quicker or stop it slowing down further if systemd lands with a simple init. My real point was that the systemd speed argument was pointless and the bloated argument in violation of UNIX principles wasn't. There is nothing stopping building concurrency on top of init like Upstart which obviously has major issues. Do you have any numbers on how much time it saves you. I know Gnome takes many many times longer to load than systemd saves! -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Hi, Am 23.07.2012 17:29, schrieb Kevin Chadwick: Tested, simply sophisticated and as fast as you make it. There is no parallelization, no socket activation and no auto mounting. In no way can it be as fast as systemd. init=/bin/sh That happens a lot in embedded. Once you get to desktop level and SSDs, who cares about a few seconds. It's not only about speed, but speed is a nice bonus. Its also about reliability. But I'm not going to enumerate the advantages of systemd over and over again. Just read the blog posts by Lennart ;). That is completely debateable. I hope you look at counter arguments too. I like what systemd does in code in the main. I just think it needs a re-design to be more usable on the commandline and be more modular so pid1 is small if it cannot stay as init. The fastest booting systems ( 1 second) use init and won't use systemd. Which systems do you have in mind? Personally I can tell you out of experience that my system boots up faster with systemd. Low memory embedded devices such as an mp3 player. I would also rather desktop and embedded systems shared pid1 as a simple init like upstart does. WRT pulse audio it won't run under a grsecurity kernel so first I'd say define modern desktop. How functional, how secure. On a modern desktop you probably have bigger concerns regarding security then running grsecurity. That said it should run fine with SElinux, which Fedora is using by default. Furthermore grsecurity seems to focus on servers anyway, so I'm not sure why you even bring this up? Not really, it is used less on desktops because more code like Adobe Flash breaks without intervention. My Arch desktops run grsecurity kernels. Best regards, Karol Babioch -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Did you read this before posting. It's obvious that reviewing the config files and getting the source and finding the bug in C is much easier of course and can be fixed immediately by anyone without another OS or machine. Did you read this before posting. It's obvious that when a service is failing, everybody first think it's because of the init process and try to fix the bug in the /sbin/init C sources. It's funny how you think init which was designed to be as simple as possible is likely to have as many bugs as systemd. You can batch test a group of scripts quickly if you have to fall back to trial and error. Cross platform peer reviewed scripts would be good of course. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
For having used systemd myself, I am inclined to believe that it definitely fits the KISS principle. I welcome the coss platform GUI for controlling services, however on Arch rc.conf served very well. I found I can see /etc/inittab and man inittab and edit. With systemd I had to Google then type lots to Copy and symlink. It's also harder to see what will run without booting said hardrive and the output of systemctl makes it harder to see what services are enabled in a single glance with all the other info provided but I'm sure that can easily be fixed, though I didn't see the commandline argument required. The main thing I would like to know is Will the DAEMONS line always stay in rc.conf or will there be a single folder where we can see just the service enabling files. The KISS part I am mainly concerned about is the more complicated nature of systemd that will innevitably lead to root exploits needlessly on simple systems. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Did you read this before posting. It's obvious that reviewing the config files and getting the source and finding the bug in C is much easier of course and can be fixed immediately by anyone without another OS or machine. Did you read this before posting. It's obvious that when a service is failing, everybody first think it's because of the init process and try to fix the bug in the /sbin/init C sources. Its a common fallacy some seem to hold that the only way to fix/debug/customize systemd is to edit the sources. Obviously those who believe so have no idea what .service files are. I never said that, there is 800K of systemd to cause havoc that is harder to test because it doesn't follow UNIX principles. You would have to incorporate all code init can run in that. I like some of systemd and an init consensus but it should have been developed as many tools. Maybe systemds features were required to make this happen and a init system with standardised scripts will finally come along and fix this problem that has plagued Linux for so long. Unfortunately it just might mean many will move back to Gentoo/Slackware or another BSD like OS. One of the founding principles of UNIX is that small tools that do a single job well allow complete flexibility whereas large tools do what the devs foresee very well but will likely hinder users or other uses. That is a part of why I prefer sudo and RBAC/Selinux to polkit. Maybe systemd doesn't hinder in this way but I'm sure it reduces re-use of it's tools for other purposes and affects security that this methodology has always brought. I can't find the book referencing many highly regarded peers right now to word it perfectly but Ironically this principle has been seen to reduce UNIX use by the masses due to the potential for variation but also means it has had technologies that never die out and especially useful for the slightly skilled users. I didn't think Arch was trying to be a Redhat for the masses. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Couldn't have said it better. I'm not by any means a technical expert, but even I could see how much basis his posts had (or didn't) Those posts were simply pointing out errors/assumptions in baseless posts and you may not see my points if you haven't done any research on the foundations of UNIX and/or security. It is easy to sell functions like it's faster even when it is irrelevent. Security is only considered in General when your bank is on the phone and for a few weeks after. -- Why not do something good every day and install BOINC.
Re: [arch-general] Upcoming changes to virtualbox
On Mon, Jul 23, 2012 at 8:28 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 07/23/2012 06:11 AM, Sébastien Luttringer wrote: Come to think of this, would dkms then be a hard dep for virtualbox? dkms become an hard dep for virtualbox-source (and virtualbox-archlinux-source). You can still use virtualbox-modules. What about for those using virtualbox-bin and virtualbox-ext-oracle for AUR? As i said in comment in virtualbox-bin they are greatly encouraged to move to virtualbox as there is no real difference. I will probably drop support of virtualbox-bin soon. I attempted to build the virtualbox-ext-oracle package which pulled in as dependencies: virtualbox 4.1.18-2 virtualbox-modules 4.1.18-4 Neither were wanted. Does this new dependency requirement need to be fixed in the AUR packages so that virtualbox-ext-oracle does not automatically pull in the Arch versions? Why neither were wanted? As far i see, virtualbox is needed by virtualbox-ext-orable and virtualbox-modules is a dependency of the virtualbox. -- Sébastien Seblu Luttringer www.seblu.net
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
[2012-07-24 13:27:50 +0100] Kevin Chadwick: you may not see my points if you haven't done any research on the foundations of UNIX and/or security. How more ridiculous can you get? -- Gaetan
Re: [arch-general] Upcoming changes to virtualbox
Sébastien Luttringer se...@seblu.net on Mon, 2012/07/23 02:01:
Some changes will be introduced in the next package release of virtualbox.
This is when virtualbox 4.1.20 is released? Have not seen anything in the
testing repos yet.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
Re: [arch-general] Upcoming changes to virtualbox
On Tue, Jul 24, 2012 at 2:50 PM, Christian Hesse l...@eworm.de wrote: Sébastien Luttringer se...@seblu.net on Mon, 2012/07/23 02:01: Some changes will be introduced in the next package release of virtualbox. This is when virtualbox 4.1.20 is released? Have not seen anything in the testing repos yet. No, tonight or tomorow (CEST). -- Sébastien Seblu Luttringer www.seblu.net
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 07/24/2012 08:37 AM, Gaetan Bisson wrote: [2012-07-24 13:27:50 +0100] Kevin Chadwick: you may not see my points if you haven't done any research on the foundations of UNIX and/or security. How more ridiculous can you get? He is not being ridiculous. He is stating his opinion and that should be valuedIt is easy to dismiss someones opinion but hard or complex to analyze. His insight may keep one from doing something stupid simply because he has looked at the problem from a different light and that should be valued. His view does have merit.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 07/24/2012 09:09 AM, Tom Gundersen wrote: On Tue, Jul 24, 2012 at 1:38 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Systemd is larger than init, so for embedded it may well quadruple boot time. What utter bullshit. Please, Kevin, if you are going to throw around numbers, do some measurements first. You keep picking on other subjects too at one tiny part without considering all that I have said. You win. I usually try to answer all emails aimed in my general direction, however with the last onslaught of spam from you, I just can't find it in me any more. Anyone with the least bit of clue will by now have realised that you don't know what you are talking about. So anything I add will just be a waste of everyone's time. -t I am sorry you think any thing you have will be a waste of time. I am looking at this problem of moving to systemd, staying with current init scripts or moving in the LSB init scripts direction. In order for one to make an informed decision one needs to consider all the facts. Without your insight or wisdom how would/will I do that? Discussion is healthy
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
[2012-07-24 09:19:27 -0400] Baho Utot: He is stating his opinion and that should be valued Baseless opinions are not valuable, they are spam. His insight may keep one from doing something stupid simply because he has looked at the problem from a different light and that should be valued. I am very sorry that you were lead to think that. -- Gaetan
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 3:24 PM, Baho Utot baho-u...@columbus.rr.com wrote: I am sorry you think any thing you have will be a waste of time. I am looking at this problem of moving to systemd, staying with current init scripts or moving in the LSB init scripts direction. In order for one to make an informed decision one needs to consider all the facts. Without your insight or wisdom how would/will I do that? Discussion is healthy I'm happy to discuss and answer any questions. However, Kevin's emails were: off-topic (this thread was not on systemd, but on rc.conf), irrelevant (the kind of embedded systems he is talking about would never run Arch), plain wrong (his descriptions of how systemd works and how to use it has nothing to do with reality). To give a couple of comments, for those who have not looked at systemd yet: Firstly, systemd is bigger and does more than sysvinit. The reason for this is that it moves functionality out of the individual daemons and into init. This functionality is stuff that would otherwise have been implemented over and over again in every daemon or rc script, each time it is implemented it would be a potential for bugs. Now we have it all in one place, where we can all work together to test and review it. The kind of features implemented in this way are for the purposes of security and reliability of the daemons on your system (i.e. it will monitor them and deal with crashes, it will lock down the kinds of things a daemon is allowed to do, what directories it can read/write to, what system calls it can make, what user it is run as, etc). I would not call this bloat, quite the opposite. It means that the total amount of code on your system, and the total amount of potential for bugs drastically decreases. Secondly, most of the functionality of systemd is separated out in separate processes/tools, and are not part of PID1. In fact, we use these tools also in initscripts, and this is why I believe we will be able to maintain initscripts, even if systemd should take over for most users. Initscripts currently use the following systemd tools: systemd-module-load systemd-udevd systemd-cryptsetup systemd-tmpfiles systemd-sysctl systemd-binfmt systemd-random-seed systemd-vconsole-setup systemd-remount-fs HTH, Tom
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 23:40:51 +1000 schrieb Gaetan Bisson bis...@archlinux.org: [2012-07-24 09:19:27 -0400] Baho Utot: He is stating his opinion and that should be valued Baseless opinions are not valuable, they are spam. Actually they are not baseless even if he didn't explain every single argument in detail. But I think e.g. regarding the UNIX philosophy he is totally right. And it actually shouldn't be necessary to explain in detail as the UNIX philosophy should be very well known anyway. Yes, I don't like those Windoze like ini files of systemd, too. Everything is and should stay a file, and every tool should do only one task but this should be done well. This is, btw., also the KISS philosophy. I really regularly wonder why people become offensive if other people say their opinions and if other people's opinions doesn't match their own opinions. Well, yes, some of Kevin's e-mails have been a bit pointless. But he is not really spamming. He just says his opinion. And it doesn't seem to be unqualified. Btw., in all those discussions about systemd as well as in all those discussions about PulseAudio, I always read more or less technical arguments from people who have objections against them or have tried them and have seen that they don't really work. From the people who like systemd and/or PulseAudio I only read arguments like it's faster, it's an evolution, it's new, everybody (distribution) uses it, it has this and that feature, which actually only makes sense and works in a very few cases or can easily be achieved in other ways. But I haven't, yet, read any technical argument for them, why it is technically better, why it doesn't break the UNIX philosophy, why it is reliable enough etc. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 16:07:50 +0200 schrieb Heiko Baums li...@baums-on-web.de: Btw., in all those discussions about systemd as well as in all those discussions about PulseAudio, I always read more or less technical arguments from people who have objections against them or have tried them and have seen that they don't really work. From the people who like systemd and/or PulseAudio I only read arguments like it's faster, it's an evolution, it's new, everybody (distribution) uses it, it has this and that feature, which actually only makes sense and works in a very few cases or can easily be achieved in other ways. But I haven't, yet, read any technical argument for them, why it is technically better, why it doesn't break the UNIX philosophy, why it is reliable enough etc. Well, now I must correct myself. I just read Tom's explanation about some technical details of systemd. The first one so far, which clarifies it a bit. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
[2012-07-24 16:07:50 +0200] Heiko Baums: Yes, I don't like those Windoze like ini files of systemd, too. Everything is and should stay a file, and every tool should do only one task but this should be done well. How about having multiple files, each doing one thing and doing it well? Wait, isn't that exactly what systemd does? This is, btw., also the KISS philosophy. Any more platitudes coming? My /dev/null is feeling a bit empty. -- Gaetan
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 4:07 PM, Heiko Baums li...@baums-on-web.de wrote: But I think e.g. regarding the UNIX philosophy he is totally right. And Yes, I don't like those Windoze like ini files of systemd, too. Everything is and should stay a file, and every tool should do only one task but this should be done well. This is, btw., also the KISS philosophy. Talking about UNIX philosophy and Windoze like ini files is probably what gets some people going. It is not technical. Yeah, we might agree that UNIX is great and Windows is bad. But in a technical argument, it is just annoying to point to tradition and philosophy rather than technical facts, regardless of what side of the argument you are on. If you claim that systemd does not follow the UNIX philosophy (I disagree, but whatever), and if you claim that anything not following the UNIX philosophy is bad (I disagree, but whatever), then you should be able to combine these two claims and point to a technical flaw or shortcomming in systemd without any reference to UNIX, or Windows, or KISS at all. I really regularly wonder why people become offensive if other people say their opinions and if other people's opinions doesn't match their own opinions. Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse. I try not to be offensive, but sometimes my exasperation shows through I guess. -t
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse. Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to just work and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it. Calvin
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 4:29 PM, Calvin Morrison mutanttur...@gmail.com wrote: Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to just work and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it. I didn't mean to imply that everyone should learn about systemd. My comment was aimed at those who make claims about its benefits or drawbacks. -t
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Op dinsdag 24 juli 2012 10:29:25 schreef Calvin Morrison: Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse. Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to just work and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it. Calvin my 2cents on your usecase: Arch Linux is always the newest and latest and ... so maybe your use-case does not fit this distributions profile if you really want everything to stay the same forever there are distributions out there which fit your needs exactly, but in my idea Arch is not it. --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 24 July 2012 10:43, Ike Devolder ike.devol...@gmail.com wrote: Op dinsdag 24 juli 2012 10:29:25 schreef Calvin Morrison: Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse. Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to just work and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it. Calvin my 2cents on your usecase: Arch Linux is always the newest and latest and ... so maybe your use-case does not fit this distributions profile if you really want everything to stay the same forever there are distributions out there which fit your needs exactly, but in my idea Arch is not it. --Ike To summarize: Arch Linux is a versatile, and simple distribution designed to fit the needs of the competent Linux® user. It is both powerful and easy to manage, making it an ideal distro for servers and workstations. Take it in any direction you like. If you share this vision of what a GNU/Linux distribution should be, then you are welcomed and encouraged to use it freely, get involved, and contribute to the community. Welcome to Arch! I have been using Arch since 2009. I like it a lot. It serves me very well :-) Calvin
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 5:07 PM, Heiko Baums li...@baums-on-web.de wrote: Yes, I don't like those Windoze like ini files of systemd, too. I honestly don't know if this is serious. What is the difference between a key=value rc.conf and a key=value ini file of systemd? -- Mantas Mikulėnas
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am 7/24/2012 4:51 PM, schrieb Mantas Mikulėnas:
On Tue, Jul 24, 2012 at 5:07 PM, Heiko Baums li...@baums-on-web.de wrote:
Yes, I don't like those Windoze like ini files of systemd, too.
I honestly don't know if this is serious. What is the difference
between a key=value rc.conf and a key=value ini file of systemd?
I think he refers to those sections: [Unit], [Service], [Install] and
whatnot, I have not explored all of those yet.
But, those are not Windows-like INI-Files. Those files are meant to be
following some XDG Desktop File Descripton Standard Whose Name I Not Now
(tm), making them easy parseable by existing libraries and programs that
implement this standard.
They are not enforced to be following this standard (show itself if you
have a type=forking .service and define multiple ExecStartPost sections
for instance), but are encouraged to be.
It's all in the documentation ;)
But yes, in the end all of those are key=value pairs.
--
AUR: kritztopf
BBS: kritter
#archlinux{,-offtopic}@freenode: kritztopf
[arch-general] LSB init scripts
I have seen some comments here about LSB init scripts. Anyone know where I might obtain an example LSB script template?
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 4:51 PM, Mantas Mikulėnas graw...@gmail.com wrote: On Tue, Jul 24, 2012 at 5:07 PM, Heiko Baums li...@baums-on-web.de wrote: Yes, I don't like those Windoze like ini files of systemd, too. I honestly don't know if this is serious. What is the difference between a key=value rc.conf and a key=value ini file of systemd? +1 I'm not a dev, but the ini files seem pretty user friendly - I liked them back on Windows too. I think maybe we should use our user pages in the wiki to put our thoughts into coherent writing, add links to back up our opinions etc. This could bring some order to the discussion, help dispelling myths and get rid oversimplifications.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 4:59 PM, Christoph Vigano m...@cvigano.de wrote: But, those are not Windows-like INI-Files. Those files are meant to be following some XDG Desktop File Descripton Standard Whose Name I Not Now (tm), making them easy parseable by existing libraries and programs that implement this standard. It is based on the desktop-entry-spec: http://standards.freedesktop.org/desktop-entry-spec/latest/, which in turn is (as far as I know) based on Window's .ini format. -t
Re: [arch-general] LSB init scripts
On Tue, Jul 24, 2012 at 5:01 PM, Baho Utot baho-u...@columbus.rr.com wrote: I have seen some comments here about LSB init scripts. Anyone know where I might obtain an example LSB script template? Most distros who use sysvinit (not Arch though) use some version of LSB scripts, take Debian as an example [0]. Each distro implemented this differently, so the details will vary. [0]: http://wiki.debian.org/LSBInitScripts/.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, 24 Jul 2012 16:07:50 +0200 Heiko Baums li...@baums-on-web.de wrote: Am Tue, 24 Jul 2012 23:40:51 +1000 schrieb Gaetan Bisson bis...@archlinux.org: Yes, I don't like those Windoze like ini files of systemd, too. One thing I noticed is that the only people who usually bash Windows are those who don't develop or know very little about programming. What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... Over time various linux projects took a lot from windows: gconf/dconf (~registry), KDE4 indexing services (~superfetch/desktop indexing), systemd-journald (~windows event viewer). This is real, get used to it. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] LSB init scripts
On 07/24/2012 11:05 AM, Tom Gundersen wrote: On Tue, Jul 24, 2012 at 5:01 PM, Baho Utot baho-u...@columbus.rr.com wrote: I have seen some comments here about LSB init scripts. Anyone know where I might obtain an example LSB script template? Most distros who use sysvinit (not Arch though) use some version of LSB scripts, take Debian as an example [0]. Each distro implemented this differently, so the details will vary. [0]: http://wiki.debian.org/LSBInitScripts/. Is there a development in process to take arch init scripts and mold them into something that is complies with LSB. If so can you point me to those? thanks
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Op dinsdag 24 juli 2012 10:51:05 schreef Calvin Morrison: On 24 July 2012 10:43, Ike Devolder ike.devol...@gmail.com wrote: Op dinsdag 24 juli 2012 10:29:25 schreef Calvin Morrison: Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse. Well for me I do not have the time to go about learning the latest and greatest init system, desktop environment, whatever. I still use KDE3, I use old school init systems... why? because I use my system to do work not to tinker. I need it to just work and continue working in the same way it has. I don't want to become educated on the latest coolest thing, I just want something that will work and work well. I do not have time to pour through documentation of systemd just to figure out how to work it. When change is just for change I do not like it. Calvin my 2cents on your usecase: Arch Linux is always the newest and latest and ... so maybe your use-case does not fit this distributions profile if you really want everything to stay the same forever there are distributions out there which fit your needs exactly, but in my idea Arch is not it. --Ike To summarize: Arch Linux is a versatile, and simple distribution designed to fit the needs of the competent Linux® user. It is both powerful and easy to manage, making it an ideal distro for servers and workstations. Take it in any direction you like. If you share this vision of what a GNU/Linux distribution should be, then you are welcomed and encouraged to use it freely, get involved, and contribute to the community. Welcome to Arch! I have been using Arch since 2009. I like it a lot. It serves me very well :-) Calvin well then i'm very ok with it :) --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] LSB init scripts
On Tue, Jul 24, 2012 at 5:12 PM, Baho Utot baho-u...@columbus.rr.com wrote: Is there a development in process to take arch init scripts and mold them into something that is complies with LSB. No. We are not interested in moving initscripts to LSB. In my opinion it is a big mess with hardly any benefit. -t
Re: [arch-general] LSB init scripts
On Tue, 24 Jul 2012 11:12:55 -0400 Baho Utot baho-u...@columbus.rr.com wrote: On 07/24/2012 11:05 AM, Tom Gundersen wrote: On Tue, Jul 24, 2012 at 5:01 PM, Baho Utot baho-u...@columbus.rr.com wrote: I have seen some comments here about LSB init scripts. Anyone know where I might obtain an example LSB script template? Most distros who use sysvinit (not Arch though) use some version of LSB scripts, take Debian as an example [0]. Each distro implemented this differently, so the details will vary. [0]: http://wiki.debian.org/LSBInitScripts/. Is there a development in process to take arch init scripts and mold them into something that is complies with LSB. If so can you point me to those? thanks Not that I'm aware of. And hopefully such project will never embark. LSB is a mess, which is one of the reasons why people started looking into alternative init systems in the first place. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 24/07/2012 11:08 AM, Leonid Isaev wrote: On Tue, 24 Jul 2012 16:07:50 +0200 Heiko Baums li...@baums-on-web.de wrote: Am Tue, 24 Jul 2012 23:40:51 +1000 schrieb Gaetan Bisson bis...@archlinux.org: Yes, I don't like those Windoze like ini files of systemd, too. One thing I noticed is that the only people who usually bash Windows are those who don't develop or know very little about programming. What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... I assure you, lots of developers, even (or maybe especially) Windows developers bash windows. The key is not throwing the baby out with the bath water. Ini style files are both easy to parse and easy to read - there's no reason not to copy the format. Certainly these systemd target files etc. are easier to read and manage than the initscripts were. It may take some getting use to not being able to see everything in DAEMONS, but the benefits to the maintainers and to me if I ever need to tweak something beyond what gets run in what order, more than offset that. Over time various linux projects took a lot from windows: gconf/dconf (~registry), KDE4 indexing services (~superfetch/desktop indexing), systemd-journald (~windows event viewer). This is real, get used to it. The registry is more debatable. (Having all your config in one place is nice, but when that one place is an inconsistent mess that can only be managed by a mediocre special purpose tool it loses it's benefits.) I think I would be very upset if they wanted to move rc.conf into a gconf like interface. As is though I find it hard to complain. I generally like Windows events except for some of the pointless make work of registering each message ahead of time in your message.dll (which .NET hacks around). That said I've never had any issue with /var/log/*.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 11:59 AM, Christoph Vigano m...@cvigano.de wrote: Am 7/24/2012 4:51 PM, schrieb Mantas Mikulėnas: On Tue, Jul 24, 2012 at 5:07 PM, Heiko Baums li...@baums-on-web.de wrote: Yes, I don't like those Windoze like ini files of systemd, too. I honestly don't know if this is serious. What is the difference between a key=value rc.conf and a key=value ini file of systemd? I think he refers to those sections: [Unit], [Service], [Install] and whatnot, I have not explored all of those yet. But, those are not Windows-like INI-Files. Those files are meant to be following some XDG Desktop File Descripton Standard Whose Name I Not Now (tm), making them easy parseable by existing libraries and programs that implement this standard. They are not enforced to be following this standard (show itself if you have a type=forking .service and define multiple ExecStartPost sections for instance), but are encouraged to be. It's all in the documentation ;) But yes, in the end all of those are key=value pairs. Just like our holy pacman.conf... -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html --- Denis A. Altoe Falqueto Linux user #524555 ---
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... Oh please, if you ever dealt with windows registry then you know it's a totally disfunctional way to keep record of anything. Over time it gets oversized, filled with crap, slow and totally impractical, in one word: bloated, and please, while windows may implement one or two good ideas the underlying infraestructure is as much messy as is it's registry. -- -msx
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 3:24 PM, Baho Utot baho-u...@columbus.rr.com wrote: I am sorry you think any thing you have will be a waste of time. I am looking at this problem of moving to systemd, staying with current init scripts or moving in the LSB init scripts direction. In order for one to make an informed decision one needs to consider all the facts. Without your insight or wisdom how would/will I do that? Discussion is healthy I'm happy to discuss and answer any questions. However, Kevin's emails were: off-topic (this thread was not on systemd, but on rc.conf), irrelevant (the kind of embedded systems he is talking about would never run Arch), Well you brought them on topic by saying at some point we will have to embrace systemd and I wasn't the one who commented first. I wonder if ArmArch will run systemd. They may not run arch but they have code and scripts ported over. Of course those scripts can easily be wrote. Also with the 3.4 kernel recently getting NOMMU support. I hope desktop and embedded will get closer not further away. I also wonder if every original process is forked from systemd like init? Is it? Then does that mean a megabyte rather than 32k of memory is being copied even when transforming into other far smaller processes. That shouldn't go down well in any embedded world where ram may actually be a rom. To give a couple of comments, for those who have not looked at systemd yet: Firstly, systemd is bigger and does more than sysvinit. The reason for this is that it moves functionality out of the individual daemons and into init. This functionality is stuff that would otherwise have been implemented over and over again in every daemon or rc script, each time it is implemented it would be a potential for bugs. Now we have it all in one place, where we can all work together to test and review it. The kind of features implemented in this way are for the purposes of security and reliability of the daemons on your system (i.e. it will monitor them and deal with crashes, it will lock down the kinds of things a daemon is allowed to do, what directories it can read/write to, what system calls it can make, what user it is run as, etc). I would not call this bloat, quite the opposite. It means that the total amount of code on your system, and the total amount of potential for bugs drastically decreases. Secondly, most of the functionality of systemd is separated out in separate processes/tools, and are not part of PID1. In fact, we use these tools also in initscripts, and this is why I believe we will be able to maintain initscripts, even if systemd should take over for most users. Initscripts currently use the following systemd tools: systemd-module-load systemd-udevd systemd-cryptsetup systemd-tmpfiles systemd-sysctl systemd-binfmt systemd-random-seed systemd-vconsole-setup systemd-remount-fs HTH, Tom plain wrong (his descriptions of how systemd works and how to use it has nothing to do with reality). Please give references if you are going to flame me in future. I don't believe I described how systemd works or how to use it. I hope you don't mind me sharing part of a private mail. We seem to disagree on imposing limits onto the user and I assume init halting being good or bad and your comments at the bottom may also prevent anyone moving away from Arch. The point is that there is no limit to what you can put in rc.conf. That's the beauty of it and the essence of UNIX. Which yes has led to variation and perhaps difficulties for the mass market. Atleast systemd has led to the co-operation that may reduce this variation for init scripts users too. I'm sorry if I take this with a pinch of salt, but previous claims I have seen you make often prove to be unsubstantiated. In your opinion, many agree with me and moreso those who have a decent understanding of UNIX. No, not in my opinion. It is objective fact. You keep on making claims (such as A is more secure/smaller/faster/more accurate than B), and then admit that you actually haven't checked/don't know for sure. I assume the same is the case here. You haven't actually read the systemd documentation or the systemd code. Not all of it of course but with /sbin/init I didn't need to. There are many ways to skin a cat, which is where I think we are getting crossed wires here. It is clear that 800K of pid 1 is going to have bugs. It is also clear that if this daemon is able to do so much such as starting services upon events that there will be major exploits. It is also almost certain that all systems are not going to require all of the functionality that the 800k represents. I am glad it has some modular nature however. I had already considered that there may be some feature I haven't considered that would have made adoption difficult as IPC would be required otherwise. I guess I wouldn't need that function though too. I'm sure raising the size
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion and other sources of information about systemd available online. Moreover, there is the source-code, and even the packages in Arch one can try out. There really is no excuse. Well actually I installed Fedora rather than another OS on one system partly to investigate and partly because some little twerp at a science park told me I should be running Fedora. Never again (atleast for a long time). -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
The registry is more debatable. I certainly wish Windows still had ini files and didn't make you eat with just a knife on a Gigantic API ;-) -- Why not do something good every day and install BOINC.
Re: [arch-general] rc.local.shutdown equivalent in systemd
On 07/24/2012 06:38 AM, Rodrigo Rivas wrote: Shouldn't it be just [Unit] Description=Unload module before shutdown [Service] Type=oneshot ExecStart=/usr/bin/rmmod modulename [Install] WantedBy=shutdown.target Without multi-user.target or Before=? In this above approach - can you be certain syslog is still running? Do you care for that matter ... gene/
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 6:06 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: I wonder if ArmArch will run systemd. ArchLinux ARM ships systemd, just like we do. On my ARM machine (a Raspberry Pi running ArchLinux ARM) I use it, and as I mentioned it works great. I hope desktop and embedded will get closer not further away. I agree. I also wonder if every original process is forked from systemd like init? Is it? Then does that mean a megabyte rather than 32k of memory is being copied even when transforming into other far smaller processes. That shouldn't go down well in any embedded world where ram may actually be a rom. This is the sort of comments I refer to. By throwing out these statements without even checking/trying first, you are spreading FUD. You preface it with I wonder, but the effect is still the same. Please give references if you are going to flame me in future. I don't believe I described how systemd works or how to use it. There were too many emails, I gave up. Though, see above. I hope you don't mind me sharing part of a private mail. Share away. -t
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, 24 Jul 2012 13:02:24 -0300 Martin Cigorraga m...@archlinux.us wrote: What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... Oh please, if you ever dealt with windows registry then you know it's a totally disfunctional way to keep record of anything. Yes, I deal a lot with windows registry. In fact, I usually edit it directly to bypass standard program removal and service management. Over time it gets oversized, filled with crap, slow and totally impractical, in one word: bloated, and please, while windows may implement one or two good ideas the underlying infraestructure is as much messy as is it's registry. The problem is not with the registry itself, but bad programming. Most software devs under windows have very little understanding of the registry. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Over time it gets oversized, filled with crap, slow and totally impractical, in one word: bloated, and please, while windows may implement one or two good ideas the underlying infraestructure is as much messy as is it's registry. The problem is not with the registry itself, but bad programming. Most software devs under windows have very little understanding of the registry I can't agree there. Even the microsoft written parts are a mess and strewn throughout in many cases. I've come to the conclusion that Microsoft must like it that way because the average user is more likely to buy a new OS with new hardware rather than fix it or migrate. -- Why not do something good every day and install BOINC.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Tue, Jul 24, 2012 at 6:06 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: I wonder if ArmArch will run systemd. ArchLinux ARM ships systemd, just like we do. On my ARM machine (a Raspberry Pi running ArchLinux ARM) I use it, and as I mentioned it works great. I hope desktop and embedded will get closer not further away. I agree. But I include uClinux etc. in that which is what the recent support may allow without patching I also wonder if every original process is forked from systemd like init? Is it? Then does that mean a megabyte rather than 32k of memory is being copied even when transforming into other far smaller processes. That shouldn't go down well in any embedded world where ram may actually be a rom. This is the sort of comments I refer to. By throwing out these statements without even checking/trying first, you are spreading FUD. You preface it with I wonder, but the effect is still the same. Ok I'm glad it's not something I still think is a certainty. I find mailing lists can be quite informative and a good place to make people think, that's all. A fork does copy the parent initially. -- Why not do something good every day and install BOINC.
Re: [arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Hi Ike, On Sat, Jul 21, 2012 at 04:27:41PM +0200, Ike Devolder wrote: Op zaterdag 21 juli 2012 13:30:24 schreef Arvid Warnecke: Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine. What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with vbetool dpms on in my handler.sh it seems to work pretty well. and for the hibernation, do you have the resume=/my/swap' and do you have the resume hook in your mkinitcpio.conf ? Okay, I added the hook, as described in the wiki, to the mkinitcpio.conf and checked that the resume part is still in the kernel line of my grub configuration. No luck. When I pm-hibernate and then start again the system boots and does not resume at all. :( Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: madhatter ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]--- pgpQXDtI2bq7q.pgp Description: PGP signature
[arch-general] lib - usr/lib
I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? I like to read it, after I finished the following occupational therapy [1]. I suspect that if I won't do it now, I have to restore my Arch from a backup? Or can I shutdown and startup anyway? Regards, Ralf [1] [root@archlinux spinymouse]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 37.58 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@archlinux spinymouse]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-12/files:lib/ /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-linux-x86-64.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db-1.0.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil.so.1 /var/lib/pacman/local/ld-lsb-3-3/files:lib/ /var/lib/pacman/local/ld-lsb-3-3/files:lib/ld-lsb.so.3 /var/lib/pacman/local/udev-compat-180-1/files:lib/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/autofs /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/btrfs-control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/microcode /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/fuse /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/tun /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ppp /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/snd/seq
Re: [arch-general] lib - usr/lib
On Tue, Jul 24, 2012 at 09:48:00PM +0200, Ralf Mardorf wrote: I laugh away this trouble. Is there any information about the advantages of lib - usr/lib? I like to read it, after I finished the following occupational therapy [1]. I suspect that if I won't do it now, I have to restore my Arch from a backup? Or can I shutdown and startup anyway? Regards, Ralf [1] [root@archlinux spinymouse]# pacman -Su :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (1): glibc-2.16.0-2 Total Installed Size: 37.58 MiB Net Upgrade Size: 0.83 MiB Proceed with installation? [Y/n] (1/1) checking package integrity [##] 100% (1/1) loading package files [##] 100% (1/1) checking for file conflicts [##] 100% error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem Errors occurred, no packages were upgraded. [root@archlinux spinymouse]# grep '^lib/' /var/lib/pacman/local/*/files /var/lib/pacman/local/glibc-2.15-12/files:lib/ /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/ld-linux-x86-64.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libBrokenLocale.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libSegFault.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libanl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libc-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libc.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcidn.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libcrypt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libdl.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libm-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libm.so.6 /var/lib/pacman/local/glibc-2.15-12/files:lib/libmemusage.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnsl.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_compat.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_db.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_dns.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_files.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_hesiod.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nis.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libnss_nisplus.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/libpcprofile.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libpthread.so.0 /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libresolv.so.2 /var/lib/pacman/local/glibc-2.15-12/files:lib/librt-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/librt.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db-1.0.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libthread_db.so.1 /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil-2.15.so /var/lib/pacman/local/glibc-2.15-12/files:lib/libutil.so.1 /var/lib/pacman/local/ld-lsb-3-3/files:lib/ /var/lib/pacman/local/ld-lsb-3-3/files:lib/ld-lsb.so.3 /var/lib/pacman/local/udev-compat-180-1/files:lib/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/autofs /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/btrfs-control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/cpu/microcode /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/fuse /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/mapper/control /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/ /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/net/tun /var/lib/pacman/local/udev-compat-180-1/files:lib/udev/devices/ppp
Re: [arch-general] lib - usr/lib
On Tue, 2012-07-24 at 15:52 -0400, Daniel Wallace wrote: remove udev-compat it is old, either update ld-lsb from aur or remove it as for the find, remove any un owned files from anything under /lib. then remove any empty directories then update Thank you :) at least it's not bad that I'm forced to get rid of some old unneeded stuff ;). Regards, Ralf
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Mon, Jul 23, 2012 at 09:36:05AM +0200, Nicolas Sebrecht wrote: The pain is the need to merge new changes while updating. Some tools (like pacdiff) can help with the job but it's very frustrating to have one configuration file and merge lot of changes in it. Especially when it comes to cosmetic/comments changes. Having one big configuration file means it's much easier to make mistakes in it and have strong problems because of that. Dedicated files to services/requirements make such problems more isolated. Yes, I concur. Although I'm not so much a fan of systemd, I can say with confidence that this assertion matches my experience. Dividing the configurations makes each package far more likely to update itself cleanly withit botching-up some other, unrelated part of your system.
Re: [arch-general] [arch-dev-public] [RFC, after the fact] initscripts config
On Mon, Jul 23, 2012 at 6:48 PM, Leonid Isaev lis...@umail.iu.edu wrote: On Mon, 23 Jul 2012 12:46:52 +0200 Tom Gundersen t...@jklm.no wrote: On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo orbisvi...@gmail.com wrote: 3) Personally this depends on the final rc.conf, is [1] or [2] going to be it? [1] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc7 [2] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f7 At the moment it is [1], so if no one tells me otherwise, that's it. 4.1) Are we going to ship default (possibly empty) replacement configuration files, which currently may not exist on many systems, and add these to the backup array? This includes (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname). I'd be against it, as it seems pointless. But it would be Dave's decision. 4.2) To be clear, is there going to be a separate configuration for the HARDWARECLOCK and TIMEZONE variables? There already are. That's the problem. HARDWARECLOCK is configured in the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is configured by pointing the /etc/localtime symlink at what you want. I wonder if there a need for TIMEZONE as a config variable at all (whereever it is located, as opposed to an install-time setting), especially if it is recommended to be left empty? d) The new format does not require a bash interpreter to be read 4.d) I think this is a terrible justification. A programming language embedded in a configuration system grants a lot of possibilities. It also makes it impossible to reason about. Or to parse from another language than what it was defined in. Also there is a sound way to read configuration files written in a programming language - simply evaluate the code. But there is no sound way to then change the options and write them back. In any case, to preserve compatibility with systemd, the new files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not contain bash. These files can all be read by bash, but are strictly defined. This means we can know their format and update them in a sound way. 5) With the plethora of changes, each for different reasons, I think there is justifcation for a comprehensive news item summarizing changes to each variable: LOCALE - /etc/locale.conf HARDWARECLOCK - deprecated Sure. USE_BTRFS - esoteric, removed for cosmetic reasons Won't kill this one, but I get your point. -t -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D I have no problem with removing the options, however I agree with Yclept in that decreasing the expressive power of the configuration file is both unnecessary and counterproductive. While a bash script may not be the best configuration format, moving to an ini-style format would hurt those who require being able to dynamically specify configuration variables. Note - I myself wouldn't be affected by decreasing the power of the format, but I can well imagine people raising a hue and cry over it. Just my 2c M
Re: [arch-general] linux 3.5-1 - No volume groups found
On Tuesday 24 of July 2012 17:21:46 BOYPT wrote: On Tue, Jul 24, 2012 at 5:02 PM, Herbert J. Skuhra hsku...@eumx.net wrote: On 24.07.2012 10:51, BOYPT wrote: On Tue, Jul 24, 2012 at 4:40 PM, Herbert J. Skuhra hsku...@eumx.net wrote: Hi, after upgrading to linux 3.5-1 yesterday my computer no longer boots. :( The following error is displayed: No volume groups found I have to run lvm vgchange -a y before I can continue booting. What do you get running lvm vgchange -a y ? If this still fail to load the mapper, it's not likely to boot. If I enter this command and then quit/exit the system boots normally. I have no idea why the vg is not activated automatically. After downgrading to linux 3.4.6-1 everything is OK. I encounter the same situation. The forum users also report the same: https://bbs.archlinux.org/viewtopic.php?id=145714 I don't know what exactly changed in the new kernel(seems like things going with udev,device mapper,kernel ...etc), adding the kernel parameters like the post said helps. Hi, I'm the OP in the forum thread you are referring to. I was wrong. The kernel parameters help, but it's only due to the one sec. delay induced by misuse of the lvmwait parameter :) David
[arch-general] vboxbuild: command not found
Hi, after upgrading, including the switch from /lib to /usr/lib virtualbox still is ok for kernel 3.4.6-1-ARCH, but when I try to build the modules for kernel 3.4.4-rt13-2-rt the vboxbuild command doesn't exist. Until now nothing else seems to be borked. [root@archlinux spinymouse]# uname -a Linux archlinux 3.4.4-rt13-2-rt #1 SMP PREEMPT RT Tue Jul 17 11:32:31 UTC 2012 x86_64 GNU/Linux [root@archlinux spinymouse]# pacman -Qi virtualbox-source Name : virtualbox-source Version: 4.1.18-3 [root@archlinux spinymouse]# vboxbuild bash: vboxbuild: command not found [root@archlinux spinymouse]# ls -hAl /lib lrwxrwxrwx 1 root root 7 Jul 7 12:09 /lib - usr/lib [spinymouse@archlinux ~]$ uname -a Linux archlinux 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux [spinymouse@archlinux ~]$ pacman -Qi virtualbox Name : virtualbox Version: 4.1.18-3 [spinymouse@archlinux ~]$ pacman -Qi virtualbox-ext-oracle Name : virtualbox-ext-oracle Version: 4.1.18-1 Regards, Ralf
Re: [arch-general] vboxbuild: command not found
2012/7/24 Ralf Mardorf ralf.mard...@alice-dsl.net: Hi, after upgrading, including the switch from /lib to /usr/lib virtualbox still is ok for kernel 3.4.6-1-ARCH, but when I try to build the modules for kernel 3.4.4-rt13-2-rt the vboxbuild command doesn't exist. Until now nothing else seems to be borked. [root@archlinux spinymouse]# uname -a Linux archlinux 3.4.4-rt13-2-rt #1 SMP PREEMPT RT Tue Jul 17 11:32:31 UTC 2012 x86_64 GNU/Linux [root@archlinux spinymouse]# pacman -Qi virtualbox-source Name : virtualbox-source Version: 4.1.18-3 [root@archlinux spinymouse]# vboxbuild bash: vboxbuild: command not found [root@archlinux spinymouse]# ls -hAl /lib lrwxrwxrwx 1 root root 7 Jul 7 12:09 /lib - usr/lib [spinymouse@archlinux ~]$ uname -a Linux archlinux 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux [spinymouse@archlinux ~]$ pacman -Qi virtualbox Name : virtualbox Version: 4.1.18-3 [spinymouse@archlinux ~]$ pacman -Qi virtualbox-ext-oracle Name : virtualbox-ext-oracle Version: 4.1.18-1 Regards, Ralf http://www.mail-archive.com/arch-general@archlinux.org/msg28434.html
Re: [arch-general] vboxbuild: command not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Somewhere on a mailing list was announced by a maintainer, that vboxbuild would be replaced by the use of dkms. But I can't recall completely where this was mentioned. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQDxz+AAoJEOGIwUZuUxpn8VsQAIRCYmcEyZhzT19vzZmdhygy EG2TZ0eFoIcTTK0SvT5RjHyyvjXauAEHnbPiAJlp9jC8e32oVzBLH788H6/9FySo wMT5pbu8zDMEE92ceNCUPk3EykSBEKMmALd+aLrIVt4JvMalLbj/bV+3uGk9M6kd uFEcsJGU83ECAm5COp1qCbdvu6a7Aw2lstV9YkyxC0UstSQHmNliX3jqvxeukX+y pxa8uk8oKGPijChJLwcGL2p8g5ckjZyEDjA5HYUsOpfKlPMdZMvvh+kAxdt3L2PG KvMqA8ny4o1/kSmTcX+/12rSr/I7rRF9r17uH5XBTU87cg4+bJtFhBZeQrM1zi8B 6cAAaIZo2UbR+e/LkJnQ8AszA2oiueRwBPekGlwuMmUzkZnwsZeAy3yr6/ZL1Qk7 L7mRGlJRT8N5WNEYgaXNcs+9UHLB6oCQ4447YZhRZn3JBCjY9dnNJ55Jwe4fLpxs vgxSGYA9Z1ynhEJMY2kY5rIXU7UsndzZkXJKTVnrOGzrLwMb1XCl4g4Zu4jFJ8bG c4cBcOTlerXnHEvj7XdQsLGfSZ/Uh/0F69PRvH/sYKnNBnWQBpl3dqzjbDarRCTr ocEiSBwnMKY2IT1Mxtx1tG11ybkzkM8YjceHmhRbds+qlh8aQvzacN9eQIuGdn8e H67iqzjF36lmhOtvRNRT =OvjQ -END PGP SIGNATURE-
Re: [arch-general] vboxbuild: command not found
On Tue, 2012-07-24 at 19:09 -0300, rafael ff1 wrote: http://www.mail-archive.com/arch-general@archlinux.org/msg28434.html Thank you, sorry, I read the thread now. Regards, Ralf
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/24/2012 01:15 AM, Martin Cigorraga wrote: The beauty behind this is we are now enjoying the new paradigm without reinstalling the system while with other distros your only chance to make the switch is reinstall not only your OS but everything else! Cheers. Now that... is the beauty of Arch! The other distro's release/reinstall cycle is far more work than the rolling-release. But, after packaging trinity on Arch, I can tell you it is a double-edge sword. You get everything building just fine until the next pacman -Syu and then 5 packages quit building due to package updates (libpng, ffmpeg, gcc, on-and-on, ...) Literally you can kick off a build in the morning, then update and have it go to hell in the evening. It gives you a great deal of respect for the sheer amount of work the Arch developers put into this disto -- David C. Rankin, J.D.,P.E.
Re: [arch-general] vboxbuild: command not found
Somewhere on a mailing list was announced by a maintainer, that vboxbuild would be replaced by the use of dkms. But I can't recall completely where this was mentioned. Here!: http://mailman.archlinux.org/pipermail/arch-general/2012-July/028477.html -- -msx
Re: [arch-general] vboxbuild: command not found
Oh well! -- -msx
[arch-general] OT: Something good happened
When using Evolution on Xfce the color theme was broken for a long time. Some text was unreadable. Today it's fixed :). I already thought about switching to LXDE. No need to do so now. Thanx, Ralf
Re: [arch-general] OT: Something good happened
On 07/25/2012 01:27 AM, Ralf Mardorf wrote: When using Evolution on Xfce the color theme was broken for a long time. Some text was unreadable. Today it's fixed :). I already thought about switching to LXDE. No need to do so now. This is magic! Thanx, Ralf -- Ionuț signature.asc Description: OpenPGP digital signature
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 10:08:26 -0500 schrieb Leonid Isaev lis...@umail.iu.edu: One thing I noticed is that the only people who usually bash Windows are those who don't develop or know very little about programming. You really shouldn't do such assumptions. You couldn't have noticed it, you're just assuming. What exactly is wrong with ini files and/or registry? Perhaps it is your misunderstanding... And I assume that you never really administrated a Windoze PC. Then you would know that particularly the registry is a PITA. Over time various linux projects took a lot from windows: gconf/dconf (~registry), Gconf is also almost a PITA. At least it's a lot more inconvenient than simple text files. KDE4 indexing services (~superfetch/desktop indexing), This indexing is one thing which makes KDE4 so slow and unstable. KDE4 was the reason why I switched to Xfce. And, yes, I tried KDE4. But Gnome and KDE4 are just optional, systemd is meant as the new init system. That's a big difference. If this all was only about an optional piece of software I wouldn't say anything. I just wouldn't use it. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 11:31:22 -0500 schrieb Leonid Isaev lis...@umail.iu.edu: The problem is not with the registry itself, but bad programming. Most software devs under windows have very little understanding of the registry. Bad programming is the most favorite answer, and totally nonsense. The registry just gets bigger and bigger and is totally cryptic. And the registry is one of the most frequent reasons for system crashes and instabilities. And it's the most frequent reason why Windoze regularly (usually every 3 months) needs to be reinstalled. Heiko
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am Tue, 24 Jul 2012 16:25:52 +0200 schrieb Tom Gundersen t...@jklm.no: Talking about UNIX philosophy and Windoze like ini files is probably what gets some people going. It is not technical. In fact it is technical. Of course, at first glance config files for rc scripts and ini files are simple text files. But the structure, the way how they are handled (sourced or parsed), etc. is pretty different. And it's not only the ini thing. It's the whole possible move to making Linux a lot more Windoze like what I'm afraid of. The UNIX philosophy has worked for about 40 years and is totally tested and approved. Systemd is not. Of course, new things don't need to be bad and times are changing and sometimes there have to be made some adjustments, but it's a question how those new things are designed. And that's another point which I'm afraid of. I have tested PulseAudio and I know who has written and designed it. And I know that it totally doesn't work with a very few exceptions. And then I see that the same person starts writing something else at the same time, which intervenes even more into the system, even if the first software doesn't work correctly. So what do you think, how this looks like? Do you really think that this sounds trustworthy? Added to this I read that there are Windoze like ini files again in this second software of this person. Why do you think I have switched from Windoze to Linux? Of course, it was not the ini files in the first place. It was the whole terrible design and concept of Windoze incl. the registry. I still always get fits of raving madness if I have to work with Windoze, because I regularly need several hours for fixing something which I had fixed within minutes in Linux because of those simple and small config files and shell scripts (and because of the UNIX philosophy). And I know Windoze pretty well, too. Btw., I'm working with Computers since more than 25 years now and with Linux exclusively more than 10 years. And I started with an Apple IIc and a 8086 with PC-DOS 3.1, worked with several Windoze versions and I know Linux since 1993. So I guess I know what I'm talking about. In Linux I have/had some simple text files with which I can/could configure the whole system, while I had a terrible, cryptic registry on Windoze. In Linux I just can/could add a daemon to rc.conf to have it run. From what I read so far about systemd in all those discussions, in systemd I have to run a special command to have a daemon started at boot time (which I additionally have to remember), I have to write such an ini file instead of just writing or editing a simple and small config file or shell script, then systemd creates some symlinks of files into another directory whose name is also totally cryptic, at least way to long. This is a total mess, if this is really true, and it's absolutely a step towards a second Windoze. You have explained some of the advantages of systemd. And this sounds quite good, I admit. But I fear it's badly designed, at least everything around those advantages. And this all is technical. Yeah, we might agree that UNIX is great and Windows is bad. But in a technical argument, it is just annoying to point to tradition and philosophy rather than technical facts, regardless of what side of the argument you are on. It's not really annoying. Well, yes, if there was no substance behind it and if the tradition wasn't approved this well as it is in Linux and UNIX. See above. The problem in such long discussions is, that it's sometimes not possible or that people just don't have the time or the nerves to explain all the arguments in detail. But if there's such a long discussion and if there are so many complains about a software or a change, then you can assume that there's something going pretty wrong. Either this software or change hasn't been explained good enough to the people (and just saying RTFM is not enough in such cases) or the software is indeed not well enough designed, which should probably be fixed. And, btw., I never ever have read such long discussions and so many complains about a software like about the software of Lennart Poettering (PulseAudio and systemd). I was definitely not the only one who complained about it. And this must have a reason. And you can't tell me, that all those people have too little knowledge. If you claim that systemd does not follow the UNIX philosophy (I disagree, but whatever), and if you claim that anything not following the UNIX philosophy is bad (I disagree, but whatever), then you should be able to combine these two claims and point to a technical flaw or shortcomming in systemd without any reference to UNIX, or Windows, or KISS at all. See above. I think, I don't need to search for links which explain the UNIX philosophy. Personally, I get exasperated when people don't take the time to educate themselves before making broad and incorrect assertions. There is a huge amount of documentation, discussion
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On Wed, Jul 25, 2012 at 1:46 AM, Heiko Baums li...@baums-on-web.de wrote: Seriously, who reads source codes? Manpages usually only explain the parameters, not the design of the software and how it works. There may be some other documentations, I haven't yet seen any. Overview of the bootprocess under systemd: http://0pointer.de/public/systemd-man/bootup.html Some info about old- and new-style daemons: http://0pointer.de/public/systemd-man/daemon.html Some general info about the systemd daemon: http://0pointer.de/public/systemd-man/systemd.html Lots and lots of man-pages documenting every little part of systemd: http://0pointer.de/public/systemd-man/ More info about systemd, including links to Lennart's blogs, which explain things in a more understandable way than the man-pages: http://www.freedesktop.org/wiki/Software/systemd/ Now I know that you can explain things. So why not do it if you find that someone doesn't know enough about what's talked about? Nobody expects that you write a second documentation, but explaining some details can sometimes help. Sure, whenever people ask something I try my best to explain what I can. My comment was aimed at those who pretend to know without doing their research. -t
[arch-general] systemd network configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Because it's summer, and I'd really rather not try to figure all this
out during the school year, I'm trying to figure out systemd *now*,
rather than waiting until rc.conf goes away.
I actually had trouble with rc.conf when I first installed Arch on my
Linode. Some daemons mysteriously wouldn't start and I couldn't figure
out how to get the networking to come up properly. (And, of course, I
was in a hurry.) So I wound up hacking rc.local to bring up both the
network and the daemons. (Yes, I know: ew!)
This is the shell snippet I'm using to bring up my network now:
rc.d start network #successfully gets some address and a route
for i in 74.207.225.79/32 74.207.227.150/32 173.230.137.73/32
173.230.137.76/32
do
ip addr add ${i} dev eth0
done
ip -6 addr add 2600:3c02::f03c:91ff:fe96:64e2/64 dev eth0
for j in $(seq 0 1)
do
for i in $(seq 0 9) a b c d e f
do
ip -6 addr add 2600:3c02::02:70${j}${i}/64 dev eth0
done
done
Basically, with the IPv4 address, my intent is to make sure I've got
all four of those addresses up. But I wasn't getting a route unless I
used the network start script.
In my copy of the Arch wiki, Im not seeing how to do something
similar under systemd. How, ideally, should I be doing this?
Thanks!
- --
David Benfell
benf...@parts-unknown.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQD0GKAAoJELT202JKF+xpbMQP/3ADZesFp6+ZAzSItwDdvjJi
vUxCgyAXscCymTuTtjYov/lBxoh5/thu4KL2EbYA/F28r4rP0blBUR4Yrhj1jIDn
tZJcaoDBY5d7mT+hgI+9rIlGlFvnm+P/cCd8MAebkIiTAmLnurgSZe22Y6kV+VKe
nyQFJEWbyGk3O8d9ODtQnpKJ9AJrDY+fsGf/saZP+0KZDjjISHzl9VN81a4WngXP
JFeTLXhopSjWYPsECrrK0PE0Q5O524TL90ZuDvNM5BqVIgmQG9FkCzKaWLm2hCYX
gLLArdpnpAGse/yHyxBjqtHVtcm0lUD647Z8aJCHkObpQcaeAvwXSblaDcOVxo0L
3WX6qRam75kPABmDNRJPPYCqEPFiSDfdpL87m00v+zFRv+WTPr4X1NurOIomAp5x
QVjOlOvnpAbyexXfaWRzYvRpDuSrKbnuxzyDNKmGRPgiRvaWAjansoif4o0ojffh
Fw1sxLIWtggEgy0SGWJ/Ke7Z18IYJ7TF/1ZfRAknBIsdjCb8rFSA7byskjwrxWzT
rEZ9qzrtB/OKZCYsi+tlGhRiyUJ2j+8g5ujqeLvN1W7FQYd8SEmGyg5zCgYnuKBP
Sw/JnsMzvdW16BnqTMLIF5zrQJGzXV81UL101MSjwnXIuWNHAmhChx5I7yObhhYc
7fkFhIf0iSdBES8WX+Dh
=WY4X
-END PGP SIGNATURE-
[arch-general] pacman and corrupt packages
Hello All, Last few days my net connection drops randomly or slows down to a crawl. As a result, there are several timeouts during package downloads. When a download timeout occurs, pacman aborts with invalid or corrupted package. Is it possible to detect which package is corrupt and invalid, so that it can be downloaded? When it happened with one package, I deleted it manually and next time it worked but when several packages get timeout, its hard to detect the failing one. Does pacman has built-in retry functionality? Here is the complete log. - :: Starting full system upgrade... resolving dependencies... looking for inter-conflicts... Targets (33): ati-dri-8.0.4-2 boost-libs-1.50.0-2 clang-3.1-3 cups-1.5.3-6 cups-filters-1.0.20-1 dbus-1.6.4-1 dbus-core-1.6.4-1 dovecot-2.1.8-2 gcc-4.7.1-5 gcc-libs-4.7.1-5 git-1.7.11.3-1 gnutls-3.0.21-2 icu-49.1.2-2 imagemagick-6.7.8.6-1 intel-dri-8.0.4-2 khrplatform-devel-8.0.4-2 libcups-1.5.3-6 libegl-8.0.4-2 libgl-8.0.4-2 libglapi-8.0.4-2 libgles-8.0.4-2 libmp4v2-2.0.0-2 llvm-3.1-3 mesa-8.0.4-2 nginx-1.2.2-2 python2-distribute-0.6.28-1 qt-4.8.2-3 qt- gstreamer-0.10.2-2 svga-dri-8.0.4-2 taglib-1.7.2-2 ttf-liberation-2.00.0-1 tzdata-2012d-1 xf86- video-intel-2.20.1-1 Total Installed Size: 515.40 MiB Net Upgrade Size: 1.88 MiB Proceed with installation? [Y/n] y (33/33) checking package integrity [#] 100% error: failed to commit transaction (invalid or corrupted package) Errors occurred, no packages were upgraded. - With pacman -sy --debug I get following error snippet - debug: found cached pkg: /var/cache/pacman/pkg/ati-dri-8.0.4-2- x86_64.pkg.tar.xz debug: sig data: iQEcBAABAgAGBQJQC9QHAAoJEJRlerIPKgkrd/EH/jhoIY6szxkh3AFGHogBLGe33tIcGhMchGI9jtxEht/Df+IB9X9tYC5nG62pOL9+v0Sl4yVLBW4Ni0mYdwQ0UfJr3Mt1s7C3LbTI1ucU8WZMZicXc8tDKurRnPBDkAqnhK4+H7 4qa6ALNfIDQK7PVQTIedAQDgO9WsPd3DsKcOfNbEXZrDZSBU3awoaQuezKaoif/JnSt7iRXn3hd8piuUgQuLQuksAe+Oa6MtEgXoCHQ22uzXa6nEV1EkO0q1sf8+0w/9+4mD3ejUutfLAQbxqmpfmw3kEuQ1eaICRLRgRu0ugKuwqi9cvdDBiw/27Z1QTkY aUNtvdT66Wb5OuAJGI= debug: checking signature for /var/cache/pacman/pkg/ati-dri-8.0.4-2- x86_64.pkg.tar.xz debug: 1 signatures returned debug: fingerprint: ADC8A1FCC15E01D45310419E94657AB20F2A092B debug: summary: valid debug: summary: green debug: status: Success debug: timestamp: 1342952455 debug: exp_timestamp: 0 debug: validity: full; reason: Success debug: key: ADC8A1FCC15E01D45310419E94657AB20F2A092B, Andreas Radke andy...@archlinux.org, owner_trust unknown, disabled 0 debug: signature is valid debug: signature is fully trusted debug: returning error 6 from _alpm_pkg_validate_internal : wrong or NULL argument passed - -- Regards Shridhar
Re: [arch-general] pacman and corrupt packages
Followup, On Wednesday 25 Jul 2012 9:03:42 AM Shridhar Daithankar wrote: With pacman -sy --debug I get following error snippet - debug: found cached pkg: /var/cache/pacman/pkg/ati-dri-8.0.4-2- x86_64.pkg.tar.xz debug: sig data: iQEcBAABAgAGBQJQC9QHAAoJEJRlerIPKgkrd/EH/jhoIY6szxkh3AFGHogBLGe33tIcGhMchGI9 jtxEht/Df+IB9X9tYC5nG62pOL9+v0Sl4yVLBW4Ni0mYdwQ0UfJr3Mt1s7C3LbTI1ucU8WZMZicX c8tDKurRnPBDkAqnhK4+H7 4qa6ALNfIDQK7PVQTIedAQDgO9WsPd3DsKcOfNbEXZrDZSBU3awoaQuezKaoif/JnSt7iRXn3hd 8piuUgQuLQuksAe+Oa6MtEgXoCHQ22uzXa6nEV1EkO0q1sf8+0w/9+4mD3ejUutfLAQbxqmpfmw3 kEuQ1eaICRLRgRu0ugKuwqi9cvdDBiw/27Z1QTkY aUNtvdT66Wb5OuAJGI= debug: checking signature for /var/cache/pacman/pkg/ati-dri-8.0.4-2- x86_64.pkg.tar.xz debug: 1 signatures returned debug: fingerprint: ADC8A1FCC15E01D45310419E94657AB20F2A092B debug: summary: valid debug: summary: green debug: status: Success debug: timestamp: 1342952455 debug: exp_timestamp: 0 debug: validity: full; reason: Success debug: key: ADC8A1FCC15E01D45310419E94657AB20F2A092B, Andreas Radke andy...@archlinux.org, owner_trust unknown, disabled 0 debug: signature is valid debug: signature is fully trusted debug: returning error 6 from _alpm_pkg_validate_internal : wrong or NULL argument passed - I deleted ati-dri package and redownloaded it. This time, without any timeouts and it still failed the upgrade with same error for the same package. So I uninstalled ati-dri and xf86-video-ati. I have intel card and got all those extra drivers because I installed the whole group for simplicity. Try again and this time it failed for gcc-libs. Delete, redownload and the error still persists. and I don't think uninstalling gcc-libs is an option. I also found https://bugs.archlinux.org/task/28014 but I don't think that can solely fix the issue. --debug is printing enough information or so I would like to think. Pl. Help. -- Regards Shridhar
Re: [arch-general] pacman and corrupt packages
Shridhar Daithankar ghodech...@ghodechhap.net writes: I deleted ati-dri package and redownloaded it. This time, without any timeouts and it still failed the upgrade with same error for the same package. So I uninstalled ati-dri and xf86-video-ati. I have intel card and got all those extra drivers because I installed the whole group for simplicity. Try again and this time it failed for gcc-libs. Delete, redownload and the error still persists. and I don't think uninstalling gcc-libs is an option. I also found https://bugs.archlinux.org/task/28014 but I don't think that can solely fix the issue. --debug is printing enough information or so I would like to think. Pl. Help. Does it continue after a pacman -Scc? - Jeremiah Dodds github: https://github.com/jdodds irc : exhortatory -
Re: [arch-general] pacman and corrupt packages
On Wed, Jul 25, 2012 at 11:51 AM, Jeremiah Dodds jeremiah.do...@gmail.com wrote: Shridhar Daithankar ghodech...@ghodechhap.net writes: I deleted ati-dri package and redownloaded it. This time, without any timeouts and it still failed the upgrade with same error for the same package. So I uninstalled ati-dri and xf86-video-ati. I have intel card and got all those extra drivers because I installed the whole group for simplicity. Try again and this time it failed for gcc-libs. Delete, redownload and the error still persists. and I don't think uninstalling gcc-libs is an option. I also found https://bugs.archlinux.org/task/28014 but I don't think that can solely fix the issue. --debug is printing enough information or so I would like to think. Pl. Help. Does it continue after a pacman -Scc? Why are you recommending clearing his entire cache (which can be quite useful) when he's already specifically cleared the offending package and still has problems?
Re: [arch-general] pacman and corrupt packages
Oon-Ee Ng ngoonee.t...@gmail.com writes: On Wed, Jul 25, 2012 at 11:51 AM, Jeremiah Dodds jeremiah.do...@gmail.com wrote: Shridhar Daithankar ghodech...@ghodechhap.net writes: I deleted ati-dri package and redownloaded it. This time, without any timeouts and it still failed the upgrade with same error for the same package. So I uninstalled ati-dri and xf86-video-ati. I have intel card and got all those extra drivers because I installed the whole group for simplicity. Try again and this time it failed for gcc-libs. Delete, redownload and the error still persists. and I don't think uninstalling gcc-libs is an option. I also found https://bugs.archlinux.org/task/28014 but I don't think that can solely fix the issue. --debug is printing enough information or so I would like to think. Pl. Help. Does it continue after a pacman -Scc? Why are you recommending clearing his entire cache (which can be quite useful) when he's already specifically cleared the offending package and still has problems? I've run into situations where I thought I had cleared a corrupted package but didn't actually do so, or where I missed one. Considering he's tried multiple times, it might be worth clearing the entire thing to make sure he's not missing something. - Jeremiah Dodds github: https://github.com/jdodds irc : exhortatory -
Re: [arch-general] Failed to compile Emacs
I must use `autoreconf -i -I m4` in order to build. On Sun, 15 Jul 2012 10:11:42 -0500 Leonid Isaev lis...@umail.iu.edu wrote: On Sun, 15 Jul 2012 17:40:09 +0700 Diep Pham Van i...@favadi.com wrote: After apply this patch, I get: cd /home/favadi/abs/emacs/src/emacs-24.1 automake --gnu -a -c lib/Makefile configure.in:29: error: version mismatch. This is Automake 1.12.2, configure.in:29: but the definition used by this AM_INIT_AUTOMAKE configure.in:29: comes from Automake 1.11.1. You should recreate configure.in:29: aclocal.m4 with aclocal and run automake again. make: *** [/home/favadi/abs/emacs/src/emacs-24.1/lib/Makefile.in] Error 63 config.status: executing gdbinit commands cd /home/favadi/abs/emacs/src/emacs-24.1 automake --gnu -a -c lib/Makefile configure.in:29: error: version mismatch. This is Automake 1.12.2, configure.in:29: but the definition used by this AM_INIT_AUTOMAKE configure.in:29: comes from Automake 1.11.1. You should recreate configure.in:29: aclocal.m4 with aclocal and run automake again. make: *** [/home/favadi/abs/emacs/src/emacs-24.1/lib/Makefile.in] Error 63 == ERROR: A failure occurred in build(). Aborting... How can I solve it? By doing exactly what it tells you -- running aclocal and autoconf in PKGBUILD right after patching. At Sat, 14 Jul 2012 15:12:02 -0500, Leonid Isaev lis...@umail.iu.edu wrote: [1 text/plain; UTF-8 (quoted-printable)] On Sun, 15 Jul 2012 02:21:47 +0700 Diep Pham Van i...@favadi.com wrote: Hello every one, I've tried to compile emacs and fail. You can view the `makepkg -s` ouput here[1]. I think the important part here: ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function) In file included from md5.h:24:0, from md5.c:25: ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function) make[2]: *** [sha1.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [md5.o] Error 1 mv -f .deps/careadlinkat.Tpo .deps/careadlinkat.Po In file included from sha256.h:21:0, from sha256.c:25: ./stdio.h:1030:1: error: ‘gets’ undeclared here (not in a function) make: *** [lib] Error 2 I do not to know what to do here. Any one can help me with this? [1] https://gist.github.com/3112844 A simple google search yields this: http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-07/msg00240.html... Does it answer your question? -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D [2 signature.asc application/pgp-signature (7bit)] -- PHAM Van Diep i...@favadi.com - dieppham...@vccorp.vn www.favadi.com - (+84) 984 339 841 System Administrator, Adtech, VCCorp, VN -- There are 10 types of people, those who understand binary and those who don't. signature.asc Description: PGP signature
Re: [arch-general] pacman and corrupt packages
On Tuesday 24 Jul 2012 11:58:14 PM Jeremiah Dodds wrote: Oon-Ee Ng ngoonee.t...@gmail.com writes: On Wed, Jul 25, 2012 at 11:51 AM, Jeremiah Dodds Does it continue after a pacman -Scc? Why are you recommending clearing his entire cache (which can be quite useful) when he's already specifically cleared the offending package and still has problems? I've run into situations where I thought I had cleared a corrupted package but didn't actually do so, or where I missed one. Considering he's tried multiple times, it might be worth clearing the entire thing to make sure he's not missing something. That is an option I have not yet tried but I just want to preserve the reproduction and debug the problem if there is any. -- Regards Shridhar
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Am 25.07.2012 02:00, schrieb Heiko Baums: Am Tue, 24 Jul 2012 11:31:22 -0500 [...] And it's the most frequent reason why Windoze regularly (usually every 3 months) needs to be reinstalled. Heiko Good morning, that is / was right for Win 98 or Win ME. Having an exception error which was caused by damaged registry files always meant a reset to state short after the OS-installation, so all the drivers and programs had to be re-installed. But my XP-Installation ran more than five years stable though being stressed by many test-installations of applications. Does not mean that XP or Win 7 is going to make an admin feel happy - but yes, there was an improvement, at least for the users. Nelson.
Re: [arch-general] pacman and corrupt packages
Op woensdag 25 juli 2012 10:30:21 schreef Shridhar Daithankar: On Tuesday 24 Jul 2012 11:58:14 PM Jeremiah Dodds wrote: Oon-Ee Ng ngoonee.t...@gmail.com writes: On Wed, Jul 25, 2012 at 11:51 AM, Jeremiah Dodds Does it continue after a pacman -Scc? Why are you recommending clearing his entire cache (which can be quite useful) when he's already specifically cleared the offending package and still has problems? I've run into situations where I thought I had cleared a corrupted package but didn't actually do so, or where I missed one. Considering he's tried multiple times, it might be worth clearing the entire thing to make sure he's not missing something. That is an option I have not yet tried but I just want to preserve the reproduction and debug the problem if there is any. -- Regards Shridhar You could try to switch mirrors, use a mirror that is not dropping all the time, or is this problem related to your own internet ? My guess is we will see more of this in the future since the package checking is much more tight now than in the past. --Ike signature.asc Description: This is a digitally signed message part.
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
Bad programming is the most favorite answer, and totally nonsense. The registry just gets bigger and bigger and is totally cryptic. And the registry is one of the most frequent reasons for system crashes and instabilities. And it's the most frequent reason why Windoze regularly (usually every 3 months) needs to be reinstalled. Heiko Hello Heiko, this is simply not true. First of all, starting with Windows XP the stability of Windows (yes, Windows, not Windoze) got much better and there are very few crashes which are mostly related to driver issues, IMO. Secondly, Windows doesn't need to be reinstalled every 3 months. Come on, most companies use Windows on their desktops and they don't need to reinstall them every 3 months. And their employees actually can work with their computers. And i don't say this because i like Windows but because i'm realistic and not unfair. I don't live in a world where one system is perfect and the others are all completely crap. If you think that Windows is completely bad then you're not professional. BTW: pacman.conf is written in an ini-style as well. Greetings, Oliver
