Bug#625257: libnih1: uninstallable in sid
On Mon, May 2, 2011 at 1:07 PM, brian m. carlson sand...@crustytoothpaste.net wrote: libnih1 depends on libc6 ( 2.12). libc6 2.13 is now in unstable, rendering libnih1 uninstallable. I'm not sure why such a strict dependency would be needed, but perhaps a mention in the documentation why might be appropriate if it is. That strict dependency appears to come from libc itself; it's not a source dep. Scott
Bug#625257: Strict dependencies due to __abort_msg
If upstart crashes, a crash dump is most definitely saved. Upstart handles SIGSEGV by catching it and forking a child and unmasking that signal in the handler - this means it's an Upstart child process that actually crashes and dumps core while the parent waits for it to exit and reaps it. This is sufficient to ensure the core dump actually hits disk or appropriate core handler. Also Upstart's code makes heavy use of assert to catch errors, so you'd most definitely want these dumped to disk as well. Finally libnih actually declares this a weak link anyway, so the versioned dependency is not strictly necessary at all. I'll upload a rebuild now, and see if it's possible to override dpkg-shlibs - since it's perfectly happy if a libc update drops that symbol. Scott On Mon, May 2, 2011 at 2:37 PM, brian m. carlson sand...@crustytoothpaste.net wrote: I've done some more looking into this bug, and it seems the reason that the dependency is so strict is that libnih1 depends on the __abort_msg symbol, which, since it is GLIBC_PRIVATE, triggers a stricter dependency. I personally think that the inflexibility of the dependencies outweighs the usefulness of the nih_log_abort_message. upstart is the only binary package using libnih1 from a non-libnih source package, and if upstart crashes, well, no crash dump will be saved and no debuggers will be run. Take from that what you will. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Fri, 2009-03-20 at 00:40 +0100, Frans Pop wrote: I think my 2 cents are played out by now, so I'll drop things here. Maybe someone else will be willing to take up the batton. At least the issue is somewhat documented now. I'll inform others in Debian that the issue exists and fix things locally for my own use case. Doesn't Debian run depmod in the postinst of the kernel package - and iirc, again on boot anyway? In which case, you'd always have module files that match the version of depmod in the host environment not the build environment. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Fri, 2009-03-20 at 12:05 +0100, Marco d'Itri wrote: On Mar 20, Scott James Remnant sc...@canonical.com wrote: Doesn't Debian run depmod in the postinst of the kernel package - and iirc, again on boot anyway? Not anymore on boot, but I can't see why depmod should NOT being run when the kernel is installed. Me neither. The only file in /lib/modules/2.x.y-z (other than the modules) we include in the kernel packages is modules.order. The rest of the modules.* come by running depmod when the package is installed; we also update it when any further packages containing modules for that kernel are installed. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part
Bug#398488: libgecode7-dev should be libgecode8-dev to match SONAME
Package: gecode Severity: serious The source package as exists in Debian generates a libgecode8 binary package that contains, as one would expect, a libgecode.so.8 library. Yet the matching development binary package is named libgecode7-dev, while it contains a libgecode.so that links to libgecode.so.8 There's no mention of any specialness in the changelog, so I assume this is simply a case of forgetting to change the -dev package name? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368969: rounding error causes generation of invalid filesystems
Package: squashfs-tools
Version: 1:2.2r2-2ubuntu2
Severity: critical
Tags: patch
Justification: causes the kernel to PANIC on an attempt to read from the
generated filesystem (unrelated package to break); and vital indexes are
lost so data in the generated filesystem cannot be retrieved (data loss)
Attached is a patch to correct a rounding error in the generation of the
fragment table indexes of generated squashfs filesystems. If the number
of fragments divides evenly into the size of each fragment table chunk
then the code believes that there are 0 bytes available in the buffer
rather then 8192 bytes.
This results in code being unable to obtain the final part of the
fragment index, making the files inaccessible and due to insufficient
sanity checking in the kernel code, the kernel PANIC.
I've also sent this patch upstream, who has verified that it is correct
and there is indeed a bug here. Note that although the patch is against
2.2r2, the difference is small enough that it will apply successfully to
3.0
Scott
--
Scott James Remnant
[EMAIL PROTECTED]
diff -ruNp squashfs-2.2r2~/squashfs-tools/mksquashfs.c squashfs-2.2r2/squashfs-tools/mksquashfs.c
--- squashfs-2.2r2~/squashfs-tools/mksquashfs.c 2006-05-26 03:13:44.0 +0100
+++ squashfs-2.2r2/squashfs-tools/mksquashfs.c 2006-05-26 03:25:33.0 +0100
@@ -942,7 +942,7 @@ unsigned int write_fragment_table()
}
for(i = 0; i meta_blocks; i++) {
- int avail_bytes = i == meta_blocks - 1 ? frag_bytes % SQUASHFS_METADATA_SIZE : SQUASHFS_METADATA_SIZE;
+ int avail_bytes = i == meta_blocks - 1 ? frag_bytes - SQUASHFS_METADATA_SIZE * i : SQUASHFS_METADATA_SIZE;
c_byte = mangle(cbuffer + block_offset, buffer + i * SQUASHFS_METADATA_SIZE , avail_bytes, SQUASHFS_METADATA_SIZE, noF, 0);
if(!swap)
memcpy(cbuffer, c_byte, sizeof(unsigned short));
signature.asc
Description: This is a digitally signed message part
Bug#329468: Bug#322309: Debian woody dpkg no longer works with recent linux kernel.
On Mon, 2005-10-10 at 00:16 +0900, Junichi Uekawa wrote: dpkg in Debian woody (3.0) is broken by recent linux kernels; due to the following command changing behavior (mmap of zero-byte length): addr=mmap(NULL, 0, PROT_READ, MAP_SHARED, fd, 0); These bugs are caused by mmap changing behavior; it used to return NULL when given a length of 0. However, it now returns -1, and gives back an errno=EINVAL. Indeed. This was the sole change in the 1.13.8 release. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#317082: Not just a dpkg bug
reassign 317082 libc6-dev,dpkg-dev thanks I managed to grab Matthias Klose and he helped me get a working demo of the problem on my lowly i386, and I understand the bug now -- there's some missing context in the above mails. For those following, the problem is that people are building 64-bit libraries on a 32-bit platform (or the other way around) as part of the package build. dpkg-shlibdeps uses plain old ldd to find out the dependencies of a binary or shared library, but the ldd on the system won't be able to identify the impostor libraries. Build yourself a quick demo (on ubuntu breezy i386): $ sudo aptitude install libc6-dev-amd64 $ apt-get source zlib $ cd zlib # edit debian/rules: add i386 to 64-ARCHS # edit debian/control: add i386 to Architecture of lib64z1 and lib64z1-dev $ debian/rules build $ fakeroot debian/rules binary This'll fail with: dpkg_shlibdeps -p lib64z1 -lbuild-tree/zlib-1.2.3 /usr/bin/ldd: line 161: /lib64/ld-linux-x86-64.so.2: cannot execute binary file dpkg-shlibdeps: failure: ldd on `debian/lib64z1/usr/lib64/libz.so.1.2.3' gave error exit status 1 dh_shlibdeps: command returned error code 256 In this example, the 32-bit i386 ldd on my system can't read the amd64 binaries that have been generated. I don't think this is just a dpkg-dev bug, these bi-arch systems need to provide ldd or an equivalent that can read either form of shared library that it would support. objdump isn't a solution either, while it sometimes can read the other shared library, it doesn't provide the linker search patch which is of critical importance to get this stuff right. So I'm including libc6-dev (for want of a better package) in this bug, as we first need ldd on these bi-arch systems (or something similar) for dpkg-shlibdeps to use before we can fix that! Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#320925: leaks dpkg.log filedescriptor to child processes
On Fri, 2005-08-05 at 18:38 +0300, Török Edvin wrote: I have made a patch that sets close-on-exec. Tell me if this is what you expected, and if my patch really fixes what you meant. Also please test if dpkg still works correctly That kinda patches gettext g Already fixed this one, yet another bug that suffered from moving this from the initialisation routine (which took care of all this) into a when needed bit of code. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#317082: Uh, help!
tags 317082 moreinfo thanks Unfortunately I don't have either a 64-bit platform, or any real knowledge of them. I've read this bug a dozen times, and I have absolutely no idea what I'm supposed to do about it. Could someone please supply a guide for idiots/dpkg maintainers or better yet, a patch! Thanks, Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#313605:
severity 313605 minor thanks This bug should not be serious, it is not a severe violation of Debian policy, and does not, in my opinion make the package unsuitable for release. Neither is it grave (it does not make dpkg unusuable, or mostly so, or introduce a security hole) or critical (in order to justify that it makes unrelated software _break_ you'd need to provide an example Bug# caused by this diversion). This bug doesn't affect dpkg's usefulness and is trivial to fix once an upload of coreutils to fix Bug#313258 has taken place. Therefore the appropriate severity is minor. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#313605: dpkg removes a file from another package using a local diversion
On Tue, 2005-06-14 at 15:28 -0400, Michael Stone wrote: On Tue, Jun 14, 2005 at 04:19:20PM +0100, Scott James Remnant wrote: On Tue, 2005-06-14 at 10:57 -0400, Michael Stone wrote: dpkg has made the md5sum.textutils binary from the coreutils binary unavailable in its original path. A package must not remove files from another package. It's diverting it, not removing it. No, it's removing it. There is no /usr/bin/md5sum.textutils once the buggy version of dpkg is installed. If you can't tell the difference between rm (unlink) and mv (rename) you _really_ shouldn't be maintaining coreutils! A diversion should be used when a package wants to install a different copy of an existing binary, not to make an existing binary unavailable. Actually, both are perfectly valid uses of diversions. I don't want md5sum.textutils to go away, regardless of whether coreutils provides /usr/bin/md5sum. So stop waving your dick about and upload a package that matches your liking. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#313605: Resolving these bugs ...
Clearly we're not getting anywhere by filing bugs on each other's packages and trading well-judged insults ... Something has to provide /usr/bin/md5sum, your package (coreutils) has the best implementation of that. If you also want to provide /usr/bin/md5sum.textutils, that's your call. Until your package is ready to provide md5sum itself, we need something to make sure it's there -- we can't have a system without it. The diversion has been working for the last six months, and seems to have not upset anybody. The easiest way to resolve this is: - you upload a coreutils which ships /usr/bin/md5sum and, if you like, the older filename - either the preinst of that package removes the diversion, or within the same dinstall run I'll upload a dpkg that removes it. That way everybody should be happy, and there should be only a short period during upgrade where there is no md5sum on the system. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#302995: gettext: ftbfs on sparc
severity 302995 normal tags 302995 - sid thanks On Mon, 2005-04-04 at 02:13 +0200, Santiago Vila wrote: On Sun, 3 Apr 2005, Blars Blarson wrote: gettext failed to build from source on the sparc buildd, however it built fine on my sparc pbuilder. The buildd log lacks some things that are in the pbuilder log config.status: creating intl-java/Makefile config.status: creating intl-csharp/Makefile and of course the sections that use those makefiles. A diff between the build logs for 0.14.2-1 and 0.14.3-1 for sparc yields the following meaningful difference: -checking for jar... jar +checking for jar... no So there was no /usr/bin/jar in the sparc autobuilder after installing the fastjar package, but /usr/bin/jar is handled via the alternatives mechanism. Seems like a dpkg bug to me. What makes you think this is a dpkg bug? Please provide a stat of /usr/bin/jar, /etc/alternatives/jar and output of update-alternatives --display jar. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#294895: [DPKG] emacsen-common package not configured before a2ps despite Depends
On Sat, 2005-03-12 at 02:03 -0800, Steve Langasek wrote: Is it certain that this is a dpkg bug? I notice that the submitter's typescript shows he was using apt 0.5.27 when upgrading, which was before the Dpkg::MaxArgs setting was bumped to 1024 -- the first typescript shows a total of 640 packages being upgraded, and the second typescript shows 281 packages not fully installed or removed, so perhaps this is a bad dpkg invocation, not a bug in dpkg itself? I don't think it's an apt issue, both emacsen-common and a2ps were passed to dpkg in the same run (they were unpacked within the same block) -- I need to digest the typescripts a little more, but I'm tending towards that it is a dpkg bug. Not in the least because I have a hunch I've seen something similar myself since a change was made to the depcycle breaker last year. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#294895: Patch for a2ps
severity 294895 normal reassign 294895 apt thanks On Fri, 2005-03-11 at 12:20 +0100, Frank Kster wrote: Thank you. This clearly shows that there was no attempt to configure emacsen-common before giving the error message about a2ps: On closer examination, a2ps and emacsen-common are being installed in different dpkg invocations. This is an APT problem. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#295169: dpkg: [S-S-D] start-stop-daemon doesn't set HOME enviroment variable when switching users via --chuid
severity 295169 normal retitle 265169 [S-S-D] doesn't set HOME enviroment variable when switching users via --chuid thanks merge 265169 267784 thanks On Sun, 2005-02-13 at 23:42 -0500, Adam R. Skutt wrote: Justification: breaks unrelated software Software using start-stop-daemon is implicitly related, therefore this justification is invalid. In particular, start-stop-daemon documents that --chuid is incomplete and, for example, doesn't even set supplementary groups. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
