RFH: maintenance of porter chroots
Hello all, DSA routinely gets requests to install/remove/etc packages in the various porter chroots. We also maintain the chroots themselves, doing routine cleanups, upgrades, reporting bugs in packages that hose chroots, etc. We're looking for interested porters to take on this work. We feel you are better placed to be a point of contact for people having trouble with their packages on your architecture of choice, and we'd like to give you access to work on blockers without having to waste time going through the round trip time of requesting things from us. We'd like a named list of people who will look after each set of architecture chroots. Assuming we get a list for each architecture, we'll be back in touch to discuss specifics of handover and so on. (If I've missed any porter lists that would be interested in being copied on this, apologies and please forward it on) Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#573940: coreutils: rm -r doesn't work on kfreebsd-i386
* Petr Salinger , 2010-03-18, 19:05:
Also, it might be interesting that:
- Despite fstatat() being not detected at configure time, rm uses
the __fxstatat symbol.
This seems to be the key point.
The FreeBSD 7.x kernel does not have the *at syscalls, only limited
emulation is available in our glibc in this case.
Under 8.x kernel *at syscalls are native and are used directly,
we have runtime detection in our glibc.
As we still want to support both kernel versions (7.x and 8.x) for
now, all *at syscalls are marked as stubs in glibc (see i.e.
). Therefore the coreutils (and any gnulib user)
should not use them at all.
Unfortunately the *stat{,at} functions are in glibc implemented via
*xstat{,at} and the *stat{,at} functions are inline's which calls
*xstat{,at},
see * on any glibc system :-(
I think this issue could be worked around, though in a ugly way.
Wouldn't the attached patch do the trick? (Sorry, no time to test it
properly myself.)
--
Jakub Wilk
diff -Nru coreutils-8.4/lib/fstatat.c coreutils-8.4/lib/fstatat.c
--- coreutils-8.4/lib/fstatat.c 2010-01-04 16:19:05.0 +
+++ coreutils-8.4/lib/fstatat.c 2010-03-18 19:21:08.0 +
@@ -107,4 +107,15 @@
# undef AT_FUNC_POST_FILE_PARAM_DECLS
# undef AT_FUNC_POST_FILE_ARGS
+#ifdef __FreeBSD_kernel__
+
+int __fxstatat(int version, int fd, const char *file, struct stat *st, int flag)
+{
+ typedef int (*tp)(int, const char *, struct stat *, int);
+ volatile tp f = fstatat;
+ return f(fd, file, st, flag);
+}
+
+#endif
+
#endif /* !HAVE_FSTATAT */
Re: Bug#565801: src:firebird2.5: FTBFS on kfreebsd-amd64
Hello. > Hi Petr, ( I read debian-bsd, so no need to CC me explicitly,) > Program received signal ?, Unknown signal. > 0x0008019347d7 in __pthread_sigsuspend () from /lib/libpthread.so.0 ... > I posted this to upstream devel list[1] and they responded: > > At the first glance this looks like broken kFreebsd/amd64. Yes, the failure is in our side, we still have to teach gdb somehow, that thread handling is the same as in linuxthreads (pre-NPTL) implementation, see #550361. Unfortunately it requires deep knowledge of gdb, which no-one porter have :-( > How likely does it seem to you that the problem is in threading stuff > on kfreebsd/amd64? We have problem in threaded gdb support, but it does not seems we have general problem with threads. The implementation is the same on both kfreebsd-i386 and kfreebsd-amd64. Take a look on my ktrace: 45835 gbak_static CALL flock(0xa,LOCK_UN) 45835 gbak_static RET flock 0 45835 gbak_static CALL close(0xa) It seems normal - unlock file and close file 45835 gbak_static CALL close(0xa) 45835 gbak_static RET close -1 errno 9 Bad file descriptor And this is strange - close again the same file, which have been closed two syscalls above ? Do you have idea about differences between firebird2.1 (builds fine) and firebird2.5 (FTBFS) ? Petr -- 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/47866.5751.8620-13244-1104627347-1268938...@seznam.cz
Re: Bug#573940: coreutils: rm -r doesn't work on kfreebsd-i386
Hi all,
to provide better picture I slightly played with order of lines from original
message.
I'd like to draw your attention to this coreutils bug, which happens to
trigger on kFreeBSD 7:
| $ mkdir -p a/b/{c,d}
| $ rm -Rf a/
| rm: cannot remove `a/b': Operation not permitted
Also, it might be interesting that:
- Despite fstatat() being not detected at configure time, rm uses the
__fxstatat symbol.
This seems to be the key point.
The FreeBSD 7.x kernel does not have the *at syscalls, only limited
emulation is available in our glibc in this case.
Under 8.x kernel *at syscalls are native and are used directly,
we have runtime detection in our glibc.
As we still want to support both kernel versions (7.x and 8.x) for now,
all *at syscalls are marked as stubs in glibc (see i.e. ).
Therefore the coreutils (and any gnulib user) should not use them at all.
Unfortunately the *stat{,at} functions are in glibc implemented via
*xstat{,at} and the *stat{,at} functions are inline's which calls *xstat{,at},
see * on any glibc system :-(
The "rm" ended up using the glibc one's even iff they are marked as stubs :-(.
The "rm" part of coreutils have been rewritten in 8.x series
and the gnulib replacement are not used.
Also, it might be interesting that:
- The problem goes away if coreutils is compiled with -O0.
The inline-ing does not happen in this case and the used fstatat()
comes from gnulib, i.e. no native ENOSYS call ...
My not entirely fruitful debugging showed that something icky happens in
line 75 of src/remove.c:
if (st->st_size == -1 && fstatat (fd, file, st, flag) != 0)
The relevant part of ktrace output, which does make no sense at all to
me, is:
For the code under it see
http://svn.debian.org/wsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/fxstatat.c
| 2676 rm CALL __sysctl(0xbfbfe628,0x4,0,0xbfbfe638,0,0)
| 2676 rm RET __sysctl 0
| 2676 rm CALL __sysctl(0xbfbfe628,0x4,0xbfbfdce0,0xbfbfe638,0,0)
| 2676 rm RET __sysctl 0
| 2676 rm CALL lstat(0xbfbfe5a8,0xbfbfdc50)
| 2676 rm NAMI "-/b"
| 2676 rm RET lstat -1 errno 2 No such file or directory
(Note, that it's "-/b", not "a/b".)
I am unsure what can be done about it.
Ideally, we could just switch to kfreebsd-8 only, but just now we have problem
with build
of some big packages (namely gcc-4.3) under kfreebsd-8.
So far it looks like race condition in scheduler/memory manager/pagedaemon/...,
so It is rather hard to give an estimate of time to solve the kfreebsd-8
problem.
Well, dot zero is dot zero :-(
Sorry
Petr
--
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/47856.5899.9621-7887-1631988740-1268935...@seznam.cz
Re: Booting broken with debian-installer
On Thu, Mar 18, 2010 at 06:23:19PM +0100, Philipp Kern wrote: > -amd64 daily instead hangs on boot at: > "Setting up filesystem, please wait ... > GEOM_LABEL: Label ufsid/4ba211726b8b4567 removed." That one can be solved by activating the IO-APIC, fwiw. Kind regards, Philipp Kern -- 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/20100318172743.ga11...@kelgar.0x539.de
Re: Booting broken with debian-installer
Hi, On Thu, Mar 18, 2010 at 05:45:14PM +0100, Philipp Kern wrote: > it seems that something broke between the daily images 20100306-1120 > and 20100307-1120. grub spits out "error: only ELF kernel supports > module.". That means booting the installer is broken with 0307 onwards. further testing revealed: this only affects kfreebsd-i386, not the -amd64 flavour, at least not in the daily image. (0312 was likewise broken.) kfreebsd-i386's 20100306 also aborts with "Configuring bootstrap-base failed with error code 1." during installation. -amd64 daily instead hangs on boot at: "Setting up filesystem, please wait ... GEOM_LABEL: Label ufsid/4ba211726b8b4567 removed." That's all with VirtualBox, too. Kind regards, Philipp Kern -- 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/20100318172319.ga10...@kelgar.0x539.de
Booting broken with debian-installer
Hi there, it seems that something broke between the daily images 20100306-1120 and 20100307-1120. grub spits out "error: only ELF kernel supports module.". That means booting the installer is broken with 0307 onwards. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Bug#565801: src:firebird2.5: FTBFS on kfreebsd-amd64
Hi Petr, I have some movement to report. -=| Petr Salinger, Tue, Feb 02, 2010 at 07:46:44PM +0100 |=- >> >> firebird2.5 2.5.0.25784~ReleaseCandidate1.ds2-6 behaved the same: >>../gen/firebird/bin/gbak_static -MODE read_only -R >>../builds/misc/help.gbak ../gen/firebird/help/help.fdb >>make[3]: *** [../gen/firebird/help/help.fdb] Segmentation fault >>(core dumped) >> >> ˙˙ and built fine on asdfasdf.debian.net. Is it possible to get the >> core dump? Maybe looking into it can sched some light. > > Yes and no. > > Line 472 is call to "dbb_functions(*p)" > > #3 0x005248b6 in Database (this=0x843d5fe28, p=0x843d52020) at > ../src/jrd/../jrd/../jrd/Database.h:472 Thanks for looking! The next upstream release candidate now reliably fails on kfreebsf/amd64 (and builds fine on /i386). The stacktrace is (obtained on asdfasdf.d.n): == (gdb) run -MODE read_only -R ../builds/misc/help.gbak ../gen/firebird/help/help.fdb Starting program: /home/dmn/firebird2.5-2.5.0.25920~ReleaseCandidate2.ds2/gen/firebird/bin/gbak_static -MODE read_only -R ../builds/misc/help.gbak ../gen/firebird/help/help.fdb Program received signal ?, Unknown signal. 0x0008019347d7 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) bt #0 0x0008019347d7 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0x000801933668 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x0008019346e0 in pthread_create@@GLIBC_2.3 () from /lib/libpthread.so.0 #3 0x0063d1a8 in ThreadStart::start ( routine=0x462a72 , arg=0x0, priority_arg=, thd_id=0x800a456a0) at ../src/jrd/ThreadStart.cpp:171 #4 0x0063d29d in gds__thread_start (entrypoint=0x7fffa4d0, arg=0x1f, priority=0, thd_id=0x94016030) at ../src/jrd/ThreadStart.cpp:73 #5 0x00454ad6 in CtrlCHandler (this=0x7fffa940, primary=0x0) at ../src/jrd/why.cpp:1004 #6 GlobalPtr (this=0x7fffa940, primary=0x0) at ../src/jrd/../common/classes/init.h:127 #7 YEntry (this=0x7fffa940, primary=0x0) at ../src/jrd/why.cpp:1036 #8 0x004610d7 in isc_attach_database ( user_status=, file_length=0, file_name=0x0, public_handle=0x0, dpb_length=24624, dpb=0x0) at ../src/jrd/why.cpp:1373 #9 0x0042f083 in open_files (uSvc=0x800a457a8) at ../src/burp/burp.cpp:1905 #10 gbak (uSvc=0x800a457a8) at ../src/burp/burp.cpp:1062 #11 0x004320c2 in main (argc=, ---Type to continue, or q to quit--- argv=) at ../src/burp/burpMain.cpp:47 = I posted this to upstream devel list[1] and they responded: [1] http://sourceforge.net/mailarchive/forum.php?thread_name=20100309131707.GF3666%40ktnx.net&forum_name=firebird-devel > At the first glance this looks like broken kFreebsd/amd64. This is > the first thread, started by us (it happens is yValve in > CtrlCHandler, in ctor of static instance of this class). Started > thread does nothing except wait for posix semaphore. How did Unknown > signal arriave here - absolutely no idea. > > PS. On freebsd/amd64 I have successfull build. How likely does it seem to you that the problem is in threading stuff on kfreebsd/amd64? Maybe they are right, or maybe my patches[2] adding support to kfreebsd are not quite right. [2] http://git.debian.org/?p=pkg-firebird/2.5.git;a=tree;f=debian/patches;hb=HEAD fix-kfreebsd_hurd-detection, freebsd_targets, install_freebsd_as_linux, maybe also optional_posix_fadv Thank you for your (and anyone else's) help on this! The bug is quite important for the release as the reverse dependencies include such things as php5 and qt4-x11 :| signature.asc Description: Digital signature
Re: integrating Debian GNU/kFreeBSD into InstallingDebianOn?
On Thu, Mar 18, 2010 at 03:13:53PM +0700, Paul Wise wrote: > On Thu, 2010-03-18 at 08:58 +0100, Alan BRASLAU wrote: > > > Concerning povray, I had forgotten (or did not realize) > > that it is non-free. I am aware that there are some > > licensing issues with the beta version, but did not > > imagine that the stable version was anything other than > > open source... > > povray releases source code, but has never been free software. There was > a plan to rectify that for povray 4 by relicensing stuff where possible > and rewriting the rest of the code. Last I saw the povray folks haven't > released 3.7, Yes, but they are working on it. All new code must be released under GPL3+, and 3.7 has seen a semi-rewrite of some core bits from C to C++. Last I checked those bits were buggy as hell though, so I guess that's why they haven't released it yet. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- 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/20100318112004.gb27...@celtic.nixsys.be
Re: integrating Debian GNU/kFreeBSD into InstallingDebianOn?
On Thu, 2010-03-18 at 08:58 +0100, Alan BRASLAU wrote: > Concerning povray, I had forgotten (or did not realize) > that it is non-free. I am aware that there are some > licensing issues with the beta version, but did not > imagine that the stable version was anything other than > open source... povray releases source code, but has never been free software. There was a plan to rectify that for povray 4 by relicensing stuff where possible and rewriting the rest of the code. Last I saw the povray folks haven't released 3.7, let alone started on povray 4. > By the way, another hitch for the moment is a need to port openjdk-6. > Is anyone working on this? From Google it appears there are some people doing that, but none that I can see for Debian GNU/kFreeBSD. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part
Re: integrating Debian GNU/kFreeBSD into InstallingDebianOn?
Hello Debian developers and others, My intention was/is to be constructive in providing some feedback on kfreebsd from a user's point of view. Concerning povray, I had forgotten (or did not realize) that it is non-free. I am aware that there are some licensing issues with the beta version, but did not imagine that the stable version was anything other than open source... On Thursday 18 March 2010 00:22:02 Wouter Verhelst wrote: > > > (at least until konsole gets fixed, as I find it awkward > > to revert to using xterm...). > > urxvt ftw! > I should probably revert to vtwm as well! > Note that unstable is a development system; it is not unexpected that > things break there every once in a while. > > As long as they are fixed before the release (and with the freeze, that > is very much doable), I don't think there's anything wrong with that. > Of course, "unstable" is, well..., unstable (as the name indicates!) I hope that all of the major problems do get rapidly fixed. By the way, another hitch for the moment is a need to port openjdk-6. Is anyone working on this? Alan -- 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/201003180858.17426.alan.bras...@cea.fr
