Bug#515793: RFP: cgit -- C-code Web Front-end to GIT
Hi, On 19-02-14 00:47, YAEGASHI Takeshi wrote: Oxan, have you already worked on your own cgit package built with something like git-source binary package? Please let me know if you made any progress. I might be able to contribute to your package! No, unfortunately I hadn't made any progress. I tried to get it working using a git-source package, but the Git package is quite complex and I couldn't get it working, so I gave up in the end. The lack of debhelper in the git package didn't help either (which might be because I'm not very knowledgeable on low-level package building). Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729781: ITP: subliminal -- Command-line tool to search and download subtitles
Hi, On 17-11-13 11:56, Etienne Millon wrote: I intend to maintain this package within the Debian Python Modules Team. It has a few unpackaged dependencies (I'll file RFPs and/or ITPs if there is no objection to the inclusion of subliminal): - python-charade (ITP #698258, not sure if replaceable by chardet) - python-enzyme (same author ; https://github.com/Diaoul/enzyme ; Apache2) - python-babelfish (same author ; https://github.com/Diaoul/babelfish ; BSD-3) - python-guessit (https://github.com/wackou/guessit ; LGPLv3) - python-pysrt (https://github.com/byroot/pysrt ; GPLv3) I've just finished and published my packaging of subliminal and its dependencies yesterday: - python-charadehttps://github.com/oxan/charade-debian - python-enzyme https://github.com/oxan/enzyme-debian - python-babelfish https://github.com/oxan/babelfish-debian - python-guessithttps://github.com/oxan/guessit-debian - python-pysrt https://github.com/oxan/pysrt-debian - subliminalhttps://github.com/oxan/subliminal-debian Feel free to re-use (parts of) the packaging. I'm also a DPMT member, so I'm willing to help out with the packaging there later on too (I didn't push to DPMT initially because Alioth is down and I'm not sure whether I can personally invest enough time to keep them up to Debian quality standards). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697439: fglrx-driver: dkms fails to build with kernel 3.7
Package: fglrx-driver Version: 1:12.11~beta11-1 Severity: important Tags: patch The current fglrx kernel module doesn't build with the 3.7 kernel as available from experimental. This is caused by the removal of VM_RESERVED, which has been replaced with VM_DONTEXPAND | VM_DONTDUMP. The patch below fixes the compilation of the fglrx kernel module. Index: fglrx-driver-12.11~beta11/common/lib/modules/fglrx/build_mod/firegl_public.c === --- fglrx-driver-12.11~beta11.orig/common/lib/modules/fglrx/build_mod/firegl_public.c 2012-12-03 03:03:45.0 +0100 +++ fglrx-driver-12.11~beta11/common/lib/modules/fglrx/build_mod/firegl_public.c 2013-01-05 12:32:40.605448455 +0100 @@ -203,6 +203,11 @@ #define VM_SHM 0 #endif +// VM_RESERVED is replaced with VM_DONTEXPAND | VM_DONTDUMP in Linux 3.7+ +#ifndef VM_RESERVED +#define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP) +#endif + #ifdef FGL_LINUX253P1_VMA_API // Linux 2.5.3-pre1 and compatibles #define FGL_VMA_API_TYPEstruct vm_area_struct * -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
Bug#688059: samba: files not deleted, smbstatus segfaults
On 02-10-12 06:50, Christian PERRIER wrote: Quoting Oxan van Leeuwen (o...@oxanvanleeuwen.nl): On 30-09-12 14:16, Christian PERRIER wrote: I think it are actually two related bugs, instead of one. The second patch seems to fix the inability to delete files, and the first patch fixes the smbstatus segfault caused by that. If it would help to get this into wheezy, I can create and test a samba 3.6.6-3 package with these two patches applied? If you have a testcase, I would really appreciate your help, yes. I have timetoworkon preparing a new package, but much less for testing andreviewing the possible patches. I've been running a modified 3.6.6-3 with the two patches applied for a few days now, and it looks like it solves the problem. Files can be deleted without problems and I don't get any smbstatus segfaults. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688059: samba: files not deleted, smbstatus segfaults
tags 688059 + patch retitle 688059 samba: files not deleted, smbstatus segfaults thanks Hi, I also experience this bug using 3.6.6. Not only makes it smbstatus segfault, it also makes deleting files impossible. It seems to be upstream bug 9058 (https://bugzilla.samba.org/show_bug.cgi?id=9058). Judging from the upstream bug report this has been a regression since 3.6.5, which affects servers with max protocol = SMB2, and is mostly triggered by Microsoft Office. I can confirm that this bug is fixed with version 3.6.8 from experimental. Please fix this bug in wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#688059: samba: files not deleted, smbstatus segfaults
On 30-09-12 14:16, Christian PERRIER wrote: My only problem is that upstream bug #9058 seems to have two different fixes: https://attachments.samba.org/attachment.cgi?id=7809 https://attachments.samba.org/attachment.cgi?id=7817 Both are unrelated and I suspect both are needed. Nut I'm having hard times just describing them. I think it are actually two related bugs, instead of one. The second patch seems to fix the inability to delete files, and the first patch fixes the smbstatus segfault caused by that. If it would help to get this into wheezy, I can create and test a samba 3.6.6-3 package with these two patches applied? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663006: libnfc
Control: retitle -1 RFP: libnfc -- Near Field Communication (NFC) library Control: unblock 663006 by 672795 Hi, I'm no longer interested in packaging this due to changing interests and shifting priorities. If anyone else wants to package this, you can find the start of my packaging in the SVN repository mentioned earlier (BSD-licensed). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710167: sbuild: support non-local sbuild user
Package: sbuild Version: 0.64.0-1 Severity: wishlist Tags: patch I run a setup where the sbuild user is in LDAP. This makes the usermod command in the postinst script fail, because usermod only operates on local users. Attached patch verifies the user exists in /etc/passwd before attempting to run usermod. I couldn't find another way to check whether running usermod on a user would work. -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (910, 'testing-proposed-updates'), (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates'), (110, 'precise-updates'), (110, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/4 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 sbuild depends on: ii adduser 3.113+nmu3 ii apt-utils 0.9.8.1 ii libsbuild-perl 0.64.0-1 ii perl5.14.2-21 ii perl-modules5.14.2-21 Versions of packages sbuild recommends: ii debootstrap 1.0.49 ii fakeroot 1.18.4-2 Versions of packages sbuild suggests: pn deborphan ii wget 1.14-1 -- no debconf information *** /tmp/patch --- debian/sbuild.postinst.orig 2013-05-28 19:26:51.069190007 +0200 +++ debian/sbuild.postinst 2013-05-28 19:27:20.906396270 +0200 @@ -68,7 +68,7 @@ --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" sbuild fi # Unlock account in case it was locked from previous purge. - usermod -U -e '' sbuild + grep '^sbuild:' /etc/passwd >/dev/null && usermod -U -e '' sbuild chown -R sbuild:sbuild /var/lib/sbuild chmod 02770 /var/lib/sbuild -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
Bug#698008: more info
Hi, This bug also affects Konsole in KDE, using Kwin as window manager. When I try to (un-)maximize the Konsole window, the X server infrequently segfaults. It seems to happen about 20% of the time, with chances increasing when the X session has been running longer. Extensive dragging of Konsole windows across screens can consistently crash the X server. I've also managed to reproduce the crash using a closed-source Qt application once. A quick Google search turned up the following relevant information: (*) ArchLinux and Gentoo are affected too: https://bbs.archlinux.org/viewtopic.php?pid=1176889 http://forums.gentoo.org/viewtopic-t-955708-start-0.html (*) 13.1 should have fixed this, but it doesn't work. There's a report of 12.6 working for someone (I haven't tried it yet). http://forum.kde.org/viewtopic.php?f=227&t=109597 (*) It has already been reported upstream, where someone mentioned that it only happens in multimontior environments, which might be true; I'm using one. http://ati.cchtml.com/show_bug.cgi?id=724 For reference, the relevant part from my Xorg.0.log: [ 15420.810] [ 15420.810] Backtrace: [ 15420.810] 0: /usr/bin/X (xorg_backtrace+0x36) [0x7fe526771d06] [ 15420.811] 1: /usr/bin/X (0x7fe5265f3000+0x182859) [0x7fe526775859] [ 15420.811] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fe525919000+0xf210) [0x7fe525928210] [ 15420.811] 3: /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x7fe525693000+0x727ed) [0x7fe5257057ed] [ 15420.811] 4: /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x7fe525693000+0x72b5f) [0x7fe525705b5f] [ 15420.811] 5: /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (pixman_blt+0x52) [0x7fe52569d8b2] [ 15420.811] 6: /usr/lib/xorg/modules/libfb.so (fbCopyNtoN+0x2c9) [0x7fe521480469] [ 15420.811] 7: /usr/lib/xorg/modules/glesx.so (0x7fe51e4a8000+0x758c1) [0x7fe51e51d8c1] [ 15420.811] 8: /usr/lib/xorg/modules/glesx.so (0x7fe51e4a8000+0x77c25) [0x7fe51e51fc25] [ 15420.811] 9: /usr/bin/X (0x7fe5265f3000+0x110a79) [0x7fe526703a79] [ 15420.811] 10: /usr/bin/X (0x7fe5265f3000+0xd9955) [0x7fe5266cc955] [ 15420.811] 11: /usr/bin/X (0x7fe5265f3000+0xdacaf) [0x7fe5266cdcaf] [ 15420.811] 12: /usr/bin/X (0x7fe5265f3000+0xd7e1c) [0x7fe5266cae1c] [ 15420.811] 13: /usr/bin/X (ConfigureWindow+0x378) [0x7fe52666eec8] [ 15420.811] 14: /usr/bin/X (0x7fe5265f3000+0x4d904) [0x7fe526640904] [ 15420.811] 15: /usr/bin/X (0x7fe5265f3000+0x52e61) [0x7fe526645e61] [ 15420.811] 16: /usr/bin/X (0x7fe5265f3000+0x41ec5) [0x7fe526634ec5] [ 15420.812] 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7fe5245a4a55] [ 15420.812] 18: /usr/bin/X (0x7fe5265f3000+0x4219d) [0x7fe52663519d] [ 15420.812] [ 15420.812] Segmentation fault at address 0x7fe4f9c15000 [ 15420.812] Fatal server error: [ 15420.812] Caught signal 11 (Segmentation fault). Server aborting [ 15420.812] [ 15420.812] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 15420.812] Please also check the log file at "/var/log/Xorg.0.log" for additional information. I'm using kernel 3.8, but can also reproduce the crash with 3.6. X and fglrx stack from testing installed (xserver-xorg-core 2:1.12.4-6, fglrx-driver 1:13.4-2). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
Bug#625877: xserver-xorg-core 1.10.2: resizing konsole hangs xserver
Hi, NVidia released a new beta version of their drivers on their forums two days ago, 275.09.04. One of the items in the changelog is this bug, and I can confirm that it is indeed fixed. The new version doesn't seem to have hit the website yet, but it's available on their FTP server. See this topic on their forum for the download link: http://nvnews.net/vbulletin/showthread.php?t=163161 Regards, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: status
Hi Clint, What's the current status of the updated python-gearman.libgearman package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#710167: [buildd-tools-devel] Bug#710167: sbuild: support non-local sbuild user
On 05-07-13 11:16, Roger Leigh wrote: Why is the user in LDAP rather than local? My understanding of this is that when packages create system users using adduser, they are created in the local system databases, and not in LDAP, therefore we would expect that any modification of these users/groups would work in maintainer scripts after their creation. I originally moved the sbuild user and group to LDAP so that I could add my regular user account to the sbuild group. However, it seems to be possible to configure sbuild to give other groups access now (this is a years old setup), so I can try that. Regarding the patch, I don't think it's necessarily safe since other types of local database are also supported by the tools. Also, this isn't a problem specific to sbuild, it's a problem relating to any package creating/modifying users. I'm not saying that it's not a problem, just that if it's something that needs addressing, it needs fixing for the general case rather than just on a package-by-package basis. Yes, I agree, it's not the best way, I just couldn't think of a cleaner one. An alternative patch would be to ignore it if usermod fails (the main problem for me is that the error causes dpkg to abort). I don't think I've seen another package using usermod in the postinst yet (most packages seem to either delete the user or leave it alone, not lock it). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#717991: python-parsedatetime: New upstream version available
Package: python-parsedatetime Version: 0.8.7-3 Severity: normal There is a new upstream version (1.1.2) available for this package. It'd be great if this version could be uploaded to Debian. (If you don't have time to maintain this package anymore, I'm willing to help out. I'm already a member of the DPMT and can prepare an updated package if you want). -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (910, 'testing-proposed-updates'), (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates'), (110, 'precise-updates'), (110, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 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 python-parsedatetime depends on: ii base-files 7.2 ii python 2.7.5-2 ii python-support 1.0.15 Versions of packages python-parsedatetime recommends: ii python-pyicu 1.5-2 python-parsedatetime 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 Archive: http://lists.debian.org/debian-bugs-dist
Bug#718309: python-irclib: duplicate of python-irc
Package: python-irclib Version: 0.4.8-1.1 Severity: serious This package is an old version of the python-irc package. - The description is the same - The Homepage field points to an old version of the homepage from the python-irc package. - They use the exact same class and method names Given that the other package is actively maintained and this package hasn't received a single maintainer upload since 2008, I suggest this package is dropped from Debian once all reverse depends are updated to use python-irc. (Actually, I suspect the python-irc package has been created in an attempt to get a recent version of the software in Debian, without following the proper procedures for taking over an unmaintained package and having a transition for the changed API). -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (910, 'testing-proposed-updates'), (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates'), (110, 'precise-updates'), (110, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 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 python-irclib depends on: ii python 2.7.5-2 python-irclib recommends no packages. python-irclib suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
Bug#718370: python-sympy: Vcs fields are incorrect
Package: python-sympy Version: 0.7.2-1 Severity: wishlist The repository that's specified in the Vcs-Svn and Vcs-Browser fields (with outdated URLs because of the Alioth migration last year, btw) doesn't contain the last uploads to Debian, but includes an alternate packaging of the same upstream release. Please update SVN to include the latest packages, or update the VCS fields to point to the correct repository. -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (910, 'testing-proposed-updates'), (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates'), (110, 'precise-updates'), (110, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 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 python-sympy depends on: ii python 2.7.5-2 ii python2.7 2.7.5-5 Versions of packages python-sympy recommends: ii dvipng 1.14-1+b2 ii ipython 0.13.2-2 ii python [python-ctypes] 2.7.5-2 ii python-imaging 1.1.7-4 ii python-numpy1:1.7.1-2 ii texlive-fonts-extra 2012.20120611-2 python-sympy 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 Archive: http://lists.debian.org/debian-bugs-dist
Bug#725621: systemd-suspend.service(8) mentions wrong path for system-sleep directory
Package: systemd Version: 204-5 Severity: normal The systemd-suspend.service(8) manpage mentions /usr/lib/systemd/system-sleep as directory for additional scripts that get executed on suspend/resume, but this directory is /lib/systemd/system-sleep in reality. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi Jonathan, Marc, On 29-07-12 18:19, Jonathan Nieder wrote: I would be very happy to see cgit in Debian. Perhaps we could approach this by building cgit from the git source package, either using dpkg source format 3.0's multiple-tarball feature or by including cgit in the Debian patch. Would you be interested in this approach? Do you have initial cgit packaging to play with? I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I see a few advantages for this over building cgit from the git source package: - It doesn't group multiple separate projects into a single source package. While technically possible with the 3.0 source format, having separate source packages is more logical imo. - If cgit is broken due to a change in git, the git package doesn't FTBFS. This has the added advantage of cgit not holding up new releases, testing migrations, etc. of git. - Smaller packages are easier to maintain in my experience, though that's a bit subjective of course. The obvious downside is introduction of a new -source package. Since we cannot build-depend on source packages yet, and there are already ~80 such packages in the archive, I think this is acceptable. With the recent Built-Using introduction this also doesn't impose any licensing problems. If this route is acceptable for the git maintainers, I'm willing to step up as cgit (co-)maintainer. If someone else wants to join too, that's great! ;) Regards, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi, On 04-08-13 00:59, Jonathan Nieder wrote: I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I would prefer not to go this way. It would mean that when I make git uploads, they'd always have a chance of breaking the cgit build without notice. And it would also mean that whenever I fix an important bug I have to track down whether cgit needs to be rebuilt. Yes, that's true. (Unfortunately Debian doesn't have CI-infrastructure available to rebuild cgit on all commits to the git package. I think that could have been a good compromise). An alternative that is not as bad is to export libgit.a (or .so, for that matter) and headers for cgit use. Wouldn't exporting the static library suffer from the same problems as exporting the source? cgit will still need to be rebuild to profit from bug fixes in git, and git can still break its build without notice. Exporting the shared library would of course prevent the first problem. However, some of the discussion in #407722 indicated that git upstream doesn't want libgit to be exported, and the Debian maintainers didn't want to overrule them. If that has changed, great :) I think git breaking cgit's build isn't that big of a problem. cgit upstream seems to be active enough in fixing compatiblity with newer git versions, and the required changes are in general quite small (upgrade from 1.7.7.4 to 1.8.3 required just 6 lines of code in total). So if you don't have a problem with exporting libgit anymore, I think that's the way we should go, and I'll create cgit packages using them. I'd far prefer to just have a copy of cgit built as part of the git build. It doesn't have to involve multiple upstream tarballs: e.g., cgit can be included in the debian/ directory in the debian.tar.xz in the short term, and in the long term I think it would be a candidate for inclusion in contrib/ upstream. Building two projects with separate release cycles and upstreams from the same source package just feels wrong to me, and I prefer to not do it, especially as the git package already seems quite complex. > All that said, if someone wants to add another binary package like > git-source to the git build and is willing to maintain it in the long > term, I'll be glad to help (and wash my hands of the day-to-day > maintenance :)). > > See /usr/share/doc/git/README.source for hints on working with the > package. Packaging is at git://git.debian.org/~jrnieder-guest/git.git I'll take a stab at doing that. Maintaining it long-term shouldn't be a problem. (fyi, the Vcs-* fields in the package indicate another repository. Might be useful to synchronize the repositories and/or changes the Vcs-* fields.) Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698008: fglrx-driver: Xorg crashed when resizing terminal window (XFCE terminal / lxterminal)
Control: reopen -1 Control: found -1 1:13.8~beta1-2 On 04-08-13 22:56, Andreas Beckmann wrote: Please try the 13.8-beta1 driver from experimental. Nope, still broken for me with same crash and log messages as previously. However, I forgot to mention that I've found a workaround for the issue with Konsole: use the --notransparency flag. (Found the workaround here: https://bugs.kde.org/show_bug.cgi?id=310666) Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#601409: Escaping color codes in prompt
After also stumbling upon this problem, I found a solution for it. If you use color codes in your prompt, you should escape them with \[ and \] to indicate that they are non-printable characters and bash shouldn't count them while determining the length of the prompt. This isn't properly documented on a lot of sites which deal with color codes in bash. If you try this prompt, it should work fine. export PS1='\[\e[0;31m\]\u\[\e[m\]@\h:\w\$ ' Not sure if this can still be considered a bug in bash. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: status
On 08-08-11 23:06, Clint Byrum wrote: Excerpts from Oxan van Leeuwen's message of Mon Aug 08 07:27:01 -0500 2011: Hi Clint, What's the current status of the updated python-gearman.libgearman package? Hi Oxan. This package has been waiting for sponsorship for some time now, and fixes the bug: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=gearman-interface Hi Clint, Did you have any luck getting the updated package in Debian yet? I'd like to have this bug resolved sometime before the upcoming Wheezy freeze, so that python-gearman is included in the Wheezy release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663006: ITP: libnfc -- Near Field Communication (NFC) library
Package: wnpp Severity: wishlist Owner: Oxan van Leeuwen * Package name: libnfc Version : 1.6.0~rc1 Upstream Author : multiple people * URL : http://www.libnfc.org/ * License : LGPL-3 Programming Lang: C Description : Near Field Communication (NFC) library libnfc is a library for Near Field Communication. It abstracts the low-level details of communicating with the devices away behind an easy-to-use high-level API. Supported NFC hardware devices are, theorically, all hardware based on the NXP PN531, PN532 or PN533 NFC controller chip. I also intend to package the libraries and applications from the nfc-tools project (http://code.google.com/p/nfc-tools/), based upon libnfc. In the ideal case a NFC packaging team that handles all NFC-related packages could be formed. I am not a Debian Developer though, so it would be nice if an interested DD could join. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
Bug#663006: Why libnfc over The Linux NFC Subsystem ?
Hi, On 12-03-12 19:20, Andreas Henriksson wrote: Could you please describe why you're interested in working on getting libnfc into Debian now that we have The Linux NFC Subsystem? I'm willing to bet my money on that the latter is the one who will survive in the long run While the Linux NFC subsystem might indeed have the best chances to survive on the long term, I think currently libnfc is in a better state. The NFC subsystem only appeared in Linux 3.1 and still has a long way to go before it equals the functionality of libnfc. I couldn't find equivalents of relatively simple programs like nfc-mfclassic. I also think it's nice to be able to update libnfc independent from your kernel, especially since NFC development (in general) has quite a high pace nowadays. Besides, there are applications that require libnfc. That is because they either were designed before the NFC subsystem was born, or need to be compatible with other operating systems too. I'd be a shame if we couldn't package those applications for Debian. Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663006: Why libnfc over The Linux NFC Subsystem ?
Hi, Thanks for your input! On 13-03-12 13:49, Andreas Henriksson wrote: You could ofcourse package anything you wish, but including it in Debian is another question for me. Including it in Debian means you are prepared to maintain it in the long run. Several years to come. I'd avoid introducing lots of programs that depend on the libnfc API which you'll later need to port over to a new API and/or provide a migration path for users to new tools that has been developed for the new stack. You're ofcourse welcome to disagree. That is only true assuming that libnfc will eventually completely disappear. Especially given the response from upstream (see Thomas' mail), I doubt that will happen. libnfc has some more features which probably won't ever make it to the kernel (mfoc has already been mentioned). There is also the possibility of writing a libnfc driver that uses the kernel module, so that they can exist (and be used) together. Even if it will be completely replaced by the NFC subsystem, I think the benefits of having a complete NFC stack in wheezy outweighs the drawback of having a migration later on. Packages have been removed and superseded since the earliest Debian releases, and when there is a (better) alternative available, that shouldn't cause much problems. Cheers, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663006: Progress?
Hi, On 08-05-12 14:02, Thomas Hood wrote: How's it going with the packaging of libnfc? Are you waiting for the 1.6.0 release? No, not really. I still have to finish up the copyright documentation and want to fix some "regressions" compared to 1.5 (mainly some functions that output to stdout, which a library shouldn't do). Unfortunately I've been a bit short on time lately, but I hope to open an RFS in the coming weeks. Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672795: RFS: libnfc/1.6.0~rc1-1 [ITP #663006] -- Near Field Communication library
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libnfc". * Package name: libnfc Version : 1.6.0~rc1-1 Upstream Author : Roel Verdult, Romuald Conty, Romain Tartiere, et al. * URL : http://www.libnfc.org/ * License : LGPL-3+ Section : libs It builds those binary packages: libnfc-dev - Near Field Communication (NFC) library (development files) libnfc-utils - Near Field Communication (NFC) library (utilities) libnfc3 - Near Field Communication (NFC) library libnfc3-dbg - Near Field Communication (NFC) library (debugging information) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libnfc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libn/libnfc/libnfc_1.6.0~rc1-1.dsc Regards, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/debian-bugs-dist
Bug#668421: apt-cacher-ng: Please add an option to configure the user apt-cacher-ng runs as
Package: apt-cacher-ng
Version: 0.7.2-1
Severity: wishlist
Tags: patch
Please include an option in /etc/default/apt-cacher-ng (or another file) to
configure the user and group the service runs as. Currently the $NAME variable
is used for that in the initscript, but changing this one also changes the
status messages.
The proposed patch below adds a $USER and $GROUP option, which can be
overridden
in /etc/default/apt-cacher-ng.
--- /etc/init.d/apt-cacher-ng~ 2012-04-11 20:38:02.496353852 +0200
+++ /etc/init.d/apt-cacher-ng 2012-04-11 20:42:32.947116077 +0200
@@ -19,6 +19,8 @@
DAEMON=/usr/sbin/apt-cacher-ng
NAME=apt-cacher-ng
DESC=apt-cacher-ng
+USER=apt-cacher-ng
+GROUP=apt-cacher-ng
test -x $DAEMON || exit 0
@@ -42,8 +44,8 @@
return 255
fi
rm -rf "$RUNDIR" || return 1
- install -d --mode=0755 -o $NAME -g $NAME "$RUNDIR" || return 1
- start-stop-daemon --start --chuid $NAME --group $NAME --quiet --pidfile
$PIDFILE --exec $DAEMON -- $DAEMON_OPTS
+ install -d --mode=0755 -o $USER -g $GROUP "$RUNDIR" || return 1
+ start-stop-daemon --start --chuid $USER --group $GROUP --quiet --pidfile
$PIDFILE --exec $DAEMON -- $DAEMON_OPTS
}
do_stop() {
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515,
'experimental'), (500, 'testing-proposed-updates'), (500, 'stable-updates'),
(110, 'oneiric-updates'), (110, 'oneiric')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 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 apt-cacher-ng depends on:
ii adduser3.113+nmu1
ii debconf [debconf-2.0] 1.5.42
ii dpkg 1.16.2
ii libbz2-1.0 1.0.6-1
ii libc6 2.13-27
ii libgcc11:4.7.0-1
ii liblzma5 5.1.1alpha+20110809-3
ii libstdc++6 4.7.0-1
ii libwrap0 7.6.q-23
ii zlib1g 1:1.2.6.dfsg-2
Versions of packages apt-cacher-ng recommends:
ii ed1.6-1
ii perl 5.14.2-9
Versions of packages apt-cacher-ng suggests:
ii doc-base
ii libfuse2 2.8.7-1
-- Configuration Files:
/etc/apt-cacher-ng/backends_debian changed:
http://ftp.nl.debian.org/debian/
/etc/apt-cacher-ng/backends_ubuntu changed:
http://nl.archive.ubuntu.com/ubuntu/
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied:
u'/etc/apt-cacher-ng/security.conf'
-- debconf information:
apt-cacher-ng/gentargetmode: No automated setup
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/debian-bugs-dist
Bug#668427: python-urllib3: Please tighten build-dependency on python-coverage
Package: python-urllib3
Version: 1.3-1
Severity: minor
python-urllib3 doesn't build in squeeze chroots, even though all
build-dependencies are satisfied. This happens because the python-coverage
version in squeeze, 2.85-1, is too old. It builds fine with a backported
python-coverage 3.4-1 from wheezy. Please tighten the build-dependency to
python-coverage (>= 3.4), or another compatible version.
For reference, the build error that happens with python-coverage 2.85 is:
/usr/lib/python3.1/distutils/dist.py:259: UserWarning: Unknown distribution
option: 'test_suite'
warnings.warn(msg)
/usr/lib/python3.1/distutils/dist.py:259: UserWarning: Unknown distribution
option: 'tests_require'
warnings.warn(msg)
make[1]: Leaving directory `/«PKGBUILDDIR»'
debian/rules override_dh_auto_test
make[1]: Entering directory `/«PKGBUILDDIR»'
# Python3 testing is not possible at the moment because missing
# dependencies: python3-coverage.
set -ex; \
for python in python2.6; do \
$python /usr/bin/nosetests; \
done
+ python2.6 /usr/bin/nosetests
...
Traceback (most recent call last):
File "/usr/bin/nosetests", line 9, in
load_entry_point('nose==1.1.2', 'console_scripts', 'nosetests')()
File "/usr/lib/python2.6/dist-packages/nose/core.py", line 118, in __init__
**extra_args)
File "/usr/lib/python2.6/unittest.py", line 817, in __init__
self.runTests()
File "/usr/lib/python2.6/dist-packages/nose/core.py", line 197, in runTests
result = self.testRunner.run(self.test)
File "/usr/lib/python2.6/dist-packages/nose/core.py", line 63, in run
result.printErrors()
File "/usr/lib/python2.6/dist-packages/nose/result.py", line 110, in
printErrors
self.config.plugins.report(self.stream)
File "/usr/lib/python2.6/dist-packages/nose/plugins/manager.py", line 94, in
__call__
return self.call(*arg, **kw)
File "/usr/lib/python2.6/dist-packages/nose/plugins/manager.py", line 162, in
simple
result = meth(*arg, **kw)
File "/usr/lib/python2.6/dist-packages/nose/plugins/cover.py", line 167, in
report
self.coverInstance.save()
AttributeError: 'module' object has no attribute 'save'
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515,
'experimental'), (500, 'testing-proposed-updates'), (500, 'stable-updates'),
(110, 'oneiric-updates'), (110, 'oneiric')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 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 python-urllib3 depends on:
ii python 2.7.2-10
ii python-six 1.1.0-2
ii python2.6 2.6.7-4
ii python2.7 2.7.2-8
python-urllib3 recommends no packages.
python-urllib3 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
Archive: http://lists.debian.org/debian-bugs-dist
Bug#663006: libnfc co-maintainer?
Hi Ludovic, On 21-05-12 16:59, Ludovic Rousseau wrote: Hello Oxan van Leeuwen, I am a Debian Developper and also a libnfc upstream maintainer (since a few days). It looks like you are not yet a DD and may be looking for a sponsor. That's great! Actually, I think you already applied the patches I created while packaging ;-). For reference, last week I have submitted the RFS as #672795 indeed. I propose you to use collab-maint projet on alioth to host the debian/* packaging files. It will then be easy to co-maintain the NFC-related packages. That sounds like a good idea. I think the current procedure for getting access to collab-maint is the one in http://deb.li/3qmXG, so I've applied to the collab-maint project at Alioth (username oxan-guest). I already made some changes to the debian/* files in https://libnfc.googlecode.com/svn/trunk/debian to fix some lintian warnings but I also prefer to have the debian/* files in a separate repository. Great. I'll take a look at them and merge the relevant changes to my packaging. Cheers, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663006: libnfc co-maintainer?
Hi, On 22-05-12 08:39, Thomas Hood wrote: Upstream contains a rather verbose debian/changelog. Could this be edited down, renamed and/or merged with ChangeLog so that debian/changelog contains exclusively a log of *Debian's* work? Or how do you feel about this? -- Thomas Hood (Maintainer of provisory libnfc packages at ppa:jdthood/nfc) In my experience the Debian changelog usually starts empty when an package is uploaded to Debian for the first time. I think most, if not all, information in the upstream debian/changelog is already in ChangeLog, which I intend to ship as the upstream changelog in the Debian packages. Regards, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663006: libnfc co-maintainer?
Hi, On 23-05-12 15:49, Ludovic Rousseau wrote: I created a (empty) SVN repository. To get it use: $ svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/libnfc Bye Great! I've imported my current libnfc package into the repository (using debian/ only, but we can change that if you want). Most notable changes with the upstream packaging are: - I renamed the libnfc-bin package to libnfc-utils and dropped the libnfc-examples and libnfc-pn53x-examples. I'm not sure how useful the examples are for end-users. - Enabled multi-arch for the library package - Added an libnfc3-dbg package - Currently it still requires pcsc due to the acr122 driver. We might want to change that, but I'm a bit reluctant because the USB driver isn't in the 1.6.0~rc1 version yet. Regards, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669269: apache2: Fix typographic errors in configuration file comments
Source: apache2 Version: 2.4.2-1 Severity: minor Tags: patch Please see attached patch against the next branch in git to fix some typographic errors in comments in the configuration files. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (900, 'stable'), (525, 'unstable'), (515, 'experimental'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (110, 'oneiric-updates'), (110, 'oneiric') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash >From 17c13988945e47ffd3aebd386ac600cc5e265707 Mon Sep 17 00:00:00 2001 From: Oxan van Leeuwen Date: Wed, 18 Apr 2012 17:42:56 +0200 Subject: [PATCH] Fix typographic errors in configuration file comments --- debian/config-dir/apache2.conf |2 +- debian/config-dir/sites-available/000-default.conf |2 +- debian/config-dir/sites-available/default-ssl.conf |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/debian/config-dir/apache2.conf b/debian/config-dir/apache2.conf index 4c8d959..a145448 100644 --- a/debian/config-dir/apache2.conf +++ b/debian/config-dir/apache2.conf @@ -36,7 +36,7 @@ # supposed to determine listening ports for incoming connections which can be # customized anytime. # -# * Configuration files in the sites-enabled/, mods-enabled/ and conf-enabled/ +# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/ # directories contain particular configuration snippets which manage modules, # global configuration fragments or site specific configuration respectively. # diff --git a/debian/config-dir/sites-available/000-default.conf b/debian/config-dir/sites-available/000-default.conf index decfca5..ba65e14 100644 --- a/debian/config-dir/sites-available/000-default.conf +++ b/debian/config-dir/sites-available/000-default.conf @@ -14,7 +14,7 @@ # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to - # include a it only for a particular virtual host. For example the + # include it only for a particular virtual host. For example the # following line enables the CGI configuration for this host # only after disabling it globally with "a2disconf". #Include conf-available/serve-cgi-bin.conf diff --git a/debian/config-dir/sites-available/default-ssl.conf b/debian/config-dir/sites-available/default-ssl.conf index 33a9f55..0c61c00 100644 --- a/debian/config-dir/sites-available/default-ssl.conf +++ b/debian/config-dir/sites-available/default-ssl.conf @@ -16,7 +16,7 @@ # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to - # include a it only for a particular virtual host. For example the + # include it only for a particular virtual host. For example the # following line enables the CGI configuration for this host # only after disabling it globally with "a2disconf". #Include conf-available/serve-cgi-bin.conf -- 1.7.9.5
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi,
On 15-08-15 12:21, Tomasz Buchert wrote:
I've tested the AppArmor profile too, it looks fine, although I'm not
sure if 'm' is needed in the profile for '/usr/sbin/postsrsd', since
it seems to work just fine without it. I've a rather basic knowledge
about AppArmor, so if you could explain it to me, I'd be grateful.
I'm not sure about it either, I just copied the AppArmor profile from
upstream. Judging from the AppArmor docs it's indeed not needed, I'll do
some further research tomorrow and remove it if possible.
And the last thing: in the systemd unit, you do:
-d$${SRS_DOMAIN:-$$(postconf -h mydomain 2>/dev/null)}
Well, first if SRS_DOMAIN is set to something that it's fine, if it's not,
then postconf is used to get the mail server domain. But postconf may not
be present! You probably need to depend on postfix, unless postsrsd can be used
with other mail software.
Technically postsrsd can be used with other mail servers too, though I
doubt it will happen in practice. Is it really a problem if postconf is
called when it's not present, though? Its output is silenced, and
postsrsd fails when the -d argument is empty anyway.
I'd also recommend using EnvironmentFile in your systemd unit [1].
The systemd unit is already loading /etc/default/postsrsd as
EnvironmentFile, it's just the defaults that are in the systemd unit.
Not sure why I did that though (I believe we usually don't support
removing files from /etc/default), so they can be safely removed. I'll
push a fix.
I also pushed some minor fixes.
Are you sure? I don't see any new commits in the collab-maint repository.
When this is done, I'll be happy to push your package,
I already use it myself for some time :).
That's great!
Cheers,
Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi, On 18-08-15 01:01, Tomasz Buchert wrote: great! Just nit-picking here, really. And trying to understand AppArmor :). You seem to be right, I've committed a patch to remove the m flag. Yes, I tried without postconf present and the unit failed. Its output is silenced, and postsrsd fails when the -d argument is empty anyway. I don't think you want this systemd unit to fail *by default*. Hmm, you're right about that. Would a Recommends be good enough, or do we really need a hard dependency? I'd like to avoid adding a hard dependency only for the systemd unit (since the daemon itself runs fine without postfix), and failing is in my opinion the only reasonable option when neither postconf nor a configured domain is present. Sorry, I didn't notice that. I agree, though, that it would make sense to put all configuation in one place. I looked a bit further into this, and Debian Policy 9.3.2 says that removing the /etc/default file should be supported, so I don't think we can drop the defaults from the systemd unit. Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "postsrsd" * Package name: postsrsd Version : 1.2-1 Upstream Author : Timo Röhling * URL : https://github.com/roehling/postsrsd * License : GPL-2+ Section : mail It builds those binary packages: postsrsd - Sender Rewriting Scheme (SRS) lookup table for Postfix To access further information about this package, please visit the following URL: http://mentors.debian.net/package/postsrsd Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/postsrsd/postsrsd_1.2-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: postsrsd (1.2-1) unstable; urgency=medium * Initial release (Closes: #757720) -- Oxan van Leeuwen Fri, 26 Dec 2014 17:35:3 Regards, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi Tomasz, Yes, I'm still looking for a sponsor. Cheers, Oxan On 23-07-15 23:40, Tomasz Buchert wrote: Hi Oxan, still looking for a sponsor? I've just wanted to implement SRS on my mail server! Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi, On 24-07-15 02:43, Cameron Norman wrote: I see the prerm file is empty -- why not just delete it? Oops, that's a leftover from the switch to dh_apparmor. I've deleted it in the git repository. Also, why do you patch the sysv-redhat init script if you end up using the sysv-lsb one? I think you can drop that part of the patch. Yes, it's probably not that useful to keep that patch. It shouldn't hurt either though. Finally, have you actually tested the AppArmor profile works on Debian? Yes, I've tested it. Cheers, Oxan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755115: php5-fpm: getallheaders() contains extra null byte after header keys
res: i386
Kernel: Linux 3.15-trunk-amd64 (SMP w/8 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 php5-fpm depends on:
ii dpkg 1.17.10
ii init-system-helpers 1.19
ii libbz2-1.0 1.0.6-5
ii libc62.19-7
ii libcomerr2 1.42.10-1.1
ii libdb5.3 5.3.28-5
ii libgssapi-krb5-2 1.12.1+dfsg-4
ii libk5crypto3 1.12.1+dfsg-4
ii libkrb5-31.12.1+dfsg-4
ii libmagic11:5.19-1
ii libonig2 5.9.5-2
ii libpcre3 1:8.31-5
ii libqdbm141.8.78-5
ii libssl1.0.0 1.0.1h-3
ii libsystemd-daemon0 208-6
ii libxml2 2.9.1+dfsg1-3
ii mime-support 3.56
ii php5-common 5.6.0~rc2+dfsg-3.1
ii php5-json1.3.5-3
ii tzdata 2014e-1
ii ucf 3.0030
ii zlib1g 1:1.2.8.dfsg-1
php5-fpm recommends no packages.
Versions of packages php5-fpm suggests:
pn php-pear
Versions of packages php5-common depends on:
ii libc6 2.19-7
ii lsof4.86+dfsg-1
ii psmisc 22.21-2
ii sed 4.2.2-4
ii ucf 3.0030
Versions of packages php5-common suggests:
ii php5-apcu [php5-user-cache] 4.0.6-1
-- Configuration Files:
/etc/logrotate.d/php5-fpm [Errno 2] No such file or directory:
u'/etc/logrotate.d/php5-fpm'
/etc/php5/fpm/php-fpm.conf changed [not included]
/etc/php5/fpm/pool.d/www.conf [Errno 2] No such file or directory:
u'/etc/php5/fpm/pool.d/www.conf'
-- no debconf information
diff -Nru php5-5.6.0~rc2+dfsg/debian/changelog php5-5.6.0~rc2+dfsg/debian/changelog
--- php5-5.6.0~rc2+dfsg/debian/changelog 2014-07-11 09:51:41.0 +0200
+++ php5-5.6.0~rc2+dfsg/debian/changelog 2014-07-17 22:14:12.0 +0200
@@ -1,3 +1,10 @@
+php5 (5.6.0~rc2+dfsg-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix null byte suffix after keys in getallheaders() result
+
+ -- Oxan van Leeuwen Thu, 17 Jul 2014 22:14:01 +0200
+
php5 (5.6.0~rc2+dfsg-3) unstable; urgency=medium
* Remove Sean Finney from Uploaders; Thanks for all the hard work!
diff -Nru php5-5.6.0~rc2+dfsg/debian/patches/php-fpm-getallheaders.patch php5-5.6.0~rc2+dfsg/debian/patches/php-fpm-getallheaders.patch
--- php5-5.6.0~rc2+dfsg/debian/patches/php-fpm-getallheaders.patch 2014-07-11 09:51:41.0 +0200
+++ php5-5.6.0~rc2+dfsg/debian/patches/php-fpm-getallheaders.patch 2014-07-17 22:14:52.0 +0200
@@ -63,7 +63,7 @@
+ } else {
+ return;
+ }
-+ add_assoc_stringl_ex(return_value, var, var_len+1, val, val_len, 1);
++ add_assoc_stringl_ex(return_value, var, var_len, val, val_len, 1);
+ if (str) {
+ free_alloca(var, use_heap);
+ }
Bug#756846: owncloud: forcibly sets /etc/owncloud to www-data in postinst
Package: owncloud Version: 7.0.0+dfsg-1 Severity: normal Dear Maintainer, The owncloud package forcibly changes the owner and group of /etc/owncloud to www-data. This is problematic if you run owncloud as another user, since you need to set the owner back on every upgrade. Please preserve user-made modifications to the config file permissions. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (110, 'testing-updates'), (110, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 owncloud depends on: ii apache2 2.4.10-1 ii apache2-bin [httpd] 2.4.10-1 ii apache2-mpm-prefork [httpd] 2.4.10-1 ii fonts-font-awesome 4.1.0~dfsg-1 ii fonts-liberation 1.07.2-6 ii fonts-linuxlibertine 5.1.3-1 ii fonts-lohit-deva 2.5.1-1 ii fonts-sil-gentium-basic 1.1-5 ii fonts-wqy-microhei 0.2.0-beta-2 ii libjs-chosen 0.9.11-1 ii libjs-dojo-dojox 1.7.2+dfsg-1 ii libjs-jcrop 0.9.12+dfsg-1 ii libjs-jquery-minicolors 1.2.1-1 ii libjs-jquery-mousewheel 6-1 ii libjs-jquery-timepicker 1.2-1 ii libjs-pdf1.0.277-1 ii libphp-phpmailer 5.1-1 ii owncloud-doc 0~20140721-2 ii php-assetic 1.1.2-1 ii php-doctrine-dbal2.4.2-3 ii php-getid3 1.9.8-1 ii php-mssql-bundle 0~20140212-1 ii php-opencloud1.10.0-2 ii php-patchwork-utf8 1.1.24-1 ii php-pear 5.4.4-14+deb7u12 ii php-pimple 1.1.1-1 ii php-sabre-dav1.8.10-1 ii php-seclib 0.3.7-1 ii php-symfony-classloader 2.3.6-1 ii php-symfony-console 2.3.1+dfsg-1 ii php-symfony-routing 2.0.19-1 ii php5 5.4.4-14+deb7u12 ii php5-gd 5.6.0~rc2+dfsg-5 ii php5-json1.3.5-3 ii php5-pgsql 5.6.0~rc2+dfsg-5 ii zendframework1.11.13-1.1 Versions of packages owncloud recommends: pn libav-tools pn libreoffice pn php-aws-sdk pn php-crypt-blowfish ii php-dropbox 1.0.0-1 ii php-google-api-php-client 0.6.7-2 pn php5-apcu | php5-xcache ii php5-cli5.6.0~rc2+dfsg-5 ii php5-curl 5.6.0~rc2+dfsg-5 pn php5-imagick pn php5-intl ii php5-ldap 5.6.0~rc2+dfsg-5 pn php5-mcrypt ii postfix [mail-transport-agent] 2.9.6-2 ii smbclient 2:4.1.9+dfsg-1~bpo70+1 Versions of packages owncloud suggests: pn libapache2-mod-xsendfile ii mariadb-server-5.5 [virtual-mysql-server] 5.5.38-1 -- Configuration Files: /etc/owncloud/htaccess [Errno 13] Permission denied: u'/etc/owncloud/htaccess' -- 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#777010: reportbug crashes when trying to submit bug report
Hi, On 05-02-15 13:15, Sandro Tosi wrote: You are using paranoid mode, which makes reportbug print the message right before submitting it, and there is where you are seeing the traceback. Yes, that's correct. reportbug crashes immediately after I exit the pager. Given your particular EDITOR env var, is it possible that PAGER is also set to something "uncommon"? No, the PAGER environment variable is unset; and the pager started was simply less. are you able to replicate this bug or was just "one off"? Yes, I was able to replicate it twice. Some further testing just now revealed that I can reproduce it reliably but only when I attach a specific file, which I've attached to this message. Let me know if I can do more to help. Regards, Oxan [0.00] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.18.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 3.18.5-1~exp1 (2015-01-31) [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.18.0-trunk-amd64 root=UUID=452d1dc1-2c61-4bba-b64a-8137c122bf0b ro net.ifnames=1 netconsole=@130.89.172.53/eth0,@130.89.171.131/60:a4:4c:d6:77:4d [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0xc29e4fff] usable [0.00] BIOS-e820: [mem 0xc29e5000-0xc29ebfff] ACPI NVS [0.00] BIOS-e820: [mem 0xc29ec000-0xc2e2efff] usable [0.00] BIOS-e820: [mem 0xc2e2f000-0xc33b] reserved [0.00] BIOS-e820: [mem 0xc33c-0xd4dabfff] usable [0.00] BIOS-e820: [mem 0xd4dac000-0xd4e43fff] reserved [0.00] BIOS-e820: [mem 0xd4e44000-0xd4e94fff] usable [0.00] BIOS-e820: [mem 0xd4e95000-0xd4fc7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xd4fc8000-0xd5f80fff] reserved [0.00] BIOS-e820: [mem 0xd5f81000-0xd5ffefff] type 20 [0.00] BIOS-e820: [mem 0xd5fff000-0xd5ff] usable [0.00] BIOS-e820: [mem 0xd700-0xdf1f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00031fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ACPI=0xd4f99000 ACPI 2.0=0xd4f99000 SMBIOS=0xf04d0 MPS=0xfd500 [0.00] efi: mem00: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x-0x8000) (0MB) [0.00] efi: mem01: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x8000-0x00058000) (0MB) [0.00] efi: mem02: [Reserved | | | | | |WB|WT|WC|UC] range=[0x00058000-0x00059000) (0MB) [0.00] efi: mem03: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x00059000-0x0005f000) (0MB) [0.00] efi: mem04: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x0005f000-0x0006) (0MB) [0.00] efi: mem05: [Boot Code | | | | | |WB|WT|WC|UC] range=[0x0006-0x0009f000) (0MB) [0.00] efi: mem06: [Reserved | | | | | |WB|WT|WC|UC] range=[0x0009f000-0x000a) (0MB) [0.00] efi: mem07: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x0010-0x00f68000) (14MB) [0.00] efi: mem08: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x00f68000-0x361bc000) (850MB) [0.00] efi: mem09: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x361bc000-0x370d6000) (15MB) [0.00] efi: mem10: [Conventional Memory| | | | | |WB|WT|WC|UC] range=[0x370d6000-0x8d955000) (1384MB) [0.00] efi: mem11: [Loader Data| | | | | |WB|WT|WC|UC] range=[0x8d955000-0xbf4dd000) (795MB) [0.0
Bug#772066: patches available
There seem to be patches available upstream now, can we please merge them for jessie? Combined with #759361, this bug makes krdc completely unusable. Patches are linked here: https://bugs.kde.org/show_bug.cgi?id=341284 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777010: reportbug crashes when trying to submit bug report
Package: reportbug Version: 6.6.3 Severity: grave Justification: renders package unusable I was trying to report a bug to the kernel, but after the report was shown for confirmation before sending the mail, it crashes: Submit this report on linux-image-3.18.0-trunk-amd64 (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|s|?]? Y Traceback (most recent call last): File "/usr/bin/reportbug", line 2211, in main() File "/usr/bin/reportbug", line 1081, in main return iface.user_interface() File "/usr/bin/reportbug", line 2203, in user_interface self.options.envelopefrom) File "/usr/lib/python2.7/dist-packages/reportbug/submit.py", line 305, in send_report os.popen(pager, 'w').write(message) IOError: [Errno 32] Broken pipe -- Package-specific info: ** Environment settings: EDITOR="/home/oxan/shell/bin/edit -f" DEBEMAIL="o...@oxanvanleeuwen.nl" EMAIL="o...@oxanvanleeuwen.nl" DEBFULLNAME="Oxan van Leeuwen" NAME="Oxan van Leeuwen" INTERFACE="text" ** /home/oxan/.reportbugrc: mode advanced ui text paranoid editor "nano -r 80" no-cc realname "Oxan van Leeuwen" email "o...@oxanvanleeuwen.nl" -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (920, 'testing'), (910, 'stable'), (900, 'testing-proposed-updates'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt 1.0.9.6 ii python2.7.8-2 ii python-reportbug 6.6.3 pn python:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs23-bin-common | emacs24-bin-common ii file 1:5.20-2 ii gnupg1.4.18-6 ii msmtp-mta [mail-transport-agent] 1.4.32-2 pn python-gtk2 pn python-gtkspell pn python-urwid pn python-vte ii xdg-utils1.1.0~rc1+git20111210-7.3 Versions of packages python-reportbug depends on: ii apt 1.0.9.6 ii python-debian 0.1.25 ii python-debianbts 1.12 pn python:any python-reportbug 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#777016: linux-image-3.18.0-trunk-amd64: kernel panic in __intel_set_mode
Package: src:linux Version: 3.18.5-1~exp1 Severity: serious My system hangs when booting using kernel 3.18 sometime after unlocking the encrypted root disk. Kernel 3.17 works fine. * Using the default kernel command line, the problem occurs everytime. * Using the nomodeset parameter, the kernel works fine but I can't use X. * When using netconsole, the system sometimes hangs and sometimes works fine, though outputting a warning in the kernel (see first log below). When the kernel hangs, unfortunately only the first few lines of the BUG show up in the netconsole (see second log at the bottom). Let me know if I can be of any more assistance. -- Package-specific info: ** Version: Linux version 3.18.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 3.18.5-1~exp1 (2015-01-31) ** Command line: BOOT_IMAGE=/vmlinuz-3.18.0-trunk-amd64 root=UUID=452d1dc1-2c61-4bba-b64a-8137c122bf0b ro net.ifnames=1 netconsole=@130.89.172.53/eth0,@130.89.171.131/60:a4:4c:d6:77:4d ** Tainted: W (512) * Taint on warning. ** Kernel log (when system was booted with netconsole and didn't panic): [9.236016] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [9.236361] acpi device:60: registered as cooling_device10 [9.236420] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input9 [9.236629] [drm] Initialized i915 1.6.0 20140905 for :00:02.0 on minor 0 [9.236710] ACPI Warning: SystemIO range 0xf040-0xf05f conflicts with OpRegion 0xf040-0xf04f (\_SB_.PCI0.SBUS.SMBI) (20140926/utaddress-258) [9.236728] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [9.236820] snd_hda_intel :00:03.0: enabling device ( -> 0002) [9.236883] snd_hda_intel :00:1b.0: enabling device ( -> 0002) [9.237298] snd_hda_intel :00:03.0: irq 31 for MSI/MSI-X [9.237400] snd_hda_intel :00:1b.0: irq 32 for MSI/MSI-X [9.247250] sound hdaudioC1D0: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line [9.247255] sound hdaudioC1D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [9.247257] sound hdaudioC1D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [9.247259] sound hdaudioC1D0:mono: mono_out=0x0 [9.247261] sound hdaudioC1D0:dig-out=0x1e/0x0 [9.247262] sound hdaudioC1D0:inputs: [9.247264] sound hdaudioC1D0: Front Mic=0x19 [9.247266] sound hdaudioC1D0: Rear Mic=0x18 [9.247268] sound hdaudioC1D0: Line=0x1a [9.260930] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/sound/card0/input18 [9.261589] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/sound/card0/input19 [9.261619] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card1/input10 [9.261928] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/sound/card0/input20 [9.262246] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1b.0/sound/card1/input11 [9.262699] input: HDA Intel PCH Line as /devices/pci:00/:00:1b.0/sound/card1/input12 [9.262997] input: HDA Intel PCH Line Out Front as /devices/pci:00/:00:1b.0/sound/card1/input13 [9.263271] input: HDA Intel PCH Line Out Surround as /devices/pci:00/:00:1b.0/sound/card1/input14 [9.263535] input: HDA Intel PCH Line Out CLFE as /devices/pci:00/:00:1b.0/sound/card1/input15 [9.263815] input: HDA Intel PCH Line Out Side as /devices/pci:00/:00:1b.0/sound/card1/input16 [9.264073] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card1/input17 [9.279344] [ cut here ] [9.279372] WARNING: CPU: 0 PID: 411 at /build/linux-xmCjRp/linux-3.18.5/drivers/gpu/drm/i915/intel_display.c:11417 intel_crtc_set_config+0xbe8/0xe60 [i915]() [9.279374] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic nls_utf8 nls_cp437 vfat fat iTCO_wdt mxm_wmi ppdev iTCO_vendor_support joydev x86_pkg_temp_thermal evdev intel_powerclamp intel_rapl coretemp efi_pstore kvm_intel psmouse kvm snd_hda_intel snd_hda_controller serio_raw snd_hda_codec efivars snd_hwdep pcspkr i2c_i801 snd_pcm snd_timer snd i915 soundcore drm_kms_helper intel_smartconnect tpm_infineon 8250_fintek video drm parport_pc tpm_tis battery parport tpm i2c_algo_bit wmi i2c_core shpchp mei_me lpc_ich mei mfd_core button processor fuse autofs4 ext4 crc16 mbcache jbd2 algif_skcipher af_alg dm_crypt dm_mod hid_generic usbhid hid netconsole configfs sg sr_mod cdrom sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel xhci_pci [9.279628] ahci libahci aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd xhci_hcd libata ehci_pci ehci_hcd scsi_mod r8169 mii usbcore usb_common thermal fa
Bug#780685: /usr/bin/crontab: Should display error message when crontab doesn't exist yet
Package: systemd-cron Version: 1.3.1+ds1-2 Severity: normal If the crontab for your user doesn't exit and you run crontab -l, a Python stacktrace is produced instead of a user-friendly error message. Traceback (most recent call last): File "/usr/bin/crontab", line 94, in action(cron_file, args) File "/usr/bin/crontab", line 55, in list with open(cron_file, 'r') as f: IOError: [Errno 2] No such file or directory: '/var/spool/cron/crontabs/oxan' -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (920, 'testing'), (910, 'stable'), (900, 'testing-proposed-updates'), (525, 'unstable'), (515, 'experimental'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-cron depends on: ii init-system-helpers 1.22 ii python 2.7.8-4 pn python:any ii systemd-sysv 215-12 systemd-cron recommends no packages. systemd-cron 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#793331: RFS: postsrsd/1.2-1 [ITP]
Hi, On 21-08-15 00:19, Tomasz Buchert wrote: I think that we either: * need hard dependency on postfix * need to have a debconf dialog that goes more or less like that: - if postconf exists, the domain is taken from there - if not, the current hostname is taken - then a debconf dialog is shown prefilled with these defaults - the obtained domain name is used in init scripts Waht do you think? Tell me if you need help with the second. The second option seems sensible, I've pushed an implementation. Let me know what you think. I think that a sensible thing to do would be to provide POSTSRSD_OPTS as 'Environment=...' and then pull a config file with 'EnvironmentFile=-...' (which may contain various configs in comments too). It seems to be sort-of standard. And, right, if you also use debconf, then you probably need to pull a file created created in postinst. I'd prefer to keep separate variables for the most common options. A single options variable will be quite cryptic (as postsrsd doesn't support long options), and that will make it harder to change a setting without having to pull the manpage. Duplicating a few defaults is a small price to pay for ease of configuration in my opinion. We could add a options variable to add additional command-line options, though I doubt it will be used much. Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
Hi Thomas, On 24-08-15 14:10, Tomasz Buchert wrote: Nicely done, but there is one issue. If you modify conffiles in postinst it marks them as changed, and this is not something you want to do. In my branch "tomasz-changes" I followed ADVANCED PROGRAMMING WITH DEBCONF section in "man debconf-devel". The outcome is that the config file is not tracked by conffiles machinery and hence the problem does not exist. Please review. Yeah, that's definitely true. Your branch looks good to me. It's probably a bit cleaner to wrap the config-writing machinery in the postinst in an if [ "$1" = "configure" ], but I don't think it hurts to execute it for the other postinst invocations as well. Other than that, I don't think there are any remaining issues preventing upload? Cheers, Oxan
Bug#793331: RFS: postsrsd/1.2-1 [ITP]
On 25-08-15 09:09, Tomasz Buchert wrote: Hi, do you understand this lintian warning about incomplete translation? It complains about the templates file, it looks strange to me. I believe it complains that there are no translations for the debconf templates yet. I'm not sure how to get translations for a package that isn't in the archive yet though, a quick search revealed only workflows for existing packages. Cheers, Oxan
Bug#797861: postsrsd: General update after the debconf review process
Hi Christian, On 18-10-15 07:07, Christian PERRIER wrote: Please notify me of your intents with regards to this. Thanks for the translation process! I've imported the translations into the Git repository. I intent to fix other outstanding bug shortly and upload a new version with the translations then. Cheers, Oxan
Bug#797861: postsrsd: Translations
Hi, Sorry that I've been a bit lacking in feedback so far. I really appreciate the review & translations, it's making Debian better for everyone :) I'll wait a few more days to see if more translations come in, and then prepare a new version with your contributions. Thanks! Regards, Oxan van Leeuwen
Bug#789708: linux-image-3.16.0-4-amd64: Audio card passthrough in libvirt causes hung task
Package: src:linux Version: 3.16.7-ckt11-1 Severity: normal We have a VM configured in libvirt that uses PCI passthrough with an audio card. When starting this VM, libvirt hangs forever and the error as shown below shows up in the kernel log. If I try to kill libvirt, it becomes a zombie process (as expected with a hung system call). We use the following configuration in libvirt (see lspci output below for details about the hardware): -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=e0eb0e74-842f-42bb-a0f4-8188aeec595b ro intel_iommu=on quiet ** Not tainted ** Kernel log: [ 961.428971] INFO: task libvirtd:1280 blocked for more than 120 seconds. [ 961.429021] Not tainted 3.16.0-4-amd64 #1 [ 961.429053] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 961.429112] libvirtdD 88046de41a88 0 1280 1 0x [ 961.429121] 88046de41630 0082 00012f00 88007da7ffd8 [ 961.429125] 00012f00 88046de41630 88007da7fe38 88007da7fdc8 [ 961.429129] 88007da7fe30 88046de41630 000c 7fdb98011710 [ 961.429134] Call Trace: [ 961.429148] [] ? schedule_timeout+0x229/0x2a0 [ 961.429155] [] ? wait_for_completion+0xa8/0x120 [ 961.429163] [] ? wake_up_state+0x10/0x10 [ 961.429189] [] ? snd_card_free+0x53/0x60 [snd] [ 961.429198] [] ? pci_device_remove+0x33/0xb0 [ 961.429207] [] ? __device_release_driver+0x7a/0xf0 [ 961.429212] [] ? device_release_driver+0x1e/0x30 [ 961.429216] [] ? unbind_store+0xb5/0xe0 [ 961.429224] [] ? kernfs_fop_write+0xda/0x150 [ 961.429235] [] ? vfs_write+0xb2/0x1f0 [ 961.429239] [] ? SyS_write+0x42/0xa0 [ 961.429246] [] ? system_call_fast_compare_end+0x10/0x15 [ 1081.519383] INFO: task libvirtd:1280 blocked for more than 120 seconds. [ 1081.519432] Not tainted 3.16.0-4-amd64 #1 [ 1081.519465] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1081.519524] libvirtdD 88046de41a88 0 1280 1 0x [ 1081.519533] 88046de41630 0082 00012f00 88007da7ffd8 [ 1081.519538] 00012f00 88046de41630 88007da7fe38 88007da7fdc8 [ 1081.519542] 88007da7fe30 88046de41630 000c 7fdb98011710 [ 1081.519546] Call Trace: [ 1081.519561] [] ? schedule_timeout+0x229/0x2a0 [ 1081.519567] [] ? wait_for_completion+0xa8/0x120 [ 1081.519575] [] ? wake_up_state+0x10/0x10 [ 1081.519601] [] ? snd_card_free+0x53/0x60 [snd] [ 1081.519610] [] ? pci_device_remove+0x33/0xb0 [ 1081.519620] [] ? __device_release_driver+0x7a/0xf0 [ 1081.519624] [] ? device_release_driver+0x1e/0x30 [ 1081.519629] [] ? unbind_store+0xb5/0xe0 [ 1081.519636] [] ? kernfs_fop_write+0xda/0x150 [ 1081.519647] [] ? vfs_write+0xb2/0x1f0 [ 1081.519651] [] ? SyS_write+0x42/0xa0 [ 1081.519659] [] ? system_call_fast_compare_end+0x10/0x15 [ 1201.609792] INFO: task libvirtd:1280 blocked for more than 120 seconds. [ 1201.609848] Not tainted 3.16.0-4-amd64 #1 [ 1201.609881] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1201.609942] libvirtdD 88046de41a88 0 1280 1 0x [ 1201.609951] 88046de41630 0082 00012f00 88007da7ffd8 [ 1201.609955] 00012f00 88046de41630 88007da7fe38 88007da7fdc8 [ 1201.609959] 88007da7fe30 88046de41630 000c 7fdb98011710 [ 1201.609963] Call Trace: [ 1201.609978] [] ? schedule_timeout+0x229/0x2a0 [ 1201.609984] [] ? wait_for_completion+0xa8/0x120 [ 1201.609993] [] ? wake_up_state+0x10/0x10 [ 1201.610019] [] ? snd_card_free+0x53/0x60 [snd] [ 1201.610027] [] ? pci_device_remove+0x33/0xb0 [ 1201.610036] [] ? __device_release_driver+0x7a/0xf0 [ 1201.610041] [] ? device_release_driver+0x1e/0x30 [ 1201.610046] [] ? unbind_store+0xb5/0xe0 [ 1201.610053] [] ? kernfs_fop_write+0xda/0x150 [ 1201.610064] [] ? vfs_write+0xb2/0x1f0 [ 1201.610068] [] ? SyS_write+0x42/0xa0 [ 1201.610076] [] ? system_call_fast_compare_end+0x10/0x15 [ 1321.700714] INFO: task libvirtd:1280 blocked for more than 120 seconds. [ 1321.700763] Not tainted 3.16.0-4-amd64 #1 [ 1321.700795] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1321.700853] libvirtdD 88046de41a88 0 1280 1 0x [ 1321.700861] 88046de41630 0082 00012f00 88007da7ffd8 [ 1321.700866] 00012f00 88046de41630 88007da7fe38 88007da7fdc8 [ 1321.700870] 88007da7fe30 88046de41630 000c 7fdb98011710 [ 1321.700874] Call Trace: [ 1321.700888] [] ? schedule_timeout+0x229/0x2a0 [ 1321.700894] [] ? wait_for_co
Bug#760995: patch
tags 760995 + patch found 760995 3.4.0-2 thanks Please see attached patch to fix this. --- spamassassin.orig 2014-09-13 01:01:07.749882769 +0200 +++ spamassassin 2014-09-13 01:00:27.965285382 +0200 @@ -36,7 +36,7 @@ if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then env -i LANG="$LANG" PATH="$PATH" start-stop-daemon \ --chuid debian-spamd:debian-spamd --start \ ---exec /usr/bin/sa-compile +--exec /usr/bin/sa-compile -- --quiet # Fixup perms -- group and other should be able to # read and execute, but never write. Works around
Bug#767990: samba: dependency on too old version of Heimdal kerberos
Package: samba Version: 2:4.1.13+dfsg-2 Severity: important Dear Maintainer, 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: 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 This was using version 1.6~git20120403+dfsg1-2 of the various Heimdal library packages. Once I updated them all to the version in jessie (1.6~rc2+dfsg-8), Samba started and samba-tool started working again: 23:12 oxan@oppenheimer [#127 0] /var/log/samba$ samba-tool testparm --parameter-name="server role" active directory domain controller I currently have the following heimdal library packages installed, which I think are all pulled in by Samba: 23:18 oxan@oppenheimer [#129 0] /var/log/samba$ aptitude search heimdal~i i A libasn1-8-heimdal - Heimdal Kerberos - ASN.1 library i A libgssapi3-heimdal - Heimdal Kerberos - GSSAPI support library i A libhcrypto4-heimdal - Heimdal Kerberos - crypto library i A libhdb9-heimdal - Heimdal Kerberos - kadmin server library i A libheimbase1-heimdal- Heimdal Kerberos - Base library i A libheimntlm0-heimdal- Heimdal Kerberos - NTLM support library i A libhx509-5-heimdal - Heimdal Kerberos - X509 support library i A libkdc2-heimdal - Heimdal Kerberos - KDC support library i A libkrb5-26-heimdal - Heimdal Kerberos - libraries i A libroken18-heimdal - Heimdal Kerberos - roken support library i A libwind0-heimdal- Heimdal Kerberos - stringprep implementati Please update the version constraint in the dependency. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (110, 'testing-updates'), (110, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 samba depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.13 ii libasn1-8-heimdal1.6~rc2+dfsg-8 ii libbsd0 0.7.0-2 ii libc62.19-12 ii libcomerr2 1.42.5-1.1 ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-8 ii libkdc2-heimdal 1.6~rc2+dfsg-8 ii libkrb5-26-heimdal 1.6~rc2+dfsg-8 ii libldb1 1:1.1.17-1~bpo70+0 ii libpam-modules 1.1.3-7.1 ii libpam-runtime 1.1.3-7.1 ii libpopt0 1.16-7 ii libpython2.7 2.7.8-11 ii libroken18-heimdal 1.6~rc2+dfsg-8 ii libtalloc2 2.1.1-2 ii libtdb1 1.3.1-1 ii libtevent0 0.9.21-1 ii lsb-base 4.1+Debian8+deb7u1 ii multiarch-support2.13-38+deb7u6 ii procps 1:3.3.3-3 ii python 2.7.8-1 ii python-dnspython 1.10.0-1 ii python-ntdb 1.0-5 ii python-samba 2:4.1.13+dfsg-2 pn python2.7:any ii samba-common 2:4.1.13+dfsg-2 ii samba-common-bin 2:4.1.13+dfsg-2 ii samba-dsdb-modules 2:4.1.13+dfsg-2 ii samba-libs 2:4.1.13+dfsg-2 ii tdb-tools1.3.0-1.1~bpo70+0 ii update-inetd 4.43 Versions of packages samba recommends: ii attr 1:2.4.46-8 ii logrotate 3.8.1-4 ii samba-vfs-modules 2:4.1.13+dfsg-2 Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb ii ldb-tools 1:1.1.17-1~bpo70+0 ii ntp1:4.2.6.p5+dfsg-2 pn smbldap-tools ii winbind2:4.1.13+dfsg-2 -- Configuration Files: /etc/logrotate.d/samba changed [not included] -- 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#757720: ITP: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix
Package: wnpp Severity: wishlist Owner: Oxan van Leeuwen * Package name: postsrsd Version : 1.1 Upstream Author : Timo Röhling * URL : https://github.com/roehling/postsrsd * License : GPL-2+ Programming Lang: C Description : Sender Rewriting Scheme (SRS) lookup table for Postfix PostSRSd provides Sender Rewriting Scheme (SRS) support for Postfix via TCP-based lookup tables. SRS is needed if your mail server acts as a forwarder, and the mail originates from a server with Sender Policy Framework (SPF) enabled. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#763293: RFS: postsrsd/1.1-1 [ITP]
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package postsrsd: * Package name: postsrsd Version : 1.1 Upstream Author : Timo Rohling * URL : https://github.com/roehling/postsrsd * License : GPL-2+ Section : mail It builds those binary packages: postsrsd - Sender Rewriting Scheme (SRS) lookup table for Postfix PostSRSd provides Sender Rewriting Scheme (SRS) support for Postfix via TCP-based lookup tables. SRS is needed if your mail server acts as a forwarder, and the mail originates from a server with Sender Policy Framework (SPF) enabled. The ITP for this package is #757720. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/postsrsd Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/postsrsd/postsrsd_1.1-1.dsc Changes since the last upload: * Initial release (Closes: #757720) Regards, Oxan van Leeuwen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#870818: RM: python-gearman -- ROM; dead upstream, low popcon
Package: ftp.debian.org Severity: normal Upstream has given up on this package and no new maintainer has stepped up in the last four years, so with a low popcon of 19 it seems best to drop this package from Debian.
Bug#849307: New upstream version available
Hi, On 25-12-16 07:46, Alexander Gerasiov wrote: > Upstream version 1.4 is available for a year. Please consider packaging > it. I've already packaged 1.4 in the git repository, but I've had some trouble getting it in the archive. Would you be willing to sponsor it? Kind regards, Oxan van Leeuwen
Bug#849307: New upstream version available
Hi, On 27-12-16 21:39, Alexander Gerasiov wrote: > Not a problem. Please upload it on mentors, or gimmi the link to git > repo with signed tag. I've pushed a signed tag debian/1.4-1 to the collab-maint repository: ssh://anonscm.debian.org/git/collab-maint/postsrsd.git Thanks!
Bug#801619: postsrsd: [INTL:ru] Russian debconf templates translation
Hi, Getting the update in the archive has been stalled for a while, but we're currently working on that; see #849307, which will hopefully be just in time for stretch.
Bug#1017361: ITA: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix
Hi, On 16-07-2023 22:35, Timo Röhling wrote: I think this was not forwarded to Oxan, so I'm resending it to You're right, thanks for the forward. On Sun, 11 Jun 2023 23:09:11 +0530 Abhijith PA wrote: Hello, I would like to adopt this package. I maintain a mailing list server where I am already using postsrsd. That's great! The packaging is currently hosted in the Debian group on Salsa, so as a DD you should already have access to it. I'm not aware of anything that needs to be done for the handover, so feel free to take over that repository (or move it elsewhere, if you prefer), and to upload a new version with you listed as Maintainer. If you've any questions about the current packaging, don't hesitate to reach out! Cheers, Oxan
Bug#571214: rtorrent: Using too much memory when running long (memory leak?)
Package: rtorrent Version: 0.7.9-2.2 Severity: normal rTorrent is using too much (more then a gigabyte) memory when it's running long. Ater 4 weeks, it's using more then 2 gigabytes of memory. In 4 days it is using 400 megabytes of memory. After restarting rTorrent, it uses only ~35MB. I've 18 torrents in it, but memory usage is also quite high when there are only 2 or 3 torrents in it. I control it using the XML-RPC interface. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rtorrent depends on: ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libcurl37.18.2-8lenny3 Multi-protocol file transfer libra ii libgcc1 1:4.3.2-1.1 GCC support library ii libncursesw55.7+20081213-1 shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libssl0.9.8 0.9.8g-15+lenny6 SSL shared libraries ii libstdc++6 4.3.2-1.1The GNU Standard C++ Library v3 ii libtorrent100.11.9-1.1 a C++ BitTorrent library ii libxmlrpc-c31.06.27-1A lightweight RPC library based on rtorrent recommends no packages. rtorrent 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#610654: ITP: python-gearman -- Python interface to the Gearman library
Package: wnpp Severity: wishlist Owner: Oxan van Leeuwen I want to package the python-gearman library, as it's a lot easier to use then python-gearman.libgearman and it has better documentation. * Package name: python-gearman Version : 2.0.2 Upstream Author : Matthew Tai * URL : http://github.com/mtai/python-gearman/ * License : Apache 2.0 Programming Lang: Python Description : Python interface to the Gearman library Gearman is a system to farm out work to other machines, dispatching function calls to machines that are better suited to do work, to do work in parallel, to load balance lots of functions calls, or to call functions between languages. This package contains a Python interface to the library, allowing Python scripts to send and receive Gearman jobs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: Bug#620496
# wheezy not affected as this bug blocks python-gearman from migrating tag 620469 + sid thanks I see three solutions for this problem: (A) Add Conflicts against each other. This prevents users from installing the packages together, which normally isn't needed as they provide the same functionality. It isn't optimal however, as in the future it might be possible that there are programs that depend on one of these libraries and that need to be co-installable. (B) Rename the python module in one of the packages. This would be the best solution, but it is a backwards-incompatible break and every reverse-dependency needs to be patched to use the renamed API. (C) Drop the __init__.py from one of the packages. The two modules are actually co-installable and usable, as they don't use the same namespace: python-gearman.libgearman uses gearman.libgearman, while python-gearman uses just gearman. The __init__.py from python-gearman can't be dropped as it imports the primary API into the gearman namespace. python-gearman.libgearman seems to be functional without the __init__.py, but I'm not 100% sure. Also having two packages providing the same Python package is confusing. I think the best we can do at this point is A, given the side-effects of the other options. I'll implement that in python-gearman (which should be enough) if nobody objects. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469:
On 04/03/2011 06:53 PM, Clint Byrum wrote: > > Oxan, thanks for the quick response. Thanks for your response! > I opened this issue upstream: > > https://github.com/Yelp/python-gearman/issues/#issue/11 > > I think the way to go is to drop __init__.py from > python-gearman.libgearman, and make it depend on python-gearman, since > it is a sub-module of the gearman namespace. That does make sense. > > I haven't been able to make gearman.libgearman work properly without > the __path__ changes, though I'm not entirely sure why as I'm sort of a > python extension novice. If anyone *can* make that work, then we don't > even need the change suggested above. I did some more testing and got it working without __init__.py. The __init__.py is only needed during compilation/installation and not during execution. This does make sense, as it adds a directory to the path that is already searched in. Not installing it in debian/rules should be enough, can you confirm that? I also think that we can demote the dependency to a Recommends, as they do work without each other. > >> I think the best we can do at this point is A, given the side-effects of the >> other options. I'll implement that in python-gearman (which should be enough) >> if nobody objects. > > Yeah I was thinking of doing the same in the python-gearman.libgearman, > but I think since its temporary we can just leave it in python-gearman > until the necessary changes can be made for python-gearman.libgearman > to depend on python-gearman. > > With the Conflicts on one side, I think we can close this bug, and open > a new wishlist bug to implement the dependency relationship. Given your response and the results above I'm hoping that we can fix this directly in one upload, without having to upload a temporary fix first :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571214: Fix
tags 571214 patch
thanks
There's a bugfix available in the upstream issue tracker
(http://libtorrent.rakshasa.no/ticket/1324). I've ported the patch to
the 0.7.9 version of Lenny and I'm using it for some days now with
stable memory usage. I've attached the patch.
Version in unstable/testing isn't affected (upstream patched in 0.8.2)
diff -Naur rtorrent-0.7.9.orig/src/rpc/xmlrpc.cc rtorrent-0.7.9/src/rpc/xmlrpc.cc
--- rtorrent-0.7.9.orig/src/rpc/xmlrpc.cc 2010-04-12 17:01:41.087611568 +0200
+++ rtorrent-0.7.9/src/rpc/xmlrpc.cc2010-04-12 17:32:19.287862029 +0200
@@ -351,7 +351,11 @@
xmlrpc_value* result = xmlrpc_array_new(env);
for (torrent::Object::list_type::const_iterator itr = object.as_list().begin(), last = object.as_list().end(); itr != last; itr++)
- xmlrpc_array_append_item(env, result, object_to_xmlrpc(env, *itr));
+{
+ xmlrpc_value* item = object_to_xmlrpc(env, *itr);
+ xmlrpc_array_append_item(env, result, item);
+ xmlrpc_DECREF(item);
+}
return result;
}
@@ -361,7 +365,11 @@
xmlrpc_value* result = xmlrpc_struct_new(env);
for (torrent::Object::map_type::const_iterator itr = object.as_map().begin(), last = object.as_map().end(); itr != last; itr++)
- xmlrpc_struct_set_value(env, result, itr->first.c_str(), object_to_xmlrpc(env, itr->second));
+{
+ xmlrpc_value* item = object_to_xmlrpc(env, itr->second);
+ xmlrpc_struct_set_value(env, result, itr->first.c_str(), item);
+ xmlrpc_DECREF(item);
+}
return result;
}
Bug#620469: Bug#620496
Hi Clint,
On 03-04-11 18:53, Clint Byrum wrote:
> I think the way to go is to drop __init__.py from
> python-gearman.libgearman, and make it depend on python-gearman, since
> it is a sub-module of the gearman namespace.
>
> I haven't been able to make gearman.libgearman work properly without
> the __path__ changes, though I'm not entirely sure why as I'm sort of a
> python extension novice. If anyone *can* make that work, then we don't
> even need the change suggested above.
I did some more testing and gearman.libgearman actually works without the
__path__ changes, when it's installed in one of the standard Debian locations.
During compilation it's not, so it needs the __path__ changes then.
The problem with implementating that is python-gearman uses dh_python2 while
gearman.libgearman uses python-support, which results in the bytecode files
(.pyc) being installed into different directories. When I converted
gearman.libgearman to dh_python2 both packages work fine. Do you agree with this
solution?
I've attached the patch that I used for testing gearman.libgearman using
dh_python. You'll probably need to make some more changes, but maybe you can use
this.
diff -Nru gearman-interface-0.13.2/debian/changelog gearman-interface-0.13.2/debian/changelog
--- gearman-interface-0.13.2/debian/changelog 2010-09-29 04:41:31.0 +0200
+++ gearman-interface-0.13.2/debian/changelog 2011-04-18 20:21:59.0 +0200
@@ -1,3 +1,9 @@
+gearman-interface (0.13.2-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+
+ -- Oxan van Leeuwen Mon, 18 Apr 2011 20:21:56 +0200
+
gearman-interface (0.13.2-3) unstable; urgency=low
* Fixing Vcs-Bzr to point at debian packaging (Closes: #596794)
diff -Nru gearman-interface-0.13.2/debian/control gearman-interface-0.13.2/debian/control
--- gearman-interface-0.13.2/debian/control 2010-09-29 04:40:46.0 +0200
+++ gearman-interface-0.13.2/debian/control 2011-04-18 20:32:19.0 +0200
@@ -1,7 +1,7 @@
Source: gearman-interface
Priority: extra
Maintainer: Clint Byrum
-Build-Depends: python-setuptools (>= 0.6b3), python, python3 (>= 3.1.2-6~), python3-all-dev (>= 3.1.2-10), python-all-dev, debhelper (>= 7.0.50~), python-support (>= 0.8.4), libgearman-dev (>= 0.13), swig, uuid-dev
+Build-Depends: python-setuptools (>= 0.6b3), python3-all-dev (>= 3.1.2-10), python-all-dev (>= 2.6.6-3~), debhelper (>= 7.0.50~), libgearman-dev (>= 0.13), swig, uuid-dev
Standards-Version: 3.9.1
Section: python
Homepage: https://launchpad.net/gearman-interface
@@ -9,7 +9,7 @@
Package: python-gearman.libgearman
Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, python-gearman
Provides: ${python:Provides}
Description: Python wrapper of libgearman
This package contains a Python wrapper of libgearman.
diff -Nru gearman-interface-0.13.2/debian/rules gearman-interface-0.13.2/debian/rules
--- gearman-interface-0.13.2/debian/rules 2010-09-29 04:40:46.0 +0200
+++ gearman-interface-0.13.2/debian/rules 2011-04-18 20:31:33.0 +0200
@@ -14,7 +14,7 @@
PY3VERS=$(shell py3versions -vs)
%:
- dh $@
+ dh --with python2,python3 $@
override_dh_build:: build-python-all build-python3-all
@@ -38,7 +38,8 @@
override_dh_install:: build $(PYVERS:%=install-python2%) $(PY3VERS:%=install-python3%)
install-python2%:
- cd python && python$* setup.py install --root $(CURDIR)/debian/python-gearman.libgearman
+ cd python && python$* setup.py install --install-layout=deb --root $(CURDIR)/debian/python-gearman.libgearman
+ find $(CURDIR)/debian/python-gearman.libgearman -name '__init__.py' -delete
install-python3%:
cd python3 && python$* setup.py install --install-layout=deb --root $(CURDIR)/debian/python3-gearman.libgearman
@@ -52,10 +53,6 @@
rm -f python/libgearman.c
rm -f python3/libgearman.c
-override_dh_pysupport::
- dh_pysupport
- dh_python3
-
override_dh_clean::
dh_clean
rm -f build-python*
@@ -66,5 +63,7 @@
rm -rf python/build/
rm -rf python/python_libgearman.egg-info/
rm -rf python3/build/
+ rm -rf python3/gearman/_libgearman*so
+ rm -rf python3/gearman/__pycache__
[ ! -f python/libgearman.c.orig ] || mv -f python/libgearman.c.orig python/libgearman.c
[ ! -f python3/libgearman.c.orig ] || mv -f python3/libgearman.c.orig python3/libgearman.c
Bug#620469: Bug#620496
On 19-04-11 05:14, Clint Byrum wrote: > > Thats great news, and yes I agree with the solution completely. I > had actually already begun porting the package to dh_python2 in the > bzr branch: > > https://code.launchpad.net/~clint-fewbar/gearman-interface/debian-packaging Great! > I've added some of your tweaks to the branch. However, its not clear to > me the reason for these two additions to debian/rules: > > rm -rf python3/build/ > + rm -rf python3/gearman/_libgearman*so > + rm -rf python3/gearman/__pycache__ > [ ! -f python/libgearman.c.orig ] || mv -f python/libgearman.c.orig > python/libgearman.c > > I was hoping you could explain those. Once I can explain what that is > in debian/changelog, I'll get it uploaded. I needed that change to be able to build the package twice in the same directory. Ultimately the clean target should return to the state after unpacking the tarball, so all created files should be deleted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#977782: buster-pu: package postsrsd/1.5-2
Hi, On 30-01-2021 21:27, Salvatore Bonaccorso wrote: I noticed that today there was an upload to security-master for it. Given our previous discussion, was this an oversight? I just have rejected the package, could you please upload it for the upcoming point release instead to ftp-master? Ah, that wasn't the intention. @Tomasz: it seems you accidentally uploaded to the security archive tonight. The last commit in the buster branch on Salsa should be for an upload the regular archive, maybe you forgot to pull? In any case, can you please upload that one? Thanks! Regards, Oxan
Bug#990439: postsrsd: CVE-2021-35525
Hi, On 29-06-2021 07:41, Salvatore Bonaccorso wrote: The following vulnerability was published for postsrsd. CVE-2021-35525[0]: Thanks for the report, I've unfortunately missed this release. Do you want to fix this through a DSA, or should I prepare&upload a stable (and bullseye) update? Kind regards, Oxan van Leeuwen
Bug#991119: unblock: postsrsd/1.10-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package postsrsd
[ Reason ]
Security fix for CVE-2021-35525.
[ Impact ]
Package is vulnerable to a potential DoS attack.
[ Tests ]
Tests from upstream backported, testsuite from upstream passes, manually tested
functionality.
[ Risks ]
Fix is a one-to-one backport from upstream, modulus formatting changes.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
N/A
unblock postsrsd/1.10-2
diff -Nru postsrsd-1.10/debian/changelog postsrsd-1.10/debian/changelog
--- postsrsd-1.10/debian/changelog 2020-12-02 22:36:36.0 +0100
+++ postsrsd-1.10/debian/changelog 2021-07-14 21:21:11.0 +0200
@@ -1,4 +1,12 @@
-postsrsd (1.10-1) UNRELEASED; urgency=medium
+postsrsd (1.10-2) UNRELEASED; urgency=medium
+
+ * Fix CVE-2021-35525: potential DoS when Postfix sends certain long data
+fields such as multiple concatenated email addresses. Fix backported from
+upstream commit 077be98d8c8. (Closes: #990439)
+
+ -- Oxan van Leeuwen Wed, 14 Jul 2021 21:21:11 +0200
+
+postsrsd (1.10-1) unstable; urgency=medium
* New upstream release (Closes: #975633)
* Drop patches integrated upstream
diff -Nru
postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
---
postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
1970-01-01 01:00:00.0 +0100
+++
postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
2021-07-14 21:21:11.0 +0200
@@ -0,0 +1,211 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?=
+Date: Sun, 21 Mar 2021 15:27:55 +0100
+Subject: SECURITY: Fix DoS on overly long input from Postfix
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Thanks to Mateusz Jończyk who reported this issue and gave valuable
+feedback for its resolution.
+
+PostSRSd would hang on an overly long GET request, because the
+fread()/fwrite() logic in the subprocess would get confused by the
+remaining input line in its buffer.
+
+Theoretically, this error should never occur, as Postfix is supposed to
+send valid email addresses only, which are shorter than the buffer, even
+assuming every single character is percent-encoded. However, Postfix
+sometimes does seem to send malformed request with multiple concatenated
+email addresses. I'm not sure if there's a reliable way to trigger this
+condition by an external attacker, but it is a security bug in PostSRSd
+nevertheless.
+
+Fixes CVE-2021-35525.
+
+Origin:
https://github.com/roehling/postsrsd/commit/077be98d8c8a9847e4ae0c7dc09e7474cbe27db2
+Forwarded: not-needed
+Last-Update: 2021-07-14
+---
+ postsrsd.c | 52 ++---
+ run_postsrsd_tests.bats | 40 +
+ 2 files changed, 68 insertions(+), 24 deletions(-)
+
+diff --git a/postsrsd.c b/postsrsd.c
+index c009d8f..5ebf7f6 100644
+--- a/postsrsd.c
b/postsrsd.c
+@@ -518,9 +518,9 @@ int main (int argc, char **argv)
+ fds[sc].events = POLLIN;
+ }
+ while(TRUE) {
+ int conn;
+-FILE *fp;
++FILE *fp_read, *fp_write;
+ char linebuf[1024], *line;
+ char keybuf[1024], *key;
+
+ if (poll(fds, socket_count, 1000) < 0) {
+@@ -540,41 +540,53 @@ int main (int argc, char **argv)
+ int i;
+ // close listen sockets so that we don't stop the main daemon
process from restarting
+ for (i = 0; i < socket_count; ++i) close (sockets[i]);
+
+- fp = fdopen(conn, "r+");
+- if (fp == NULL) exit(EXIT_FAILURE);
+- fds[0].fd = conn;
+- fds[0].events = POLLIN;
+- if (poll(fds, 1, timeout * 1000) <= 0) return EXIT_FAILURE;
+- line = fgets(linebuf, sizeof(linebuf), fp);
+- while (line) {
+-fseek (fp, 0, SEEK_CUR); /* Workaround for Solaris */
++ /* create separate input/output streams */
++ fp_read = fdopen(conn, "r");
++ if (fp_read == NULL)
++return EXIT_FAILURE;
++ fp_write = fdopen(dup(conn), "w");
++ if (fp_write == NULL) return EXIT_FAILURE;
++ errno = 0;
++ alarm(timeout);
++ if (errno != 0)
++ return EXIT_FAILURE;
++ while ((line = fgets(linebuf, sizeof(linebuf), fp_read))) {
+ char* token;
++alarm(0);
++if (strlen(line) >= sizeof(linebuf) - 1) {
++ fprintf(fp_write, "500 Invalid request\n");
++ fflush(fp_write);
++ return EXIT_FAILURE;
++}
Bug#991120: buster-pu: package postsrsd/1.5-2+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Security fix for CVE-2021-35525.
[ Impact ]
Package is vulnerable to a potential DoS attack.
[ Tests ]
The version in buster didn't have any integration tests nor autopkgtests, so I
didn't backport those. However, I did run the test suite from the package in
testing against the buster version and it passes (except some tests for new
features that aren't present in buster). I've also manually verified that the
package still works.
[ Risks ]
Fix is a one-to-one backport from upstream, modulus formatting changes.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[ ] the issue is verified as fixed in unstable
As of writing the fix isn't in unstable yet, since I don't have upload rights.
I've asked my sponsor to upload the fix for both stable and unstable at the
same time -- it seemed unnecessary to add another roundtrip delay, as it's
exactly the same fix.
[ Changes ]
Add patch with security fix for CVE-2021-35525.
[ Other info ]
N/A.
diff -Nru postsrsd-1.5/debian/changelog postsrsd-1.5/debian/changelog
--- postsrsd-1.5/debian/changelog 2020-12-19 01:36:37.0 +0100
+++ postsrsd-1.5/debian/changelog 2021-07-14 21:37:55.0 +0200
@@ -1,3 +1,11 @@
+postsrsd (1.5-2+deb10u2) UNRELEASED; urgency=medium
+
+ * Fix CVE-2021-35525: potential DoS when Postfix sends certain long data
+fields such as multiple concatenated email addresses. Fix backported from
+upstream commit 077be98d8c8. (Closes: #990439)
+
+ -- Oxan van Leeuwen Wed, 14 Jul 2021 21:37:55 +0200
+
postsrsd (1.5-2+deb10u1) buster; urgency=medium
* CVE-2020-35573: Ensure timestamp tags aren't too long before trying to
diff -Nru
postsrsd-1.5/debian/patches/0005-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
postsrsd-1.5/debian/patches/0005-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
---
postsrsd-1.5/debian/patches/0005-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
1970-01-01 01:00:00.0 +0100
+++
postsrsd-1.5/debian/patches/0005-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
2021-07-14 21:37:55.0 +0200
@@ -0,0 +1,120 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?=
+Date: Sun, 21 Mar 2021 15:27:55 +0100
+Subject: SECURITY: Fix DoS on overly long input from Postfix
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Thanks to Mateusz Jończyk who reported this issue and gave valuable
+feedback for its resolution.
+
+PostSRSd would hang on an overly long GET request, because the
+fread()/fwrite() logic in the subprocess would get confused by the
+remaining input line in its buffer.
+
+Theoretically, this error should never occur, as Postfix is supposed to
+send valid email addresses only, which are shorter than the buffer, even
+assuming every single character is percent-encoded. However, Postfix
+sometimes does seem to send malformed request with multiple concatenated
+email addresses. I'm not sure if there's a reliable way to trigger this
+condition by an external attacker, but it is a security bug in PostSRSd
+nevertheless.
+
+Fixes CVE-2021-35525.
+
+Tests not backported, as v1.5 did not have them yet.
+
+Origin:
https://github.com/roehling/postsrsd/commit/077be98d8c8a9847e4ae0c7dc09e7474cbe27db2
+Forwarded: not-needed
+Last-Update: 2021-07-14
+---
+ postsrsd.c | 54 +++---
+ 1 file changed, 35 insertions(+), 19 deletions(-)
+
+diff --git a/postsrsd.c b/postsrsd.c
+index a6fd118..64e1ad0 100644
+--- a/postsrsd.c
b/postsrsd.c
+@@ -501,9 +501,9 @@ int main (int argc, char **argv)
+ fds[sc].events = POLLIN;
+ }
+ while(TRUE) {
+ int conn;
+-FILE *fp;
++FILE *fp_read, *fp_write;
+ char linebuf[1024], *line;
+ char keybuf[1024], *key;
+
+ if (poll(fds, socket_count, 1000) < 0) {
+@@ -523,37 +523,53 @@ int main (int argc, char **argv)
+ int i;
+ // close listen sockets so that we don't stop the main daemon
process from restarting
+ for (i = 0; i < socket_count; ++i) close (sockets[i]);
+
+- fp = fdopen(conn, "r+");
+- if (fp == NULL) exit(EXIT_FAILURE);
+- fds[0].fd = conn;
+- fds[0].events = POLLIN;
+- if (poll(fds, 1, timeout * 1000) <= 0) return EXIT_FAILURE;
+- line = fgets(linebuf, sizeof(linebuf), fp);
+- while (line) {
+-fseek (fp, 0, SEEK_CUR); /* Workaround for Solaris */
++ /* create separate input/output streams */
++ fp_read = fdopen(conn, "r");
++ if (fp_read == NULL)
++return EXIT_FAILURE;
++ fp_write = f
Bug#990439: postsrsd: CVE-2021-35525
Hi Salvatore, Sorry for the delay in getting back to you. On 05-07-2021 21:47, Salvatore Bonaccorso wrote: I think we can do the following action plan, let me know if you agree: The release btw is not yet fully missed, so I would suggest: upload a very targetted fix aimed for bullseye to unstable, ask the release team for unblocking and aging the package, so we make sure the fix lands in bullseye before the release. For buster, it looks to me that the issue is low severity enough that we can have an update via an upcoming point release. Sounds like a plan. I've prepared the updated packages with a backport from upstream, asked my sponsor to upload them and filed unblock&tracking bugs (#991119 for bullseye and #991120 for buster). Thanks! Kind regards, Oxan
Bug#991119: postsrsd security update
Hi, On 14-07-2021 22:05, Oxan van Leeuwen wrote: Hi Tomasz, Another (low-severity) security update for postsrsd is required (see #994039). For bullseye, I've prepared a package in the master branch on Salsa. Can you upload that to unstable? Given the imminent freeze I've filed an unblock request (#991119). Do you by any chance happen to have time to upload this shortly? The window to get the update into bullseye is closing. Thanks! Regards, Oxan
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Hi, On 14-12-2020 22:43, Sean Whitton wrote: On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote: 'not fail' here means that the script terminates with return code 0. This is how I would read it too. Would a patch to add "(i.e. exit with return code 0)" resolve the original submitter's concerns? Though I'm still not convinced it's a sensible requirement, that clarification would resolve my main concern (i.e. having to fix init scripts to work with an absent defaults file). By the way, there's an identical requirement a few paragraphs before, so it might be good to insert the same clarification there as well. Cheers, Oxan
Bug#977782: buster-pu: package postsrsd/1.5-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Upstream recently discovered a potential remote denial-of-service attack in
postsrsd (CVE-2020-35573) [1]. Fortunately, this issue is currently not
exploitable in Debian due to gcc optimizing the problematic loop away. Thus,
the
security has decided not to issue a DSA [2], but instead suggested to fix it
through a stable update.
This issue is already fixed in postsrsd/1.10-1 in unstable and testing.
I've prepared a backport of the one-line fix to stable, and attached the source
debdiff. I've verified that this doesn't break anything and the package still
works properly.
Cheers,
Oxan
[1]
https://github.com/roehling/postsrsd/commit/4733fb11f6bec6524bb8518c5e1a699288c26bac
[2] https://security-tracker.debian.org/tracker/CVE-2020-35573
diff -Nru postsrsd-1.5/debian/changelog postsrsd-1.5/debian/changelog
--- postsrsd-1.5/debian/changelog 2019-02-23 14:27:44.0 +0100
+++ postsrsd-1.5/debian/changelog 2020-12-19 01:36:37.0 +0100
@@ -1,3 +1,11 @@
+postsrsd (1.5-2+deb10u1) buster; urgency=medium
+
+ * CVE-2020-35573: Ensure timestamp tags aren't too long before trying to
+decode them, to protect against a potential denial-of-service attack
+(backported from upstream commit 4733fb1).
+
+ -- Oxan van Leeuwen Sat, 19 Dec 2020 01:36:37 +0100
+
postsrsd (1.5-2) unstable; urgency=medium
* Increase hashlength for unit tests (cherry-picked from upstream db9ed58)
diff -Nru
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
---
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
1970-01-01 01:00:00.0 +0100
+++
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
2020-12-19 01:36:37.0 +0100
@@ -0,0 +1,29 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?=
+Date: Sat, 12 Dec 2020 10:42:28 +0100
+Subject: SECURITY: Fix potential denial of service attack against PostSRSd
+
+I discovered that PostSRSd could be tricked into consuming a lot of CPU
+time with an SRS address that has an excessively long time stamp tag,
+e.g.
+
+SRS0==T=0...@example.com
+
+(cherry picked from commit 4733fb11f6bec6524bb8518c5e1a699288c26bac)
+
+Fixes CVE-2020-35573.
+---
+ srs2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/srs2.c b/srs2.c
+index b07a664..6a2eebb 100644
+--- a/srs2.c
b/srs2.c
+@@ -230,6 +230,7 @@ srs_timestamp_check(srs_t *srs, const char *stamp)
+ time_t now;
+ time_t then;
+
++ if (strlen(stamp) != 2) return SRS_ETIMESTAMPOUTOFDATE;
+ /* We had better go around this loop exactly twice! */
+ then = 0;
+ for (sp = stamp; *sp; sp++) {
diff -Nru postsrsd-1.5/debian/patches/series postsrsd-1.5/debian/patches/series
--- postsrsd-1.5/debian/patches/series 2019-02-23 14:27:44.0 +0100
+++ postsrsd-1.5/debian/patches/series 2020-12-19 01:36:37.0 +0100
@@ -1,3 +1,4 @@
0001-Adapt-init-scripts-for-Debian-practices.patch
0002-Increase-hash-length-for-unit-tests.patch
0003-Hook-up-endianness-sizeof-long-detection-code-in-SHA.patch
+0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Source: debian-policy Version: 4.5.1.0 Severity: normal Currently Policy requires that init.d scripts, and only init.d scripts, don't fail if the corresponding /etc/default is removed (section 9.3.2, second-to-last paragraph). Personally I interpret "not fail" as "succeed to function", i.e. it has to actually start the daemon. I don't think that's a particularly sensible requirement. Policy doesn't require programs to function if their native configuration files are removed, so why should default files be any different? Furthermore, this requirement doesn't exist for systemd unit files, and there are in fact unit files in the archive that fail if the default file is removed. Also, to me removing configuration files seems like a "don't break your system" kind of action. If the system administrator does it, they get to keep the pieces and are reponsible for the fallout. The other option is that "not fail" means that the init script is allowed to not start the daemon, but it shouldn't cause any further breakage. That seems like a sensible requirement to me, but the wording could use some clarification in this case.
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
On 30-11-2020 19:28, Ansgar wrote:> I think we should keep the
requirement. Legacy init.d scripts are still
handled as conffiles and kept around even if the package is removed
(unlike systemd unit files). Thus init scripts are still run[1] and
should behave sensibly.
For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors. So the init script still needs to
do something sensible (probably just do nothing).
I don't think this requirement is necessary to handle that case. There
is already a separate, explicit requirement for init scripts to not fail
for removed-but-not-purged packages a few paragraphs before, and Policy
explicitly states init scripts should use ``test -f daemon || exit 0''.
[1]: For packages shipping native .service files for systemd, this
might mean that for removed-but-not-purged packages suddenly the
sysvinit script gets started? After all there is no longer a .service
files to prefer over the sysvinit script...
At least for packages using debhelper that's not the case, as
dh_installsystemd (and its predecessor dh_systemd_enable) mask the
service on package removal.
Cheers,
Oxan
Bug#895308: opendkim: verification of missing KeyTable entires gives incomprehensible error
Package: opendkim Version: 2.11.0~alpha-10+deb9u1 Severity: normal On startup, OpenDKIM verifies if the SigningTable doesn't reference any missing KeyTable entries. However, if the KeyTable is put in an SQL database, and the key is missing for a given domain, this gives the following error on startup, and refuses to startup: opendkim: /etc/opendkim.conf: could not find valid key record "" in KeyTable This error is quite incomprehensible, and certainly doesn't point to the fact that startup fails due to invalid data in the database. Please change the error message to something like this: opendkim: failed to find valid key record "" in KeyTable for domain "example.com" opendkim: refusing to start due to invalid data in database Thanks in advance! -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages opendkim depends on: ii adduser 3.115 ii dns-root-data2017072601~deb9u1 ii init-system-helpers 1.48 ii libbsd0 0.8.3-1 ii libc62.24-11+deb9u3 ii libdb5.3 5.3.28-12+deb9u1 ii libldap-2.4-22.4.44+dfsg-5+deb9u1 ii liblua5.1-0 5.1.5-8.1+b2 ii libmemcached11 1.0.18-4.1 ii libmemcachedutil21.0.18-4.1 ii libmilter1.0.1 8.15.2-8 ii libopendbx1 1.4.6-11+b1 ii libopendkim112.11.0~alpha-10+deb9u1 ii librbl1 2.11.0~alpha-10+deb9u1 ii libssl1.11.1.0f-3+deb9u2 ii libunbound2 1.6.0-3+deb9u1 ii libvbr2 2.11.0~alpha-10+deb9u1 ii lsb-base 9.20161125 opendkim recommends no packages. Versions of packages opendkim suggests: ii opendkim-tools 2.11.0~alpha-10+deb9u1 ii unbound 1.6.0-3+deb9u1 -- Configuration Files: /etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: '/etc/dkimkeys/README.PrivateKeys' /etc/opendkim.conf [Errno 13] Permission denied: '/etc/opendkim.conf' -- no debconf information
