Bug#862884: Please upload
As a result of this patch not being applied, I couldn't connect my laptop to my employer's VPN (because I run testing, and this package isn't available in testing). Applying the patch and building it locally worked fine.
Bug#486478: Where's the build log?
I went to buildd.debian.net and I don't see the build log for this package. And the [0] reference doesn't seem to have been filled in in the original mail. How very strange. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486478: Where's the build log?
On Mon, Jun 23, 2008 at 09:33:14PM +0200, Daniel Baumann wrote: ...and sorry for having missed in the first mail. That's OK, I was just a bit perturbed at not being able to find the build logs in the system. It's a bit odd the way it's built. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486478: Where's the build log?
On Mon, Jun 23, 2008 at 09:28:53PM +0200, Daniel Baumann wrote: mips: http://buildd.debian.org/fetch.cgi?pkg=linux-modules-extra-2.6ver=2.6.25-2arch=mipsstamp=1213610531file=log Thanks! Here's the failing line: CC [M] /build/buildd/linux-modules-extra-2.6-2.6.25/debian/build/build_mips_none_r4k-ip22_et131x/et131x_initpci.o et131x_initpci.c: In function 'et131x_pci_setup': et131x_initpci.c:1375: error: implicit declaration of function 'pci_set_consistent_dma_mask' But look at this: $ grep pci_set_consistent_dma_mask include/linux/* include/linux/pci.h:int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask); $ grep pci.h et131x_initpci.c #include linux/pci.h The only way I can see this happening is if CONFIG_PCI isn't set. But as far as I can tell, this driver is PCI only, so it should be disabled for non-PCI builds. s390: http://buildd.debian.org/fetch.cgi?pkg=linux-modules-extra-2.6ver=2.6.25-2arch=s390stamp=1213582615file=log We know s390 doesn't have PCI ;-) Hell, it doesn't have MMIO, IO ports ... anyway, it should be disabled for s390. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462412: kerneloops: Refuses to run, lacks documentation
On Thu, Jan 24, 2008 at 07:27:03PM +0100, Johan Walles wrote: Package: kerneloops Version: 0.7-1 Severity: grave Justification: renders package unusable Grave? Are you serious? Anyway, I have 0.10 prepared with an init script. I just need to upload it, which won't happen until I'm physically reunited with my gpg secret key, which will be in approximately 2 weeks. In the meantime you can download some untrustable packages from http://people.debian.org/~willy/kerneloops/ (feel free to verify the orig.tar.gz matches upstream and the contents of the diff.gz, then rebuild it yourself). -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
On Tue, Jun 05, 2007 at 04:46:56PM +0200, Martin Michlmayr wrote: * Daniel Jacobowitz [EMAIL PROTECTED] [2007-05-22 10:21]: /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. IIRC there's a configure option you have to specify to use libunwind; maybe that's what's broken. Has there been any progress on this bug? I'd need to use gdb on ia64. :/ I have to confess that once I built gdb from CVS, I got distracted with other things. The fate of the debugger, I guess ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
I hit the same problem as the buildd and Kurt. Since I need something more recent than gdb 6.5 in order to handle current ia64 executables, I tried to run it anyway. It's not pretty: $ ./objdir/gdb/gdb gs GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as ia64-linux-gnu... (no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) set args /home/willy/gnupg/keyanalyze-200204-willy/bsdcan2007/output/graph.ps (gdb) run Starting program: /usr/bin/gs /home/willy/gnupg/keyanalyze-200204-willy/bsdcan2007/output/graph.ps (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x20580e61 in strncat () from /lib/libc.so.6.1 (gdb) bt #0 0x20580e61 in strncat () from /lib/libc.so.6.1 #1 0x4010a8a0 in ?? () /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Aborted I really don't know how to go about debugging the debugger when the previous version of the debugger no longer works. $ gdb ./objdir/gdb/gdb GNU gdb 6.5-debian This GDB was configured as ia64-linux-gnu...BFD: /home/willy/debian/gdb/gdb-6.6.dfsg/objdir/gdb/gdb: don't know how to handle OS specific section `.gnu.hash' [0x6ff6] /home/willy/debian/gdb/gdb-6.6.dfsg/objdir/gdb/gdb: not in executable format: File format not recognized -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
On Tue, May 22, 2007 at 08:23:34AM -0400, Daniel Jacobowitz wrote: On Tue, May 22, 2007 at 06:00:20AM -0600, Matthew Wilcox wrote: I hit the same problem as the buildd and Kurt. Since I need something more recent than gdb 6.5 in order to handle current ia64 executables, I tried to run it anyway. It's not pretty: If you have some time to look at this, could you try building a CVS checkout of GDB on ia64? Maybe that will work better. Much better: === gdb Summary === # of expected passes11320 # of unexpected failures69 # of unexpected successes 2 # of expected failures 41 # of known failures 45 # of unresolved testcases 1 # of untested testcases 5 # of unsupported tests 13 (ulimit -c was set to 0, so some of those fails are my fault). Running it against gs, my previous testcase, I now get: Program received signal SIGSEGV, Segmentation fault. 0x20580e61 in strncat () from /lib/libc.so.6.1 (gdb) bt #0 0x20580e61 in strncat () from /lib/libc.so.6.1 #1 0x4010a8a0 in ?? () #2 0x40005970 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) which is a damn sight better than the assertion failure. /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. That's very strange... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389415: [HELP] Bug#389415: wordnet_1:2.1-2(ia64/unstable): FTBFS: cast from pointer to int of diff size. (fwd)
On Tue, Sep 26, 2006 at 11:22:38AM +0200, Andreas Tille wrote: Probably it did not hit the mirrors, but now it should be there. (Debian verison number -2 is missleading because -1 was in experimental and than was overriden by another upload of a previous upstream version with colon versioning). Hope this helps tracking down the problem. OK, it's there now. Here's line 17 of stubs.c: static Id = $Id: stubs.c,v 1.7 2005/04/29 19:01:57 wn Exp $; which is just garbage. static const char Id[] = ... would make sense. How does that build on any architecture? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389415: [HELP] Bug#389415: wordnet_1:2.1-2(ia64/unstable): FTBFS: cast from pointer to int of diff size. (fwd)
On Tue, Sep 26, 2006 at 02:51:14PM +0200, Andreas Tille wrote: On Tue, 26 Sep 2006, Matthew Wilcox wrote: which is just garbage. static const char Id[] = ... would make sense. Well, this sounds very reasonable in dead. How does that build on any architecture? As expected fine on i386 and probably better than before on any other. So if you commit that it compiles on ia64 chances seems to be good for any other, IMHO. The thing is, it doesn't even build on i386. So I don't understand how you uploaded it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389415: [HELP] Bug#389415: wordnet_1:2.1-2(ia64/unstable): FTBFS: cast from pointer to int of diff size. (fwd)
On Mon, Sep 25, 2006 at 07:36:11PM +0200, Andreas Tille wrote: is any kind soul out there that is able to send me a patch for this problem. I have no real idea what to do. Get:1 http://http.us.debian.org unstable/main wordnet 1:2.0g-14 (tar) [5464kB] Where's the source? cc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/usr/include/tcl8.4 -I/usr/include -I../include -I/usr/include/tcl8.4 -I/usr/include-g -Wall -O2 -c -o wishwn-stubs.o `test -f 'stubs.c' || echo './'`stubs.c stubs.c:17: warning: type defaults to 'int' in declaration of 'Id' stubs.c:17: warning: initialization makes integer from pointer without a cast stubs.c:17: error: initializer element is not computable at load time TBH, this looks like you have a misdeclaration in stubs.c. The initialization makes integer from pointer message is not the source of the problem. Need to see at least line 17 from stubs.c to be any use at all in diagnosing this problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379982: Misuse of alternatives
Package: git Version: 4.3.20-8 Severity: serious Justification: Policy 10.1 10.1 Binaries Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via alternatives or the Conflicts mechanism. See Maintainer Scripts, Section 3.9 and Conflicting binary packages - Conflicts, Section 7.3 respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325650: debug output
On Tue, Jul 11, 2006 at 09:31:04AM +0200, Marco d'Itri wrote: On Jul 11, Matthew Wilcox [EMAIL PROTECTED] wrote: I don't know why Marco changed the location of MAKEDEV; it was right before: Because if makedev is not installed but udev is, /sbin/MAKEDEV will not exist. Most other packages use /dev/MAKEDEV, but probably ppp is the only one which pbuilder tries to install. But ... makedev is Priority: required, even in sid. And Policy says that removing a package marked as required may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing. udev is still merely optional. Usually I think this would be solved with a pre-depend, but obviously we do not want to use one here. I think that just text -x MAKEDEV is an acceptable solution. Any other comments? I think it can always rely on /sbin/MAKEDEV being there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325650: debug output
On Tue, Jul 11, 2006 at 01:40:01PM +0200, Marco d'Itri wrote: On Jul 11, Matthew Wilcox [EMAIL PROTECTED] wrote: But ... makedev is Priority: required, even in sid. And Policy says that removing a package marked as required may cause your system to become totally broken and you may not even be able to use dpkg to put things back, so only do so if you know what you are doing. udev is still merely optional. It's time to start making the changes needed in a world where makedev is optional and udev is required. That seems premature. Right now, ppp is broken and won't install on sid because of this change. It would have worked fine with /sbin/MAKEDEV because makedev (being required) is configured and installed before ppp. So could you revert this change and use /sbin/MAKEDEV instead for the moment, then work with whoever needs to care to make udev a required package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325650: debug output
# This is actually a bad bug to be reopening, there's two bugs mixed in # together; the second reporter confused the symptoms. # However, Matt and Bob are already looking at this bug, so there's some # benefit. reopen 325650 reassign 325650 ppp thanks Looks like a bug in ppp's postinst to me: O: Setting up ppp (2.4.4rel-1) ... P: Configuring package ppp D: Updating ppp to status 3 O: /var/lib/dpkg/info/ppp.postinst: line 41: ./MAKEDEV: No such file or directory O: dpkg: error processing ppp (--configure): O: subprocess post-installation script returned error exit status 1 O: dpkg: dependency problems prevent configuration of pppconfig: O: pppconfig depends on ppp (= 2.3.7); however: O: Package ppp is not configured yet. O: dpkg: error processing pppconfig (--configure): O: dependency problems - leaving unconfigured O: dpkg: dependency problems prevent configuration of pppoeconf: O: pppoeconf depends on ppp (= 2.4.2+20040428-2) | pppoe (= 3.0); however: O: Package ppp is not configured yet. O: Package pppoe is not installed. O: pppoeconf depends on ppp (= 2.4.1.uus2-4); however: O: Package ppp is not configured yet. O: dpkg: error processing pppoeconf (--configure): O: dependency problems - leaving unconfigured O: Errors were encountered while processing: O: ppp O: pppconfig O: pppoeconf O: E: Sub-process /usr/bin/dpkg returned an error code (1) D: Return code: 25600 - Aborting with an error - cleaning the build env - removing directory /var/cache/pbuilder/build//18172 and its subdirectories ppp's postinst script seems to have changed between 2.4.4b1-1.diff.gz and ppp_2.4.4rel-1.diff.gz from: # create /dev/ppp if we are not using devfs if [ ! -c /dev/ppp ]; then cd /dev /sbin/MAKEDEV ppp fi to: # create /dev/ppp if we are not using udev if [ ! -c /dev/ppp ]; then cd /dev ./MAKEDEV ppp fi I don't know why Marco changed the location of MAKEDEV; it was right before: $ dpkg -S MAKEDEV makedev: /sbin/MAKEDEV -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278479: reverted
Hi. I've reverted this change as I believe it's based on a flawed interpretation of the FHS. Please see http://sourceforge.net/mailarchive/forum.php?thread_id=10004256forum_id=3128 The comment about debsums indicating that the file has changed is entirely correct. That's called working as designed: debsums is intended primarily as a way of determining what installed files have been locally modified by the administrator or damaged by media errors and is of limited use as a security tool. Running update-pciids counts as 'locally modified by the administrator' to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329888: reassign
reassign 329888 linux-2.6 tags 329888 +patch thanks For the next release, please apply this patch: http://cvs.parisc-linux.org/linux-2.6/arch/parisc/kernel/pacache.S?r1=1.19r2=1.20makepatch=1diff_format=u It fixes a latent kernel bug that is now flagged by recent binutils changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329888: [parisc-linux] binutils breaks hppa kernel build,
On Sat, Sep 24, 2005 at 09:27:22PM -0400, John David Anglin wrote: The last fic opcode entry is wrong. It's using the wrong instruction format, the mask is wrong, pa10 is wrong, etc. I don't think we realised this until now. I suspect we've been silently emitting bad code up until this point, and given that it's in flush_kernel_icache_page, maybe it explains some of our occasional crashes. The code was previously: fic,m %r23(%r26) We're trying to flush kernel space at this point, so we can use any of sr4-sr7. I suspect before we were putting sr0 in, which could have been flushing any random space instead of the one we wanted. I'll commit this change to the kernel source now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329888: [parisc-linux] binutils breaks hppa kernel build,
On Sat, Sep 24, 2005 at 11:24:31PM -0400, John David Anglin wrote: On Sat, Sep 24, 2005 at 09:27:22PM -0400, John David Anglin wrote: The last fic opcode entry is wrong. It's using the wrong instruction format, the mask is wrong, pa10 is wrong, etc. I don't think we realised this until now. I suspect we've been silently emitting bad code up until this point, and given that it's in flush_kernel_icache_page, maybe it explains some of our occasional crashes. The code was previously: fic,m %r23(%r26) I've committed a fix to binutils head. The above should now be accepted when generating PA 2.0 code. However, I'd probably avoid using this feature for awhile. It looks like the bug has been present since ~ 1996. This is in a file that's used on pa1.1 processors too, so I've gone with specifying sr4 explicitly. Thanks for fixing this bug and exposing our bug ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. I've prepared the necessary backports and some rudimentary documentation and put it online at http://higgs.djpig.de/upgrade/upgrade-kernel/ I'll give it a try now. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294867: base: de4x5.ko generates endless loop of errors with phobos p430tx
On Mon, Feb 14, 2005 at 06:21:24PM +0100, Marco d'Itri wrote: reassign 294867 kernel-image-2.6.8-i386 thanks If a driver hangs the system when loaded, it is a good hint of a kernel bug. I think de4x5 should be a driver of last resort. Tulip should always be preferred to drive a given piece of hardware. I wouldn't shed any tears if we stopped shipping de4x5 by default -- it's caused no end of problems on parisc and ia64. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294867: base: de4x5.ko generates endless loop of errors with phobos p430tx
On Mon, Feb 14, 2005 at 01:09:43PM -0500, Joey Hess wrote: Matthew Wilcox wrote: I think de4x5 should be a driver of last resort. Tulip should always be preferred to drive a given piece of hardware. I wouldn't shed any tears if we stopped shipping de4x5 by default -- it's caused no end of problems on parisc and ia64. OTOH it's the only module that can drive the ethernet card of my a500 (hppa). I think you have that backwards. de4x5 *doesn't* work on hppa whereas tulip does. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
