Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Tue, 15 Aug 2023 15:08:11 +0200, Scott Kitterman wrote: > > On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > > Hi Scott, > > > > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: > > > > > those are all binary without source. That's a problem. > > > > Given your role as ftpmaster you definitely have more experience than I > > in this field. I personally was thinking more in the line of binary > > data we can not avoid in some cases. This is a bit in the line with > > Rdata decision[1] where those binary data files are documented in > > debian/README.source. > > > > My point is just: If we remove those data files (which are IMHO harmless > > since these are not executd but used as input in tests - please correct > > me if I'm wrong) we can not test the package. Removing the files > > prevents testing and thus we can not know whether the package we deliver > > will work. I've actually shown that not all tests are working but > > stopped investigating this further. > > Even if they are used as data (I didn't check), they are, in fact, binary > blobs of code by our definition and that requires the corresponding source. They are zip files containing python source code. It is possible to include compiled C extensions in wheels, but I checked and these wheels are all pure python, so no binary blobs are included. Kind regards, Jeroen Dekkers
Bug#1033607: [Pkg-sogo-maintainers] Bug#1033607: sogo: /usr/bin/sogo linked against wrong version of libgnustep-base
Hi Phil, On Sat, 01 Apr 2023 02:41:05 +0200, Phil Gruber wrote: > > Thanks for getting back to me. > > Here's what this looks like for me: > > > $ /usr/sbin/sogod > > /usr/sbin/sogod: error while loading shared libraries: > > libgnustep-base.so.1.24: cannot open shared object file: No such file or > > directory > > $ ldd -r /usr/sbin/sogod | grep gnustep > > libgnustep-base.so.1.27 => /usr/lib/libgnustep-base.so.1.27 > > (0x7f6c6428f000) > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > libgnustep-base.so.1.24 => not found > > I just removed and re-installed the sogo package, but it didn't make a > difference. Can you use objdump to figure out which files have the dependency on libgnustep-base.so.1.24? objdump -p /usr/sbin/sogod | grep NEEDED If that doesn't list libgnustep-base.so.1.24 then try libSOGo.so.5 and all the other libraries listed by ldd. Kind regards, Jeroen Dekkers
Bug#919217: Acknowledgement (Missing dependency on devscripts)
Control: tag -1 +patch https://salsa.debian.org/jelmer/lintian-brush/merge_requests/1
Bug#919217: Missing dependency on devscripts
Package: lintian-brush Version: 0.10 Severity: serious Lintian-brush must depend on devscripts because it calls dch to update the changelog. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Control: tag -1 +patch On Mon, 29 Oct 2018 00:36:00 +0100, Colin Watson wrote: > > On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote: > > I see this same at_keyboard behaviour: working in VirtualBox, delivering > > garbage on this real hardware: > > - an HP Proliant DL380 Gen5 machine > > - with a Compaq PS/2 keyboard italian layout attached > > - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, > > containing a keyboard layout file made with > > ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb > [...] > > Having read > > > > http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html > > it is obvious what's going on: at_keyboard is using scankey set 1 but the > > keyboard is using set 2 and the keyboard controller is not translating. > > Sorry for the long delay. Are you still in a position to test this? > > I just ran across this upstream commit: > > > https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c4b8bec5fee4e30a165fd14a188cf3ab8eccd095 > > Ignoring the specific hardware mentioned here, it seems like this could > be a plausible cause: if GRUB manages to get out of sync with the > keyboard controller on the command/data sequence, then it could easily > end up confused about which is the current scan code set (see the > changes to query_mode in particular) and so end up using the wrong set, > or possibly even send a nonsense command somehow. It seems worth > testing if you can. I cherry-picked that commit and tested it but it didn't fix the problem. The bug was introduced somewhere between GRUB 2.00 and 2.02 so I used git bisect to find the commit that introduced the bug: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0c62a5b28e2783d84d266341c4388b494e058114 As far as I understand the change it will no longer poll forever in the module init when the keyboard controller isn't ready. The problem seems to be that we used to initialize the keyboard controller in the module init but now we always do it later when getkey is called. Somehow this messes up things but I have no idea why. I changed it so that it only initializes the keyboard controller when it is ready and doesn't poll when it isn't. Here is the merge request: https://salsa.debian.org/grub-team/grub/merge_requests/6 I've tested this on my old laptop (X200s thinkpad) and the problem goes away with this patch. Kind regards, Jeroen Dekkers
Bug#812574: grub-pc: wants to overwrite admin configuration on each upgrade
On Tue, 11 Apr 2017 19:26:44 +0200, Thorsten Glaser wrote: > debconf (developer): starting /tmp/grub-pc.config.GkdXih configure > 2.02~beta2-36 > debconf (developer): <-- SET grub2/linux_cmdline rootdelay=5 net.ifnames=0 > syscall.x32=y vsyscall=emulate kaslr > debconf (developer): --> 0 value set > debconf (developer): <-- SET grub2/linux_cmdline_default > debconf (developer): --> 0 value set > debconf (developer): <-- SET grub-pc/timeout 4 > debconf (developer): --> 0 value set > debconf (developer): <-- INPUT medium grub2/linux_cmdline > debconf (developer): --> 30 question skipped > debconf (developer): <-- INPUT medium grub2/linux_cmdline_default > debconf (developer): --> 30 question skipped > debconf (developer): <-- GO > debconf (developer): --> 0 ok Here grub-pc.config parses /etc/default/grub and sets grub-pc/timeout to 4. > debconf (developer): starting /var/lib/dpkg/info/grub-pc.postinst configure > 2.02~beta2-36 > debconf (developer): <-- GET grub2/linux_cmdline > debconf (developer): --> 0 rootdelay=5 net.ifnames=0 syscall.x32=y > vsyscall=emulate kaslr > debconf (developer): <-- GET grub2/linux_cmdline_default > debconf (developer): --> 0 > debconf (developer): <-- GET grub-pc/timeout > debconf (developer): --> 0 4 > debconf (developer): <-- GET grub-pc/hidden_timeout > debconf (developer): --> 0 false > ucf: The new file is /tmp/grub.ePz0QM4HXU > ucf: The Destination file is /etc/default/grub > ucf: The Source directory is /tmp > ucf: The State directory is /var/lib/ucf > ucf: The md5sum is found here is /usr/share/grub/default/grub.md5sum > The hash file exists > egrep [[:space:]]\/etc\/default\/grub$ /var/lib/ucf/hashfile > 2dcf752a6412b128ad753b192aaa39ba /etc/default/grub > The new start file is `/tmp/grub.ePz0QM4HXU\' > The destination is `/etc/default/grub\' (`\/etc\/default\/grub\') > The history is kept under \'/tmp\' > The file may be cached at \'/var/lib/ucf/cache/:etc:default:grub\' > The destination file exists, and has md5sum: > 011d1dd794945a8b756d52be4c8cdc88 /etc/default/grub > The old md5sum exists, and is: > 2dcf752a6412b128ad753b192aaa39ba > The new file exists, and has md5sum: > 359c3711e747b287ed186472de6b966a /tmp/grub.ePz0QM4HXU Here we generate /etc/default/grub based on the values stored by debconf. The problem is that we just changed grub-pc/timeout and thus the new file has the new timeout while the old file has the old timeout and you get the ucf prompt. I don't really see an easy way to fix this. On the one hand we try to prevent a prompt on upgrade by parsing the cmdline and timeout, but on the other hand this causes an ucf prompt on the next upgrade if there were also other changes made. This would only happen once after one of the variables are changed and debconf is updated and not on each upgrade as the original bug report claimed. Kind regards, Jeroen Dekkers
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Thu, 16 Oct 2014 17:57:20 +0200 Sven Joachim svenj...@gmx.de wrote: On 2014-10-13 16:25 +0200, Colin Watson wrote: On Wed, Mar 12, 2014 at 08:24:31PM +0100, Sven Joachim wrote: After upgrading the grub packages and rebooting my laptop, grub displayed the boot menu and then was hung. The countdown before booting the default kernel was not started and grub did not accept any keyboard input. I had to boot a rescue system from a USB stick, chroot into my installation and downgrade to 2.00-22 to get back to a working system. Sorry for the delay in replying to this. Could you please post the output of: sudo debconf-show grub-pc ? Is there anything else interesting about your system, since this is not something I can reproduce? I have diverted /sbin/update-grub to maintain /boot/grub/grub.cfg by hand, as you suggested in bug #578576. Therefore the debconf data are probably not too interesting. Bearing in mind the period of time involved, it might also be worth trying with 2.02~beta2-14 now that you have rescue media to hand. I have managed to install 2.02~beta2-15 on a USB stick which is much easier to recover, and the offending command which causes grub to freeze is terminal_input at_keyboard, which I have been using for obtaining a German keyboard layout (see #686817 on that matter; I'm sure there was an even older bug, but cannot find it now). If I remove that statement, grub works. From the grub command line I can insmod at_keyboard without problems, but terminal_input at_keyboard freezes grub. I tried to reproduce this in a virtual machine (using kvm), but under kvm everything seems to work fine including the german keyboard layout. When I tried it on real hardware I could reproduce the problem, but instead of freezing I got garbage input after switching terminal_input to at_keyboard. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764798: grub2: Grub rescue shell with RAID 6 mdadm over 8 disks
Control: tag -1 moreinfo Hi Mike, On Thu, 23 Oct 2014 18:20:00 -0500 Mike ctrl...@yahoo.com wrote: Greetings, anything else needed from me? I don't have VMWare, but tried to reproduce it using KVM (the host machine is running wheezy). When I configure 10 SATA disks I see all of them in grub, but when I use VirtIO disks I only see 7 of them. Turning debugging on and looking further I see that the bios simply gives an error when trying to access disk 8 and the boot menu also only shows 7 disks - so in this case the problem is in the bios, not in grub. Can you turn on debugging in the grub console using 'set pager=1' and 'set debug=all' and give the output? The debug information from biosdisk.c is the most interesting. If the problem is that the bios doesn't support more than 8 disks there is not much we can do except for documenting it and give a warning for RAID arrays with more than 8 disks. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750258: sogo: FTBFS: make[5]: *** No rule to make target 'SOGo.framework/sogo/', needed by 'SOGo.framework/sogo/SOGo'. Stop.
Control: reassign -1 gnustep-make
Control: forcemerge 747028 -1
This is caused by a bug in gnustep-make and already filed as #747028
(and marked as affecting sogo). A package with a fix is currently
waiting for a sponsor on mentors.debian.net.
At Mon, 2 Jun 2014 21:12:08 +0200,
David Suárez wrote:
Source: sogo
Version: 2.1.1b-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20140601 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
gcc -shared -Wl,-soname,libSOGo.so.2 -rdynamic -Wl,--rpath,/usr/lib/sogo
-lmemcached -Wl,-z,relro -Wl,-z,now -pthread -shared-libgcc
-fexceptions -o ./SOGo.framework/Versions/2/sogo/libSOGo.so.2.1.1b
obj/SOGo.obj/NSFramework_SOGo.o obj/SOGo.obj/SOGoBuild.m.o
obj/SOGo.obj/SOGoProductLoader.m.o obj/SOGo.obj/SOGoCache.m.o
obj/SOGo.obj/SOGoConstants.m.o obj/SOGo.obj/SOGoObject.m.o
obj/SOGo.obj/SOGoContentObject.m.o obj/SOGo.obj/SOGoFolder.m.o
obj/SOGo.obj/SOGoGCSFolder.m.o obj/SOGo.obj/SOGoParentFolder.m.o
obj/SOGo.obj/SOGoPublicBaseFolder.m.o obj/SOGo.obj/SOGoUserFolder.m.o
obj/SOGo.obj/SOGoSieveManager.m.o obj/SOGo.obj/SOGoDefaultsSource.m.o
obj/SOGo.obj/SOGoSystemDefaults.m.o obj/SOGo.obj/SOGoDomainDefaults.m.o
obj/SOGo.obj/SOGoUserDefaults.m.o obj/SOGo.obj/SOGoUserSettings.m.o
obj/SOGo.obj/SOGoDateFormatter.m.o obj/SOGo.obj/SOGoPermissions.m.o
obj/SOGo.obj/SOGoStartupLogger.m.o obj/SOGo.obj/SOGoUserManager.m.o
obj/SOGo.obj/LDAPSource.m.o obj/SOGo.obj/LDAPSourceSchema.m.o
obj/SOGo.obj/SQLSource.m.o obj/SOGo.obj/SOGoUserProfile.m.o
obj/SOGo.obj/SOGoSQLUserProfile.m.o obj/SOGo.obj/NSArray+DAV.m.o
obj/SOGo.obj/NSArray+Utilities.m.o obj/SOGo.obj/NSCalendarDate+SOGo.m.o
obj/SOGo.obj/NSDictionary+DAV.m.o obj/SOGo.obj/NSDictionary+URL.m.o
obj/SOGo.obj/NSDictionary+Utilities.m.o obj/SOGo.obj/NSNull+Utilities.m.o
obj/SOGo.obj/NSNumber+Utilities.m.o obj/SOGo.obj/NSObject+DAV.m.o
obj/SOGo.obj/NSObject+Utilities.m.o obj/SOGo.obj/NSString+DAV.m.o
obj/SOGo.obj/NSString+Utilities.m.o obj/SOGo.obj/NSString+Crypto.m.o
obj/SOGo.obj/NSData+Crypto.m.o obj/SOGo.obj/NSURL+DAV.m.o
obj/SOGo.obj/SOGoSession.m.o obj/SOGo.obj/SOGoCASSession.m.o
obj/SOGo.obj/SOGoDAVAuthenticator.m.o
obj/SOGo.obj/SOGoProxyAuthenticator.m.o
obj/SOGo.obj/SOGoStaticAuthenticator.m.o
obj/SOGo.obj/SOGoWebAuthenticator.m.o obj/SOGo.obj/SOGoWebDAVAclManager.m.o
obj/SOGo.obj/SOGoWebDAVValue.m.o obj/SOGo.obj/SOGoMailer.m.o
obj/SOGo.obj/SOGoGroup.m.o obj/SOGo.obj/SOGoUser.m.o
obj/SOGo.obj/DOMNode+SOGo.m.o obj/SOGo.obj/WORequest+SOGo.m.o
obj/SOGo.obj/WOResourceManager+SOGo.m.o obj/SOGo.obj/WOResponse+SOGo.m.o
obj/SOGo.obj/WOContext+SOGo.m.o obj/SOGo.obj/SOGoCredentialsFile.m.o
obj/SOGo.obj/SOGoSAML2Session.m.o obj/SOGo.obj/SOGoSAML2Exceptions.m.o
-L../../SOPE/GDLContentStore/obj/-L/usr/local/lib -L/usr/lib
-Wl,--no-as-needed -L../../OGoContentStore/./obj/ -lOGoContentStore
-L../../SOPE/NGCards/./obj/ -lmemcached -lGDLAccess -lNGObjWeb -lNGCards
-lNGMime -lNGStreams -lNGExtensions -lEOControl -lDOM -lSaxObjC -lNGLdap
-lSBJson -lGDLContentStore -rdynamic -pthread -shared-libgcc -fexceptions
-fgnu-runtime -L/usr/local/lib -L/usr/lib -lgnustep-base -lobjc -lm
-lgnutls -llasso -lcrypt -ldl (cd ./SOGo.framework/Versions/2/sogo; rm
-f libSOGo.so; if [ libSOGo.so.2 != libSOGo.so.2.1.1b ]; then rm -f
libSOGo.so.2; ln -s libSOGo.so.2.1.1b libSOGo.so.2; fi; ln -s libSOGo.so.2
libSOGo.so; ) || rm -f ./SOGo.framework/Versions/2/sogo/libSOGo.so.2.1.1b ;
\
(cd ./SOGo.framework/Versions/2/sogo; \
rm -f SOGo; \
ln -s libSOGo.so SOGo) \
for f in SOGoDefaults.plist DAVReportMap.plist CASLogoutRequestMap.plist
SOGoSAML2Metadata.xml; do \
if [ -f $f -o -d $f ]; then \
cp -fr $f ./SOGo.framework/Versions/2/Resources/; \
else \
echo Warning: $f not found - ignoring; \
fi; \
done
Warning: SOGoSAML2Metadata.xml not found - ignoring
(echo {; echo ' NOTE = Automatically generated, do not edit!;'; \
echo NSExecutable = \SOGo\;; \
echo NSMainNibFile = \\;; \
echo NSPrincipalClass = \SOGo\;; \
echo Classes = ; \
cat ./derived_src/SOGo-class-list; \
echo ;; \
echo }) SOGo.framework/Versions/2/Resources/Info-gnustep.plist
if [ -r SOGoInfo.plist ]; then \
plmerge SOGo.framework/Versions/2/Resources/Info-gnustep.plist
SOGoInfo.plist; \
fi
make[5]: *** No rule to make target 'SOGo.framework/sogo/', needed by
'SOGo.framework/sogo/SOGo'. Stop.
make[4]: *** [SOGo.all.framework.variables] Error 2
The full build log is available from:
http://aws-logs.debian.net/ftbfs-logs/2014/06/01/sogo_2.1.1b-1_unstable.log
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
Bug#749678: sogo: FTBFS on amd64: No rule to make target 'SOGo.framework/sogo/'
Control: reassign -1 gnustep-make
Control: merge -1 747028
Thanks for filing the bug report. The bug is already known and caused
by gnustep-make in combination with make 4.0, a fix is pending:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747028
I mistakenly marked the bug affecting the binary package and not the
source package and apparently the source package bts page doesn't show
bugs affecting binary packages, so that's probably why you didn't see
the bug.
At Wed, 28 May 2014 22:22:29 -0400,
Logan Rosen wrote:
Source: sogo
Version: 2.1.1b-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
The package sogo 2.1.1b-1 FTBFS on amd64. A test build was performed using an
amd64 pbuilder using the unstable repository.
Here is the relevant tail of the log:
(echo {; echo ' NOTE = Automatically generated, do not edit!;'; \
echo NSExecutable = \SOGo\;; \
echo NSMainNibFile = \\;; \
echo NSPrincipalClass = \SOGo\;; \
echo Classes = ; \
cat ./derived_src/SOGo-class-list; \
echo ;; \
echo }) SOGo.framework/Versions/2/Resources/Info-gnustep.plist
if [ -r SOGoInfo.plist ]; then \
plmerge SOGo.framework/Versions/2/Resources/Info-gnustep.plist
SOGoInfo.plist; \
fi
make[5]: *** No rule to make target 'SOGo.framework/sogo/', needed by
'SOGo.framework/sogo/SOGo'. Stop.
/usr/share/GNUstep/Makefiles/Master/rules.make:298: recipe for target
'SOGo.all.framework.variables' failed
make[4]: *** [SOGo.all.framework.variables] Error 2
The full log is attached. A no-change rebuild of the package also failed on
all
architectures (except for arm64, which has a dependency wait) in Ubuntu
Utopic:
https://launchpad.net/ubuntu/+source/sogo/2.1.1b-1build1
Thanks,
Logan Rosen
-- System Information:
Debian Release: jessie/sid
APT prefers utopic-updates
APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500,
'utopic'), (100, 'utopic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.15.0-2-generic (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746793: closing 746793
close 746793 thanks Alioth login on sso.debian.org works again -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747028: gnustep-make causes FTBFS of SOGo with make 4.0
Package: gnustep-make Version: 2.6.2-2.1 Severity: serious Tags: patch A bug in one of the makefiles of gnustep-make causes SOGo to FTBFS with make 4.0. The problem is that in two places there is a '/' appended to a directory target and apparently that isn't allowed anymore. This has already been fixed upstream with this commit: http://svn.gna.org/viewcvs/gnustep?view=revisionrevision=36185 The fix is included in the latest upstream release, so packaging the latest version will fix the bug. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-24-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746793: sso.debian.org login with alioth account doesn't work
Package: sso.debian.org Severity: grave Logging in with my alioth account on sso.debian.org doesn't work. I get the following error message: Authentication failed Invalid authenticating information Login on alioth.debian.org with the same username and password works. Someone else reported the same problem on the #debconf IRC channel. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-24-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726472: [Pkg-samba-maint] Bug#726472: share passwords not working after upgrade from samba3
At Sat, 19 Oct 2013 10:16:31 -0700, Steve Langasek wrote: Ok. I think we need to undo this /var/lib/samba/private nonsense. It is a pointless and imperfect migration (as shown by this bug report), and the only rationale upstream ever gave for keeping these files in a separate private directory is some stupid and ancient target OS that couldn't properly set per-file permissions. Debian users have been using /var/lib/samba exclusively for the better part of a decade; migrating to this private/ directory adds no value for our users. I disagree. Putting private stuff in /var/lib/samba/private might be nonsense, but this is what upsteam decided and using the same location as upstream is far from pointless. In my opinion it is the other way around and it would be a pointless deviation from upstream to continue putting the files in /var/lib/samba instead of /var/lib/samba/private. And the only reason I can think of that the migration is imperfect is that we already messed this up earlier, but that would only be an argument for not continuing with this deviation in my eyes. And if we indeed messed up then we need to clean it up regardless of what directory we are going to put the files in. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720974: FTBFS with debhelper 9.20130720
Package: sogo Version: 2.0.7-1 Severity: serious The changed makefile heuristic in debhelper 9.20130720 causes distclean to be run when config.make is not available resulting in a build failure: dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean --parallel dh_testdir -O--parallel debian/rules override_dh_auto_clean make[1]: Entering directory `/«PKGBUILDDIR»' dh_auto_clean make -j8 distclean GNUmakefile:4: /common.make: No such file or directory make[2]: Entering directory `/«PKGBUILDDIR»' GNUmakefile:17: /aggregate.make: No such file or directory make[2]: *** No rule to make target `/aggregate.make'. Stop. make[2]: Leaving directory `/«PKGBUILDDIR»' dh_auto_clean: make -j8 distclean returned exit code 2 make[1]: *** [override_dh_auto_clean] Error 2 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring'), (100, 'raring-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-29-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703187: Last upload forgets to include .egg-info directory
Package: python-gevent Version: 0.13.6-1+nmu2 Severity: serious Tags: patch The last NMU that fixed #661342 forgets to include the .egg-info directory, causing tools like pip that rely on the egg infrastructure to fail to see gevent. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal'), (100, 'quantal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-25-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru python-gevent-0.13.6/debian/python-gevent.install python-gevent-0.13.6/debian/python-gevent.install --- python-gevent-0.13.6/debian/python-gevent.install 2013-03-03 14:22:23.0 +0100 +++ python-gevent-0.13.6/debian/python-gevent.install 2013-03-16 15:26:35.0 +0100 @@ -1,2 +1,3 @@ usr/lib/python2*/*-packages/gevent/*.py usr/lib/python2*/*-packages/gevent/*[!_][!d].so +usr/lib/python2*/*-packages/*.egg-info
Bug#680818: yate
At Mon, 10 Sep 2012 02:43:07 +0100, Martín Ferrari wrote: The package in svn does not look in very good shape ATM. That commit is from July, the pending tag was not added to the bug, and the control file has currently many commented-out lines that should be removed... Dunno if waiting for maintainer before uploading is warranted. As far as I know there currently isn't an active maintainer for yate and the package is in a pretty bad shape. I did the last improvements to the yate package and committed those to svn, but then didn't have the time to finish it. Sorry for that, I should've have finished it or let people know I didn't have time to finish it. The control file only has yate-h323 commented out because it doesn't build (see below). As this is supposed to be temporary I think commenting it out is better than removing the lines. At Tue, 11 Sep 2012 02:05:55 +0100, Martín Ferrari wrote: On Mon, Sep 10, 2012 at 2:09 PM, Paul Chitescu pa...@voip.null.ro wrote: I guess this has to do with the recent banishing of OpenH323 from Debian. Yate should work with H323Plus but it does not detect it automatically. It doesn't? Then the current conditional dependency on it is broken... Building against H323Plus didn't work, so Mark Purcell disabled H.323 in the version currently in the archive, but didn't remove the build dependency and didn't remove the yate-h323 package. Among other improvements I removed the yate-h323 package and the build dependency, as I didn't have the time to investigate why yate didn't build with H323Plus and in my opinion it's better to have yate without H.323 than no yate at all. The package currently in subversion should build without problems. I also did some other important fixes, but I'm not sure whether they are important enough to be acceptable during the freeze. The changelog is at http://anonscm.debian.org/viewvc/pkg-voip/yate/trunk/debian/changelog?revision=9912view=markup If anyone can get yate to compile with H323Plus, then that would of course be better than having no H.323 support, but at the moment the fastest route to having a package without RC bugs is keeping H.323 disabled and removing the build dependency and yate-h323 package. Kind regards, Jeroen Dekkers P.S. No need to mail to both the bug and pkg-voip-maintainers, the bug mail gets send to pkg-voip-maintainers because it is the maintainer address. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676229: gnustep-make: should depend on a chosen version of gobjc, not just gobjc
Am I missing something that still needs to be done or is this bug fixed by the upload of gnustep-base 1.22.1-3 and can be closed? Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678060: Configuration should be purged in nginx-common
Package: nginx Version: 1.2.0-1 Severity: serious Tags: patch The nginx-light, nginx-full and nginx-naxsi packages delete the /etc/nginx and /var/log directory when they are purged, but the configuration files are owned by nginx-common. This can give all sort of problems, for example if you do apt-get install nginx-light, then apt-get install nginx-full and dpkg --purge nginx-light you end up with a sytem that doesn't have an /etc/nginx or /var/log/nginx. Attached patch moves the purging to the nginx-common package where it belongs. -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-25-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff --git a/debian/nginx-common.postrm b/debian/nginx-common.postrm index 5992af9..14abd21 100644 --- a/debian/nginx-common.postrm +++ b/debian/nginx-common.postrm @@ -14,7 +14,11 @@ case $1 in fi ;; - purge|remove|failed-upgrade|abort-install|abort-upgrade|disappear) + purge) +rm -rf /var/lib/nginx /var/log/nginx /etc/nginx +;; + + remove|failed-upgrade|abort-install|abort-upgrade|disappear) ;; *) diff --git a/debian/nginx-full.postrm b/debian/nginx-full.postrm deleted file mode 100644 index ce81bd5..000 --- a/debian/nginx-full.postrm +++ /dev/null @@ -1,20 +0,0 @@ -#!/bin/sh - -set -e - -case $1 in - purge) -rm -rf /var/lib/nginx /var/log/nginx /etc/nginx -;; - - remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) -;; - - *) -echo postrm called with unknown argument \`$1' 2 -exit 1 -esac - -#DEBHELPER# - -exit 0 diff --git a/debian/nginx-light.postrm b/debian/nginx-light.postrm deleted file mode 100644 index ce81bd5..000 --- a/debian/nginx-light.postrm +++ /dev/null @@ -1,20 +0,0 @@ -#!/bin/sh - -set -e - -case $1 in - purge) -rm -rf /var/lib/nginx /var/log/nginx /etc/nginx -;; - - remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) -;; - - *) -echo postrm called with unknown argument \`$1' 2 -exit 1 -esac - -#DEBHELPER# - -exit 0 diff --git a/debian/nginx-naxsi.postrm b/debian/nginx-naxsi.postrm deleted file mode 100644 index ce81bd5..000 --- a/debian/nginx-naxsi.postrm +++ /dev/null @@ -1,20 +0,0 @@ -#!/bin/sh - -set -e - -case $1 in - purge) -rm -rf /var/lib/nginx /var/log/nginx /etc/nginx -;; - - remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) -;; - - *) -echo postrm called with unknown argument \`$1' 2 -exit 1 -esac - -#DEBHELPER# - -exit 0
Bug#624148: Also hit this issue
Hi, I also hit this issue with the apache2 DSA and it's a bit sad to see that this bug has been known and fixed for almost a year, but has never been pushed to stable and is causing problems with another DSA now. As far as I understand the fix, unattended-upgrades will wrongly upgrade a package when the conffile that is changed is not the first conffile of a package. As this might happen again, can you please make sure that the next stable update will have a fixed package? Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593648: grub-pc install fails on RAID1
At Tue, 07 Jun 2011 17:58:21 -0700, Ross Boylan wrote: Since md0 isn't partitioned it seems like the problem is the manifestation of another issue of GRUB accepting metadata at the end of last partition as metadata for the whole disk. This is fixed for 1.x metadata but is still a problem with 0.9 one due to 0.9 data sector not containing enough info to determine where it belongs to easily and reliably. What metadata are you referring to? The md metadata? Yes. The md 0.9 metadata is located at the end, they changed this to the beginning in 1.1/1.2 (note that 1.0 still stores it at the end). The problem is that if you have a partition which ends at the last sector of the disk the metadata of a raid array on such a patition will be at exactly the same place as the metadata of a raid array that spans the whole disk. I think we should first check the partitions for raid metadata and make sure that the size of the raid is not bigger than that of the partition. But as far as I remember (it has been a while since I did grub development) we would need to do some refactoring to be able to do that. And we should really add test cases for all those different kind of raid setups... Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605357: Patch for #605357
tags 605357 patch thanks I can reproduce the segfault in a virtual machine by creating multiple RAID array members with the same number. This shouldn't happen normally, so I still wonder how it's possible to hit this bug, but the backtrace is exactly the same: #0 0x00407dcb in grub_disk_adjust_range (disk=0x0, sector=0x7fffdea0, offset=0x7fffde98, size=4096) at ../../kern/disk.c:364 part = 0x1010 #1 0x00407f1f in grub_disk_read (disk=0x0, sector=0, offset=0, size=4096, buf=0x687660) at ../../kern/disk.c:397 tmp_buf = 0x0 real_offset = 0 #2 0x0042c9cd in grub_raid5_recover (array=0x66d4c0, disknr=0, buf=0x67e5d0 , sector=0, size=4096) at ../../disk/raid5_recover.c:48 err = 64 buf2 = 0x687660 i = 1 #3 0x0042c014 in grub_raid_read (disk=0x66c460, sector=0, size=8, buf=0x67e5d0 ) at ../../disk/raid.c:400 read_size = 8 next_level = 0 read_sector = 0 e = 0 b = 0 p = 2 n = 1 disknr = 0 array = 0x66d4c0 err = GRUB_ERR_READ_ERROR #4 0x0040809f in grub_disk_read (disk=0x66c460, sector=0, offset=0, size=512, buf=0x7fffe190) at ../../kern/disk.c:443 data = 0x0 start_sector = 0 len = 512 pos = 0 tmp_buf = 0x67e5d0 real_offset = 0 #5 0x0042e16d in grub_lvm_scan_device (name=0x66d710 md/0) at ../../disk/lvm.c:284 err = GRUB_ERR_NONE disk = 0x66c460 da_offset = 140737488348144 da_size = 4202832 mda_offset = 140737488348912 mda_size = 0 buf = '\000' repeats 232 times, o\003C, '\000' repeats 17 times, #\n\000\000\300\342\377\377\377\177\000\000\027\247B, '\000' repeats 13 times, j\003C, '\000' repeats 17 times, \b\000\000\000\360\342\377\377\377\177\000\000\273\251B, '\000' repeats 13 times, j\003C, '\000' repeats 21 times\360, \343\377\377\377\177\000\000;\...@\000\000\000\000\000\261\002c\000\000\000\000\000q\002c\000\000\000\000\000\000\000\000\000n\001\000\000v\002c, '\000' repeats 69 times\260, \304f\000\000\000\000\000\020\000\000\000\000\000\000\000\377\377\377\377\000\000\000\000P\266\377\367\377\177\000\000\000\000\000\000\000\000\000\000\320\343\377\377\377\177\000 vg_id = \f\344\377\377\377\177\000\000`\304f, '\000' repeats 27 times pv_id = \340\343\377\377\377\177\000\000\177\215B, '\000' repeats 13 times\377, \000\000\000\000\000\000\000\240\341\377\377\377\177 metadatabuf = 0x0 p = 0x0 q = 0x77bb8e40 vgname = 0x7fffe420 @\344\377\377\377\177 lh = 0x7fffe190 pvh = 0x7fffe6f0 dlocn = 0x0 mdah = 0x0 rlocn = 0x778d284c i = 0 j = 4223242 vgname_len = 0 vg = 0xe400ba490040 pv = 0x66c440 #6 0x004072d9 in iterate_disk (disk_name=0x66d710 md/0) at ../../kern/device.c:96 dev = 0x0 hook = 0x42e0f0 grub_lvm_scan_device ents = 0x41007fff00e3ff49 #7 0x0042b5ba in grub_raid_iterate (hook=0x7fffe540) at ../../disk/raid.c:84 array = 0x66d4c0 #8 0x004079a8 in grub_disk_dev_iterate (hook=0x7fffe540) at ../../kern/disk.c:212 p = 0x63afc0 #9 0x00407462 in grub_device_iterate (hook=0x42e0f0 grub_lvm_scan_device) at ../../kern/device.c:168 ents = 0x63b010 #10 0x0042ef82 in grub_mod_init (mod=0x0) at ../../disk/lvm.c:679 No locals. #11 0x0042ef6a in grub_lvm_init () at ../../disk/lvm.c:677 No locals. #12 0x0042f072 in grub_init_all () at grub_probe_init.c:58 No locals. #13 0x00402e10 in main (argc=2, argv=0x7fffe6f8) at ../../util/grub-probe.c:443 dev_map = 0x0 argument = 0x7fffe93c / In insert_array() in disk/raid.c, we first check if we already have all the devices of the array. After that we check if the specific member that we want to add already exists. In both cases we just print a debug message instead of returning an error. What happens then is that array-device[new_array-index] gets overwritten and nr_devs gets incremented. Thus nr_devs gets incremented without adding a new disk. When trying to read the raid array later on, some disk pointers are still NULL and we get a segfault when we dereference it. The attached patch returns an error in both cases, so we at least don't segfault (which I tested on the virtual machine). I talked with Julien on IRC, but his segfaults disappeared, so we will probably never know for sure what really happened. Regards, Jeroen dekkers --- grub2-1.98+20100804/disk/raid.c~2010-12-15 18:36:32.0 +0100 +++ grub2-1.98+20100804/disk/raid.c 2010-12-15 19:58:53.0 +0100 @@ -496,17 +496,18 @@ the same. */ if (array-total_devs == array-nr_devs) - /* We found more members of the array than the array - actually has
Bug#605357: Info received (Patch for #605357)
Digging further, I see my patch is just a revert of http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/revision/1184 Robert, do you remember the history of that change? Because as far as I understand the code, grub_raid_register() will just continue to iterate if insert_array() returns an error. If it's just about silencing the error because it is reported non-fatal: I think that's wrong. If you've got array members with the same number, either there is something going wrong in your system, and it's a good thing to report that. Or you're messing around and you know what you are doing and you know that you can ignore the error. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593648: Can't reproduce bug #593648
tags 593648 unreproducible thanks I'm not able to reproduce this bug. I tried to create the same layout: Device Boot Start End Blocks Id System /dev/sda1 1 61 487424 fd Linux raid autodetect Partition 1 does not end on cylinder boundary. /dev/sda2 61 73 97280 fd Linux raid autodetect Partition 2 does not end on cylinder boundary. /dev/sda3 73 110 292864 fd Linux raid autodetect Partition 3 does not end on cylinder boundary. /dev/sda4 110 261 1217536 fd Linux raid autodetect Partition 4 does not end on cylinder boundary. Device Boot Start End Blocks Id System /dev/sdb1 1 61 487424 fd Linux raid autodetect Partition 1 does not end on cylinder boundary. /dev/sdb2 61 73 97280 fd Linux raid autodetect Partition 2 does not end on cylinder boundary. /dev/sdb3 73 110 292864 fd Linux raid autodetect Partition 3 does not end on cylinder boundary. /dev/sdb4 110 261 1217536 fd Linux raid autodetect Partition 4 does not end on cylinder boundary. md3 : active raid1 sda4[0] sdb4[1] 1217472 blocks [2/2] [UU] md2 : active raid1 sda3[0] sdb3[1] 292800 blocks [2/2] [UU] md1 : active (auto-read-only) raid1 sda2[0] sdb2[1] 97216 blocks [2/2] [UU] md0 : active raid1 sda1[0] sdb1[1] 487360 blocks [2/2] [UU] /dev/md0 on / type ext4 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/md3 on /home type ext4 (rw) /dev/md2 on /var type ext4 (rw) I tried installing squeeze directly using the beta2 installer and first installing lenny and upgrading to squeeze. Both worked fine. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573992: postrm uses rm instead of rmdir to remove directory
Package: atftpd Version: 0.7.dfsg-8 Severity: serious Tags: patch Postrm removes the tftp directory with rm -f instead of rmdir, giving the following error when removing the package: Removing atftpd ... Purging configuration files for atftpd ... rm: cannot remove `/srv/tftp': Is a directory dpkg: error processing atftpd (--purge): subprocess installed post-removal script returned error exit status This should fix it: --- debian/atftpd.postrm.orig 2010-03-15 14:43:28.0 +0100 +++ debian/atftpd.postrm2010-03-15 14:59:08.0 +0100 @@ -18,7 +18,7 @@ fi if [ -d $BASEDIR ]; then -rm -f $BASEDIR +rmdir --ignore-fail-on-non-empty $BASEDIR fi # logrotate -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages atftpd depends on: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libpcre3 7.8-3 Perl 5 Compatible Regular Expressi ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra ii update-inetd 4.36 inetd configuration file updater Versions of packages atftpd recommends: ii openbsd-inetd [inet-superse 0.20080125-4 The OpenBSD Internet Superserver Versions of packages atftpd suggests: ii logrotate 3.7.8-4Log rotation utility -- debconf information: * atftpd/port: 69 * atftpd/tftpd-timeout: 300 * atftpd/mcast_port: 1758 * atftpd/verbosity: 5 (LOG_NOTICE) * atftpd/timeout: true * atftpd/tsize: true * atftpd/retry-timeout: 5 * atftpd/multicast: true * atftpd/ttl: 1 * atftpd/use_inetd: true * atftpd/basedir: /srv/tftp * atftpd/mcast_addr: 239.239.239.0-255 atftpd/logfile: /var/log/atftpd.log * atftpd/blksize: true * atftpd/logtofile: false * atftpd/maxthread: 100 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502618: partman: /dev/mapper/vg0-home is apparently in use by the system
I currently have the same problem. The reason the logical volume is in use seems to be that when you finish partitioning and partman goes to the stage of creating the filesystems, the system has suddenly created partitions on top of the volumes. That means there is a /dev/mapper/vg0-homep1, which uses /dev/mapper/vg0-home and makes it impossible to create a filesystem there. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501306: update-grub fails with raid1 boot partition
On Wed, Oct 08, 2008 at 10:46:26AM +0100, Dan Poltawski wrote: On Wed, Oct 08, 2008 at 01:35:53AM -0400, Samat K Jain wrote: On Tuesday 07 October 2008 04:53:57 am Dan Poltawski wrote: Just in response to this - my problem has not been caused by an upgrade - it was a clean lenny install onto a new machine a few days ago. Well, something regenerated device.map since installation. I don't think your system would boot with the device.map you've provided---grub would have ever installed properly. I believe, from what you've provided, your device.map should contain: (hd0) /dev/sda (hd1) /dev/sdb Did you try the workaround? Namely running `grub-mkdevicemap --no-floppy` again? Yes I did, this does resolve the problem and also contains the same map as you guessed at. I'm looking through the apt log to see if I can find anything which would regenerate the device.map since install. It might be possible that the names sda to sdd were used for something that wasn't an hard disk during the install (a card reader with 4 different slots might be a good candidate). Then your system would still boot properly with your old device.map because grub detected that sde was the first hard disk, but then you wouldn't be able to run update-grub because your first hard disk is sda now. Could you check this in the installation log or by running the debian installer again to the point where it detects all the disks? Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474918: Patch for 474918
tags 474918 +patch thanks GCC 4.3 inlines a bit more aggresive than 4.2, this causes _undi_call to be inlined, which results in multiple definitions of rm_undi_call. Telling gcc not to inline _undi_call fixes this bug, see the attached patch. Regards, Jeroen Dekkers etherboot.patch Description: Binary data
Bug#475789: octave3.0: Conflict with octave2.9 must include epoch in version
Package: octave3.0 Version: 1:3.0.0-10 Severity: grave Justification: renders package unusable Installing octave3.0 results in the following: Unpacking octave3.0 (from .../octave3.0_1%3a3.0.0-10_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/octave3.0_1%3a3.0.0-10_amd64.deb (--unpack): trying to overwrite `/usr/share/enscript/hl/octave.st', which is also in package octave2.9 The problem is that the conflicts doesn't include the epoch in the version: Conflicts: octave (= 2.0.16-2), octave2.9 ( 3) I guess that should be 1:3. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages octave3.0 depends on: ii libblas3gf [libblas.so 1.2-1.5 Basic Linear Algebra Subroutines 3 ii libc6 2.7-10GNU C Library: Shared libraries ii libcurl3-gnutls7.18.0-1 Multi-protocol file transfer libra ii libfftw3-3 3.1.2-3 library for computing Fast Fourier ii libgcc11:4.3.0-3 GCC support library ii libgfortran3 4.3.0-3 Runtime library for GNU Fortran ap ii libglpk0 4.28-3linear programming kit with intege ii libhdf5-serial-1.6.6-0 1.6.6-4 Hierarchical Data Format 5 (HDF5) ii liblapack3gf [liblapac 3.1.1-0.4 library of linear algebra routines ii libncurses55.6+20080308-1Shared libraries for terminal hand ii libpcre3 7.4-1+lenny1 Perl 5 Compatible Regular Expressi ii libqhull5 2003.1-8 calculate convex hulls and related ii libreadline5 5.2-3 GNU readline and history libraries ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3 ii libsuitesparse-3.1.0 3.1.0-3 collection of libraries for comput ii texinfo4.11.dfsg.1-4 Documentation system for on-line i ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime Versions of packages octave3.0 recommends: ii gnuplot 4.2.2-1A command-line driven interactive pn libatlas3gf-base none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430210: mhc-utils: Uninstallable because postinst fails
Package: mhc-utils Version: 0.25.1+20070220-1 Severity: grave Justification: renders package unusable Postinst fails and that makes the packages uninstallable: Unpacking mhc-utils (from .../mhc-utils_0.25.1+20070220-1_amd64.deb) ... Setting up mhc-utils (0.25.1+20070220-1) ... dpkg: error processing mhc-utils (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: mhc-utils E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mhc-utils depends on: ii libc6 2.5-9 GNU C Library: Shared libraries ii libgtk2-ruby 0.15.0-1.1 GTK+ bindings for the Ruby languag ii libpisock90.12.2-9 library for communicating with a P ii libruby1.81.8.6-1+b1 Libraries necessary to run Ruby 1. ii ruby1.8 1.8.6-1+b1 Interpreter of object-oriented scr Versions of packages mhc-utils recommends: ii mhc0.25.1+20070220-1 Message Harmonized Calendaring sys -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430210: mhc-utils: Uninstallable because postinst fails
At Sat, 23 Jun 2007 21:09:55 +0900 (JST), Tatsuya Kinoshita wrote: On June 23, 2007 at 1:39PM +0200, jeroen (at dekkers.cx) wrote: Postinst fails and that makes the packages uninstallable: Unpacking mhc-utils (from .../mhc-utils_0.25.1+20070220-1_amd64.deb) ... Setting up mhc-utils (0.25.1+20070220-1) ... dpkg: error processing mhc-utils (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: mhc-utils E: Sub-process /usr/bin/dpkg returned an error code (1) Hmm, I cannot reproduce this bug. mhc-utils is installable on my environment (sid, i386). Anyway, I'll cleanup mhc-utils.postinst to fix this bug in the next upload. Debugging the postinst, the problem seems to be db_get 'shared/pilot/port' If I install kpilot, which asks the debconf question which port to use, the problem goes away. Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383298: python-wxgtk2.6: should be build for python 2.4
Package: python-wxgtk2.6 Version: 2.6.3.2.1.4 Severity: grave Tags: patch Justification: renders package unusable With python 2.4 being the default in sid and wxWidgets using python 2.3, programs that use the default python version and wxWidgets don't work anymore (e.g. bittornado-gui). I tried building wxWidgets for python 2.4 and I didn't encounter any problem. Bittornado-gui also works fine with the pyton 2.4 wxwidgets packages. This is the patch I used: --- wxwidgets2.6-2.6.3.2.1.4/debian/python-version 2006-05-01 06:39:13.0 +0200 +++ wxwidgets2.6-2.6.3.2.1.4jeroen/debian/python-version2006-08-16 12:28:38.0 +0200 @@ -1 +1 @@ -python_ver := python2.3 +python_ver := python2.4 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-amd64 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages python-wxgtk2.6 depends on: ii libc62.3.6-15GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3 ii libwxbase2.6-0 2.6.3.2.1.4 wxBase library (runtime) - non-GUI ii libwxgtk2.6-02.6.3.2.1.4 wxWidgets Cross-platform C++ GUI t ii python 2.4.3-11An interactive high-level object-o ii python-central 0.5.5 register and build utility for Pyt ii python-wxversion 2.6.3.2.1.4 wxWidgets Cross-platform C++ GUI t ii python2.32.3.5-15An interactive high-level object-o python-wxgtk2.6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373917: python-formencode should conflict with python2.4-formencode too
Package: python-formencode Version: 0.5.1-1 Severity: grave Justification: renders package unusable Python-formencode only conflicts with python2.3-formencode ( 0.5.1), but it should also conflict with python2.4-formencode ( 0.5.1), because it contains both the python 2.3 and 2.4 code. I got the following error: dpkg: error processing /var/cache/apt/archives/python-formencode_0.5.1-1_all.deb (--unpack): trying to overwrite `/usr/lib/python2.4/site-packages/formencode/__init__.py', which is also in package python2.4-formencode dpkg-deb: subprocess paste killed by signal (Broken pipe) After purging python2.4-formencode everything is okay. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-amd64-k8-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages python-formencode depends on: ii python2.3.5-9An interactive high-level object-o ii python-central0.4.17 register and build utility for Pyt python-formencode recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
