Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On 17/01/2014 21:33, Michael Vogt wrote: I have a kfreebsd stable install in qemu now and can reproduce the bug with my git apt tree. It looks like the pty handling in pkgDpkgPM broke and the stdout of the dpkg inside the pty is closed/unavailable too early for some reason. I see: error writing to 'standard output': No such file or directory on the dpkg status-fd when running with apt-get install 2vcard -o Debug::pkgDPkgProgressReporting=true I haven't found the root cause of the issue yet unfortunately. As a workaround you can use the -o Dpkg::Use-Pty=False option, e.g.: # apt-get -o Dpkg::Use-Pty=False dist-upgrade Thank you. pty support in glibc was recently adjusted to use the new /dev/pts interface. Perhaps this might be related? -- 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/52daa587.9070...@debian.org
Re: Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On Sun, Jan 12, 2014 at 08:05:06PM +, Steven Chamberlain wrote: Control: tags -1 found apt/0.9.14.2 Indeed upgrading only libapt-pkg4.12 is enough to trigger this. [..] I bisected this and it it appears that c3045b is the one that introduced the problem. Looking closer it appears that I can not do ioctl(d-slave, TIOCSCTTY, 0) more than ones on freebsd without a new openpty() to get a new master pty (i.e. I can not use the slave fd again). I will do more digging into this issue. Cheers, Michael -- 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/20140118231653.GB10489@bod
Re: Bug#735097: empathy: Empathy 3.8 kfreebsd-amd64 can't open window conversation
On Fri, 17 Jan 2014 at 01:37:34 -0200, brunomaxi...@openmailbox.org wrote: Em 2014-01-15 13:20, Robert Millan escreveu: On 12/01/2014 19:21, Bruno Maximo e Melo wrote: I'm reporting this bug from Linux. When reporting a bug from a different machine, please set the Version pseudo-header to the right version, and attach or send the info collected by reportbug --template empathy on the machine that has the bug. Otherwise, we can't tell which versions of packages you have. I've marked this as not found in version 3.4.2.3-2+deb7u1 and found in version 3.8.4-3, based on you saying testing and Empathy 3.8. If your empathy package is older than 3.8.4-3, please upgrade to the current testing version before continuing. Please send the output of reportbug --template empathy on the kfreebsd testing machine, so we can see what its dependency versions are like. Empathy can't open window conversation in kfreebsd-amd64 testing. Look this video: http://media.libreplanetbr.org/u/dharc/m/embathy-bug-kfreebsd-amd64/ That video doesn't seem to exist any more. When you run it from the command-line, do you see any error messages? This help? ** (empathy:2384): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. It would be useful to see the debug log from running it as: EMPATHY_LOGFILE=empathy.log EMPATHY_DEBUG=all G_MESSAGES_DEBUG=all empathy If it gets far enough into startup, this log file might contain personal information (like your IM addresses or your friends' IM addresses) so please look at it before sending, and replace anything you don't want to be public with or something. After the warning message, does your shell go back to a shell prompt, or does the empathy process continue to run? If it goes back to a shell prompt, please try typing: echo $? and say what the output is. I'd expect either 0, 1 or something greater than 128. If it's greater than 128, it would be helpful if you could get a backtrace using gdb. See https://wiki.debian.org/HowToGetABacktrace. The short version is: $ sudo apt-get install gdb empathy-dbg libglib2.0-0-dbg libgtk-3-0-dbg \ libclutter-1.0-dbg libc6-dbg ... $ EMPATHY_LOGFILE=empathy.log EMPATHY_DEBUG=all G_MESSAGES_DEBUG=all \ gdb -batch -ex set logging on -ex run -ex 'thread apply bt full' \ -ex kill -ex quit /usr/bin/empathy That should produce logfiles empathy.log and gdb.txt - please send both. Robert, thanks for looking at this. I expect this might be something kFreeBSD-specific, so we'll probably need your help. Thanks, S -- 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/20140119000412.ga5...@reptile.pseudorandom.co.uk
Bug#734328: Bug#726248: Bug#734328: kfreebsd-kernel-headers: Don't ship sys/sdt.h here
Robert Millan r...@debian.org writes: What's wrong with Replaces: ? I proposed this in my last mail, but it went unanswered: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726248#105 I really don't see why you want us to remove legacy functionality from k-k-h. As far as I can see its presence doesn't stop you from providing an alternative and making other packages Build-Depend on it. Hmm, I must have thought this was covered well enough in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726248#110 But I guess that left out the detail that Replaces is supposed to be accompanied by Breaks (or Conflicts?), which is iirc due to the unpleasent consequences that occur if you remove the replacing package before the replaced package: the files are just gone. So, if you want to continue to make those files available, it's best if you split them off into their own, non-build-essential package, which systemtap-sdt-dev could safely conflict with, but dtrace could still explicitly use. And having a -dev package that conflicts with something in build-essential is a non-starter: besides the impracticality of replacing the *rest* of the kFreeBSD headers, the buildds are NOT smart enough to allow installing a package conflicting with/providing one in build-essential. (I belive this is deliberate.) As for the dtrace userland, we don't have it yet, but we're much closer. There's a ctfutils package, and latest versions of the kernel are built with CTF debug information and dtrace support now. I think that eventually we can have both implementations of SDT probes. Systemtap obviously has better integration with the GNU toolchain but DTrace will most likely have better kernel integration for us. I think there's room for both options and I think it's great to have this choice. So why remove the BSD version of sys/sdt.h? Better to provide users with two great tools than just one, don't you think? Yes, that would be nicest, though I'd hope that they could eventually agree to use (something like) Systemtap's NOP-ful representation[1] for probe points rather than having their own incompatible ABIs for overlapping APIs like they do now. [1]: https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- 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/87k3dwtnk6@naesten.dyndns.org
