Re: Bug#559980: aptitude: Totally broken on GNU/kFreeBSD

2009-12-10 Thread Aurelien Jarno
Robert Millan a écrit :
> Just an observation, not directly related to the bug report so leaving
> the BTS out of it:
> 
> On Tue, Dec 08, 2009 at 03:50:10AM +0100, Cyril Brulebois wrote:
>> It would be nice to
>> have a working d-i again ASAP
> 
> Since your bug prevents migration of aptitude to testing, I guess this means
> that making d-i images default to testing would resolve the "unable to 
> install"
> problem, leaving users with only a small "have to use cupt/apt instead of
> aptitude" inconvenience.
> 

This has been done yesterday, however the readlink bug in freebsd-utils
now prevents the image to boot correctly. freebsd-utils won't migrate
soon, as it depends on freebsd-libs which depends on kfreebsd-8, which
is not ready to migrate (RC bug).

I'll see with the release team if we can fix the bug through
testing-proposed-updates.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Bug#559980: aptitude: Totally broken on GNU/kFreeBSD

2009-12-09 Thread Robert Millan

Just an observation, not directly related to the bug report so leaving
the BTS out of it:

On Tue, Dec 08, 2009 at 03:50:10AM +0100, Cyril Brulebois wrote:
> It would be nice to
> have a working d-i again ASAP

Since your bug prevents migration of aptitude to testing, I guess this means
that making d-i images default to testing would resolve the "unable to install"
problem, leaving users with only a small "have to use cupt/apt instead of
aptitude" inconvenience.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#559980: aptitude: Totally broken on GNU/kFreeBSD

2009-12-07 Thread Cyril Brulebois
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 
| 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));