120403 2006-01-26 04:09 0000 coreutils-5.93 & autofs 2006-05-30 09:45:27 0000 1 1 1 Unclassified Gentoo Linux Core system 2005.1 All Linux RESOLVED FIXED QAcanfix P2 critical --- 1 andrej.filipcic@ijs.si net-fs@gentoo.org boda2004@mail.ru dopey@moonteeth.com exien.ow@gmail.com grobian@gentoo.org haubi@gentoo.org jfilling@gmail.com langthang@gentoo.org manuel@mclure.org massimilianoadamo@yahoo.it qa@gentoo.org robbat2@gentoo.org rphillips@gentoo.org stevee@gorbag.com t4bs@internode.on.net zzam@gentoo.org andrej.filipcic@ijs.si 2006-01-26 04:09:40 0000 sort +POS1 does not work anymore with cureutils-5.93. POSIX or bug? Anyway, /etc/autofs/auto.net from autofs needs a patch: --- auto.net.org 2005-11-08 19:49:54.000000000 +0100 +++ auto.net 2006-01-26 13:08:25.824136932 +0100 @@ -22,7 +22,7 @@ # Newer distributions get this right SHOWMOUNT="/usr/sbin/showmount --no-headers -e $key" -$SHOWMOUNT | LC_ALL=C sort +0 | \ +$SHOWMOUNT | LC_ALL=C sort | \ awk -v key="$key" -v opts="$opts" -- ' BEGIN { ORS=""; first=1 } { if (first) { print opts; first=0 }; print " \\\n\t" $1, key ":" $1 } vapier@gentoo.org 2006-01-26 10:41:22 0000 most likely it's POSIX rearing it's "helpful" head andrej.filipcic@ijs.si 2006-01-29 01:33:28 0000 Created an attachment (id=78396) autofs patch this patch is in fedora devel to fix sort in autofs manuel@mclure.org 2006-04-11 18:39:06 0000 *** Bug 129642 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-04-12 00:47:07 0000 *** Bug 129644 has been marked as a duplicate of this bug. *** grobian@gentoo.org 2006-04-12 01:11:59 0000 coreutils 5.93 has been stabled without this patch to autofs. Most likely more systems running "stable" will be broken now. Please patch/bump autofs stable to fix this. dopey@moonteeth.com 2006-04-12 12:58:41 0000 the fedora patch (-k 1) is more appropriate than dropping the +0 argument entirely (as in the original reporter's comment) as it results in the identical behavior as +0 did. Not that it REALLY matters what order the mount points are processed in though :) jakub@gentoo.org 2006-04-13 02:12:10 0000 *** Bug 129780 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-04-18 17:38:49 0000 *** Bug 130411 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-05-01 00:31:33 0000 *** Bug 131859 has been marked as a duplicate of this bug. *** langthang@gentoo.org 2006-05-12 10:14:39 0000 (In reply to comment #5) > coreutils 5.93 has been stabled without this patch to autofs. Most likely more > systems running "stable" will be broken now. Please patch/bump autofs stable > to fix this. > This bug isn't moving. QA, please do something about this. halcy0n@gentoo.org 2006-05-19 18:28:29 0000 rphillips, robbat2: can one of you please add this patch and bump the latest stable version? If there is no response in a week, I'll assume it is alright to add this, and I will bump it and add it. robbat2@gentoo.org 2006-05-19 19:14:39 0000 halcy0n: you can go ahead and commit it. I'm trying to work on the newer autofs stuff - which needs some major rewriting of the init script again :-(. halcy0n@gentoo.org 2006-05-19 20:43:37 0000 Fixed. Thanks Robin. grobian@gentoo.org 2006-05-23 00:55:05 0000 Bug is NOT fixed. The added patch only "fixes" the auto.net file that is installed in the samples. The real problem is the auto.net file that is installed from ${FILESDIR} into /etc/autofs/. This file still contains the sort +0. Please change auto.net in ${FILESDIR}, or use the one from the sources and rebump to really fix this annoying issue that still breaks stable systems. antarus@gentoo.org 2006-05-27 21:52:53 0000 Refixed jakub@gentoo.org 2006-05-29 03:03:13 0000 *** Bug 134741 has been marked as a duplicate of this bug. *** grobian@gentoo.org 2006-05-30 01:52:11 0000 this is really embarassing, but sorry... this fix again breaks a stable system: % sort +k 1 sort: open failed: +k: No such file or directory Not sure, but I think it should be "-k 1" which works fine. Since I am no member of any of the involved groups here, I don't like to commit a fix that works... but please, could someone fix this for real very quickly now? If you need a patch reviewal on a system (or three) that uses autofs, please send me mail, as I think it is clear that none of the committers actually could try the script out before committing. massimilianoadamo@yahoo.it 2006-05-30 02:04:46 0000 (In reply to comment #17) > this is really embarassing, but sorry... this fix again breaks a stable system: > > % sort +k 1 > sort: open failed: +k: No such file or directory > > Not sure, but I think it should be "-k 1" which works fine. well, we had to wait only few months before seeing the patch available, but not yet in the tree, with the huge change: sort -k 1 ????? antarus@gentoo.org 2006-05-30 08:02:05 0000 (In reply to comment #17) > this is really embarassing, but sorry... this fix again breaks a stable system: > > % sort +k 1 > sort: open failed: +k: No such file or directory > > Not sure, but I think it should be "-k 1" which works fine. Since I am no > member of any of the involved groups here, I don't like to commit a fix that > works... but please, could someone fix this for real very quickly now? If you > need a patch reviewal on a system (or three) that uses autofs, please send me > mail, as I think it is clear that none of the committers actually could try the > script out before committing. > No this was completely my fault, I even looked at the sort manpage before changing it! :/ jakub@gentoo.org 2006-05-30 09:45:27 0000 *** Bug 134929 has been marked as a duplicate of this bug. *** 78396 2006-01-29 01:33 0000 autofs patch autofs-4.1.4-fix-sort-opts.patch text/plain LS0tIGF1dG9mcy00LjEuNC9zYW1wbGVzL2F1dG8ubmV0Lm9yaWcJMjAwNS0xMS0wMyAxOToxNTox MC4wMDAwMDAwMDAgLTA1MDAKKysrIGF1dG9mcy00LjEuNC9zYW1wbGVzL2F1dG8ubmV0CTIwMDUt MTEtMDMgMTk6MTU6MTkuMDAwMDAwMDAwIC0wNTAwCkBAIC0zNyw3ICszNyw3IEBAIGRvbmUKICMg TmV3ZXIgZGlzdHJpYnV0aW9ucyBnZXQgdGhpcyByaWdodAogU0hPV01PVU5UPSIkU01OVCAtLW5v LWhlYWRlcnMgLWUgJGtleSIKIAotJFNIT1dNT1VOVCB8IExDX0FMTD1DIHNvcnQgKzAgfCBcCisk U0hPV01PVU5UIHwgTENfQUxMPUMgc29ydCAtayAxIHwgXAogCWF3ayAtdiBrZXk9IiRrZXkiIC12 IG9wdHM9IiRvcHRzIiAtLSAnCiAJQkVHSU4JeyBPUlM9IiI7IGZpcnN0PTEgfQogCQl7IGlmIChm aXJzdCkgeyBwcmludCBvcHRzOyBmaXJzdD0wIH07IHByaW50ICIgXFxcblx0IiAkMSwga2V5ICI6 IiAkMSB9Cg==