Re: [arch-general] [signoff] lvm2/device-mapper 2.02.82-1
Excerpts from Thomas Bächler's message of So Jan 30 21:45:28 +0100 2011: Am 27.01.2011 14:30, schrieb Thomas Bächler: Am 27.01.2011 11:35, schrieb Jan Spakula: This is weird. I think lvm2 is supposed to wait for udev to finish creating all links before returning. Inserting a 'sleep 1' or '/sbin/udevadm settle' in rc.sysinit after the vgchange call should fix this, but it shouldn't be necessary. Inserting 'sleep 1' after 'activate_vgs' (new initscripts) does indeed save the day. I don't know how to figure out why in my case lvm2 doesn't wait for udev... Any suggestions for further testing welcome. I thought so. (I guess this issue stays the same in the new initscripts.) I suppose this must be a bug in the device-mapper - the udev integration is supposed to wait for symlink creation before returning. Could you try with the device-mapper and lvm2 packages from here? This should fix your problem. Thanks. https://dev.archlinux.org/~thomas/lvm_fix/ I booted a couple of times with your packages and the problem didn't show up yet (without 'sleep 1' of course). Btw I do have udisks installed. Thanks!
Re: [arch-general] [signoff] lvm2/device-mapper 2.02.82-1
Excerpts from Thomas Bächler's message of Mi Jan 26 16:29:43 +0100 2011: Am 26.01.2011 11:38, schrieb Eric Bélanger: On Wed, Jan 26, 2011 at 3:33 AM, Jan Spakula bende...@archlinux.us wrote: Excerpts from Eric Bélanger's message of Mi Jan 26 05:16:44 +0100 2011: lvm2/device-mapper 2.02.82-1 are in testing for minor upstream update. Please test and signoff. Users signoffs are welcome. Hi, I have problems with both 2.02.81 and 2.02.82: I have encrypted root (normal partition) + some extra encrypted partitions on lvm via crypttab. The ones in crypttab don't unlock, the error message is something along the lines of ... /dev/vg/swap doesn't exist or access denied (it gets overwritten immediately, so I don't see the beginning of the message). This is right after lvm2 hook is run. Then a bit later in the emergency shell, the /dev/vg/* links are already there; so perhaps there's some extra delay until the symlinks are created in /dev/ with the newer lvm2? This is weird. I think lvm2 is supposed to wait for udev to finish creating all links before returning. Inserting a 'sleep 1' or '/sbin/udevadm settle' in rc.sysinit after the vgchange call should fix this, but it shouldn't be necessary. Inserting 'sleep 1' after 'activate_vgs' (new initscripts) does indeed save the day. I don't know how to figure out why in my case lvm2 doesn't wait for udev... Any suggestions for further testing welcome.
Re: [arch-general] [RFT] initscripts 2011.01-1
Excerpts from Thomas Bächler's message of Mi Jan 26 18:34:22 +0100 2011: Okay, this has been sitting in git for a lng time, and I am throwing it out there. This should receive lots of testing, as there has been major rewriting done. We need to make sure there are no regressions. It should also fix a small number of bugs. snip Rewrite /etc/crypttab processing. I've found a small issue coming from this: the fourth column (options) in /etc/crypttab used to mean everything beginning with the 4th column to the end of the line, apparently now it is required to put the whole expression within ... For instance I have some parameters in the SWAP line, I had to change the line swap /dev/vg/swap SWAP -c aes-xts-plain -h sha256 -s 256 to swap /dev/vg/swap SWAP -c aes-xts-plain -h sha256 -s 256 In the first case, the cryptsetup call during sysinit fails, since only '-c' was used as a parameter and the call 'cryptsetup -d /dev/urandom -c create ...' didn't make sense to cryptsetup. Another slight annoyance comes from the lines (from rc.sysinit) # isLuks only gives an exit code but no output to # stdout or stderr. if $CS isLuks $2; then open=luksOpen a=$2 b=$1 fi It's not true that there's no output; I get the message Device /dev/vg/swap is not a valid LUKS device. every time I boot :) Do you want me to file a bug?
Re: [arch-general] [RFT] initscripts 2011.01-1
Excerpts from Thomas Bächler's message of Do Jan 27 14:04:12 +0100 2011: Am 27.01.2011 11:50, schrieb Jan Spakula: Excerpts from Thomas Bächler's message of Mi Jan 26 18:34:22 +0100 2011: https://projects.archlinux.org/initscripts.git/commit/?id=c1f38e1186a60a2d63947881d2879c22fc375da4 https://projects.archlinux.org/initscripts.git/commit/?id=f4703f832e6d8578c52dd8a71b9bf34894fe3d34 Please try these two trivial patches. They should fix your issues (revert your crypttab back to the previous format). Yep, these solve the issues. Thanks and sorry the hassle. Jan
Re: [arch-general] [RFT] initscripts 2011.01-1
Excerpts from Heiko Baums's message of Do Jan 27 14:23:25 +0100 2011: Am Thu, 27 Jan 2011 11:50:31 +0100 schrieb Jan Spakula bende...@archlinux.us: Another slight annoyance comes from the lines (from rc.sysinit) # isLuks only gives an exit code but no output to # stdout or stderr. if $CS isLuks $2; then open=luksOpen a=$2 b=$1 fi It's not true that there's no output; I get the message Device /dev/vg/swap is not a valid LUKS device. every time I boot :) But this is the output on the console. For those if clauses you need a boolean (true or false resp. 0 or 1) and this is not given by cryptsetup isLuks. This value is only given as an exit code. So this part of the script is absolutely correct and the only way to handle this. I like clause with exit codes much better that any funky checking for a message ;) I was addressing the comment in the script that it ..gives no output; silently suggesting to explicitly silence the cryptsetup call, so that no unnecessary messages are displayed during booting. Jan
Re: [arch-general] X fails to start with intel card after latest kernel update
Excerpts from David C. Rankin's message of So Okt 11 10:16:57 +0200 2009: On Sunday 11 October 2009 03:10:15 am David C. Rankin wrote: I'm back already. The wiki page must be out of date. It says to put the following in modprobe.conf (which is deprecated): options i915 modeset=1 Now what?? Put it in /etc/modprobe.d/modprobe.conf (that's where I have it).
Re: [arch-general] LaTeX problems ?
Excerpts from Piyush P Kurur's message of Mo Aug 31 14:48:03 +0200 2009: complaint was that they are not in the correct format. So I guess the following needs to be done. 1) Add libpoppler as a dependency to latex you are right about this. 2) recompile libpoppler with latest gcc which ever it is. this is what I don't understand: you write they are not in the correct format - who is they? which program complains? It's possibly the issue that's come up on the forums: if you get something like: --- This is TeX, Version Fatal format file error; I'm stymied --- then you need to run 'updmap --all' (as the user you get this error with). Alternatively, you can delete the user's local texlive generated formats 'rm ~/.texlive/texmf-var/web2c/*.fmt' (then the system-wide generated formats will be used, and they do get regenerated automatically on upgrade).
Re: [arch-general] LaTeX problems ?
Excerpts from Christian Himpel's message of Mo Aug 31 15:32:48 +0200 2009: On Mon, Aug 31, 2009 at 15:22, Jan Spakulajan.spak...@gmx.com wrote: Excerpts from Piyush P Kurur's message of Mo Aug 31 14:48:03 +0200 2009: It's possibly the issue that's come up on the forums: if you get something like: --- This is TeX, Version Fatal format file error; I'm stymied --- then you need to run 'updmap --all' (as the user you get this error with). Alternatively, you can delete the user's local texlive generated formats 'rm ~/.texlive/texmf-var/web2c/*.fmt' (then the system-wide generated formats will be used, and they do get regenerated automatically on upgrade). i think it's 'fmtutil --all' instead of 'updmap --all'. you could also run 'fmtutil-sys --all' as root to recreate the system-wide format files. Eh, of course it's fmtutil. Sorry. However the point is that 'fmtutil-sys --all' *does* get run automatically on texlive upgrade, but if the user has generated the formats themselves at some point, these formats are preferred by texlive regardless of system changes. So the user need to regenerate or delete the local format files.
Re: [arch-general] vi from testing has gone nuts - does not honor virc/~.virc settings
Excerpts from Loui Chang's message of Mo Jun 22 16:41:41 +0200 2009: Is there a way for him to try the new 'dmraid' without going the whole way and migrating to [testing]. This would also be useful for him (and me) to know. Pretty simple. Enable testing, install dmraid, disable testing. Then your testing is limited to those packages only. While this works fine most of the time, when you run into problems and ask about it here or on the forums, the first thing that people tell you is: you should either use [testing] all the way or not at all, since any particular package in [testing] might crucially depend in some other packages in [testing], and they don't get updated when you only update one particular package. Anyway, I still think it's a good idea to search the MLs and forums before asking for help here. Big chances are someone has already noticed/the change was announced in the dev ML.
Re: [arch-general] [arch-dev-public] Kill old gcc versions
Excerpts from Baho Utot's message of Mo Jun 15 03:14:10 +0200 2009: I can do thatif you can stand all the bug reports :) I hope you understand that the problem is with upstream (if the package won't compile because the source is not standards compliant), so it should be reported there and not on arch's bugtracker.
Re: [arch-general] Openbox - great lightweight desktop, similar to icewm, but better in several regards
Excerpts from Andrei Thorp's message of Mi Jun 10 23:02:39 +0200 2009: - Xmonad and Awesome are both initally based on DWM, though both of them now have almost none of that original code left due to it being not actually that great (plus the wms changed a lot) Just to crush the urban myth that gets mentioned more than it should be recently: xmonad is not based on dwm. Yes, the idea of what should it do came from dwm, but it was written from scratch (in haskell, no C code ever).
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Excerpts from Attila's message of Fr Mai 29 17:42:23 +0200 2009: And still again i suggest to take a look at other distros where daemons get restarted without a problem during a upgrade procedure. Sorry, but i find this rule of don't restart during the upgrade a little bit academically.-) For me it's about 'expectations'. I expect a package manager to manage packages (unpack a new one over the old one in a sensible manner) and don't expect it to decide what's best for me in terms of what's running or not. I still find it 100% better to *let me know* that config might have changed (pacman does this automatically) and that something might need to be done if, say, I run this and that daemon. Don't run it for me. And if you absolutely have to, *let me know*. -- Jan
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Excerpts from ludovic coues's message of Do Mai 28 17:09:52 +0200 2009: A solution in pacman, getting rid of user adding in .install script, can allow security like asking user to confirm creation of group and user. This would be a secure way of doing thing, and users/admin would be aware of new user/group. I don't get how is adding/removing users/groups from pacman directly safer then doing the same from the install script. How about just *informing* the user what's happening in the install script? Then there would be no 'unexpected behavior'.
Re: [arch-general] Laptop Install - 2 questions remain, WPA and Compiz with Radeon Driver
Excerpts from David C. Rankin, J.D.,P.E.'s message of So Mai 03 12:11:04 +0200
2009:
(1) My laptop has an Atheros card and is happily using the madwifi driver.
The
only problem is that I'm starting it manually and need to know where to put
the pieces to have it start automatically. Basically, it takes 3 commands to
get my wifi going:
ESSID=${1:-skyline}
IFACE=${2:-wlan0}
iwconfig ${IFACE} essid ${ESSID}
wpa_supplicant -i${IFACE} -Dwext -c/etc/wpa_supplicant.conf -d -B
/var/log/wpa_start.log 21
sleep 2 # This doesn't count as a command
dhcpcd wlan0
My question is Where do I put this stuff to make it happen when I start
Arch??
Install the netcfg package, create a profile under /etc/network.d (there are
some examples, so you shouldn't have any problem), and edit /etc/rc.conf: add
the name of your profile into NETWORKS=(...) and add 'net-profiles' to your
DAEMONS.
-- Jan
Re: [arch-general] Bug reports for out of date packages?
Excerpts from hollunder's message of Di Apr 07 13:35:20 +0200 2009: On Tue, 7 Apr 2009 10:41:00 +0200 ludovic coues cou...@gmail.com wrote: I suppose that some maintainer are not looking as often as some people from the arch's community want to there package. Couldn't be multiple maintainer for package ? Some of us (archaudio people) wished that was possible in AUR as well, simple because it happens that some maintainer is not available for some time. This is one reason for our upcoming binary repo, but I'd personally rather stick with AUR. So yeah, is something like this possible for any of the repos? You can do what the arch-haskell group has done: create a new user: archaudio, adopt all the packages that you want to be shared, and share the password :)
[arch-general] fortune-mod packages
I've noticed that all fortune-mod packages (except fortune-mod itself) have been removed from extra (by Eric). Do you plan on uploading them to AUR, or should I just grab PKGBUILDs from svn and upload them myself if I'm interested on maintaining some of them? Thanks, Jan
Re: [arch-general] udev-139 and file permissions of /dev/net/tun
Excerpts from Attila's message of Di Mär 10 18:51:15 +0100 2009: Hi, i use a script to prepare a bridged network for a kvm session and therefore i have this line in /etc/udev/rules.d/01-attila.rules: KERNEL==tun, NAME=net/%k, MODE=0660, GROUP=network After upgrading udev my file permissions of the new persistent /dev/net/tun looks so after booting up: crw-rw-rw- 1 root root 10, 200 8. Mär 00:43 /dev/net/tun I play with this lines in /etc/udev/permissions.d/00-my.permissions: a) tun:root:network:0660 b) net/tun:root:network:0660 I reboot even after changing the line but there is no change. If i do a modprobe tun there be the right permissions: crw-rw 1 root network 10, 200 8. Mär 00:43 /dev/net/tun So my questions is how and/or where can i control the file permissions of the persistent devices from the new udev? This is definitly not bad, i want more to know what i have overseen.-) See you, Attila This reminds of a problem Dusty had and discussed on forums: http://bbs.archlinux.org/viewtopic.php?id=60060 Result: the device node was created before the rule was applied. So maybe ... ? Good luck, Jan
Re: [arch-general] [PATCHES] About /var/run/ and /var/lock/ checks in daemons
Excerpts from Jan de Groot's message of Thu Feb 12 08:59:41 +0100 2009: On Thu, 2009-02-12 at 05:51 -0200, Gerardo Exequiel Pozzi wrote: I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple purge function for these directories at rc.sysinit step. In my case this is just for fun!, but other users can be benefited by this, for example netbook users. If this requires patching so many packages, and given the fact that /var/run on tmpfs is not default in archlinux, maybe you should try building /var/run from an initial directory or something like that. This is also what I use for my OpenBSD router which runs from compactflash and has /var mounted on ramdisk. I have a setup on my netbook where the whole /var is mounted as tmpfs and rsynced from and to real directory (/var-sync in my case) on boot/shutdown. Patches to rc.sysinit and rc.shutdown follow. [Note that whenever you update initscripts, you need to patch at least rc.shutdown before rebooting :)]
Re: [arch-general] Tool to stop and start services? (Don't Panic)
Excerpts from ert256's message of Thu May 22 10:18:48 -0500 2008: I found that some time ago, but i don't use this. http://aur.archlinux.org/packages.php?ID=16966 This is not quite compatible with arch's initscripts. You'd need to rewrite (or at least rearrange) pretty much all the initscripts supplied with arch's packages, if you'd want to use this for the usual services. -- Jan
[arch-general] texlive (again?)
Hello Archers, I want to bring up the TeX distributions issue. Current status: - tetex in extra: unmaintained (upstream) though still usable, some parts are already getting outdated (pdftex, some latex packages); - texlive in community: firmicus keeps it pretty up to date, the dist itself is actively developed. Proposal: Switch to texlive eventually officially (for now keeping tex-related pkgs in community). How it can be done: - from the dev side: 1) officially announce that the switch *is* going to happen. 2) move tetex and all packages depending on it from extra to community (that's only: kile, latex2html, lyx, texmacs) (the trouble is that these makedep on tetex: evince, kdegraphics, yodl; but maybe just keep tetex on the build machine for a time being?) - from TUs: 3) gradually replace tetex deps by texlive deps in community packages - from users: 4) gradually replace tetex deps in AUR by texlive Comments: - 3) and 4) don't need to happen instantly - we'll just have 2 tex dists at the same level in community for a while - note that none of the above programs link anything against tetex, they just need working tex compiler (which texlive definitely provides), so they don't even need to be recompiled - the official statement is important, so that we can nag maintainers to change dependencies ;) - there's been on/off-going discussion about this on the forums (http://bbs.archlinux.org/viewtopic.php?pid=358172 - tomk has said Regarding the possibility of bringing texlive into the official repos, there are currently two missing ingredients among the existing dev team: interest and time. AFAIK none of us is a habitual tex user, and that would be the first requirement. - so this proposal asks for the opposite: bring the so far official tetex down to community, to level it out with texlive and make the switch powered by the users possible.) What do *you* think? PS. Sorry for the long e-mail (about 15-times longer than I usually write). -- Jan Spakula
