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#825970: pypy: Please package pypy3 as well now
On Wed, 11 Jul 2018 11:38:31 +0200, Lumin wrote: > Python2 is dying. Is there any reason so that pypy3 shouldn't be > compiled and uploaded? If you lack time and need help, please just ask. I'd also like to see pypy3 packaged. Is there already any work done on packaging pypy3? If not then we should probably start with creating a pypy3 source package based on the pypy2 packaging.
Bug#682347: mark 'editor' virtual package name as obsolete
On Thu, 24 Aug 2017 19:16:53 +0200, Christoph Berg wrote: > > Re: Russ Allbery 2017-08-24 <87efs1lyc7@hope.eyrie.org> > > Oh, thank you! For some reason, apt-cache rdepends didn't show any of > > those packages. All of them except dnsvi are Suggests, which basically > > doesn't accomplish anything. > > > > Copying myon on this message as maintainer of dnsvi, which has a > > dependency on "vim | editor". Christoph, we're proposing finally removing > > the editor virtual package completely, with the patch included here: > > Thanks for the notice. I'm quite surprised that my dnsvi seems to be > the only package in Debian that requires a text editor. Given that our > base doesn't really include one, and getting dependencies Just Right > is among the things that Debian is really good at, dropping the > existing "editor" virtual package seems Just Wrong to me. Nano is priority important which means it will be installed by default and someone who explicitly uninstalls nano will probably also install another editor. I doubt a dependency on editor will make any difference in practice. Kind regards, Jeroen Dekkers
Bug#783581: [Pkg-samba-maint] Bug#783581: samba-tool ImportError libnetif.so.0 invalid ELF header
Control: tag -1 unreproducible moreinfo At Tue, 28 Apr 2015 09:21:38 +0300, Risto Paavola wrote: > > The problem seems to be bigger. A lot of samba tools, including samba itself > are not working: > # samba_dnsupdate > Traceback (most recent call last): > File "/usr/sbin/samba_dnsupdate", line 41, in > import samba > File "/usr/lib/python2.7/dist-packages/samba/__init__.py", line 50, in > > from samba._ldb import Ldb as _Ldb > ImportError: /usr/lib/x86_64-linux-gnu/samba/libnetif.so.0: invalid ELF header > > # samba_upgradedns > Traceback (most recent call last): > File "/usr/sbin/samba_upgradedns", line 32, in > import samba > File "/usr/lib/python2.7/dist-packages/samba/__init__.py", line 50, in > > from samba._ldb import Ldb as _Ldb > ImportError: /usr/lib/x86_64-linux-gnu/samba/libnetif.so.0: invalid ELF header > > # samba > samba: error while loading shared libraries: > /usr/lib/x86_64-linux-gnu/samba/libnetif.so.0: invalid ELF header I can't reproduce this on my system. Can you show me the output of "ls -al /usr/lib/x86_64-linux-gnu/samba/libnetif.so.0"? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium
At Sun, 05 Apr 2015 22:12:02 +0200, David Douard wrote: > > Package: wnpp > Severity: wishlist > Owner: David Douard > > * Package name: libnacl > Version : 1.4.2 > Upstream Author : Thomas S Hatch > * URL : https://libnacl.readthedocs.org/ > * License : Apache 2.0 > Programming Lang: Python > Description : ctypes wrapper for libsodium > > This library is used to gain direct access to the functions exposed by > Daniel J. Bernstein's nacl library via libsodium or tweetnacl. It has > been constructed to maintain extensive documentation on how to use nacl > as well as being completely portable. > > This package is a dependency for raet, the new transport layer for salt. I think it would be better to name the package python-libnacl to prevent confusion with nacl itself. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741464: grub-pc-bin: hangs after displaying boot menu
Thu, 16 Oct 2014 17:57:20 +0200 Sven Joachim 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-dist-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" 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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767990: [Pkg-samba-maint] Bug#767990: samba: dependency on too old version of Heimdal kerberos
Control: reassign -1 libkrb5-26-heimdal 1.6~rc2+dfsg-8 Control: retitle -1 libkrb5.so.26: krb5_ntlm_init_get_challange symbol disappeared At Mon, 03 Nov 2014 23:19:58 +0100, Oxan van Leeuwen wrote: > The Samba version currently in jessie has a dependency on a too old version > of Heimdal Kerberos. When I installed the Samba package from jessie on a > wheezy > host, Samba failed to start and samba-tool gave the following output: If you want a newer samba on wheezy you should install samba from wheezy-backports, because that is what is supported and tested. > 23:11 oxan@oppenheimer [#125 0] /var/log/samba$ samba-tool testparm > --parameter-name="server role" > Traceback (most recent call last): > File "/usr/bin/samba-tool", line 33, in > from samba.netcmd.main import cmd_sambatool > File "/usr/lib/python2.7/dist-packages/samba/__init__.py", line 50, in > > from samba._ldb import Ldb as _Ldb > ImportError: /usr/lib/x86_64-linux-gnu/libgssapi.so.3: symbol > krb5_ntlm_init_get_challange, version HEIMDAL_KRB5_2.0 not defined in file > libkrb5.so.26 with link time reference As far as I can see this is actually libgssapi.so.3 in wheezy having problems with libkrb6.so.26 from jessie because krb5_ntlm_init_get_challange has been renamed to krb5_ntlm_init_get_challenge (typo got fixed) without providing a compatibility symbol or bumping the SO version, so reassigning to heimdal. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763762: [Pkg-samba-maint] Bug#763762: Bug#763762: samba-libs depends on libcups2 (>= 1.6.0) which makes it hard to install cups 1.5
At Mon, 6 Oct 2014 10:33:45 +0200, Michal Hocko wrote: > > On Sat, Oct 04, 2014 at 04:08:37AM +0200, Jelmer Vernooij wrote: > > On Thu, Oct 02, 2014 at 03:41:56PM +0200, Michal Hocko wrote: > > > after having serious problems with the current cups 1.7 version > > > I have decided to go back to 1.5 version. The downgrade stumbled > > > over samba-libs dependency, though, which in turn requires a lot of > > > downgrades including the whole kde stack from 4.14 to 4.8 resulting in > > > an unpleasant: > > > --- Packages being removed because they are no longer used (66) > > > --- Packages being automatically held in their current state (14) > > > --- Packages being automatically installed to satisfy dependencies (39) > > > --- Packages to be downgraded (90) > > > --- Packages being held back (12) > > > --- Packages to be removed (14) > > > > > > This looks like a major pain just because of a single dependency. So I > > > was curious whether samba-libs really needs libcups >= 1.6 or it would > > > work with older versions as well. > > > I cannot seem to find anything in the changelog that would mentioned > > > bump up of the dependency because of a bug or feature. The previous > > > libsmbclient which seems to be behind most of the dependency hell didn't > > > depend on samba at all > > > Version: 2:3.6.6-6+deb7u4 > > > Depends: libc6 (>= 2.10), libcap2 (>= 2.10), libcomerr2 (>= 1.01), > > > libgssapi-krb5-2 (>= 1.10+dfsg~), libk5crypto3 (>= 1.6.dfsg.2), libkrb5-3 > > > (>= 1.10+dfsg~), libldap-2.4-2 (>= 2.4.7), libtalloc2 (>= > > > 2.0.4~git20101213), libtdb1 (>= 1.2.7+git20101214), libwbclient0 (>= > > > 2:3.6.0~pre3), zlib1g (>= 1:1.1.4) > > > > > > This leaves a hope that 1.6 dependency came with the new samba-libs > > > which used the current up-to-date libcups version. But I might be > > > completely wrong here of course. > > > > I'd be open to changing this to libcups2 >= 1.5; I'm not aware of a > > specific reason we need 1.6. > > That would be really great! I wanted to try to rebuild the package with > the changed dependency but I couldn't find it in the control file > because it seems to be auto-generated. Then I failed to understand > how to sneak the right version in. > > Is there anything more I can help you with? As far as I can see, the dependency is indeed auto-generated and that means it depends on libcups2 >= 1.6.0 because it uses symbols that don't exist in earlier versions of the library. Given that packages in unstable are always build against packages from unstable there isn't much we can do about that. If you want a samba package that uses an older version of libcups2 you can try using the packages from wheezy-backports which are build against the wheezy libcups2. You can also try to build the package yourself with an older version of libcups2-dev installed. Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762397: [Reproducible-builds] Bug#762397: libgpg-error: please do not capture the current time during the build process
At Mon, 22 Sep 2014 15:15:50 -0400, Daniel Kahn Gillmor wrote: > > On 09/21/2014 04:58 PM, Dominic Hargreaves wrote: > > On Sun, Sep 21, 2014 at 10:45:14PM +0200, Jérémy Bobbio wrote: > >> As part of the “reproducible builds” effort [1], it was detected that > >> libgpg-error could not be built reproducibly. > >> > >> The build process capture the time of the build. This piece of > >> information is not really helpful to anyone and prevents the build > >> process from being deterministic. > >> > >> The attached patch will instead use the time of the latest > >> debian/changelog entry. Once applied, libgpg-error can be built > >> reproducibly! :) > > > > Wouldn't it be better to patch configure.ac in a way useful to upstream; > > for example by having it use the time from an exported environment > > variable? Otherwise the package is going to have to carry around a > > Debian-specific patch forever. > > I like Dominic's suggestion (we'd need to pass the env var from > debian/rules), and i'll see what i can suggest upstream. Jérémy actually already wrote a patch for dpkg-buildpackage to export DEB_BUILD_TIMESTAMP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75 But if we want to push these things upstream, wouldn't it be better to remove the DEB_ prefix from the name of the environment variable? Jeroen Dekkers
Bug#756172: ITP: ssh-cron -- cron-like job scheduler that handles ssh key passphrases
At Wed, 30 Jul 2014 22:17:43 -0700, tony mancill wrote: > I contacted the upstream author (on the cc: - hi Frank), and his concern > with the passphraseless key trigger mechanism is precisely that you > don't have a passphrase. The key is unprotected and subject to > theft/unauthorized use. This could potentially occur on the system that > is (normally) the legitimate source of the trigger. But ssh-cron will need to have the passphrase to be able to use the key, so someone who can steal the key from ssh-cron can also steal the passphrase from ssh-cron. What is the added security benefit of storing a key and passphrase instead of a passphraseless key? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756361: The httpd virtual package should be provided by apache2, not apache2-bin
Package: apache2 Version: 2.4.10-1 Severity: important Currently the httpd virtual package is provided by apache2-bin, but apache2-bin does not include the configuration files and init scripts, so it doesn't provide a working web server. The apache2 package has those files and should be the package providing the httpd virtual package. This is also how it is in wheezy, where httpd is provided by the mpm packages which depend on apache2.2-common for the configuration files and init scripts. I set the severity to important because web applications that depend on httpd currently won't work with only apache2-bin installed. See also the following thread on debian-devel about this: https://lists.debian.org/debian-devel/2014/07/msg01065.html -- 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-32-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716880: Solutions for the Apache upgrade hell
At Sun, 13 Jul 2014 13:17:24 +0200, Arno Töll wrote: > What would you do in our situation? Side note 2: We kinda expected this > situation and added a trapdoor in Wheezy [1], but it turned out, that > even that is not good enough to prevent havoc with --purge-unused. It's not really ideal either, but another option would be doing an update in the next wheezy point release preparing this migration. For example moving the configuration files from apache2.2-common to apache2 or apache2.2-bin in wheezy shouldn't cause any problem and after the files have been moved apache2.2-common can be safely purged during upgrade. Moving them to apache2 package would mean you won't have to move them again in the upgrade to apache 2.4, but it would create a new and circular dependency of apache2.2-common on apache2. Given that apache2.2-common already depends on apache2.2-bin and there exists a transitional package in jessie it might be a better candidate. Then you would have to move it again in the jessie package, but I'm afraid there aren't any easy solutions. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
At Sat, 12 Jul 2014 14:46:45 +0200, Toni Mueller wrote: > On Sat, Jul 12, 2014 at 02:15:13PM +0200, Kurt Roeckx wrote: > > > I'm not really sure what you mean by this. I'm pretty sure the > > openssl development team has a pretty good understanding of > > security and I don't see anybody adding a backdoor in it. > > Ok, but for whatever reason, they have an imho not as shiny track > record, as has OpenBSD. Which is no wonder, given all the revelations we > have had recently, but hey, sometimes one has to make a decision. OpenSSL was part of OpenBSD before they created the LibreSSL fork, so how isn't OpenSSL part of the OpenBSD track record? > > I think GnuTLS is actually a better alternative and wish there > > were more people developing and using it. > > But developing GnuTLS is a full-time job, and then there's the control > problem with the FSF - you are certainly aware about the problems the > original upstream ran into when he wanted to break loose from the FSF > (for a reason I have forgotten). LibreSSL is a much lower-hanging fruit, > as it is supposed to be mostly, or entirely, plug-compatible with > OpenSSL. To me, the playing field largely looks like this atm: > > * GnuTLS, with an API incompatible with OpenSSL, thus requiring huge >amounts of work to make significant use of it. It depends on how you look at it. If you see the OpenSSL API as something that isn't really well designed then other libraries not copying the API is actually a good thing. > * MatrixSSL, which once had a dubious license, and which still did not >come out too well in the SSL lib comparison I recently saw (see the >list archive), > * the now newly staffed OpenSSL project, with their mixed track >record (eg. "FIPS"), and now > * LibreSSL, which sounds much like an OpenSSL on a diet, and with some >exercise, and promising thrust behind it, but mostly simply a >drop-in. You forget one of the big problems with OpenSSL that LibreSSL doesn't fix: the license. It actually makes the mess even bigger, given that some of the GPL exceptions only talk about "the OpenSSL library" and don't exempt OpenSSL-derived code. So even if LibreSSL is a drop-in for OpenSSL we can't replace OpenSSL with LibreSSL for those projects. You also forget to list two other TLS libraries: * NSS, in my opinion the biggest downside of NSS is that it includes NSPR. This both increases the code size a lot and makes the API less nice if I remember correctly. * PolarSSL, which I really like from a technical point of view. Featurewise it is pretty complete (the only major feature it doesn't implement is DTLS AFAICS), while being one tenth the size of OpenSSL / GnuTLS: https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Code_size_and_dependencies PolarSSL is also used by OpenVPN-NL, the hardened OpenVPN version that is used by the Dutch government. The downsides are that it looks like it doesn't have a stable API and contributing needs copyright assignment because it is dual-licensed. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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.
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-dist-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=revision&revision=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-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673538: libobjc3 -> libobjc4 transition
At Tue, 03 Jul 2012 00:44:00 +0300, Yavor Doganov wrote: > > At Sun, 01 Jul 2012 00:02:17 +0100, > Adam D. Barratt wrote: > > > If we postponed the main transition(s) until wheezy+1, would the > > gnustep-base upload be the only thing required for wheezy? > > Yes, it would be the only thing needed if we talk about the core > GNUstep packages (-make, -base, -gui, -back). We'll have to fix the > RC bugs in the other packages, but that goes without saying. I'm working on the SOGo packaging and just saw that we haven't done this transition yet. What is blocking it? Lack of time? Is there anything I can help with? I don't have a lot of time available either, but if it is just packaging gnustep-base 1.24.6 and uploading it I should be able to help with that. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732189: sogo: Need 2.1 version
Yes, I plan to package sogo 2.1, but I didn't have time for it in the
past weeks and won't have time in the next couple of weeks either.
At Sun, 15 Dec 2013 14:04:24 +0100,
nb wrote:
>
> Package: sogo
> Version: 2.0.7-2
> Severity: minor
>
> Dear Maintainer,
>
> I'm using z-push-contrib wich is a z-push (d-push under Debian) active sync,
> not yet in the main branch.
> The problem is that CARDDAV part takes care of sogo 2.1, which works
> differently from 2.0 in the naming of vcards urls.
>
> Do you plan to package sogo 2.1 which is available since dec 5th
>
> Thanks
>
>
> -- System Information:
> Debian Release: jessie/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.10-3-686-pae (SMP w/1 CPU core)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages sogo depends on:
> ii adduser 3.113+nmu3
> ii gnustep-base-runtime 1.22.1-4.2+b1
> ii libc6 2.17-97
> ii libcurl3-gnutls 7.33.0-1
> ii libgcc1 1:4.8.2-8
> ii libglib2.0-0 2.36.4-1
> ii libgnustep-base1.22 1.22.1-4.2+b1
> ii libgnutls26 2.12.23-8
> ii liblasso3 2.3.6-2.2+b2
> ii libmemcached101.0.8-1
> ii libobjc4 4.8.2-8
> ii libsbjson2.3 2.3.2-2
> ii libsope1 2.0.7-1
> ii libssl1.0.0 1.0.1e-4
> ii libxml2 2.9.1+dfsg1-3
> ii libxmlsec11.2.18-2
> ii libxmlsec1-openssl1.2.18-2
> ii libxslt1.11.1.28-2
> ii sogo-common 2.0.7-2
> ii tmpreaper 1.6.13+nmu1
> ii zip 3.0-8
>
> sogo recommends no packages.
>
> Versions of packages sogo suggests:
> ii mysql-server 5.5.33+dfsg-1
>
> -- Configuration Files:
> /etc/sogo/sogo.conf changed:
> {
> SOGoProfileURL = "mysql://sogo:4989@127.0.0.1:3306/sogo/sogo_user_profile";
> OCSFolderInfoURL = "mysql://sogo:4989@127.0.0.1:3306/sogo/sogo_folder_info";
> OCSSessionsFolderURL =
> "mysql://sogo:4989@127.0.0.1:3306/sogo/sogo_sessions_folder";
> OCSEMailAlarmsFolderURL =
> "mysql://sogo:4989@127.0.0.1:3306/sogo/sogo_alarms_folder";
> SOGoLanguage = French;
> SOGoAppointmentSendEMailNotifications = YES;
> SOGoMailingMechanism = smtp;
> SOGoSMTPServer = 127.0.0.1;
> SOGoTimeZone = "Europe/Paris";
> SOGoSentFolderName = Sent;
> INBOX/SOGoTrashFolderName = Trash;
> SOGoDraftsFolderName = Brouillons;
> SOGoIMAPServer = "imaps://localhost:993/?tls=YES";
> SOGoSieveServer = "sieve://localhost:4190/?tls=YES";
> SOGoIMAPAclConformsToIMAPExt = YES;
> SOGoVacationEnabled = NO;
> SOGoForwardEnabled = NO;
> SOGoSieveScriptsEnabled = NO;
> SOGoFirstDayOfWeek = 0;
> SOGoMailMessageCheck = manually;
> SOGoMailAuxiliaryUserAccountsEnabled = NO;
> SOGoFirstDayOfWeek = 1;
> SOGoMailMessageCheck = every_minutes;
> SOGoLoginModule = Calendar;
> SOGoMailDomain = dagami.org;
> SOGoUserSources = ({canAuthenticate = YES; displayName = "SOGo Users"; id =
> users; isAddressBook = YES; type = sql; userPasswordAlgorithm = md5; viewURL
> ="mysql://sogo:4989@127.0.0.1:3306/sogo/sogo_users";});
> SOGoSuperUsernames = (admin);
> // SOGoPasswordChangeEnabled = YES;
> // GCSFolderDebugEnabled = YES;
> // GCSFolderStoreDebugEnabled = YES;
> // ImapDebugEnabled = YES;
> }
>
>
> -- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692984: upstream binary / DAViCal / CardDAV problems on wheezy
At Thu, 29 Aug 2013 14:21:20 +0200, Daniel Pocock wrote: > I have a Debian wheezy server running the DAViCal package > > On the desktop, I have icedove and iceowl-extension (Calendar). They > work fine with the DAViCal server for calendar/tasks. I've also tested > the Evolution client using DAViCal for contacts, that works fine too. > > I downloaded upstream's SOGo Connector plugin for ThunderBird 10 and > installed it in icedove. It appears to install successfully and I can > define a "Remote Address Book", but I can't see any of the contacts in > DAViCal and I can't create any either. > > Is the ThunderBird 17 variant of this plugin more likely to work > successfully? The plugin is developed for SOGo and only tested on SOGo, so I don't think the newer version is more likely to work than the older version... Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714771: Yate modules should not be executable
Package: yate Version: 4.3.0-1~dfsg-2 Severity: normal Currently yate modules are installed executable, but according to the the Debian policy they shouldn't. See also the discussion at http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2013-June/023703.html -- 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-23-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677951: sogo: tmpreaper issue
Hi Michael, At Sun, 15 Jul 2012 07:55:44 +0200, Michael Biebl wrote: > > Hi, > > > It needs tmpreaper for the cron.daily job that cleans up the > > /var/spool/sogo directory where drafts are temporarily stored. From > > reading the tmpfiles.d manpage, it seems that to get the same > > functionality I should create a file /etc/tmpfiles.d/sogo.conf with > > the contents: > > since this is a tmpfiles.d snippet provided by a package, install it in > /usr/lib/tmpfiles.d/. /etc/tmpfiles.d is supposed to be reserved for the > local administrator It's a configuration file provided by the package, so shouldn't it be put in /etc according to the Debian policy? Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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#700888: Can't start OpenVPN using ifupdown when running systemd
Package: openvpn Version: 2.2.1-8 Severity: normal When running systemd it isn't possible to start OpenVPN using ifupdown. The problem is that /etc/network/if-up.d/openvpn calls "/etc/init.d/openvpn start $vpn". When running systemd this call is changed to "systemctl start openvpn" by the lsb functions provided by systemd and the $vpn argument is lost. -- 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-23-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691552: unblock: yate/4.1.0-1~dfsg-3
At Sun, 11 Nov 2012 18:36:14 +0100, Julien Cristau wrote: > > On Wed, Nov 7, 2012 at 09:28:28 +1100, Mark Purcell wrote: > > > On Wed, 7 Nov 2012 00:32:36 Paul Chitescu wrote: > > > > unblock yate/4.1.0-1~dfsg-3 > > > > > > > > [...] > > > > > > Does this require any more action? > > > > Hi Paul, > > > > Yes we are awaiting a decision from debian-release. > > > debian-release don't like the debian/rules changes much. I think we can all agree on that. Such changes shouldn't happen during the freeze, but the problem is that the debian/rules file is buggy: http://anonscm.debian.org/viewvc/pkg-voip/yate/tags/4.1.0-1~dfsg-2/debian/rules?revision=9806&view=markup On line 21-22 and 96-97 you see the use of dh, but in lines 24-94 old style debhelper is used. This is just wrong and causes bugs. The proper fix would be to use only one style and this is what Mark did in the last version. It might be possible to spend a lot of time to see whether the known bugs can be fixed with minimal changes and just hope there aren't more bugs caused by the mix of debhelper styles, but I think that's a waste of time and keeping the mix of debhelper isn't going to make reviewing what's going on easier. Yate is also just a leaf package. If Yate gets new RC bugs because of these changes and those aren't quickly fixed it can simply be removed from testing. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683229: [yate-core] module regfile is missing but its config file exists
reassign 683229 yate retitile 683229 Binary package "yate" doesn't ship any module at all severity serious thanks At Mon, 30 Jul 2012 02:15:44 +0200, Lars Kruse wrote: > as a novice user of yate it took me some time to understand why the settings > in > my /etc/yate/regfile.conf file were ignored completely. Finally I realized > that > the regfile module is not part of the debian package. > > Please either add the regfile module (which is great for a quick start) or > remove the corresponding config file in order to avoid confusion. Due to a bug in debian/rules the yate binary package doesn't have any modules at all. Severity bumped to serious because we actually miss 34 modules because of this. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688018: Please add Jeroen Dekkers as a Debian Maintainer
Package: debian-maintainers Severity: normal Please add Jeroen Dekkers as a Debian Maintainer. Jetring changeset is attached. -- 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-14-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 Comment: Jeroen Dekkers Date: Tue, 18 Sep 2012 10:14:59 +0200 Action: import Recommended-By: Jelmer Vernooij , Thijs Kinkhorst Agreement: http://lists.debian.org/debian-newmaint/2012/09/msg00015.html Advocates: http://lists.debian.org/debian-newmaint/2012/09/msg00016.html http://lists.debian.org/debian-newmaint/2012/09/msg00018.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQGNBE4Q018BDAC8iV5v7cCqZiY1l6Z/iX7XkGCAN0KSkCc1B7NY1zk//EY6lzXY dZQuGWhdltziV1jxY3hRYpQee/JenNq4eiOLVc/BXhLjfVZbVa9zUHf7aINirxQw L2nHvfk9HhHIZJzS1nKDqecIMDFrPHONujITWNvjdsOlwLluuItl4Q3Es9mJdqeM zI0HH737IuqlvxDEH9ajFJQ8Rl1pUSr5mq/3BkvYe+JS4V7RtEyiMX/9LduLNZG+ D0UIklgQ7c6ZfRYEzzqPXwuBGFHYTDFRvVSZye6gbQvSe+T2Z9/6iQaMDFvpax0r 4isYxUmAJM8ivOc4wOBe2ezIyjXNvihUT+SVTqIVmVeLBzrm/T4Vd1graE1IO3O7 mOz2gi8+BjjAO34AGqdA+6dqOeRlYbIpY5FFNkfpvLJI/ue3OfbaPpTMA3T2e/Fv 4xCYMZsq1+zS0XKUBWk07QFeX5J7A9AtnSm4FA3V3UsZT8tWNB5Ad8GMTxxMQGXy mPIDyuPwS7ZFkLUAEQEAAbQiSmVyb2VuIERla2tlcnMgPGplcm9lbkBkZWtrZXJz LmNoPokBvQQTAQgAJwIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAUCThDWGAUJ CWYENAAKCRAK2ymcHxN8n95fC/91LeG/8oc398Tu5mWLom1jVNGLwPdEln9rbHxp 1SUbQ76Hrgs+0swjIy57mZOgD9nyBERXe8tKKU318bdVBbO7T7GfiQ4czV2/wNNy 5NKkGKac6gjbgCuO4sGTI+PgdR6Da1NLdOl6DdL535iUgZa/yoKRdala1/PiE1r+ jF4SXNMa7RJMcMs/oSwo/fAp87nyb4zh4ugtG7f5YplmJ4fBZBGypwLe39DO7isx L09QU46NK7fA37SWyRsXXKWQghuNc9jYFXND2NS27t+Xge+RA5cjjOh7/PO59Ny/ 9YRArJrN9gOOZvNcDxdL+HkVGq7Ah2CB2h01Jx80LvOpeKqzjQcqSbYbkIuqQep1 AT5LctpV9qrlsvj8nRBmd2TIaAvaQHLtWogQEjqR8dTLt7XtopSh966L7W3xtsFc PgCDhzAmwdgAYtp9VBo8wbecxrm9Q6bQD1R8VtYAJ8DSWVcWHclW0mkMPv+Ox6EB Gp/IqTGbwHRZrKvt62N3PgUq8JSIRgQQEQgABgUCThD00QAKCRCLSsSBrB5xXpKL AJ9Zija3HzTCy/Ky3IkZPrYMAsGzugCdH6XCx5kVWbjwKo9XH2XFYUIKYQ2JAhwE EAEIAAYFAk6NY/UACgkQRJKitEgIT02nRw/+IuYSXZp09EZlWLS7uqw1Hosa86BJ Wz1PK7A02tx/qrVjBZPQX8ljmQKE2rglgUDc76rM2kRT1IHF/dUnlFJT9b3XnvJI RWzf1eI3Fbnz1L3OLyJdufqlCjTDwiv0pR4ZNOqqF2xYYXFVw03t2S9Besa3siQz cxG233eRBftS1ph2b4AsnMbzVq5qPBeQsvAU52X0N6Y/B4dMWOJ9PFi0Xf1qOGeq oICMMmEbzXz+AboSUzsDEbUqCBDhjywZ4bSA8nKr5rRaZIRJsPrDrLSbNw9Yzd5U tt/aNZ2A/V/q5n1h15UVSBvHub+2cSMBsRPJl9UZ9Z67IE5QC4+YoBWf4QR90WDQ 8XRW+CAS045Sc+AkyEmCLxn3eq6B6Um9W/AmN71IWD0RCJm3VFM11pmgJ8rcEf9N r5UrP523BGtW9XAThb4IFFmQ/OS+msM5ND+iOyqJrgvldszxQZPMRKf8SZyr5Pyu XrLUEKwpYVGuQQBv+1Os77Sc470ewGwQmZiVtpxY23hLcjUy46KtnIUUXI8tKHnl 23BVQuqRn479GURle/2iBJghbiXFceI2roRIKoBP55yGou641yoykjpF8mm2ieJ2 d0pFhLTGdd6THG+0HaSSxI9GhqEsf9Qwk1kpSIpisN/suJhqD94bxAxH9aRNI4TO p39/umgfRl13X8KIRgQQEQgABgUCTi8otQAKCRD2KOuTR0MgbFEJAJ4gZHHKkJU0 j7dttqv3M+4DI/IlcgCfTp7B3n3g3DmXw3vkFRkK8F2dbhuJAhwEEAEIAAYFAk4v KLUACgkQPZCKs/D79R9mdg//aq7FxW75kg6UJPYIilRE/BWTjzU27yG7+cxpbeqv z/xhUwv/503Aa5YqVgKoJmeKBqGZ8f/6K/H5kwv9jQy+qxVzAHIoE/zasu/wu9BJ dBZAGpxbkdMhI4npzA9k+fobVu02r8frs0S9iSzolt5CNJs/jHBDKjfJ+N1rdWi5 ME2uJarsG4tzw+U476WXyXHt90SDYeUIula2uLAiwZpj8/Tewwlh454mRELADgG7 Yt2StRbP27nT83YSFVqo0cv35XFPdjPsAkkO+X4OTs4np+5Lih+aTJnUR3FTYCv/ o7AUXqSEEmaWzXJWlA7PGmKYOKgsOAfnswVxttChZvJ4kXodNAzeeKesaOPfblvt W3DtxxTS2VKIOLHMHrCtRtUl2GFVBXxtDVK/xtFYlxDphxldRDG9ks1h+/5WH65M Kta3oStqM8sAsR6RW2fy0g0qoq2ZTYCs44WNYwn/RWZj3Ijd5d9Gry/zlJ150S5T iVWpg7kGuanHNmYDoi4Uhl6quhvvBC+JReN5myAMc1MOPmbNsn1PoUWd0w7si1HQ mDA+rRXTUYdwOzLgbNxgdYtN4lI6K12GJJMntSQkknaA0uAPOQjZAYVgCqvBE/Ue f550rFdqWgjFQU5k7L7oB6UbIdXo4bAsYqU2vqOkzuCU9y6UyJ5Wt36fckJ3ipx6 mWGJAvQEEAEKAN4FAk4vM46HFIAAEABuc2lnbm90ZXNAZ3JlcC5iZSJodHRw Oi8vd3d3LmdyZXAuYmUvZ3BnL0NGNjIzMThENUJCRUQ0OEYzM0FDRDU0MzFCMDAw NjI1NkZCMjkxNjQvMEQ4MEVBQkIwNDQ3NkU1NDJDOTQwOEUxMEFEQjI5OUMxRjEz N0M5Ri5hc2MiTxpodHRwOi8vd3d3LmdyZXAuYmUvZ3BnL0NGNjIzMThENUJCRUQ0 OEYzM0FDRDU0MzFCMDAwNjI1NkZCMjkxNjQvY2VydC1wb2xpY3ktdjIACgkQGwAG JW+ykWQxvw//cc92+fgRA1ls78c3uo+GgK/VS/OL1eX3mcircoh8OyABpp9me1CO vhcHsrTPX5nxivGwvik38WZkt1vwJ5aXlKrEydZyqLJXc2IBGvRc5u+svRVYOZ2U wsEzmr3gmgM4XYWHLA6OLsUW3ez+K/RjQVpv6vEA9isiaApbj330+Qb+WgY7Xg5H rrkvHdMFft7V24dWvIXUc9XijtvUqu6KRbEd5owtZZzhCDNCJn+1b9ZUlfZ19ESJ ooMjO6Z745JGnWMrGcUOZN+edzK1aRbt/+jpoHX2Wee/T7+4wkoNUGmK1q/EjUDA r2V/AMWf1uwQRjqldoPJDmpfm2MYMBkmqHrashWeWkgm2riNoHocntsTDOx4T8px jogK9kz0dLJbONMXYedFlHISDLD7MdhMODHhuL/B4L6D5nP0b/STzQR4uGSAJcEX Zg73sdMUSWaaD4eG6G8n4+OUoB4QUHFYHj0hwpwN35N2cuZcfo+njIP0BI21Gf/s 84goQQXqx6UIFPkaisrk0tRCwE6SaPwDnukkgACh/SnA4kXWCjA1BkkxA8Tu5OHW KMBy1upO17Nr/e2sTyAe+hb2B2DFheJbfXRn+l7kBXpO5rxyHHbsJrwvUZPolcvY e+rf8CeqVBc6qJJwPTxhvuaT
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 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=9912&view=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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682683: unblock: sope/1.3.16-1
At Wed, 1 Aug 2012 22:36:12 +0200, Julien Cristau wrote: > > On Tue, Jul 24, 2012 at 17:33:09 +0200, Jeroen Dekkers wrote: > > > The upstream release is a bugfix only release. Most of the fixes are > > already in 1.3.15-4 because they are debian fixes submitted upstream > > or were backported from development version to the debian package. The > > only actual changes in the Debian package are: > > > > * Build with hardening enabled > > * Addition of two methods to classes in NGLdap > > * Change in NGObjWeb to not use a deprecated method > > > That doesn't sound like it fixes an important bug in the package, or am > I missing something? Although enabling hardening doesn't fix an important bug, it does add a lot of protection against security bugs. It's a release goal and if I'm right changes for release goals are also allowed. SOPE includes a lot of old code that deals directly with untrusted input from the web, having hardening enabled for such code is important in my opinion. The two new NGLdap methods are used by SOGo 1.3.16 and I'm not sure that it works correctly when used with an older SOPE version that doesn't have these methods. It's not really a tested/supported configuration and I would have to check that if the added hardening isn't a reason to unblock. The deprecated method change doesn't really matter at all. I prepared these packages with the intention that they were uploaded before the freeze, but my sponsor didn't had the time to do the upload. That's why it's included, but I can't see how that change can cause any problems. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681469: unblock: sbjson/2.3.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package sbjson The new version builds with hardening enabled and links correctly with the libraries it depends on, resulting in correct Depends. unblock sbjson/2.3.2-2 -- 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-26-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 sbjson-2.3.2/debian/changelog sbjson-2.3.2/debian/changelog --- sbjson-2.3.2/debian/changelog 2012-05-09 23:11:11.0 +0200 +++ sbjson-2.3.2/debian/changelog 2012-06-29 19:11:14.0 +0200 @@ -1,3 +1,10 @@ +sbjson (2.3.2-2) unstable; urgency=low + + * Build with hardening enabled. + * Correctly link with libobjc and libgnustep-base. + + -- Jeroen Dekkers Fri, 29 Jun 2012 19:09:28 +0200 + sbjson (2.3.2-1) unstable; urgency=low * Initial release. (Closes: #672134) diff -Nru sbjson-2.3.2/debian/control sbjson-2.3.2/debian/control --- sbjson-2.3.2/debian/control 2012-05-09 23:11:11.0 +0200 +++ sbjson-2.3.2/debian/control 2012-06-29 18:23:32.0 +0200 @@ -2,7 +2,7 @@ Section: libs Priority: optional Maintainer: Jeroen Dekkers -Build-Depends: debhelper (>= 9), cdbs, gobjc, gnustep-make, libgnustep-base-dev +Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), cdbs, gobjc, gnustep-make, libgnustep-base-dev Standards-Version: 3.9.3 Homepage: http://stig.github.com/json-framework Vcs-Browser: https://github.com/dekkers/sbjson diff -Nru sbjson-2.3.2/debian/patches/0001-add-makefiles.patch sbjson-2.3.2/debian/patches/0001-add-makefiles.patch --- sbjson-2.3.2/debian/patches/0001-add-makefiles.patch2012-05-09 23:11:11.0 +0200 +++ sbjson-2.3.2/debian/patches/0001-add-makefiles.patch2012-06-29 19:11:09.0 +0200 @@ -3,18 +3,18 @@ Subject: add-makefiles --- - Classes/GNUmakefile | 27 +++ + Classes/GNUmakefile | 29 + GNUmakefile |9 + - 2 files changed, 36 insertions(+), 0 deletions(-) + 2 files changed, 38 insertions(+) create mode 100644 Classes/GNUmakefile create mode 100644 GNUmakefile diff --git a/Classes/GNUmakefile b/Classes/GNUmakefile new file mode 100644 -index 000..2249e72 +index 000..625d963 --- /dev/null +++ b/Classes/GNUmakefile -@@ -0,0 +1,27 @@ +@@ -0,0 +1,29 @@ +# GNUstep makefile +include $(GNUSTEP_MAKEFILES)/common.make + @@ -39,6 +39,8 @@ +SBJsonParser.m \ +SBJsonWriter.m + ++SBJson_LIBRARIES_DEPEND_UPON += -lgnustep-base -lobjc ++ +-include GNUmakefile.preamble +include $(GNUSTEP_MAKEFILES)/library.make +-include GNUmakefile.postamble diff -Nru sbjson-2.3.2/debian/rules sbjson-2.3.2/debian/rules --- sbjson-2.3.2/debian/rules 2012-05-09 23:11:11.0 +0200 +++ sbjson-2.3.2/debian/rules 2012-06-29 17:57:11.0 +0200 @@ -3,6 +3,11 @@ # Uncomment this to turn on verbose mode. export DH_VERBOSE=1 +export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow +include /usr/share/dpkg/buildflags.mk +# FIXME: dpkg-buildflags / cdbs should support OBJCFLAGS +DEB_MAKE_BUILD_TARGET = all messages=yes OBJCFLAGS="$(CFLAGS)" + include /usr/share/cdbs/1/rules/gnustep.mk include /usr/share/cdbs/1/class/gnumakefile.mk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680563: Do not call dh_installinit twice
Package: yate Version: 4.1.0-1~dfsg-2 Severity: normal Tags: patch Dh_installinit is called twice, once by "dh install" and once manually in the rules file, resulting in duplicate update-rc.d calls in postinst/postrm. This patch fixes that, although the rules file probably needs a big cleanup because currently it's a mix of dh(1) and standard debhelper. -- 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-26-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 Versions of packages yate depends on: pn adduser 3.113ubuntu2 pn libc6 2.15-0ubuntu10 pn libyate4.0.0 pn yate-core yate recommends no packages. yate suggests no packages. commit 167503cfefcb2cab905c53f85a0d7b08b2e2e6c0 Author: Jeroen Dekkers Date: Wed Jul 4 02:07:40 2012 +0200 Do not call dh_installinit twice diff --git a/debian/rules b/debian/rules index 025de7c..7f27cfd 100755 --- a/debian/rules +++ b/debian/rules @@ -50,7 +50,6 @@ binary-indep: install dh_testroot -i dh_auto_install dh_installlogrotate -i - dh_installinit -i -- defaults 21 dh_installdocs -i dh_installexamples -i -XCVS dh_installcron -i @@ -84,7 +83,6 @@ binary-arch: install find $(subpacks) -name '*.conf' -type f -printf '-name %f -o\n' \ | xargs | sed -e 's/ -o$$//' | xargs find $(CURDIR)/debian/yate-core \ | xargs $(RM) -fv - dh_installinit -a dh_installman -a dh_link -a dh_strip -a
Bug#680562: Enable hardening and multiarch
Package: yate
Version: 4.1.0-1~dfsg-2
Severity: important
Tags: patch
The attached patch enabled hardening by setting the debhelper compat
level 9 and compiling /usr/bin/yate as PIE. The patch also enables
multiarch because that's automatically enabled when changing to compat
level 9.
-- 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-26-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
Versions of packages yate depends on:
pn adduser 3.113ubuntu2
pn libc6 2.15-0ubuntu10
pn libyate4.0.0
pn yate-core
yate recommends no packages.
yate suggests no packages.
commit c0927bd741cd5467df339e2c2f94dc61c90299b5
Author: Jeroen Dekkers
Date: Wed Jul 4 01:53:23 2012 +0200
Switch to debhelper level 9, enables hardening and multiarch
diff --git a/debian/compat b/debian/compat
index 7f8f011..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-7
+9
diff --git a/debian/control b/debian/control
index edc06d8..ec368ec 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,8 @@ Section: comm
Priority: optional
Maintainer: Debian VoIP Team
Uploaders: Kilian Krause , Jose Carlos Garcia Sogo , Mark Purcell , Santiago Garcia Mantinan , Mikael Magnusson , Faidon Liambotis , Tzafrir Cohen
-Build-Depends: debhelper (>= 8),
+Build-Depends: debhelper (>= 9),
+ dpkg-dev (>= 1.16.1~),
autotools-dev,
dh-autoreconf,
libopenh323-dev | libh323plus-dev (>= 1.22.0~),
@@ -42,6 +43,7 @@ Section: libs
Replaces: libyate4.0.0
Conflicts: libyate4.0.0
Depends: ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: multiarch-support
Description: Shared library for YATE
YATE is a telephony engine aimed at creating a telephony server that
performs well enough to deal with PBX requirements and also flexible
diff --git a/debian/libyate4.1.0.install b/debian/libyate4.1.0.install
index 50cbbd1..a994e62 100644
--- a/debian/libyate4.1.0.install
+++ b/debian/libyate4.1.0.install
@@ -1 +1 @@
-usr/lib/libyate*.so.*
+usr/lib/*/libyate*.so.*
diff --git a/debian/patches/0002-Compile-daemon-as-PIE.patch b/debian/patches/0002-Compile-daemon-as-PIE.patch
new file mode 100644
index 000..fa7d14c
--- /dev/null
+++ b/debian/patches/0002-Compile-daemon-as-PIE.patch
@@ -0,0 +1,20 @@
+--- a/Makefile.in
b/Makefile.in
+@@ -312,7 +312,7 @@
+ test -z "$$rev" || echo "$$rev" > packing/revision.txt
+
+ %.o: @srcdir@/%.cpp $(MKDEPS) @srcdir@/yatengine.h
+- $(COMPILE) -c $<
++ $(COMPILE) -fPIE -c $<
+
+ @srcdir@/configure: @srcdir@/configure.in
+ cd @srcdir@ && ./autogen.sh --silent
+@@ -324,7 +324,7 @@
+ ./config.status
+
+ yate: $(OBJS) $(LIBS) libyate.so
+- $(LINK) -o $@ $(LIBTHR) $^ @LIBS@
++ $(LINK) -fPIE -pie -o $@ $(LIBTHR) $^ @LIBS@
+
+ libyate.so: $(YLIB)
+ ln -sf $^ $@
diff --git a/debian/patches/series b/debian/patches/series
index 7bd7b31..fbe0a0a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
warning-unknown-architecture.patch
0001-Fix-parallel-make-v2.patch
+0002-Compile-daemon-as-PIE.patch
diff --git a/debian/rules b/debian/rules
index 9547703..025de7c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,9 @@
#!/usr/bin/make -f
+export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
+export DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
DEBVERSION:=$(shell head -n 1 debian/changelog \
| sed -e 's/^[^(]*(\([^)]*\)).*/\1/')
UPVERSION:=$(shell echo $(DEBVERSION) | sed -e 's/^.*://' -e 's/-[0-9.]*$$//' -e 's/~dfsg$$//')
@@ -24,7 +28,7 @@ endif
config.status: check-ilbc
dh_autoreconf --as-needed
dh_auto_configure --\
- --without-openh323 --disable-ilbc --without-amrnb --without-coredumper --enable-sctp
+ --without-openh323 --disable-ilbc --without-amrnb --without-coredumper --enable-sctp CFLAGS="$(CFLAGS) $(CPPFLAGS)"
build: build-arch build-indep
diff --git a/debian/yate-alsa.install b/debian/yate-alsa.install
index cbb98c9..e8a963e 100644
--- a/debian/yate-alsa.install
+++ b/debian/yate-alsa.install
@@ -1 +1 @@
-usr/lib/yate/client/alsachan.yate
+usr/lib/*/yate/client/alsachan.yate
diff --git a/debian/yate-core.install b/debian/yate-core.install
index 750ffc9..ba30a9e 100644
--- a/debian/yate-core.install
+++ b/debian/yate-core.install
@@ -1,6 +1,6 @@
etc/yate/*.conf
-usr/lib/yate/*.yate
-usr/lib/yate/client/osschan.yate
-usr/lib/yate/client/jabberclient.yate
-usr/lib/yate/sig/
+usr/lib/*/yate/*.yate
+usr/lib/*/yate/client/osschan.yate
+usr/lib/*/yate/client/jabberclient.yate
+usr/lib/*/yate/sig/
usr/share/yate/data/*
diff --git a/debian/yate-dahdi.install b/debian/yate-dahdi.install
index 7e65580..
Bug#527900: Postrm was totally broken, fixes for both postinst/postrm
tags 527900 +patch thanks Because of the if statements the postrm statements were never run, so the directory wasn't cleaned up and the yate user/group not deleted. The attached patch fixes that and also fixed a few things in the postinst. yate-postinstrm.patch Description: Binary data
Bug#469729: Run yate as non-root and use cap_sys_nice for thread priority
tags 469729 +patch thanks The attached patch makes yate run as the user yate. Yate is given the cap_sys_nice capability so it is still able to change the thread priority. The ulimit changes can be done by changing the limit for the yate user in /etc/security/limits.conf, we don't need to give yate root permissions for that. So as far as I can see any concerns voiced in the bug report has been taking care of. yate-runasnormaluser.patch Description: Binary data
Bug#673538: libobjc3 -> libobjc4 transition
Hi, I just read that there might not be time to do the transition, but this bug actually combined two transitions: the libobjc transition and the gnustep transition. If the gnustep transition isn't going to happen, we still need to finish libobjc4 transition on the archs that have gcc 4.7 as default, right? Because at the moment there is a mix of packages depending on libobjc3 and libobjc4, which in the case of for example SOGo means that both libobjc3 and libobjc4 get pulled in. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676183: Severity should be critical
severity 676183 critical affects 676183 resolvconf thanks Marking this bug as critical. It breaks DNS configuration, causing everything that needs DNS to fail when the system is rebooted after an upgrade. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677951: sogo: tmpreaper issue
At Mon, 18 Jun 2012 06:27:26 +, shawn wrote: > I have systemd installed, which provides a tmpreaper-like functionality: > tmpfiles.d(5) > > If you are going to depend on tmpreaper, can you make it "tmpreaper | > systemd"? > > also, why does sogo need a tmpreaper so bad as to put it as a depends? It needs tmpreaper for the cron.daily job that cleans up the /var/spool/sogo directory where drafts are temporarily stored. From reading the tmpfiles.d manpage, it seems that to get the same functionality I should create a file /etc/tmpfiles.d/sogo.conf with the contents: d /var/spool/sogo 750 sogo sogo 1d Is that correct? And will this clean the directory every day like the cronjob does or will it only clean the directory on boot? I can't find that in the manpage... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678047: sogo: database dependancy not in control file
At Mon, 18 Jun 2012 19:55:18 +, shawn wrote: > It seems that Sogo needs a database, however there is no indication of this > when installing. > > Sogo should have a suggests: on a database, I think it would nice if there > was a sqlite install > that "Just Works" out of the box. You are right, there should be a suggest on postgresql | mysql-server, but a default sqlite install that just works isn't possible because SOGo doesn't support sqlite. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676183: Same problem with resolvconf and a bridge
I've got the same problem with resolvconf, after booting the nameserver configured /etc/network/interfaces doesn't end up in /etc/resolv.conf. In my case the dns information is also configured on a bridge and a manual ifdown br0;ifup br0 gives me a correct /etc/resolv.conf. -- To UNSUBSCRIBE, email to debian-bugs-dist-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#677119: sogo: new stable version 1.3.16 available
At Mon, 11 Jun 2012 20:55:19 +0200, W. Martin Borgert wrote: > A new stable version 1.3.16 of SOGo is available. > It seems to contain bug fixes only. It also added support for more hash functions, changing a lot of things in the code that talks with OpenSSL. That means the GnuTLS patch needs to be updated and I currently don't have the time to do that, so a new release won't be packages soon and I'll target 1.3.15 for wheezy (unless anyone else ports the GnuTLS patch to 1.3.16). Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672175: ITP: sope -- SKYRiX Object Publishing Environment
Package: wnpp Severity: wishlist Owner: Jeroen Dekkers * Package name: sope Version : 1.3.14 Upstream Author : Inverse inc. * URL : http://www.sogo.nu * License : LGPL Programming Lang: Objective-C Description : SKYRiX Object Publishing Environment An extensive set of Objective-C frameworks which form a complete Web application server environment. Besides the Apple WebObjects compatible appserver that has been extended with Zope concepts, it contains a large set of reusable classes: XML processing (SAX, DOM), MIME/IMAP4 processing, LDAP connectivity, RDBMS connectivity, and iCalendar parsing. Reason for packaging is that this is a dependency of SOGo (ITP #584073), my current packaging can be found at https://github.com/dekkers/sope -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672134: ITP: sbjson -- Objective-C JSON library
Package: wnpp Severity: wishlist Owner: Jeroen Dekkers * Package name: sbjson Version : 2.3.2 Upstream Author : Stig Brautaset * URL : http://stig.github.com/json-framework/ * License : BSD-3-clause Programming Lang: Objective-C Description : Objective-C JSON library A strict JSON parser and generator for Objective-C. It adds categories to existing Objective-C objects for a super-simple interface. More flexible APIs are also provided for added control. Reason for packaging is that this is a dependency of SOGo (ITP #584073), my current packaging can be found at https://github.com/dekkers/sbjson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663506: Bug #663506 still in 0.1.6+20120309git-2
reopen 663506 thanks The latest version (0.1.6+20120309git-2) still doesn't have a versioned dependency on python-request. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#584073: SOGo packaging update
This is an update I just sent to the SOGo list: I've just submitted some of the patches I created that fixes some issues that would prevent SOGo from getting into Debian. I've pushed my current work for 1.3.11 to github: https://github.com/dekkers/sope-debian https://github.com/dekkers/sogo-debian I'm using git-buildpackage to build the packages. Things that still need to be done: - I've patched SOPE to be able to use GnuTLS, but not SOGo yet. SOGo is a bit harder because GnuTLS doesn't provide a drop-in replacement for checking of S/MIME signatures. I don't know how much used this feature is, disabling the S/MIME signature checking might also be an option. - SOGo needs to use /etc for configuration (http://sogo.nu/bugs/view.php?id=1156). I did some experimentation with GNUstep and SOGo defaults and concluded that it isn't that hard, but I still need to code and test such a patch. - We should use debconf to ask where to find the SQL and LDAP databases. - A DEP5-complaint (http://dep.debian.net/deps/dep5) debian/copyright file needs to be created. - The bundled javascript libraries need to be unbundled and the libraries from the Debian packages need to be used instead. And there might be more things I'm forgetting and this is just for SOGo 1.3. For SOGo 2.0 there is even a lot more work to be done. I currently don't have much time to work on this as I'm too busy with things that pay the rent or will do so in the future, so any help is more than welcome. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651053: [Pkg-utopia-maintainers] Bug#651053: Don't prefer random DHCP hostname over system hostname
At Thu, 05 Jan 2012 19:35:17 +0100, Michael Biebl wrote: > > On 05.01.2012 19:22, Jeroen Dekkers wrote: > > At Thu, 05 Jan 2012 14:42:33 +0100, > > Michael Biebl wrote: > >> Could you please attach your /etc/NetworkManager/nm-system-settings.conf > >> If you have the ifupdown plugin enabled (which is the default), then the > >> hostname configured in /etc/hostname should take precedence over the > >> DHCP provided hostname. > > > > My nm-system-settings.conf is: > > > > [main] > > no-auto-default=ETH0MACADDR, > > > > My NetworkManager.conf is: > > > > [main] > > plugins=ifupdown,keyfile > > > > [ifupdown] > > managed=false > > Ok, this is your problem then. You have both, the old and deprecated > nm-system-settings.conf file and the new NetworkManager.conf. > As the old file takes precedence, and your nm-system-settings.conf does > not contain plugins=ifupdown,keyfile, this might explain your problem. > > Please migrate any settings you have in nm-system-settings.conf to > NetworkManager.conf, and delete that file. I can confirm this was the problem, after deleting the old file my hostname isn't changed anymore. > I'm not sure how you ended up having both config files. The Debian > package at least tries to migrate the settings in it postinst. It's possible that I downgraded network-manager in the past and that might explain having both configuration files. Kind regards, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651053: Don't prefer random DHCP hostname over system hostname
At Thu, 05 Jan 2012 14:42:33 +0100, Michael Biebl wrote: > Could you please attach your /etc/NetworkManager/nm-system-settings.conf > If you have the ifupdown plugin enabled (which is the default), then the > hostname configured in /etc/hostname should take precedence over the > DHCP provided hostname. My nm-system-settings.conf is: [main] no-auto-default=ETH0MACADDR, My NetworkManager.conf is: [main] plugins=ifupdown,keyfile [ifupdown] managed=false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#651053: Don't prefer random DHCP hostname over system hostname
Package: network-manager
Version: 0.9.2.0-1
Severity: important
Tags: patch
NetworkManager keeps changing my hostname when I connect to a wireless
network. I'm a bit puzzled why NetworkManager gives a higher priority
to the name that a dhcp server on a random wireless network returns
than the hostname configured by the user in /etc/hostname. In my
opinion NetworkManager shouldn't overrule configuration done by the
user and in Debian the hostname is already set by
/etc/init.d/hostname.sh. It causes a lot of trouble, from annoying
change of your shell prompts to errors because your hostname isn't
resolvable.
The attached patch changes the order of preference, so that an already
set hostname takes precedence over a hostname from DHCP.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages network-manager depends on:
ii adduser3.113
ii dbus 1.4.16-1
ii isc-dhcp-client4.1.1-P1-17
ii libc6 2.13-21
ii libdbus-1-31.4.16-1
ii libdbus-glib-1-2 0.98-1
ii libgcrypt111.5.0-3
ii libglib2.0-0 2.30.2-4
ii libgnutls262.12.14-3
ii libgudev-1.0-0 175-2
ii libnl1 1.1-7
ii libnm-glib40.9.2.0-1
ii libnm-util20.9.2.0-1
ii libpolkit-gobject-1-0 0.102-2
ii libuuid1 2.19.1-5
ii lsb-base 3.2-28
ii udev 175-2
ii wpasupplicant 0.7.3-5
Versions of packages network-manager recommends:
ii dnsmasq-base 2.59-2
ii iptables 1.4.12-1
ii modemmanager 0.5-1
ii policykit-1 0.102-2
ii ppp 2.4.5-5
Versions of packages network-manager suggests:
ii avahi-autoipd 0.6.30-5
-- Configuration Files:
/etc/NetworkManager/nm-system-settings.conf changed [not included]
(Only contents is the MAC address of the wired interface)
-- no debconf information
--- a/src/nm-policy.c
+++ b/src/nm-policy.c
@@ -307,8 +307,8 @@
/* Hostname precedence order:
*
* 1) a configured hostname (from settings)
- * 2) automatic hostname from the default device's config (DHCP, VPN, etc)
- * 3) the original hostname when NM started
+ * 2) the original hostname when NM started
+ * 3) automatic hostname from the default device's config (DHCP, VPN, etc)
* 4) reverse-DNS of the best device's IPv4 address
*
*/
@@ -321,6 +321,13 @@
return;
}
+ /* Try using the hostname from when NM started up.
+ */
+ if (policy->orig_hostname) {
+ _set_hostname (policy, policy->orig_hostname, "from system startup");
+ return;
+ }
+
/* Try automatically determined hostname from the best device's IP config */
if (!best4)
best4 = get_best_ip4_device (policy->manager, &best_req4);
@@ -375,14 +382,6 @@
}
}
- /* If no automatically-configured hostname, try using the hostname from
- * when NM started up.
- */
- if (policy->orig_hostname) {
- _set_hostname (policy, policy->orig_hostname, "from system startup");
- return;
- }
-
/* No configured hostname, no automatically determined hostname, and no
* bootup hostname. Start reverse DNS of the current IPv4 or IPv6 address.
*/
Bug#650680: Can't backport 9.1 extensions with pg_buildext
Package: postgresql-server-dev-all Version: 125 Severity: normal It's not possible to backport a 9.1 extension that's build with pg_buildext. pg_buildext doesn't build the 9.1 extension because /usr/share/postgresql-common/supported-versions always returns 8.4, even if the postgresql packages from squeeze-backports are installed and the backported postgresql-server-dev-all depends on postgresql-server-dev-9.1. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postgresql-server-dev-all depends on: ii dctrl-tools2.19 ii lsb-release3.2-28 ii postgresql-common 126 ii postgresql-server-dev-9.1 9.1.1-3+b1 postgresql-server-dev-all recommends no packages. postgresql-server-dev-all suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#584073: Working on packaging SOGo
retitle 584073 ITP: sogo -- a modern and scalable groupware thanks I started working on packaging SOPE and SOGo a few months ago and I made of lot of progress during debcamp/debconf. You can find the current state on launchpad: https://code.launchpad.net/~dekkers/sope/sope-debian https://code.launchpad.net/~dekkers/sogo/sogo-debian Note that this is a work in progress and might be broken from time to time as I'm not doing rigorous testing before committing things at the moment. There are still a few issues left, such as decoupling the embedded javascripts libraries and linking SOGo to GnuTLS instead of OpenSSL (I already ported SOPE to GnuTLS and that patch has been accepted upstream). Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#598361: This bug is RC and should be fixed in a point release.
severity 598361 grave thanks Given that this bug can cause data corruption, the severity shouldn't be normal and the fix for this bug should be uploaded to stable-proposed-updates. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618266: [PATCH] kfreebsd support for radvd
Package: radvd Version: 1:1.6-1 Severity: important Tags: patch Hi, Attached is a patch to make radvd work on GNU/kFreebsd. Regards, Jeroen Dekkers radvd.patch Description: Binary data
Bug#616505: [checks/files] Detect embedded copies of CKeditor
Package: lintian Version: 2.5.0~rc1 Severity: wishlist Tags: patch FCKEditor has been renamed to CKEditor, but lintian only checks for embedded copies of FCKEditor. The attached patch adds a check for CKEditor. Regards, Jeroen Dekkers lintian-ckeditor.patch Description: Binary data
Bug#612644: tryton-server: Postinst resets insecure permissions on configuration file with passwords
Package: tryton-server Version: 1.6.1-2 Severity: important Hi, >From README.Debian: * trytond must have read access to its configuration file, otherwise it will start with internal defaults. The postinst script will (re)set correct permissions on the standard configuration file (0644 on /etc/tyond.conf). This means that the database password and admin password configured in /etc/trytond.conf will be readable for all users on the system after postinst is run, even if the user has been so wise to make it 0600, because making the tryton database available to all users on the system is a very bad idea. The postinst shouldn't overrule user changes of the permissions of the config file. Regards, Jeroen Dekkers -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (990, 'stable'), (500, 'squeeze-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 tryton-server depends on: ii adduser 3.112+nmu2 add and remove users and groups ii python 2.6.6-3+squeeze5 interactive high-level object-orie ii python-dateutil 1.4.1-3 powerful extensions to the standar ii python-genshi 0.6-1Python XML-based template engine ii python-lxml 2.2.8-2 pythonic binding for the libxml2 a ii python-pkg-resources0.6.14-4 Package Discovery and Resource Acc ii python-psycopg2 2.2.1-1 Python module for PostgreSQL ii python-relatorio0.5.5-1 Python module to create reports fr ii python-simplejson 2.1.1-1 simple, fast, extensible JSON enco ii python-support 1.0.10 automated rebuilding support for P Versions of packages tryton-server recommends: ii logrotate3.7.8-6 Log rotation utility pn openoffice.org-core(no description available) pn openoffice.org-draw(no description available) pn openoffice.org-writer (no description available) ii postgresql 8.4.7-0squeeze2 object-relational SQL database (su ii postgresql-client-8.4 [p 8.4.7-0squeeze2 front-end programs for PostgreSQL pn python-openoffice (no description available) ii python-openssl 0.10-1 Python wrapper around the OpenSSL pn python-pydot (no description available) pn python-tz (no description available) ii python-webdav0.9.4-1 WebDAV server implementation in Py Versions of packages tryton-server suggests: pn python-psyco (no description available) pn python-sphinx (no description available) pn tryton-client | tryton-neso(no description available) -- Configuration Files: /etc/trytond.conf [Errno 13] Permission denied: u'/etc/trytond.conf' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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-dist-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' , "o\003C", '\000' , "#\n\000\000\300\342\377\377\377\177\000\000\027\247B", '\000' , "j\003C", '\000' , "\b\000\000\000\360\342\377\377\377\177\000\000\273\251B", '\000' , "j\003C", '\000' "\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' "\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' pv_id = "\340\343\377\377\377\177\000\000\177\215B", '\000' "\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 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 ) 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
Bug#593365: [Pkg-libvirt-maintainers] Bug#593365: Virt-manager with libvirt 0.8.2-1 can't connect to server running Lenny anymore
Hi Guido, At Fri, 8 Oct 2010 15:47:07 +0200, Guido Günther wrote: > I can only assume the error got ignored in earlier versions. The real > cause of the problem seems to be the version in Lenny. I'd be great if > you could check the attached patch. > > There could be more bugs lurking though if you're not running on real > hardware since /dev/kvm isn't available then, but in this case the more > detailed error message should give us another hint. I have found a kvm-capable machine I can test on, so /dev/kvm exists. But I get the following error with the patch: libvirtError: internal error Cannot find QEMU binary /usr/bin/qemu-system-x86_64: No such file or directory Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593365: [Pkg-libvirt-maintainers] Bug#593365: Virt-manager with libvirt 0.8.2-1 can't connect to server running Lenny anymore
Hi Guido,
At Fri, 1 Oct 2010 10:00:45 +0200,
Guido Günther wrote:
> It checks three error conditions but only sets an error message for one
> of them. Can I ask you to try the attached patch against 0.4.6 and see
> if it changes the error message? This should get us closer to the cause.
I get this error (from virt-manager.log):
libvirtError: internal error Cannot find suitable hypervisor
> What version of kvm are you running on the Lenny system? I assume the
> one from Lenny? Could you also check if deinstalling it and running qemu
> instead does any difference?
When I remove kvm and install qemu it works. If I install kvm again
it works too. But when I remove qemu, I get the same error again.
This small script gives the same error:
===
#!/usr/bin/python
import libvirt
import sys
conn = libvirt.open("qemu+ssh://r...@beppe/system")
if conn == None:
print 'Failed to open connection to the hypervisor'
sys.exit(1)
print conn.getVersion()
===
That outputs:
===
libvir: QEMU error : internal error Cannot find suitable hypervisor
Traceback (most recent call last):
File "./test.py", line 11, in
ret = conn.getVersion()
File "/usr/lib/python2.6/dist-packages/libvirt.py", line 1784, in getVersion
if ret == -1: raise libvirtError ('virConnectGetVersion() failed',
conn=self)
libvirt.libvirtError: internal error Cannot find suitable hypervisor
===
The strange thing is that when I run the script with 0.8.1, I get:
===
libvir: Remote error : unmarshalling remote_error
Traceback (most recent call last):
File "./test.py", line 11, in
print conn.getVersion()
File "/usr/lib/python2.6/dist-packages/libvirt.py", line 1681, in getVersion
if ret == -1: raise libvirtError ('virConnectGetVersion() failed',
conn=self)
libvirt.libvirtError: unmarshalling remote_error
===
Googling for that error message turns up that it's a bug in 0.8.1 that
should be fixed in 0.8.2. But virt-manager works fine with 0.8.1...
Regards,
Jeroen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593365: [Pkg-libvirt-maintainers] Bug#593365: Virt-manager with libvirt 0.8.2-1 can't connect to server running Lenny anymore
At Thu, 30 Sep 2010 20:32:01 +0200, Guido Günther wrote: > > On Thu, Sep 30, 2010 at 06:22:15PM +0200, Guido Günther wrote: > > On Thu, Sep 30, 2010 at 06:00:04PM +0200, Jeroen Dekkers wrote: > > > I actually just tried again using virt-manager with libvirt 0.8.3-1 > > > and I got the same problem. I've got 3 servers with Lenny that I can't > > > connect to. A fourth server is running Lenny with a kernel, kvm and > > > libvirt from backports and I can connect to that one without problems. > > That weird since I used that one too. You're using netcat-openbsd on the > > affected machines for sure? > > If you wouldn't it wouldn't get that far. Could you run libvirtd on the > remote lenny box like (as root): > > LIBVIRT_DEBUG=1 libvirtd > > and see if there's something in the log output? Look for something like > > "libVir=%p, type=%s, typeVer=%p" It's strange that you can't reproduce the bug, because I just installed 2 virtual machines in virtualbox, one lenny with libvirtd and one squeeze with virt-manager and I see the problem there. Running with LIBVIRT_DEBUG as you suggest gives the following output: debian:~# LIBVIRT_DEBUG=1 libvirtd DEBUG: libvirt.c: virInitialize (register drivers) DEBUG: libvirt.c: virConnectOpen (name=qemu:///system) DEBUG: libvirt.c: do_open (name "qemu:///system" to URI components: scheme qemu opaque (null) authority (null) server (null) user (null) port 0 path /system ) DEBUG: libvirt.c: do_open (trying driver 0 (Test) ...) DEBUG: libvirt.c: do_open (driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 1 (Xen) ...) DEBUG: libvirt.c: do_open (driver 1 Xen returned DECLINED) DEBUG: libvirt.c: do_open (trying driver 2 (QEMU) ...) DEBUG: libvirt.c: do_open (driver 2 QEMU returned SUCCESS) DEBUG: libvirt.c: do_open (network driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (network driver 1 QEMU returned SUCCESS) DEBUG: libvirt.c: do_open (storage driver 0 Test returned DECLINED) DEBUG: libvirt.c: do_open (storage driver 1 storage returned SUCCESS) DEBUG: libvirt.c: virConnectGetCapabilities (conn=0x1993b50) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virNodeGetInfo (conn=0x1993b50, info=0x7fff519bb6f0) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectGetVersion (conn=0x1993b50, hvVer=0x7fff519bb728) DEBUG: libvirt.c: virConnectClose (conn=0x1993b50) DEBUG: hash.c: virUnrefConnect (unref connection 0x1993b50 qemu:///system 1) DEBUG: hash.c: virReleaseConnect (release connection 0x1993b50 qemu:///system) The virConnectGetVersion repears every second until I close virt-manager. Regards, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593365: [Pkg-libvirt-maintainers] Bug#593365: Virt-manager with libvirt 0.8.2-1 can't connect to server running Lenny anymore
Hi Guido, At Wed, 29 Sep 2010 14:13:16 +0200, Guido Günther wrote: > sorry it took a moment. No problem. > On Wed, Aug 18, 2010 at 01:32:44PM +0200, Jeroen Dekkers wrote: > > Hi Guido, > > > > At Wed, 18 Aug 2010 11:17:13 +0200, > > Guido Günther wrote: > > > Hi Jeroen, > > > On Tue, Aug 17, 2010 at 04:43:57PM +0200, Jeroen Dekkers wrote: > > > > Package: python-libvirt > > > > Version: 0.8.2-1 > > > > Severity: important > > > > > > > > When I upgraded libvirt from 0.8.1-2+b1 to 0.8.2-1 virt-manager > > > > couldn't connect to my server running lenny anymore. Virt-manager log > > > > says: > > > Does connectiong via virsh to the remove machine work as expected? > > > > That works fine: > > > > runge:~% virsh --version > > 0.8.2 > > runge:~% virsh > > Welcome to virsh, the virtualization interactive terminal. > > > > Type: 'help' for help with commands > >'quit' to quit > > > > virsh # connect qemu+ssh://r...@nescio.viaisn.org/system > I just checked with virt-manager from Squeeze and I can't reproduct > your error. What version of libvirt is the Lenny box running? The default version: ii libvirt-bin 0.4.6-10 the programs for the libvirt library ii libvirt00.4.6-10 library for interfacing with different virtu I actually just tried again using virt-manager with libvirt 0.8.3-1 and I got the same problem. I've got 3 servers with Lenny that I can't connect to. A fourth server is running Lenny with a kernel, kvm and libvirt from backports and I can connect to that one without problems. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593365: [Pkg-libvirt-maintainers] Bug#593365: Virt-manager with libvirt 0.8.2-1 can't connect to server running Lenny anymore
Hi Guido, At Wed, 18 Aug 2010 11:17:13 +0200, Guido Günther wrote: > Hi Jeroen, > On Tue, Aug 17, 2010 at 04:43:57PM +0200, Jeroen Dekkers wrote: > > Package: python-libvirt > > Version: 0.8.2-1 > > Severity: important > > > > When I upgraded libvirt from 0.8.1-2+b1 to 0.8.2-1 virt-manager > > couldn't connect to my server running lenny anymore. Virt-manager log > > says: > Does connectiong via virsh to the remove machine work as expected? That works fine: runge:~% virsh --version 0.8.2 runge:~% virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # connect qemu+ssh://r...@nescio.viaisn.org/system virsh # list Id Name State -- 1 duik running 2 blueiron running 3 ambitrunning 5 intern running Regards, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593365: Virt-manager with libvirt 0.8.2-1 can't connect to server running Lenny anymore
Package: python-libvirt
Version: 0.8.2-1
Severity: important
When I upgraded libvirt from 0.8.1-2+b1 to 0.8.2-1 virt-manager
couldn't connect to my server running lenny anymore. Virt-manager log
says:
[Tue, 17 Aug 2010 16:23:31 virt-manager 21449] INFO (virt-manager:161)
Application startup
[Tue, 17 Aug 2010 16:23:31 virt-manager 21450] DEBUG (engine:338) About to
connect to uris ['qemu+ssh://jero...@jan.chnet/system',
'qemu+ssh://r...@reinier.chnet/system', 'qemu+ssh://r...@beppe/system',
'qemu+ssh://r...@nescio.viaisn.org/system']
[Tue, 17 Aug 2010 16:23:31 virt-manager 21450] DEBUG (engine:628) window
counter incremented to 1
[Tue, 17 Aug 2010 16:23:53 virt-manager 21450] DEBUG (connection:836)
Scheduling background open thread for qemu+ssh://r...@nescio.viaisn.org/system
[Tue, 17 Aug 2010 16:23:53 virt-manager 21450] DEBUG (connection:981)
Background thread is running
[Tue, 17 Aug 2010 16:23:53 virt-manager 21450] DEBUG (connection:1019)
Background open thread complete, scheduling notify
[Tue, 17 Aug 2010 16:23:53 virt-manager 21450] DEBUG (connection:1024)
Notifying open result
[Tue, 17 Aug 2010 16:23:53 virt-manager 21450] DEBUG (connection:1032)
qemu+ssh://r...@nescio.viaisn.org/system capabilities:
x86_64
hvm
64
/usr/bin/qemu-system-x86_64
pc
isapc
/usr/bin/kvm
[Tue, 17 Aug 2010 16:23:53 virt-manager 21450] ERROR (virt-manager:173)
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/util.py", line 340, in _safe_wrapper
return func(*args)
File "/usr/share/virt-manager/virtManager/connection.py", line 1034, in
_open_notify
self.tick()
File "/usr/share/virt-manager/virtManager/connection.py", line 1430, in tick
oldNets, self.nets) = self._update_nets()
File "/usr/share/virt-manager/virtManager/connection.py", line 1069, in
_update_nets
virtinst.support.SUPPORT_CONN_NETWORK)
File "/usr/lib/pymodules/python2.6/virtinst/support.py", line 437, in
check_conn_support
return _check_support(conn, feature, conn)
File "/usr/lib/pymodules/python2.6/virtinst/support.py", line 324, in
_check_support
actual_drv_ver = _hv_ver(conn)
File "/usr/lib/pymodules/python2.6/virtinst/support.py", line 271, in _hv_ver
ret = cmd(*args)
File "/usr/lib/python2.6/dist-packages/libvirt.py", line 1784, in getVersion
if ret == -1: raise libvirtError ('virConnectGetVersion() failed',
conn=self)
libvirtError: Unknown failure
None
[Tue, 17 Aug 2010 16:23:57 virt-manager 21450] DEBUG (engine:632) window
counter decremented to 0
[Tue, 17 Aug 2010 16:23:57 virt-manager 21450] DEBUG (engine:641) Exiting app
normally.
When I downgrade libvirt to 0.8.1-2+b1 it works again. The log with 0.8.1-2+b1
is:
[Tue, 17 Aug 2010 16:22:43 virt-manager 17740] INFO (virt-manager:161)
Application startup
[Tue, 17 Aug 2010 16:22:43 virt-manager 17741] DEBUG (engine:338) About to
connect to uris ['qemu+ssh://jero...@jan.chnet/system',
'qemu+ssh://r...@reinier.chnet/system', 'qemu+ssh://r...@beppe/system',
'qemu+ssh://r...@nescio.viaisn.org/system']
[Tue, 17 Aug 2010 16:22:43 virt-manager 17741] DEBUG (engine:628) window
counter incremented to 1
[Tue, 17 Aug 2010 16:22:46 virt-manager 17741] DEBUG (connection:836)
Scheduling background open thread for qemu+ssh://r...@nescio.viaisn.org/system
[Tue, 17 Aug 2010 16:22:46 virt-manager 17741] DEBUG (connection:981)
Background thread is running
[Tue, 17 Aug 2010 16:22:46 virt-manager 17741] DEBUG (connection:1019)
Background open thread complete, scheduling notify
[Tue, 17 Aug 2010 16:22:46 virt-manager 17741] DEBUG (connection:1024)
Notifying open result
[Tue, 17 Aug 2010 16:22:46 virt-manager 17741] DEBUG (connection:1032)
qemu+ssh://r...@nescio.viaisn.org/system capabilities:
x86_64
hvm
64
/usr/bin/qemu-system-x86_64
pc
isapc
/usr/bin/kvm
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (connection:1211)
Connection doesn't seem to support interface APIs. Skipping all interface
polling.
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (connection:1277)
Connection doesn't seem to support nodedev APIs. Skipping all nodedev polling.
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (connection:209) Libvirt
version does not support physical interface listing
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (connection:248) Libvirt
version does not support media listing.
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (manager:801) VM duik
started
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (manager:801) VM blueiron
started
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (manager:801) VM intern
started
[Tue, 17 Aug 2010 16:22:48 virt-manager 17741] DEBUG (manager:801) VM ambit
started
[Tue, 17 Aug 2010 16:22:51 virt-manager 17741] DEBUG (
Bug#579989: [DebianGIS-dev] Bug#579989: Tries to dlopen libproj.so instead of libproj.so.0
At Mon, 3 May 2010 09:30:08 +0200, Francesco P. Lovergine wrote: > > On Sun, May 02, 2010 at 10:24:17PM +0200, Jeroen Dekkers wrote: > > Package: libgdal1-1.6.0 > > Version: 1.6.3-3+b2 > > Severity: normal > > Tags: patch > > > > I'm getting the following error: > > > > ERROR 6: Unable to load PROJ.4 library (libproj.so), creation of > > OGRCoordinateTransformation failed. > > > > This is because GDAL tries to dlopen libproj.so, but it should dlopen > > libproj.so.0. I tested the attached patch and that fixes the error. > > > > This is a non-sense: > > fran...@blegrez:~$ ldd /usr/lib/libgdal1.6.0.so|grep proj > libproj.so.0 => /usr/lib/libproj.so.0 (0xb4e7) > > So, _what_ are you doing _exactly_ to get this type of error? But that's because libogdi.so.3 links with libproj: runge:~% objdump -x /usr/lib/libogdi.so.3 | grep NEEDED NEEDED libdl.so.2 NEEDED libz.so.1 NEEDED libexpat.so.1 NEEDED libproj.so.0 NEEDED libm.so.6 NEEDED libc.so.6 libgdal1.6.0.so.1 doesn't link directly to it: runge:~% objdump -p /usr/lib/libgdal1.6.0.so.1 | grep NEEDED NEEDED libgeos_c.so.1 NEEDED libsqlite3.so.0 NEEDED libodbc.so.1 NEEDED libodbcinst.so.1 NEEDED libexpat.so.1 NEEDED libxerces-c.so.28 NEEDED libjasper.so.1 NEEDED libhdf5.so.6 NEEDED libmfhdfalt.so.0 NEEDED libdfalt.so.0 NEEDED libogdi.so.3.2 NEEDED libgif.so.4 NEEDED libjpeg.so.62 NEEDED libpng12.so.0 NEEDED libnetcdf.so.4 NEEDED libpq.so.5 NEEDED libz.so.1 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libdl.so.2 NEEDED libcurl-gnutls.so.4 NEEDED libmysqlclient.so.16 NEEDED libstdc++.so.6 NEEDED libgcc_s.so.1 NEEDED libm.so.6 NEEDED libc.so.6 As far as I understand because GDAL only needs libproj for doing certain kind of conversions. So it does a dlopen() when it needs it, but uses libproj.so instead of libproj.so.0. I found the bug when using the GIS part of django with the OpenStreetMap widget, so that's a bit of a complex test case. But I've also found a bug report for Fedora and they patched it the same way, see http://cvs.fedoraproject.org/viewvc/rpms/gdal/F-13/gdal.spec?revision=1.74&view=markup line 170. If you look at the source, ogr/ogrct.cpp is doing pfn_pj_init = (projPJ (*)(int, char**)) CPLGetSymbol( pszLibName, "pj_init" ); where pszLibName is set to libproj.so earlier in the code, and CPLGetSymbol is a platform independent wrapper defined in port/cplgetsymbol.cp that calls dlopen/dlsym. And that's clearly wrong, as it should always open libproj.so.0. And not just because libproj.so only exists in the libproj-dev package, but if libproj gets a SONAME bump because of an ABI change you would get a library with a different ABI if you dlopen just libproj.so. I hope this explanation clears everything up. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#579989: Tries to dlopen libproj.so instead of libproj.so.0
Package: libgdal1-1.6.0 Version: 1.6.3-3+b2 Severity: normal Tags: patch I'm getting the following error: ERROR 6: Unable to load PROJ.4 library (libproj.so), creation of OGRCoordinateTransformation failed. This is because GDAL tries to dlopen libproj.so, but it should dlopen libproj.so.0. I tested the attached patch and that fixes the error. -- 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 libgdal1-1.6.0 depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.20.0-3+b1 Multi-protocol file transfer libra ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libgcc1 1:4.4.2-9GCC support library ii libgeos-c1 3.2.0-1 Geometry engine for Geographic Inf ii libgif4 4.1.6-9 library for GIF images (library) ii libhdf4-0-alt 4.2r4-10 The Hierarchical Data Format libra ii libhdf5-serial-1.8.4 [l 1.8.4-patch1-1 Hierarchical Data Format 5 (HDF5) ii libjasper1 1.900.1-7The JasPer JPEG-2000 runtime libra ii libjpeg62 6b-16.1 The Independent JPEG Group's JPEG ii libmysqlclient165.1.45-1 MySQL database client library ii libnetcdf4 1:3.6.3-1An interface for scientific data a ii libogdi3.2 3.2.0~beta2-6Open Geographic Datastore Interfac ii libpng12-0 1.2.43-1 PNG library - runtime ii libpq5 8.4.3-1 PostgreSQL C client library ii libsqlite3-03.6.23.1-1 SQLite 3 shared library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libxerces-c28 2.8.0+deb1-2 validating XML parser library for ii odbcinst1debian22.2.14p2-1 Support library for accessing odbc ii unixodbc2.2.14p2-1 ODBC tools libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages libgdal1-1.6.0 recommends: pn proj-bin (no description available) libgdal1-1.6.0 suggests no packages. -- no debconf information #! /bin/sh /usr/share/dpatch/dpatch-run ## libproj.dpatch by ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Dlopen libproj.so.0 instead of libproj.so @DPATCH@ diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' gdal-1.6.3~/ogr/ogrct.cpp gdal-1.6.3/ogr/ogrct.cpp --- gdal-1.6.3~/ogr/ogrct.cpp 2008-09-16 10:32:39.0 +0200 +++ gdal-1.6.3/ogr/ogrct.cpp 2010-05-02 21:24:39.087609517 +0200 @@ -80,7 +80,7 @@ #elif defined(__APPLE__) # define LIBNAME "libproj.dylib" #else -# define LIBNAME "libproj.so" +# define LIBNAME "libproj.so.0" #endif //
Bug#579987: FTBFS when python-setuptools is installed
Package: libgdal1-1.6.0 Version: 1.6.3-3+b2 Severity: normal GDAL fails to build when python-setuptools is installed. When I uninstall python-setuptools it builds fine. The error I get is: make[1]: Entering directory `/home/jeroen/src/debian/gdal-1.6.3/swig/python' /usr/bin/python2.6 setup.py install numpy include /usr/lib/python2.6/dist-packages/numpy/core/include setup.py:78: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module. import popen2 running install error: can't create or remove files in install directory The following error occurred while trying to add or remove files in the installation directory: [Errno 13] Permission denied: '/usr/local/lib/python2.6/dist-packages/test-easy-install-13219.write-test' The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: /usr/local/lib/python2.6/dist-packages/ Perhaps your account does not have write access to this directory? If the installation directory is a system-owned directory, you may need to sign in as the administrator or "root" account. If you do not have administrative access to this machine, you may wish to choose a different installation directory, preferably one that is listed in your PYTHONPATH environment variable. For information on other options, you may wish to consult the documentation at: http://peak.telecommunity.com/EasyInstall.html Please make the appropriate changes for your system and try again. make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/jeroen/src/debian/gdal-1.6.3/swig/python' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- 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 libgdal1-1.6.0 depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.20.0-3+b1 Multi-protocol file transfer libra ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libgcc1 1:4.4.2-9GCC support library ii libgeos-c1 3.2.0-1 Geometry engine for Geographic Inf ii libgif4 4.1.6-9 library for GIF images (library) ii libhdf4-0-alt 4.2r4-10 The Hierarchical Data Format libra ii libhdf5-serial-1.8.4 [l 1.8.4-patch1-1 Hierarchical Data Format 5 (HDF5) ii libjasper1 1.900.1-7The JasPer JPEG-2000 runtime libra ii libjpeg62 6b-16.1 The Independent JPEG Group's JPEG ii libmysqlclient165.1.45-1 MySQL database client library ii libnetcdf4 1:3.6.3-1An interface for scientific data a ii libogdi3.2 3.2.0~beta2-6Open Geographic Datastore Interfac ii libpng12-0 1.2.43-1 PNG library - runtime ii libpq5 8.4.3-1 PostgreSQL C client library ii libsqlite3-03.6.23.1-1 SQLite 3 shared library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libxerces-c28 2.8.0+deb1-2 validating XML parser library for ii odbcinst1debian22.2.14p2-1 Support library for accessing odbc ii unixodbc2.2.14p2-1 ODBC tools libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages libgdal1-1.6.0 recommends: pn proj-bin (no description available) libgdal1-1.6.0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543420: Status of Bug#543420
Hi, There is no activity on this bug for over half a year, but it's not marked wontfix either. Can anybody give a status update? It would be nice if Squeeze ships with an upstart that can also be used when SE Linux is enabled. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562748: Bug also found in newer version of network-manager
found 562748 0.7.999-3 found 562748 0.8-1 retitle 562748 NetworkManager with disabled ifupdown plugin doesn't work correctly anymore thanks I just tried the newer NetworkManager packages in testing and unstable and hit the same problem. The problem is that it changed the hostname of the system (resulting in X not working anymore): Feb 28 10:55:05 runge NetworkManager: Setting system hostname to 'dhcppc0' (from DHCP) Other than that, it also changes /etc/hosts by adding that hostname to 127.0.0.1, resulting in that the reverse DNS of 127.0.0.1 is dhcppc0 instead of localhost: 127.0.0.1 dhcppc0 localhost.localdomain localhost I'm really wondering how someone can think that letting NetworkManager change these things can ever be a good thing. Anyway, I started to look why this happens on my system and not on other systems. It turns out that the problem is that I disabled the ifupdown module in the past, when I enable it again in /etc/NetworkManager/nm-system-settings.conf all problems go away. Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562748: Why is this bug severity normal?
severity 562748 critical thanks Why the heck is this bug severity normal, letting it break systems running testing? Regards, Jeroen Dekkers (not amused that his laptop ended up in a broken state) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506972: hang on reboot with virtio
At Sun, 15 Feb 2009 22:24:03 +0100, Jeroen Dekkers wrote: > I just ran into this bug today. Too bad nobody took the time to > isolate the patch, it took me only 5 minutes to find and it's pretty > trivial: > > http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff;h=77c125369426a519fb9ea92dc159fa5ce392f354 > > I just applied the patch and installed the resulting debian packages > and it reboots fine with virtio devices now. For anyone who is interested in the package with the patch applied, you can find it here: http://dekkers.cx/kvm/ Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506972: hang on reboot with virtio
I just ran into this bug today. Too bad nobody took the time to isolate the patch, it took me only 5 minutes to find and it's pretty trivial: http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commitdiff;h=77c125369426a519fb9ea92dc159fa5ce392f354 I just applied the patch and installed the resulting debian packages and it reboots fine with virtio devices now. Given that you have to use virtio if you want to have good performance with KVM and not being able to reboot is a pretty grave bug IMHO, is there any chance of this fix going into 5.0.1? Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-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#492609: semi: mime-edit.el doesn't compile without /usr/bin/mailx or /usr/lib/sendmail
Package: semi Version: 1.14.6+0.20070618-1 Severity: important mime-edit.nl has a (require 'sendmail) and this gives an error when it can't find /usr/bin/mail or /usr/lib/sendmail. Given that semi doesn't depend on mailx or mail-transport-agent, this results in a compilation failure of mime-edit.el. This in turn causes compile errors in reverse dependencies such as wanderlust, which marks those packages unusable. (E.g. install emacs22 and wl on a fresh system with only base installed and it gives a load error when you try to start wl) -- 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.25-2-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 semi depends on: ii apel 10.7-2 portable library for emacsen ii emacs22-gtk [emacsen] 22.2+2-2 The GNU Emacs editor (with GTK use ii flim 1:1.14.9-2 library about internet message for ii make 3.81-5 The GNU version of the "make" util semi recommends no packages. Versions of packages semi suggests: ii gnupg 1.4.9-2 GNU privacy guard - a free PGP rep ii mailcrypt 3.5.8+CVS.2005.04.29.1-12 An Emacs interface to the GNU Priv ii wl 2.14.0-9 mail/news reader supporting IMAP f -- no debconf information -- 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#372680: Fixed in 4.8
tags 372680 +fixed-upstream thanks According to https://bugzilla.mindrot.org/show_bug.cgi?id=926 this bug has been fixed in 4.8. The patch that fixes the problem is attached to that bug report. Regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470549: libldb-dev should be in the libdevel section, not in the libs section
Package: libldb-dev Version: 0.9.2~git20080122-1 Severity: normal libldb-dev should be in the libdevel section, not in the libs section -- 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=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libldb-dev depends on: ii libc6-dev2.7-6 GNU C Library: Development Librari ii libldb0 0.9.2~git20080122-1 LDAP-like embedded database - shar ii libtalloc-dev1.1.0~svn26291-1hierarchical pool based memory all ii pkg-config 0.22-1 manage compile and link flags for libldb-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464933: linux-image-2.6.24-1-amd64: r8169 doesn't work with 2.6.24 (regression from 2.6.23)
At Tue, 12 Feb 2008 01:56:30 +0100, maximilian attems wrote: > > On Sat, 09 Feb 2008, Jeroen Dekkers wrote: > > > Package: linux-image-2.6.24-1-amd64 > > Version: 2.6.24-3 > > Severity: important > > > > > > With 2.6.24 r8169 stopped working on my asus A6Tc laptop. If I run > > tcpdump on both sides, I see that it's able to send DHCP requests, but > > the tcpdump on my laptop never shows the DHCP replies, so I guess > > there is some bug in the receiving code. If I boot the same system > > with 2.6.23 everything works fine. > > > > please provide further info: > dmesg > lsmod > ip a > ip r Sorry for the late reply, but here it is.. dmesg: Initializing cgroup subsys cpuset Linux version 2.6.24-1-amd64 (Debian 2.6.24-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19)) #1 SMP Mon Feb 11 13:47:43 UTC 2008 Command line: root=/dev/mapper/cauchy-root ro acpi=noirq resume=/dev/mapper/cauchy-swap BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 3ffc (usable) BIOS-e820: 3ffc - 3ffce000 (ACPI data) BIOS-e820: 3ffce000 - 3fff (ACPI NVS) BIOS-e820: 3fff - 4000 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ff7c - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 262080) 1 entries of 3200 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000FBB50, 0014 (r0 ACPIAM) ACPI: RSDT 3FFC, 0034 (r1 A M I OEMRSDT 4000702 MSFT 97) ACPI: FACP 3FFC0200, 0084 (r2 A M I OEMFACP 4000702 MSFT 97) ACPI: DSDT 3FFC0440, 724B (r1 A0462 A04620000 INTL 2002026) ACPI: FACS 3FFCE000, 0040 ACPI: APIC 3FFC0390, 0070 (r1 A M I OEMAPIC 4000702 MSFT 97) ACPI: MCFG 3FFC0400, 003C (r1 A M I OEMMCFG 4000702 MSFT 97) ACPI: OEMB 3FFCE040, 005B (r1 A M I AMI_OEM 4000702 MSFT 97) Scanning NUMA topology in Northbridge 24 CPU has 2 num_cores No NUMA configuration found Faking a node at -3ffc Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 262080) 1 entries of 3200 used Bootmem setup node 0 -3ffc Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 262080 On node 0 totalpages: 261983 DMA zone: 56 pages used for memmap DMA zone: 1065 pages reserved DMA zone: 2878 pages, LIFO batch:0 DMA32 zone: 3527 pages used for memmap DMA32 zone: 254457 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x508 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 MPTABLE: OEM ID: ASUS MPTABLE: Product ID: MPTABLE: APIC at: 0xFEE0 I/O APIC #2 at 0xFEC0. Setting APIC routing to flat Processors: 2 swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e swsusp: Registered nosave memory region: 000e - 0010 Allocating PCI resources starting at 5000 (gap: 4000:bec0) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 34400 bytes of per cpu data Built 1 zonelists in Node order, mobility grouping on. Total pages: 257335 Policy zone: DMA32 Kernel command line: root=/dev/mapper/cauchy-root ro acpi=noirq resume=/dev/mapper/cauchy-swap Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) TSC calibrated against PM_TIMER Marking TSC unstable due to TSCs unsynchronized time.c: Detected 1607.303 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Checking aperture... CPU 0: aperture @ 858c00 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 1022660k/1048320k available (2143k kernel code, 25272k reserved, 1003k data, 316k init) Calibrating delay using timer specific routine.. 3224.17 BogoMIPS (lpj=6448357) Security Framework initialized SELinux: Disabled at boot. Capability LSM initialized Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes
Bug#464933: linux-image-2.6.24-1-amd64: r8169 doesn't work with 2.6.24 (regression from 2.6.23)
Package: linux-image-2.6.24-1-amd64 Version: 2.6.24-3 Severity: important With 2.6.24 r8169 stopped working on my asus A6Tc laptop. If I run tcpdump on both sides, I see that it's able to send DHCP requests, but the tcpdump on my laptop never shows the DHCP replies, so I guess there is some bug in the receiving code. If I boot the same system with 2.6.23 everything works fine. -- Package-specific info: -- 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.23-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 linux-image-2.6.24-1-amd64 depends on: ii debconf [debconf-2.0]1.5.19 Debian configuration management sy ii initramfs-tools [linux-initr 0.91d tools for generating an initramfs ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo linux-image-2.6.24-1-amd64 recommends no packages. -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.24-1-amd64/preinst/abort-overwrite-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/old-dir-initrd-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/failed-to-move-modules-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/bootloader-test-error-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/preinst/lilo-initrd-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/create-kimage-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/depmod-error-initrd-2.6.24-1-amd64: false linux-image-2.6.24-1-amd64/postinst/old-system-map-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/lilo-has-ramdisk: linux-image-2.6.24-1-amd64/preinst/overwriting-modules-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/bootloader-error-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/preinst/abort-install-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/postinst/old-initrd-link-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/kimage-is-a-directory: linux-image-2.6.24-1-amd64/preinst/bootloader-initrd-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/prerm/would-invalidate-boot-loader-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/initrd-2.6.24-1-amd64: linux-image-2.6.24-1-amd64/prerm/removing-running-kernel-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/preinst/elilo-initrd-2.6.24-1-amd64: true linux-image-2.6.24-1-amd64/postinst/depmod-error-2.6.24-1-amd64: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441404: apache2.2-common: SSLCertificateChainFile in virtual host context
Package: apache2.2-common Version: 2.2.3-4+etch1 Severity: normal According to the documentation, SSLCertificateChainFile should also work in a virtual host context, but it doesn't really have any effect there. Apache only sends the certificate chain when I specify the chain with SSLCertificateChainFile in the global server config. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.3-4+etch1 utility programs for webservers ii libmagic1 4.17-5etch2 File type determination library us ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii mime-support 3.39-1MIME files 'mime.types' & 'mailcap ii net-tools 1.60-17 The NET-3 networking toolkit ii procps 1:3.2.7-3 /proc file system utilities apache2.2-common recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423826: CIFS_POSIX should also be enabled
retitle 423826 please enable CIFS_XATTR and CIFS_POSIX thanks Just to make sure that ACLs are really enabled when this bugs gets closed: CIFS_XATTR alone doesn't enable ACLs, you also need to enable CIFS_POSIX. Jeroen Dekkers -- 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#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#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
At Mon, 4 Jun 2007 22:30:12 +0200, Robert Millan wrote: > > On Mon, Jun 04, 2007 at 10:11:30PM +0200, Jeroen Dekkers wrote: > > At Sun, 3 Jun 2007 23:37:25 +0200, > > Robert Millan wrote: > > > Here's another report with issues about LVM. I notice the device name is > > > different than previous ones (note: device.map only has /dev/sda). > > > > The problem seems to be that grub-install is probing for things > > outside of /boot. GRUB shouldn't use anything outside of /boot to > > start. > > update-grub calls grub-probe a few times, in different places. Some of them > could be avoided, but at least these appear to be necessary: > > # Device containing our userland. Typicaly used for root= parameter. > GRUB_DEVICE="`grub-probe --target=device /`" > > # Filesystem for the device containing our userland. Used for stuff like > # choosing Hurd filesystem module. > GRUB_FS="`grub-probe --target=fs /`" > > See also 00_header.in for code that might scan /usr/share/ in search of > unifont. If e.g. /usr is a separate partition, grub needs to know that > somehow to load the font later. GRUB shouldn't load anything from any other partition than /boot. The whole reason that we have /boot partitions is that it might be possible that the rest isn't readable by GRUB. The reason we have grub-probe is to find out which modules need to be in core.img. You're currently using grub-probe for other things and that isn't always going to work. Grub-probe won't be able to parse encrypted LVM volumes for example, and thus grub-probe --target=fs / is never going to work if your / is encrypted. Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427289: more LVM stuff (Re: Bug#427289: grub-probe: error: unknown device when / is an encrypted LVM)
At Sun, 3 Jun 2007 23:37:25 +0200, Robert Millan wrote: > Here's another report with issues about LVM. I notice the device name is > different than previous ones (note: device.map only has /dev/sda). The problem seems to be that grub-install is probing for things outside of /boot. GRUB shouldn't use anything outside of /boot to start. Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID
At Mon, 21 May 2007 13:23:38 +0100,
Sam Morris wrote:
>
> On Mon, 2007-05-21 at 13:08 +0200, Jeroen Dekkers wrote:
> > At Sat, 19 May 2007 15:13:58 +0100,
> > Sam Morris wrote:
> > > In addition, it would be nice if the 'out of disk' error could be
> > > deferred until grub actually tries to read a block that is out of range,
> > > as grub-legacy does
> >
> > The problem is that it actually tries to do that, because the RAID
> > superblock is located at the end of the partition.
>
> Oh, good point. My only remaining point of confusion is how I am able to
> access the (md0) device fine from within grub, since it can't read the
> superblocks. Does it just assume that any pc partitions of type 0xfd
> with unreadable superblocks are part of a RAID 1 array, or is it
> possible that something else is going on?
>
> My array is made up of partitions on two disks; the first is the primary
> master on the motherboard's ATA controller, and the second is on a
> Promise PCI card.
>
> Now, AFAIK the promise card cannot do 48-bit LBA addressing without a
> bios flash that I never applied. But is it possible that my
> motherboard's controller is able to do 48-bit addressing?
>
> If this were the case it would explain how grub is able to access an
> (md0) device (via the fully-readable (hd0,2) device), and also where the
> 'out of disk' error comes from (from trying to read the superblock of
> (hd3,2)).
>
> If this is the case, it would be nice if the raid module would only
> throw a warning if some of the component devices could not be added to a
> RAID1 array.
I think the handling of errors/warnings in GRUB2 can probably be
improved, but it shouldn't give an error in this case. See the code in
raid.c line 344. Can you test whether this patch makes the error go away?
Index: disk/raid.c
===
RCS file: /cvsroot/grub/grub2/disk/raid.c,v
retrieving revision 1.3
diff -u -p -r1.3 raid.c
--- disk/raid.c 17 May 2007 23:23:03 - 1.3
+++ disk/raid.c 21 May 2007 13:10:25 -
@@ -344,7 +344,10 @@ grub_raid_scan_device (const char *name)
err = grub_disk_read (disk, sector, 0, GRUB_RAID_SB_BYTES, (char *) &sb);
grub_disk_close (disk);
if (err)
-return 0;
+{
+ grub_errno = GRUB_ERR_NONE;
+ return 0;
+ }
/* Look whether there is a RAID superblock. */
if (sb.md_magic != GRUB_RAID_SB_MAGIC)
Jeroen Dekkers
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423022: Bug#422851: "grub-probe -t partmap" doesn't work with software RAID
At Sat, 19 May 2007 15:13:58 +0100, Sam Morris wrote: > In addition, it would be nice if the 'out of disk' error could be > deferred until grub actually tries to read a block that is out of range, > as grub-legacy does The problem is that it actually tries to do that, because the RAID superblock is located at the end of the partition. > (even through it doesn't 'see' the RAID partition as > such, I can still boot from it without complaint). That's probably because you have RAID1. The only difference between a RAID and a non-RAID is that there is a RAID superblock at the end, you can just mount a RAID1 partition as normal. This is how grub legacy was always able to boot from RAID1 partitions. This won't work with RAID0 or RAID5 however. > I wonder if d-i warns the user that they may be creating an unbootable > system if the partition that contains /boot does not exist wholly within > the first 7.8 GiB/128 GiB/128 PiB (depending on the addressing mode in > use) of the disk? :) I think that 7.8GiB limit has been gone for a long time now, I don't think there will be a lot of installations on such machines. My guess is that the 128 GiB limit is still a problem. Jeroen Dekkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
