Re: schroot: mount: exec mount_nullfs not found: No such file or directory
Hi Robert, On 12/02/2012 22:24, Robert Millan wrote: If someone can confirm this fixes the problem, I could cherry-pick the execvP() fix from upstream, but that requires importing the whole execvP() implementation so I'd rather be sure it's what we need. Could someone please check if 044_mount_exec.diff is the culprit? Yes, it works without 044_mount_exec.diff ! FTR, during rebuild of freebsd-utils-9.0 without 044_mount_exec.diff, it FTBFS with an "error: redefinition of 'getvfsbyname'". It seems to come from getvfsbyname redefined debian/patches/tmp_glibc.diff. I think that debian/patches/tmp_glibc.diff should be dropped since 2.13-26 is in unstable now. But maybe I'm just plain wrong as I'm not following kfreebsd closely... Regards, -- Damien -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f384603.9030...@drazzib.com
Bug#659659: current version of ifconfig breaks D-I
Package: freebsd-net-tools-udeb Version: 9.0-1 Severity: grave udhcpc expects this to work, but it doesn't: $ sudo ifconfig xl0 inet 0.0.0.0 ifconfig: can't set link-level netmask or broadcast -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212214235.9915.6695.reportbug@thorin
Re: schroot: mount: exec mount_nullfs not found: No such file or directory
On 12/02/12 21:24, Robert Millan wrote: >> If anyone allows the use of sudo for /bin/mount, that should reset the >> environment to something sane, so they should not be at risk. > > Wouldn't it be better to fix the bug instead? Yes, of course... > ... I could cherry-pick the > execvP() fix from upstream, but that requires importing the whole > execvP() implementation so I'd rather be sure it's what we need. If it is easier, here is the older method used upstream before execvP and paths.h: http://svnweb.freebsd.org/base/head/sbin/mount/mount.c?r1=117030&r2=117031 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f383043.2010...@pyro.eu.org
Re: schroot: mount: exec mount_nullfs not found: No such file or directory
El 12 de febrer de 2012 21:19, Steven Chamberlain ha escrit: > I tested that /lib/freebsd/mount (for which /bin/mount is wrapper > script) does accept a user-specified PATH when looking for a helper to > execute. But fortunately it is not setuid (at least on my own Squeeze > installation). > > If anyone allows the use of sudo for /bin/mount, that should reset the > environment to something sane, so they should not be at risk. Wouldn't it be better to fix the bug instead? >> If this patch is the problem, we could use execvP() instead (like upstream >> did). > > I see that upstream previously searched /sbin then /usr/sbin, before > rewriting it to use execvP with _PATH_SYSPATH which is > "/rescue:/sbin:/usr/sbin". If someone can confirm this fixes the problem, I could cherry-pick the execvP() fix from upstream, but that requires importing the whole execvP() implementation so I'd rather be sure it's what we need. Could someone please check if 044_mount_exec.diff is the culprit? -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxprsx9fhrpjg43j0fssdcdkvq2bdgdx9+hwxfhmtcx...@mail.gmail.com
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 4:31 PM, Ævar Arnfjörð Bjarmason wrote: > Also what does it even mean that threads have pids? Can you kill(1) > threads individuall? Send signals to them that aren't sent to the > parent process etc? I'm getting mixed test results[1] from CPANTesters related to inter-thread signalling, despite all having the same OS version (8.1-1-686). Not sure I can explain what's going on (though it's not the only platform suffering from this). Leon [1]: http://matrix.cpantesters.org/?dist=threads-posix-0.002;reports=1;os=gnukfreebsd -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahhgv8grimh4wbs7yqtxvhvrtatqc6cfvphlmykfhh7bpad...@mail.gmail.com
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
El 12 de febrer de 2012 21:05, Leon Timmermans ha escrit: > I'm getting mixed test results[1] from CPANTesters related to > inter-thread signalling, despite all having the same OS version > (8.1-1-686). Not sure I can explain what's going on (though it's not > the only platform suffering from this). 8.1 is only kernel version, but the threads-have-pids "feature" is userland-dependant. I suggest you add distribution information to your matrix, you could obtain this with lsb_release command (present in most GNU derivatives). -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXO_H2QwFszus99==foyjfw4om6_+mbklhvv8y1phr0...@mail.gmail.com
Re: schroot: mount: exec mount_nullfs not found: No such file or directory
On 12/02/12 20:52, Robert Millan wrote: > I recently applied this patch in mount to support /usr/sbin helpers: > > http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-utils/debian/patches/044_mount_exec.diff?revision=4047&view=markup > > could you try rebuilding freebsd-utils without it? Hi, I tested that /lib/freebsd/mount (for which /bin/mount is wrapper script) does accept a user-specified PATH when looking for a helper to execute. But fortunately it is not setuid (at least on my own Squeeze installation). If anyone allows the use of sudo for /bin/mount, that should reset the environment to something sane, so they should not be at risk. > If this patch is the problem, we could use execvP() instead (like upstream > did). I see that upstream previously searched /sbin then /usr/sbin, before rewriting it to use execvP with _PATH_SYSPATH which is "/rescue:/sbin:/usr/sbin". Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f382cdb.40...@pyro.eu.org
Re: schroot: mount: exec mount_nullfs not found: No such file or directory
El 12 de febrer de 2012 20:15, Damien Raude-Morvan ha escrit: > Does anybody have a clue ? I recently applied this patch in mount to support /usr/sbin helpers: http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-utils/debian/patches/044_mount_exec.diff?revision=4047&view=markup could you try rebuilding freebsd-utils without it? If this patch is the problem, we could use execvP() instead (like upstream did). -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXPD_OjKTvpfwKtbjK+EegWLf=9daasdngyheohxd4f...@mail.gmail.com
Re: [buildd-tools-devel] Bug#650978: schroot: mount: exec mount_nullfs not found: No such file or directory
On Sun, Feb 12, 2012 at 09:15:00PM +0100, Damien Raude-Morvan wrote: > Hi BSD Porters, > > Since last December, I'm unable to use sbuild/schroot on an unstable box : > > ~# sbuild-update -ugdc unstable > E: 10mount: mount: exec mount_nullfs not found: No such file or directory > E: unstable-kfreebsd-amd64-sbuild-1329077042-35644: Chroot setup > failed: stage=setup-start > Chroot setup failed > Error setting up unstable chroot > Chroot setup failed at /usr/bin/sbuild-update line 166. > > FTR: > 1) I can manually mount -t nullfs via sudo > 2) I haven't made any change to PATH > 3) AFAIK, mount can't find its helper in /sbin/ > > This issue is tracked as #650978. > > Does anybody have a clue ? Well, I have a suspicion of the problem. 1) schroot setup scripts are run without a PATH being set. This has not been an issue to date for some reason; either this works on Linux and not BSD, or we were hitherto only using shell builtins or commands which didn't rely on PATH. This fix is fairly simple: we need to explicity set PATH in the environment before execing the setup scripts. 2) BSD mount is not using a sensible PATH to search for its helpers. If it's using the user PATH to search for its helpers, there might be security implication here, especially if it's SUID like on Linux. We can fix (1) in schroot fairly simply. (2) might need some investigation by the BSD porters. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212203250.gt8...@codelibre.net
Re: schroot: mount: exec mount_nullfs not found: No such file or directory
Hi, On 12/02/12 20:15, Damien Raude-Morvan wrote: > ~# sbuild-update -ugdc unstable At that shell, if you first run: ~# echo $PATH What is the actual output? I just wonder if /sbin is missing from PATH either before, or after, you run sbuild-update. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f3823eb.8010...@pyro.eu.org
schroot: mount: exec mount_nullfs not found: No such file or directory
Hi BSD Porters, Since last December, I'm unable to use sbuild/schroot on an unstable box : ~# sbuild-update -ugdc unstable E: 10mount: mount: exec mount_nullfs not found: No such file or directory E: unstable-kfreebsd-amd64-sbuild-1329077042-35644: Chroot setup failed: stage=setup-start Chroot setup failed Error setting up unstable chroot Chroot setup failed at /usr/bin/sbuild-update line 166. FTR: 1) I can manually mount -t nullfs via sudo 2) I haven't made any change to PATH 3) AFAIK, mount can't find its helper in /sbin/ This issue is tracked as #650978. Does anybody have a clue ? Regards, -- Damien -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f381dc4.8030...@drazzib.com
Re: freebsd-libs transition
El 12 de febrer de 2012 12:53, Adam D. Barratt ha escrit: > Looking at > http://release.debian.org/transitions/html/freebsd-libs.html , there are > several packages which build-depend on a -dev package produced by > freebsd-libs but don't have a run-time dependency; what's the situation > with them? argyll: libusbhid is used for a private libray known as libinst, which doesn't seem to be installed anywhere. kfreebsd-*: libsbuf-dev is needed for a build system component, which is not installed in kfreebsd package. libsdl1.2: It was built without usb support because configure probe failed, most likely due to breakage in kfreebsd-kernel-headers which isn't present anymore. With up-to-date sid configure probe succeeds but it FTBFS later due to API change (filed as #659615). zfsutils: gratuitous build-dependency (fixed in SVN). totem: gratuitous build-dependency (filed as #659622). colord: gratuitous build-dependency (filed as #659624). libimobiledevice gratuitous build-dependency (filed as #659625). libisoburn: gratuitous build-dependency (filed as #659621). -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caofdtxpe+zjthof7hssyua3qrjcgnkcah3qfky2br_xqbcs...@mail.gmail.com
Bug#659625: gratuitous Build-Depends on libusb2-dev
Package: libimobiledevice Version: 1.1.1-3 Severity: normal Tags: patch User: debian-bsd@lists.debian.org Usertags: kfreebsd libimobiledevice builds fine without libusb2-dev, it can be safely removed. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212161827.37103.52069.reportbug@thorin
Bug#659624: gratuitous Build-Depends on libusb2-dev
Package: colord Version: 0.1.16-2 Severity: normal Tags: patch User: debian-bsd@lists.debian.org Usertags: kfreebsd colord builds fine without libusb2-dev, it can be safely removed. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212161652.37012.71441.reportbug@thorin
Bug#659622: gratuitous Build-Depends on libcam-dev
Package: totem Version: 3.2.1-2 Severity: normal Tags: patch libcam is not needed (anymore?) to build totem. Build-Depends on libcam-dev can be removed. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212160647.14818.70075.reportbug@thorin
Bug#659621: gratuitous Build-Depends on libcam-dev
Package: libisoburn Version: 1.2.0-1 Severity: normal Tags: patch User: debian-bsd@lists.debian.org Usertags: kfreebsd Build-Depends on libcam-dev is not needed since it is only libburn which uses CAM directly. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash === modified file 'debian/control' --- debian/control 2012-02-12 15:39:42 + +++ debian/control 2012-02-12 16:02:00 + @@ -6,7 +6,6 @@ Uploaders: George Danchev = 8), libburn-dev (>= 1.2.0), libisofs-dev (>= 1.2.0), libreadline-dev, zlib1g-dev, libacl1-dev, libattr1-dev, libjte-dev, - libcam-dev [kfreebsd-any] Build-Depends-Indep: doxygen Standards-Version: 3.9.2 Homepage: http://libburnia-project.org
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 16:31, Ævar Arnfjörð Bjarmason wrote: > I obviously much prefer #1, and I don't think it would harm kFreeBSD > users, what do you think? Has the Debian GNU/kFreeBSD port had many > issues due to differences in getpid()/getppid() behavior? I've pushed a patch implementing #1 to a branch: http://perl5.git.perl.org/perl.git/commitdiff/8c442cc912aa -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacbzzx5afexa8e4kdjtncqx6hwcnnsd-j4vgmq4tbxahnbm...@mail.gmail.com
Bug#659615: FTBFS on kfreebsd-amd64
Package: libsdl1.2 Version: 1.2.15-1 Severity: serious Justification: fails to build (but built succesfully in the past) libsdl1.2 fails to build on up-to-date kfreebsd-amd64 sid: libtool: compile: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Iinclude -I../../include -D_GNU_SOURCE=1 -fvisibility=hidden -D_REENTRANT -DXTHREADS -I/usr/include/directfb -D_REENTRANT -I/usr/include/ -DHAVE_USBHID_H -DUSBHID_UCR_DATA -DUSBHID_NEW -D_REENTRANT -Wall -c ../../src/joystick/bsd/SDL_sysjoystick.c -fPIC -DPIC -o build/.libs/SDL_sysjoystick.o ../../src/joystick/bsd/SDL_sysjoystick.c: In function ?SDL_SYS_JoystickUpdate?: ../../src/joystick/bsd/SDL_sysjoystick.c:462:28: error: ?struct usb_gen_descriptor? has no member named ?ucr_data? ../../src/joystick/bsd/SDL_sysjoystick.c:486:30: error: ?struct usb_gen_descriptor? has no member named ?ucr_data? ../../src/joystick/bsd/SDL_sysjoystick.c:494:30: error: ?struct usb_gen_descriptor? has no member named ?ucr_data? ../../src/joystick/bsd/SDL_sysjoystick.c:502:30: error: ?struct usb_gen_descriptor? has no member named ?ucr_data? ../../src/joystick/bsd/SDL_sysjoystick.c: In function ?report_alloc?: ../../src/joystick/bsd/SDL_sysjoystick.c:585:48: error: ?struct usb_gen_descriptor? has no member named ?ucr_data? this appears to be due to API change in libusbhid. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 8.1-1-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=locale: no s?ha pogut establir LC_ALL al locale per defecte: El fitxer o directori no existeix UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212153358.25557.11301.reportbug@thorin
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 15:16, Robert Millan wrote:
> El 12 de febrer de 2012 12:42, Niko Tyni ha escrit:
>> [crossposted to the Debian GNU/kFreeBSD development list debian-bsd
>> and the Perl 5 development list perl5-porters ]
>
> Thanks for bringing this up.
>
>>> This is also a complete non-issue in practice these days, LinuxThreads
>>> was a Linux 2.4 thread implementation that nobody maintains
>>> anymore[2], all modern Linux distros use NPTL threads which don't
>>> suffer from this discrepancy.
>
> This is not correct. LinuxThreads is only obsolete on GNU/Linux, but
> it is maintained and used on GNU/kFreeBSD because, contrary to what
> its name would indicate, it's a reasonably portable pthread library
> with few kernel-specific dependencies.
I'll adjust the commit message to mention that.
>> Under POSIX threads the getpid() and getppid() functions return the
>> same values across multiple threads, i.e. threads don't have their own
>> PID's. This is not the case under the obsolete LinuxThreads where each
>> thread has a different PID, so getpid() and getppid() will return
>> different values across threads.
>
> The version of LinuxThreads used on GNU/kFreeBSD has been patched to
> use kFreeBSD (kernel of FreeBSD) thread primitives, and thus future
> releases of Debian GNU/kFreeBSD will no longer be affected by this
> problem.
>
> Debian "Squeeze" release *IS* affected, however. It'd be better if
> you could wait at least until there's a new release before breaking
> compatibility with Squeeze users.
With this patch on top this passes tests on my 6.0 kFreeBSD machine:
diff --git a/t/op/getpid.t b/t/op/getpid.t
index 67a0f90..7688240 100644
--- a/t/op/getpid.t
+++ b/t/op/getpid.t
@@ -30,7 +30,16 @@ my $ppid2 : shared = 0;
new threads( sub { ($pid2, $ppid2) = ($$, getppid()); } ) -> join();
-# If this breaks you're either running under LinuxThreads or your
-# system doesn't have POSIX thread semantics.
-is($pid, $pid2, 'getpid() in a thread is the same as in the parent');
-is($ppid, $ppid2, 'getppid() in a thread is the same as in the parent');
+# If this breaks you're either running under LinuxThreads (and we
+# haven't detected it) or your system doesn't have POSIX thread
+# semantics.
+if ($^O =~ /^(?:gnukfreebsd|linux)$/ and
+(my $linuxthreads = qx[getconf GNU_LIBPTHREAD_VERSION 2>&1])
=~ /linuxthreads/) {
+chomp $linuxthreads;
+diag "We're running under $^O with linuxthreads <$linuxthreads>";
+isnt($pid, $pid2, "getpid() in a thread is different from
the parent on this non-POSIX system");
+isnt($ppid, $ppid2, "getppid() in a thread is different from
the parent on this non-POSIX system");
+} else {
+is($pid, $pid2, 'getpid() in a thread is the same as in the parent');
+is($ppid, $ppid2, 'getppid() in a thread is the same as in
the parent');
+}
However the return values of $$ and getppid() in threads on kFreeBSD
with linuxthreads will of course be different. I think that's a
feature as pointed out in the original commit message.
So here's what we can do:
1. We can take this patch as-is with that fix above on top, which
means that it'll pass tests everywhere but on Linux 2.4 and
kFreeBSD 6.0 $$ and getppid() will reflect the OS's idea, not our
POSIX emulation.
2. I could munge it (urghl) so this whole thing tries to detect
linuxthreads, and if they're there we try to cache the pid, this
means however that on Linux 2.4 users running embedded
PerlInterpreter that they fork (with e.g. uWSGI) will run into
subtle issues on Linux 2.4 and kFreeBSD 6.0.
I think in practice the number of users that'lle be harmed by the
caching will outnumber those that are harmed because they're
writing multithreaded Perl programs and relying on this particular
feature.
3. We can revert the un-caching of $$ and made everyone suffer the
edge cases for the sake of linuxthreads.
I obviously much prefer #1, and I don't think it would harm kFreeBSD
users, what do you think? Has the Debian GNU/kFreeBSD port had many
issues due to differences in getpid()/getppid() behavior?
Also what does it even mean that threads have pids? Can you kill(1)
threads individuall? Send signals to them that aren't sent to the
parent process etc?
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cacbzzx6vxdwrh65oerzttgguxsrhsdx3dzttpcpgsdtnhc6...@mail.gmail.com
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 1:42 PM, Niko Tyni wrote: > I have no idea whether it's really LinuxThreads based or something > else, but please note that Debian GNU/kFreeBSD seems to be affected as > t/op/getpid.t started failing there with 0e21945565eb4664d84 (around > Perl 5.15.1). See [perl #96270]. That does make sense, NTPL has some firm demands on the kernel, LinuxThreads on kFreeBSD would be much easier to pull off. That might explain another threading related issue I got from CPAN Testers too (not related to pids though). Leon -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cahhgv8jfwzn9mwyugfpkvj+6ptgzrvm0anc5gx-re-128ks...@mail.gmail.com
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
El 12 de febrer de 2012 12:42, Niko Tyni ha escrit: > [crossposted to the Debian GNU/kFreeBSD development list debian-bsd > and the Perl 5 development list perl5-porters ] Thanks for bringing this up. >> This is also a complete non-issue in practice these days, LinuxThreads >> was a Linux 2.4 thread implementation that nobody maintains >> anymore[2], all modern Linux distros use NPTL threads which don't >> suffer from this discrepancy. This is not correct. LinuxThreads is only obsolete on GNU/Linux, but it is maintained and used on GNU/kFreeBSD because, contrary to what its name would indicate, it's a reasonably portable pthread library with few kernel-specific dependencies. However... > Under POSIX threads the getpid() and getppid() functions return the > same values across multiple threads, i.e. threads don't have their own > PID's. This is not the case under the obsolete LinuxThreads where each > thread has a different PID, so getpid() and getppid() will return > different values across threads. The version of LinuxThreads used on GNU/kFreeBSD has been patched to use kFreeBSD (kernel of FreeBSD) thread primitives, and thus future releases of Debian GNU/kFreeBSD will no longer be affected by this problem. Debian "Squeeze" release *IS* affected, however. It'd be better if you could wait at least until there's a new release before breaking compatibility with Squeeze users. HTH -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXPsjcMzpVbZ+Jv+bG9FnDz5Jqp3LSwK-=ntww5b2ta...@mail.gmail.com
Re: Bug#652575: rsyslog: /etc/init.d/rsyslog modifications for GNU/Hurd
On 12.02.2012 14:11, Michael Biebl wrote:
> Could you please check the attached rsyslog init script, if it works
> properly on hurd?
Sorry, attached the wrong version. Test this one.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#! /bin/sh
### BEGIN INIT INFO
# Provides: rsyslog
# Required-Start:$remote_fs $time
# Required-Stop: umountnfs $time
# X-Stop-After: sendsigs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: enhanced syslogd
# Description: Rsyslog is an enhanced multi-threaded syslogd.
#It is quite compatible to stock sysklogd and can be
#used as a drop-in replacement.
### END INIT INFO
#
# Author: Michael Biebl
#
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="enhanced syslogd"
NAME=rsyslog
RSYSLOGD=rsyslogd
RSYSLOGD_BIN=/usr/sbin/rsyslogd
RSYSLOGD_OPTIONS="-c5"
RSYSLOGD_PIDFILE=/var/run/rsyslogd.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$RSYSLOGD_BIN" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
# Define LSB log_* functions.
. /lib/lsb/init-functions
do_start()
{
DAEMON="$RSYSLOGD_BIN"
DAEMON_ARGS="$RSYSLOGD_OPTIONS"
PIDFILE="$RSYSLOGD_PIDFILE"
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# other if daemon could not be started or a failure occured
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --
$DAEMON_ARGS
}
do_stop()
{
DAEMON="$RSYSLOGD_BIN"
PIDFILE="$RSYSLOGD_PIDFILE"
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# other if daemon could not be stopped or a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE --exec $DAEMON
}
#
# Tell rsyslogd to close all open files
#
do_rotate() {
DAEMON="$RSYSLOGD_BIN"
PIDFILE="$RSYSLOGD_PIDFILE"
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE --exec
$DAEMON
}
create_xconsole() {
XCONSOLE=/dev/xconsole
if [ "$(uname -s)" != "Linux" ]; then
XCONSOLE=/run/xconsole
ln -sf $XCONSOLE /dev/xconsole
fi
if [ ! -e $XCONSOLE ]; then
mknod -m 640 $XCONSOLE p
chown root:adm $XCONSOLE
[ -x /sbin/restorecon ] && /sbin/restorecon $XCONSOLE
fi
}
sendsigs_omit() {
OMITDIR=/run/sendsigs.omit.d
mkdir -p $OMITDIR
ln -sf $RSYSLOGD_PIDFILE $OMITDIR/rsyslog
}
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$RSYSLOGD"
create_xconsole
do_start
case "$?" in
0) sendsigs_omit
log_end_msg 0 ;;
1) log_progress_msg "already started"
log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg "Stopping $DESC" "$RSYSLOGD"
do_stop
case "$?" in
0) log_end_msg 0 ;;
1) log_progress_msg "already stopped"
log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
rotate)
log_daemon_msg "Closing open files" "$RSYSLOGD"
do_rotate
log_end_msg $?
;;
restart|force-reload)
$0 stop
$0 start
;;
status)
status_of_proc -p $RSYSLOGD_PIDFILE $RSYSLOGD_BIN $RSYSLOGD && exit 0
|| exit $?
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|rotate|restart|force-reload|status}" >&2
exit 3
;;
esac
:
signature.asc
Description: OpenPGP digital signature
Re: Bug#652575: rsyslog: /etc/init.d/rsyslog modifications for GNU/Hurd
On 27.01.2012 10:18, Guillem Jover wrote:
>
>> * rsyslog should probably switch to use s-s-d --exec instead (why is
>>it using --name anyway? that option has always been more unreliable).
>
> Still pending.
So, I had another look at it. This seems to be a typical case of
copy&paste. The rsyslog init script is based on the skeleton file from
/etc/init.d/ which uses --name in stop.
Guillem, if --name is unreliable as you suggest, it might make sense to
update the skeleton file accordingly?
I guess I just use --exec everywhere, as I don't want to add further
arch specific checks.
>>> Also the creation of xconsole is disabled, since it does not work yet.
>>
>> Why does it not work?
>
> If it does not work then there might be a problem with named pipes?
>
I changed the logic a bit in create_xconsole()
Could you please check the attached rsyslog init script, if it works
properly on hurd?
Thanks,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
#! /bin/sh
### BEGIN INIT INFO
# Provides: rsyslog
# Required-Start:$remote_fs $time
# Required-Stop: umountnfs $time
# X-Stop-After: sendsigs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: enhanced syslogd
# Description: Rsyslog is an enhanced multi-threaded syslogd.
#It is quite compatible to stock sysklogd and can be
#used as a drop-in replacement.
### END INIT INFO
#
# Author: Michael Biebl
#
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="enhanced syslogd"
NAME=rsyslog
RSYSLOGD=rsyslogd
RSYSLOGD_BIN=/usr/sbin/rsyslogd
RSYSLOGD_OPTIONS="-c5"
RSYSLOGD_PIDFILE=/var/run/rsyslogd.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$RSYSLOGD_BIN" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
# Define LSB log_* functions.
. /lib/lsb/init-functions
do_start()
{
DAEMON="$RSYSLOGD_BIN"
DAEMON_ARGS="$RSYSLOGD_OPTIONS"
PIDFILE="$RSYSLOGD_PIDFILE"
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# other if daemon could not be started or a failure occured
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --
$DAEMON_ARGS
}
do_stop()
{
NAME="$RSYSLOGD"
PIDFILE="$RSYSLOGD_PIDFILE"
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# other if daemon could not be stopped or a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE --name $NAME
}
#
# Tell rsyslogd to close all open files
#
do_rotate() {
NAME="$RSYSLOGD"
PIDFILE="$RSYSLOGD_PIDFILE"
start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE --name
$NAME
}
create_xconsole() {
XCONSOLE=/dev/xconsole
if [ "$(uname -s)" = "GNU/kFreeBSD" ]; then
XCONSOLE=/var/run/xconsole
ln -sf $XCONSOLE /dev/xconsole
fi
if [ ! -e $XCONSOLE ]; then
mknod -m 640 $XCONSOLE p
chown root:adm $XCONSOLE
[ -x /sbin/restorecon ] && /sbin/restorecon $XCONSOLE
fi
}
sendsigs_omit() {
OMITDIR=/run/sendsigs.omit.d
mkdir -p $OMITDIR
ln -sf $RSYSLOGD_PIDFILE $OMITDIR/rsyslog
}
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$RSYSLOGD"
create_xconsole
do_start
case "$?" in
0) sendsigs_omit
log_end_msg 0 ;;
1) log_progress_msg "already started"
log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
stop)
log_daemon_msg "Stopping $DESC" "$RSYSLOGD"
do_stop
case "$?" in
0) log_end_msg 0 ;;
1) log_progress_msg "already stopped"
log_end_msg 0 ;;
*) log_end_msg 1 ;;
esac
;;
rotate)
log_daemon_msg "Closing open files" "$RSYSLOGD"
do_rotate
log_end_msg $?
;;
restart|force-reload)
$0 stop
$0 start
;;
status)
status_of_proc -p $RSYSLOGD_PIDFILE $RSYSLOGD_BIN $RSYSLOGD && exit 0
|| exit $?
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|rotate|restart|force-reload|status}" >&2
exit 3
;;
esac
:
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
[crossposted to the Debian GNU/kFreeBSD development list debian-bsd and the Perl 5 development list perl5-porters ] On Sat, Feb 11, 2012 at 07:57:43PM +, Ævar Arnfjörð Bjarmason wrote: > [This is a patch I've just committed to > avar/remove-linuxthreads-pid-caching) I'll be pushing it to blead > unless there are any sound objections to it] > > Under POSIX threads the getpid() and getppid() functions return the > same values across multiple threads, i.e. threads don't have their own > PID's. This is not the case under the obsolete LinuxThreads where each > thread has a different PID, so getpid() and getppid() will return > different values across threads. [...] > This is also a complete non-issue in practice these days, LinuxThreads > was a Linux 2.4 thread implementation that nobody maintains > anymore[2], all modern Linux distros use NPTL threads which don't > suffer from this discrepancy. [...] > We've already been failing the tests in t/op/getpid.t on these systems > that nobody apparently uses, just leave those tests in place as-is so > they'll start failing if perl ever runs on a system without POSIX > thread semantics. I have no idea whether it's really LinuxThreads based or something else, but please note that Debian GNU/kFreeBSD seems to be affected as t/op/getpid.t started failing there with 0e21945565eb4664d84 (around Perl 5.15.1). See [perl #96270]. > If this change is found to be unacceptable (i.e. we want to continue > to emulate POSIX thread semantics for the sake of LinuxThreads ) we > also need to revert v5.14.0-251-g0e21945, because currently we're only > emulating POSIX semantics for getppid(), not getpid(). I'm cc'ing the debian-bsd list, hopefully the porters can comment on this. http://www.debian.org/ports/kfreebsd-gnu/ http://www.nntp.perl.org/group/perl.perl5.porters/2012/02/msg183442.html https://rt.perl.org/rt3/Public/Bug/Display.html?id=96270 -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212124231.GA3786@madeleine.local.invalid
Re: freebsd-libs transition
On Sat, 2012-02-04 at 20:07 +, Adam D. Barratt wrote: > On Sat, 2012-02-04 at 20:00 +, Robert Millan wrote: > > Anyhow, is there something I can do to help at this point? Just let me > > know. > > Being prepared to handle any issues quickly when they come up, mainly. Looking at http://release.debian.org/transitions/html/freebsd-libs.html , there are several packages which build-depend on a -dev package produced by freebsd-libs but don't have a run-time dependency; what's the situation with them? Regards, Adam -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1329051221.27786.33.ca...@jacala.jungle.funky-badger.org
Re: Bug#651624: is zfs incompatible with the GNU Project ?
On 10.02.2012 03:00, Benjamin Kaduk wrote: On Thu, 9 Feb 2012, Hannes wrote: I was under the impression that the ZFS kernel code in FreeBSD is original work under the 2C-BSDL . At least the headers in /usr/src/sys/cddl/compat/opensolaris/kern give this impression. So only the userland code (lib and tools) is under CDDL. My impression was that there was a specific effort to implement a set of headers and in-kernel hooks as original work under the BSDL, that would be sufficient to allow a CDDL-licensed module to be loaded at runtime and still supply ZFS functionality. This way, the stock kernel that is shipped is entirely BSDL, but the existing bulk of the CDDL ZFS code can be used with only minimal changes for compatibility. /usr/src/sys/modules/zfs/Makefile is enlightening on where things come from, most notably /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/. These files have the CDDL header in them. Ah, ok. And since CDDL's copyleft is weak, it doesn't spread to the rest of the kernel, when distributed together, right? It may only not be distributed together with GPL-Modules, because those would spread their license, which they couldn't to the CDDL-Code? Did I get that right? I love copyright law :D Regards, Hannes -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f37a5b6.9070...@soulrebel.in-berlin.de
