November 2012 - Arch-general - lists.archlinux.org

[arch-general] LVM Thin Provisioning
by Squall Lionheart 21 Nov '12

21 Nov '12

Hello, I have been reading about Thin Provisioning in LVM and wanted to play with it however, when I try to create a thin pool it shows an error saying: # lvcreate --thinpool -L 1G vg/pool WARNING: Unrecognised segment type thin Unable to create LV with unknown segment type thin. Run `lvcreate --help' for more information. I am running version: # lvm version LVM version: 2.02.98(2) (2012-10-15) Library version: 1.02.77 (2012-10-15) Driver version: 4.23.0 and have the following targets for device mapper: # dmsetup targets snapshot-merge v1.1.0 snapshot-origin v1.7.1 snapshot v1.10.0 zero v1.0.0 striped v1.5.0 linear v1.1.0 error v1.0.1 According to what I could find, this feature has been available since version 2.02.89 and is enabled with the compile time option of --with-thin=internal, but doesn't appear to be enabled in the Arch package. Am I correct or does something need to be configured on my machine? Thank you Squall -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N https://github.com/headmastersqual <http://twitter.com/headmastersqual>l

3 3

[arch-general] Virtualbox hosting qemu-kvm guests
by Steve P. 21 Nov '12

21 Nov '12

Hi This is my first posting so bear with me. I am trying to get qemu-kvm to work inside Virtualbox, but when I try to #modprobe the kvm-intel or kvm_intel module, it errors stating that operation is not permitted. Is qemu known to run inside virtualbox? The host hardware is an i7 that supports hardware virtualization fine. I have qemu running natively on the same box so it is confusing, but want to use VB also. Thanks in advance.

4 3

[arch-general] Unofficial Repository Guidelines
by Jesus Alvarez 21 Nov '12

21 Nov '12

Hey everyone, There are no guidelines on the wiki for creating and distributing unofficial repositories. The tools make this feature incredibly easy to implement, but with that power comes great responsibility, and I am a bit confused. It would be nice to have a set of guidelines for creating and distributing unofficial repositories on the wiki. The reason I ask this is because I created two signed repositories for some packages I maintain, zfs and netflix-desktop. They do have usage, and in my forum posts, people seem to really appreciate the availability of the repo. However, I am not a TU, so my keys are not signed by any of the master keys. I don't want to contribute to a bad habit of not checking package sources before installing something from some repo. When I brought the topic up in #archlinux, there was some concern I was using a repo and not solely relying on AUR. I did my best to provide lots of information to people, like the complete sources and lots of information about myself and the packages so people are comfortable adding my key to their keyring. But I am a very thorough person, so doing this is natural. Others won't be so willing to do the work. So what is the general consensus regarding unofficial repositories? Thanks, demizer

4 6

[arch-general] pacman optional package messages on update
by mike cloaked 20 Nov '12

20 Nov '12

Recently there have been some (slightly) confusing output lines running pacman -Syu. This evening I see: New optional dependencies for logrotate cron: scheduled log rotation However: [root@lapmike3 ~]# pacman -Q cron error: package 'cron' was not found But of course: [root@lapmike3 ~]# pacman -Q cronie cronie 1.4.8-3 So presumably I do not need to try to pacman -S cron !! Similarly the other day there was an optional dependency of python3 when in fact presumably the package name is "python" but happens to be version 3? (which for me was already installed) Just a point for clarification - especially for new users who may be a bit confused by the output and take inappropriate action as a result! -- mike c

3 2

Re: [arch-general] Gentoo udev fork w/o systemd
by Thomas Bächler 20 Nov '12

20 Nov '12

