Re: Bug#559398: goffice0.4: FTBFS on GNU/kFreeBSD: headers/includes issues
Cyril Brulebois k...@debian.org (04/12/2009): | In file included from /usr/include/gtk-2.0/gtk/gtk.h:228, | from /usr/include/libglade-2.0/glade/glade-xml.h:26, | from ../../../goffice/gtk/goffice-gtk.h:23, | from ../../../goffice/gtk/goffice-gtk.c:22: | /usr/include/gtk-2.0/gtk/gtkitemfactory.h:47: warning: function declaration isn't a prototype | In file included from /usr/include/sys/stat.h:107, | from /usr/include/glib-2.0/glib/gstdio.h:26, | from ../../../goffice/gtk/goffice-gtk.c:32: | /usr/include/bits/stat.h:198: error: expected ')' before 'dev' | /usr/include/bits/stat.h:199: error: expected ')' before 'dev' | ../../../goffice/gtk/goffice-gtk.c: In function 'cb_parent_mapped': | ../../../goffice/gtk/goffice-gtk.c:210: warning: ISO C forbids passing argument 6 of 'g_signal_handlers_disconnect_matched' between function pointer and 'void *' | make[4]: *** [goffice-gtk.lo] Error 1 At first glance, it looks like it could be a bug in the headers since dev_t is declared through sys/types.h, which probably should be included prior to using it in a prototype. Heya here, it looks like this bug is still present in the latest upload of the kfreebsd headers. Maybe I should just open bugreports against the appropriate package instead of asking on the mailing list, it might help keeping track of possible bugs. And if I'm wrong and headers are fine, bugs could simply be closed? Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#559398: goffice0.4: FTBFS on GNU/kFreeBSD: headers/includes issues
| /usr/include/bits/stat.h:198: error: expected ')' before 'dev' | /usr/include/bits/stat.h:199: error: expected ')' before 'dev' it looks like this bug is still present in the latest upload of the kfreebsd headers. The bug is in our headers, but the header comes from libc0.1-dev, not kfreebsd-kernel-headers. It is pending - http://svn.debian.org/wsvn/glibc-bsd/?op=compcompare[]=...@2876compare[]=...@2877 http://svn.debian.org/wsvn/pkg-glibc/?op=compcompare[]=...@4023compare[]=...@4024 Maybe I should just open bugreports against the appropriate package instead of asking on the mailing list, it might help keeping track of possible bugs. And if I'm wrong and headers are fine, bugs could simply be closed? I expect more problems would be on our side, so it might be better for unclear cases to bother us and not the package maintainer. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#559398: goffice0.4: FTBFS on GNU/kFreeBSD: headers/includes issues
Petr Salinger petr.salin...@seznam.cz (07/12/2009): The bug is in our headers, but the header comes from libc0.1-dev, not kfreebsd-kernel-headers. Oh, indeed. I guess some bits of sleep might help… I expect more problems would be on our side, so it might be better for unclear cases to bother us and not the package maintainer. Makes sense, will do. Mraw, KiBi. signature.asc Description: Digital signature
Bug#559980: aptitude: Totally broken on GNU/kFreeBSD
Package: aptitude
Version: 0.6.1.3-3
Severity: serious
Tags: patch
Justification: Broken package manager, broken d-i, etc.
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi,
for quite a while, we've had broken GNU/kFreeBSD d-i images, users
complaining about installation being stuck at 1%. For quite a while too,
aptitude started not working at all on GNU/kFreeBSD (which I didn't
notice initially since I'm mainly using cupt on my porter box). So I
took some time to check various settings, and found out that with
current sid libraries, sid's aptitude wasn't working, while testing's
was.
Not working means, among other things:
- “aptitude update” doesn't do anything but waiting.
- “aptitude” alone cleans up the screen, and then does nothing at all.
So I started “bisecting” versions between testing (0.4.11.11-1) and
sid's, and determined that DEBIAN_aptitude_0.5.9rc2-1 was OK while
DEBIAN_aptitude_0.5.9rc3-1 was not. Looking at the log between both,
the changeset below sounded like a good candidate, so I used
DEBIAN_aptitude_0.5.9rc3-1 and reverted it, which gave me a working
aptitude. I then got back to sid's, applied the attached patch (which
acts as a revert, but only for GNU/kFreeBSD), and aptitude seems to be
working fine:
- “aptitude update” is alright.
- “aptitude install foo” is alright.
- “aptitude” and then:
* u-update
* U-upgrade
* C-changelog
are alright.
Changeset:
| $ hg log -r 3246 -p
| changeset: 3246:ebf77e8755f5
| parent: 3241:11f5f723d2c4
| user:Daniel Burrows dburr...@debian.org
| date:Wed Sep 23 08:58:29 2009 -0700
| summary: Block SIGWINCH by default to ensure that cwidget is able to
sigwait() on it. (Closes: #547212)
|
| diff -r 11f5f723d2c4 -r ebf77e8755f5 src/main.cc
| --- a/src/main.cc Sun Sep 13 09:05:49 2009 -0700
| +++ b/src/main.cc Wed Sep 23 08:58:29 2009 -0700
| @@ -502,6 +502,27 @@
|
| int main(int argc, char *argv[])
| {
| + // Block signals that we want to sigwait() on by default and put the
| + // signal mask into a known state. This ensures that unless threads
| + // deliberately ask for a signal, they don't get it, meaning that
| + // sigwait() should work as expected. (the alternative, blocking
| + // all signals, is troublesome: we would have to ensure that fatal
| + // signals and other things that shouldn't be blocked get removed)
| + //
| + // In particular, as of this writing, log4cxx doesn't ensure that
| + // its threads block signals, so cwidget won't be able to sigwait()
| + // on SIGWINCH. (cwidget is guilty of the same thing, but that
| + // doesn't cause problems for aptitude)
| + {
| +sigset_t mask;
| +
| +sigemptyset(mask);
| +
| +sigaddset(mask, SIGWINCH);
| +
| +sigprocmask(SIG_SETMASK, mask, NULL);
| + }
| +
|srandom(time(0));
|
|using namespace log4cxx;
I guess that even if the original changeset was meant to fix a bug, this
very bug can stay around on GNU/kFreeBSD until somebody proposes a
better solution than just disabling this codepath. It would be nice to
have a working d-i again ASAP (although I didn't build an image to
check, I already spent a long time building and building again aptitude,
and I'm not yet used to d-i image building); and even if that's not
sufficient, getting back a working aptitude would be nice.
Thanks for considering this quickly.
(I'm Cc-ing debian-bsd@, in case somebody has an idea about what's going
on exactly.)
Mraw,
KiBi.
--- a/src/main.cc
+++ b/src/main.cc
@@ -528,6 +528,9 @@ int main(int argc, char *argv[])
// its threads block signals, so cwidget won't be able to sigwait()
// on SIGWINCH. (cwidget is guilty of the same thing, but that
// doesn't cause problems for aptitude)
+ //
+ // Do not do that on GNU/kFreeBSD, that totally breaks aptitude:
+#if !defined(__GLIBC__)
{
sigset_t mask;
@@ -537,6 +540,7 @@ int main(int argc, char *argv[])
sigprocmask(SIG_SETMASK, mask, NULL);
}
+#endif
srandom(time(0));
Purpose driving kfreebsd?
Hey guys, I think it's awesome that you have done this, and that Debian is supporting it as official port. I was looking for FAQs and such, do you have any? Basically I want to learn about why as much as the technical what driving this port. I'd also love to see if anyone is interested in giving a techncial presentation in New York City on kfreebsd at a user group meeting in Q1 2010. If someone is available that would be great, otherwise, I plan to learn about kfreebsd and potentially give the preso myself. The target of the preso would be both Linux and BSD users. (And all interested parties). Basically I get the sense that most folks are like me, in that they know it exists, they just don't really know anyone who uses it, nor do they understand why someone would use it. (Over plain Debian or FreeBSD). Cheers, Brian -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