I started replying, and then the post got way too long and I stopped. As you simply ignored most of what I said, I'll just quote most of this for reference and not reply to it (it is a funny read, after all). It is really pointless to keep arguing, because you won't see reason anyway (and frankly, I won't either). Look at the bottom for one thing I will actually reply to. Am 20.11.2012 14:35, schrieb Felipe Contreras: > On Tue, Nov 20, 2012 at 1:46 PM, Thomas Bächler <thomas(a)archlinux.org> wrote: >> Am 20.11.2012 12:00, schrieb Felipe Contreras: >>> Thomas Bächler wrote: >>>> Am 20.11.2012 01:07, schrieb Kevin Chadwick: >>>>> Odd, my take was that the main goal was trying to bring back a >>>>> separate /usr. >>>> >>>> They believe that the problem is that udev refuses to work with /usr not >>>> mounted. They also believe the problem to be "solved" by just removing >>>> the test. They do not even remotely understand why separate /usr is >>>> broken, >>> >>> This is not true. It might be broken for *some* setups, but not all. >>> >>> Do you want me to point to the mails where Gentoo developers explain how >>> a separate /usr works perfectly fine in *their* setup? >> >> As a Linux distributor, you want to have a setup that works for all of >> your users. > > Gentoo is not your traditional distributor, read about it. > >> And in fact, I remember receiving many bug reports that library A and >> binary B needed to be in / instead of /usr. You'd end up patching >> Makefiles and moving files around, creating new bugs because you missed >> something. It was a workload that was not worth the gain at all. > > That is up to Gentoo developers to decide, and they will do so in a months time. > >> So you cannot simply consider what is needed for _your_ setup, but what >> is needed for _all_ setups. > > Yes I can. It is *my* setup. > > If by _you_, you meant Gentoo developers, then read about Gentoo. They > don't dictate what all their users should do. > >> In addition, some bugs that occur are very subtle, so an ignorant >> developer may not even notice them, and thus consider them non-existent. > > Yes, all software has those. > >>> This is a hasty generalization fallacy; because a separate /usr is >>> broken in some cases, doesn't mean it's broken in all cases. >> >> If it's broken in any supported setup, it can be considered broken. You >> need to think globally - thinking about your single computer is >> ignorant, and you should not be developing a Linux distribution with >> such thinking. > > If you don't think Gentoo should exist, that's your choice. Gentoo > does exist however, and what they do is up to them. > >>> Since Gentoo is all about choice, a package like udev should not break >>> the setups that are already working. >> >> That's Gentoo's problem. They refuse to do the right thing and mount >> /usr before switching from initramfs to real root. > > Not all users use initramfs. What to do is the users' choice. > >>>> and that "fixing" this problem eventually results in installing >>>> everything to / and leaving /usr mostly empty. >>> >>> Wrong. Only the things that are needed at early boot, which are not that >>> many. >> >> And this is where you are wrong. Udev launches programs any time (in >> particular, on early boot) because certain devices appear. In the >> future, this will be done for more programs, not less. And every time >> such a rule is added, you need to move another program from /usr to /, >> because someone will report it as a bug. > > Really? How many? > % grep 'IMPORT{program}' -r /usr/lib/udev/rules.d | sed -e > 's/^.*${program}=$"$\S\+$.*"/\2/' | sort | uniq | wc -l > 18 > > 18 is a lot? > > And no, udev doesn't trigger these programs just because the devices > appear. It depends on the kind of device. All the udisks rules for > example are not triggered until the user is logged in. Plus rules have > conditions they have to meet. > > And ultimately Gentoo has full control over the rules. If upstream > adds a rule that has a program that doesn't work with separate /usr, > they can just remove it until it's fixed. > >> Now, you could rewrite udev to ignore those events and execute them >> later when /usr is mounted. The question you need to ask yourself is >> this: What is the gain, and what is the cost? The cost: udev becomes >> much more complex because it needs to store failed events and retry them >> later, which may lead to many more internal problems. This is a very >> high cost in terms of maintenance and code over-complication. > > That's for Gentoo developers to decide. > >> What is the gain? You support a separation between / and /usr which >> serves no technical purpose and is not well-defined. So you do lots of >> work for nothing - when you just could have made sure everything is >> mounted and accessible before switching to the real root (which is easy >> to do, compared to everything I described above). > > Up to Gentoo developers to decide. > >>>> They also "fixed" udev by removing blkid support, although util-linux >>>> deprecated the "blkid -o udev" option a while ago. >>> >>> And you think util-links is the only one that provides blkid? >>> >>> What's this that I see in the corner of my eye? >>> >>> http://git.busybox.net/busybox/tree/util-linux/blkid.c >>> >>> That's right, and alternative implementation of blkid. >> >> What you see in the corner of your eye is an implementation of blkid that >> a) is often behind the util-linux implementation when new file systems >> appear. > > Irrelevant. > >> b) never supported 'blkid -o udev', which udev relied on before it >> linked to libblkid. > > Maybe they will. How hard could it be? > >> So, unless eudev reintroduces libblkid support, it will rely on >> util-linux versions older than 2.23, because that's when the >> udev-compatible output will be gone. > > It's right there: > https://github.com/gentoo/eudev/commit/31040610c959a9f12d0df9f28fa3566fc0bc… > > Why are you worrying about potential problems with util-linux versions > older than 2.23, which is not even released yet on code that is only a > few days old, hasn't had a single release yet, hasn't even been > announced, and yet already fixed the problem? > >> This is another indication of how little these guys know about what's >> going on in the Linux ecosystem. > > Or how little you know about what they are actually doing. > > You are just looking for reasons to complain. What do you gain by that? > >>>> The general consensus seems to be that they have no idea what they are >>>> doing (see the statements of Greg K-H or Kay Sievers on the topic). >>> >>> Oh, I wasn't aware that Greg K-H and Kay Sievers were the holders of The >>> Truth. >> >> They are just two of the people who know what's going on and have dealt >> with these topics for years. In contrast to the eudev people, they >> understand the problems and why particular choices were made. > > Kay is the reason why udev is an awful piece of code. Greg hasn't > touched udev in years. "Awful piece of code" demands some proof. > And if you put so much emphasis on what these guys say, what about this guy? Yes, the eudev people keep bringing this up. In fact, this post is about a bug that they did not even mention in their posts, that has since been fixed (with an extra 2 lines), and that they didn't do anything about. But let's take it apart. >> Kay, you are so full of sh*t that it's not funny. Yes, Linus loves to insult people. We all know that. >> You're refusing to >> acknowledge your bugs, you refuse to fix them even when a patch is sent to >> you, and then you make excuses for the fact that we have to work around your >> bugs, and say that we should have done so from the very beginning. What Linus completely ignores is that Kay sent a mail to the LKML about the changes long before they hit any major distributions (execpt Arch) - and nobody spoke against them. Linus didn't even reply to the thread. So suddenly, 9 months later, what didn't even deserve his attention before is now a big problem - and it even got "fixed" after he spoke. Kay did nothing wrong here, he communicated his changed openly. >> but quite frankly, I am leery of the fact that the udev maintenance seems to >> have gone into some "crazy mode" where they have made changes that were known >> to be problematic, and are pure and utter stupidity. Oh yes, Linus likes to generalize when he is ranting. This was about this single change, he didn't give examples of any others. And as I said, the change was clearly communicated when it was made (many many months before the thread you referenced). >> We are apparently better off trying to avoid udev like the plague. Doing >> something very similar to this for module loading is probably a good idea >> too. More insults with no technical justification. Linus' "rant mode" is something you need to read with lots of care. > Linus Torvalds: > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4975… > > Or are you interested in the opinions of prominent developers only > when they fit your world-view? I am interested in opinions when they are founded on a technical basis. Linus often likes to rant, and most of the time he is right when he does. In this case, there was only one technical argument - most of the people that quote this post (press, eudev maintainers, ...) don't even know what this was about in the first place (do you?). They merely read the insults around it and believe Linus is right, because he is Linus. This whole issue has long been settled, and yet they use it as an argument against Kay and his maintainership of udev.

1 0

Re: [arch-general] Gentoo udev fork w/o systemd
by Thomas Bächler 20 Nov '12

20 Nov '12

Am 20.11.2012 12:00, schrieb Felipe Contreras: > Thomas Bächler wrote: >> Am 20.11.2012 01:07, schrieb Kevin Chadwick: >>> Odd, my take was that the main goal was trying to bring back a >>> separate /usr. >> >> They believe that the problem is that udev refuses to work with /usr not >> mounted. They also believe the problem to be "solved" by just removing >> the test. They do not even remotely understand why separate /usr is >> broken, > > This is not true. It might be broken for *some* setups, but not all. > > Do you want me to point to the mails where Gentoo developers explain how > a separate /usr works perfectly fine in *their* setup? As a Linux distributor, you want to have a setup that works for all of your users. And in fact, I remember receiving many bug reports that library A and binary B needed to be in / instead of /usr. You'd end up patching Makefiles and moving files around, creating new bugs because you missed something. It was a workload that was not worth the gain at all. So you cannot simply consider what is needed for _your_ setup, but what is needed for _all_ setups. In addition, some bugs that occur are very subtle, so an ignorant developer may not even notice them, and thus consider them non-existent. > This is a hasty generalization fallacy; because a separate /usr is > broken in some cases, doesn't mean it's broken in all cases. If it's broken in any supported setup, it can be considered broken. You need to think globally - thinking about your single computer is ignorant, and you should not be developing a Linux distribution with such thinking. > Since Gentoo is all about choice, a package like udev should not break > the setups that are already working. That's Gentoo's problem. They refuse to do the right thing and mount /usr before switching from initramfs to real root. >> and that "fixing" this problem eventually results in installing >> everything to / and leaving /usr mostly empty. > > Wrong. Only the things that are needed at early boot, which are not that > many. And this is where you are wrong. Udev launches programs any time (in particular, on early boot) because certain devices appear. In the future, this will be done for more programs, not less. And every time such a rule is added, you need to move another program from /usr to /, because someone will report it as a bug. Now, you could rewrite udev to ignore those events and execute them later when /usr is mounted. The question you need to ask yourself is this: What is the gain, and what is the cost? The cost: udev becomes much more complex because it needs to store failed events and retry them later, which may lead to many more internal problems. This is a very high cost in terms of maintenance and code over-complication. What is the gain? You support a separation between / and /usr which serves no technical purpose and is not well-defined. So you do lots of work for nothing - when you just could have made sure everything is mounted and accessible before switching to the real root (which is easy to do, compared to everything I described above). >> They also "fixed" udev by removing blkid support, although util-linux >> deprecated the "blkid -o udev" option a while ago. > > And you think util-links is the only one that provides blkid? > > What's this that I see in the corner of my eye? > > http://git.busybox.net/busybox/tree/util-linux/blkid.c > > That's right, and alternative implementation of blkid. What you see in the corner of your eye is an implementation of blkid that a) is often behind the util-linux implementation when new file systems appear. b) never supported 'blkid -o udev', which udev relied on before it linked to libblkid. So, unless eudev reintroduces libblkid support, it will rely on util-linux versions older than 2.23, because that's when the udev-compatible output will be gone. This is another indication of how little these guys know about what's going on in the Linux ecosystem. >> The general consensus seems to be that they have no idea what they are >> doing (see the statements of Greg K-H or Kay Sievers on the topic). > > Oh, I wasn't aware that Greg K-H and Kay Sievers were the holders of The > Truth. They are just two of the people who know what's going on and have dealt with these topics for years. In contrast to the eudev people, they understand the problems and why particular choices were made.

1 0

[arch-general] Pulseaudio update - mpd now refuses to play as same user
by Oon-Ee Ng 20 Nov '12

20 Nov '12

Hi, Pulseaudio from [testing] just updated to 2.99.2-1, now mpd audio output (running mpd as my own user) fails with the following:- Nov 19 14:45 : output: Failed to enable "MPD Pulse Output" [pulse]: pa_context_connect() has failed: Connection refused Nov 19 14:45 : player_thread: problems opening audio device while playing "PointBreak-StandTough.mp3" Setting up pulseaudio to listen on TCP locally as in the wiki works, but I never needed to do that before. Can anyone else verify this? Is it perhaps logind related (worked fine before this last pulseaudio update)?

8 10

[arch-general] A systemd-logind shutdown issue
by Leonid Isaev 19 Nov '12

19 Nov '12

Hi, On all my installations with systemd I am seeing strange errors in journal/syslog on shutdown. For simplicity, I use "systemctl poweroff" w/o X. The error is either ---------------- Nov 18 16:37:26 bluemoon login: pam_systemd(login:session): Failed to connect to system bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ---------------- or ---------------- Nov 13 18:00:02 bluemoon systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE Nov 13 18:00:02 bluemoon systemd[1]: Stopped Login Service. Nov 13 18:00:02 bluemoon systemd[1]: Unit systemd-logind.service entered failed state ---------------- I can only achieve "clean" shutdown if all users are logged out and the power button is pressed. Somehow, if I simply stop/start systemd-logind.service it restarts cleanly. So there seems to be a race on shutdown between systemd-logind and something else (login?). I have seen similar problems on the web, but noone seems to care... Any idea how I can get more info about/debug this? TIA PS: And yes, the above error occurs independently of the value of KillUserProcesses. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

1 0

[arch-general] community repository and old versions of updated packages
by Jens Arm 19 Nov '12

19 Nov '12

Hi ArchLinux-Team For some months now I'm using ArchLinux (i686) and I like it much. I use a local package mirror which I sometimes update using rsync. Since about 2 weeks I found out that old package versions of updated packages in the community repository not get deleted anymore. core and extra is OK. Here an example of e.g. filezilla which gets last updated on 19.11: ./ArchLinux/community/os/i686/filezilla-3.5.3-1-i686.pkg.tar.xz ./ArchLinux/community/os/i686/filezilla-3.5.3-1-i686.pkg.tar.xz.sig ./ArchLinux/community/os/i686/filezilla-3.6.0-1-i686.pkg.tar.xz ./ArchLinux/community/os/i686/filezilla-3.6.0-1-i686.pkg.tar.xz.sig ./ArchLinux/community/os/i686/filezilla-3.6.0.1-1-i686.pkg.tar.xz ./ArchLinux/community/os/i686/filezilla-3.6.0.1-1-i686.pkg.tar.xz.sig Is this known or a bug? regards Jens

2 1

[arch-general] netbeans freeze
by Arno Gaboury 19 Nov '12

19 Nov '12

Dear list, I recently started a Java certification and installed netbeans. I experience a lot of few seconds freezes, with the CPU up to 100%. These issues arrise even when I am not building neither running any code. My system is usually working very well and has enough CPU to build anything in a very short time (kernels, ROM...). Is there any settings in netbeans or Arch I missed? Any idea where could this comes from? It is really annoying, especially for a Java newbie wich find it very difficult to write even the smallest code :-( TY for help.

3 2