Bug#703639: kill -HUP $(cat /var/run/syslog-ng.pid) can cause duplicate logging issues
Control: found -1 3.3.5-4
Control: found -1 3.3.6-2
Cye Stoner cye.sto...@echostar.com writes:
When syslog-ng is sent a SIGHUP with the previous configurationin place,
the following errors are thrown to /var/log/messages(in duplicate)
Error in configuration, unresolved source reference;
source='s_sys_does_not_exist'
Error in configuration, unresolved source reference;
source='s_sys_does_not_exist'
Error initializing new configuration, reverting to old config;
Error initializing new configuration, reverting to old config;
Thanks for the report, I reproduced it with the latest git master of
syslog-ng 3.3 too, so the problem applies to the latest 3.3 as well.
While I have not found a fix yet, I did notice two things:
* Fixing the configuration and reloading gets things back in order, no
matter how many times messages were duplicated before.
* Running in foreground with internal logs printed to stderr, the
problem does not appear.
I'll try to narrow this down, and provide a fix ASAP.
I'm using the following configuration to test with:
@version: 3.3
source s_internal {
internal();
};
destination d_all {
file(/tmp/all-messages.log);
};
log {
source(s_internal);
#source(s_does_not_exist);
destination(d_all);
};
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690067: what is to be done?
Csillag Tamas csta...@digitus.itk.ppke.hu writes: The patch seems fine to me. Is something missing? Is something still needs to be done? I still need to prep the other things. I most likely will have time this coming friday. For the record, pretty much everything that needs to be fixed, is fixed in my tree[1], on either on my packaging/debian/3.3 or packaging/debian/3.4 branches - all the work left now is to diff the packaging against those trees, and pick the relevant fixes for this bug, and others. [1]: https://github.com/algernon/syslog-ng/ -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695639: /usr/sbin/approx-gc Not_found error
Control: reassign -1 approx 4.5-1+squeeze1 Brian May br...@microcomaustralia.com.au writes: Package: aaprox s/aa/ap/; -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695801: debian/compat -- allow to specify compatibility range with debhelper taking the largest specified
Yaroslav Halchenko deb...@onerussian.com writes: Package: debhelper Version: 9.20120608 Severity: wishlist At the moment debian/compat allows to specify a single level, which debhelper takes as the compatibility level and enables(/disables?) some features accordingly. But often dh-based packaging itself is simple/generic enough to work fine even with previous releases of debhelper still in production in Debian stable or its derivatives (e.g. ubuntu 10.04 LTS carries 7.4.15ubuntu1). This hardcoded single compat leve unnecessarily complicates backporting requiring to patch debian/compat and debian/control for versioned build-depends on debhelper. Sorry, but this is a terrible idea. This introduces unrelability, as if you'd build a 17-19 package on a system that is not up to date, and has 18, you might get a different (and non-conforming) package, than if you just build-depended on = 19~. It is easier to backport a recent debhelper to Lucid, really. -- |8], random passer by -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696199: closed by Ivo De Decker ivo.dedec...@ugent.be (Re: Build-Depends autoconf 2.68)
Control: severity -1 normal From: Ivo De Decker ivo.dedec...@ugent.be To: 696199-d...@bugs.debian.org Date: Tue, 18 Dec 2012 22:40:31 +0100 Subject: Re: Build-Depends autoconf 2.68 Hi, On Tue, Dec 18, 2012 at 01:08:11AM +0100, Mathieu Malaterre wrote: dh-exec fails to build on debian/stable with: dh-exec is not available in stable (squeeze), so there is no reason to expect it to build in squeeze. First of all, please don't close bugs opened against my packages, unless you opened them yourself, or asked me first. I happen to agree with the reporter, this *is* a bug, although not a serious one. Your package as-is cannot be backported. If there is an implicit dependency, it is required to be versioned explicitly in d/control (there are older versions of autoconf in the archive). Not in the suites dh-exec was prepared for. Ancient versioned dependencies are not much more than noise. However, making backporting easier is a reasonable wish, so I'll add the explicit autoconf = 2.68 dependency. (That, or fix my configure to work on squeeze, if that's not too hard) If you do not want to upload, I can NMU your package. I will upload a backportable version, targetting unstable. I don't believe this issue warrants a freeze exception however, so I'm not going to pursue that. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696679: unblock: libmikmod/3.1.12-5
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package libmikmod
The current package in testing suffers from a serious issue (not
reported though, only observed while preparing -5): in certain cases,
applications that rely on libmikmod will not see any driver but the
nosound one, effectively rendering them useless. As it turns out,
enabling the fortify hardening flags breaks libmikmod's module loading,
so -5 turns that off, as a temporary measure until I figure out what the
underlying problem really is.
It also rearranges the order of sound drivers, so nosound is preferred
over saving to music.raw, as to not pollute the filesystem with huge
music files. With this change in place, the pulseaudio-esound-compat |
oss-compat recommendation could be lowered to suggests.
All of these are fairly trivial changes, but nevertheless, would make
the libmikmod version in wheezy much more useful, so I'd like to request
an unblock for it.
A debdiff between -4.1 (currently in wheezy) and -5 (in unstable) has
been attached. Some parts of the diff have been omitted, as they're just
noise (timestamp changes under debian/patches, and other noops like
that).
Thanks in advance!
unblock libmikmod/3.1.12-5
--
|8]
diff -Nru libmikmod-3.1.12/debian/changelog libmikmod-3.1.12/debian/changelog
--- libmikmod-3.1.12/debian/changelog 2012-10-19 23:06:31.0 +0200
+++ libmikmod-3.1.12/debian/changelog 2012-12-21 16:41:16.0 +0100
@@ -1,13 +1,26 @@
+libmikmod (3.1.12-5) unstable; urgency=low
+
+ * Acknowledge the NMU, thanks Simon!
+ * Make the nosound driver have higher priority than the disk
+writers. (Closes: #690943)
+ * Demote the pulseaudio-esound-compat | oss-compat recommendation to
+Suggests, now that the fallback is not the disk writer.
+(Closes: #696013)
+ * Build with hardening=-fortify, as enabling fortification breaks the
+driver loading.
+
+ -- Gergely Nagy alger...@madhouse-project.org Fri, 21 Dec 2012 16:41:15 +0100
+
libmikmod (3.1.12-4.1) unstable; urgency=low
- * Non-maintainer upload (acknowledged by maintainer).
+ * Non-maintainer upload.
* Apply patches from Hans de Goede and Pantelis Koukousoulas to enable
the ESD driver, so we can interoperate with PulseAudio (Closes: #385844)
* Recommend pulseaudio-esound-compat | oss-compat because if we don't have
one of those, the fallback path is to write output to ./music.raw, which
is unlikely to be what you want!
- -- Simon McVittie s...@debian.org Fri, 19 Oct 2012 22:05:18 +0100
+ -- Simon McVittie s...@debian.org Fri, 19 Oct 2012 09:12:08 +0100
libmikmod (3.1.12-4) unstable; urgency=low
diff -Nru libmikmod-3.1.12/debian/control libmikmod-3.1.12/debian/control
--- libmikmod-3.1.12/debian/control 2012-10-19 23:04:43.0 +0200
+++ libmikmod-3.1.12/debian/control 2012-12-21 16:12:03.0 +0100
@@ -32,7 +32,7 @@
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
-Recommends: pulseaudio-esound-compat | oss-compat
+Suggests: pulseaudio-esound-compat | oss-compat
Description: Portable sound library
This library is capable of playing samples as well as module
files and was originally written by Jean-Paul Mikkers (MikMak) for DOS. It has
diff -Nru libmikmod-3.1.12/debian/libmikmod2.lintian-overrides libmikmod-3.1.12/debian/libmikmod2.lintian-overrides
--- libmikmod-3.1.12/debian/libmikmod2.lintian-overrides 1970-01-01 01:00:00.0 +0100
+++ libmikmod-3.1.12/debian/libmikmod2.lintian-overrides 2012-12-21 16:48:37.0 +0100
@@ -0,0 +1,3 @@
+# Fortification has been explicitly disabled, as it breaks module
+# loading for some reason.
+libmikmod2: hardening-no-fortify-functions usr/lib/*/libmikmod.so.2.0.4
diff -Nru libmikmod-3.1.12/debian/patches/0014-playercode-mdreg-Register-the-NULL-driver-before-the.patch libmikmod-3.1.12/debian/patches/0014-playercode-mdreg-Register-the-NULL-driver-before-the.patch
--- libmikmod-3.1.12/debian/patches/0014-playercode-mdreg-Register-the-NULL-driver-before-the.patch 1970-01-01 01:00:00.0 +0100
+++ libmikmod-3.1.12/debian/patches/0014-playercode-mdreg-Register-the-NULL-driver-before-the.patch 2012-12-21 16:09:51.0 +0100
@@ -0,0 +1,37 @@
+From: Gergely Nagy alger...@madhouse-project.org
+Date: Fri, 21 Dec 2012 16:07:43 +0100
+Subject: playercode/mdreg: Register the NULL driver before the file writers
+
+Register the NULL driver sooner, as having no sound is preferable to
+writing to music.raw: file writing should be used only when explicitly
+selected.
+
+Reported-by: Simon McVittie s...@debian.org
+Closes: #690943
+Signed-off-by: Gergely Nagy alger...@madhouse-project.org
+---
+ playercode/mdreg.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/playercode/mdreg.c b/playercode/mdreg.c
+index 4018c7e..f158e18 100644
+--- a/playercode/mdreg.c
b/playercode/mdreg.c
+@@ -82,6
Bug#701991: maven3: CVE-2013-0253
Control: reassign -1 src:maven Moritz Muehlenhoff j...@inutil.org writes: Package: maven3 There is no maven3 package, so I'm reassigning to maven, which does have a version = 3, so I assume it is the package you meant to file the bug against. Severity: grave Tags: security Justification: user security hole Please see http://maven.apache.org/security.html for details. Cheers, Moritz -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701989: libiptcdata: Added DEP-8 tests
Control: reassign -1 src:libiptcdata Vibhav Pant vibh...@ubuntu.com writes: Package: llibiptcdata When filing bugs, please make sure that the package name is correct, otherwise it will end up misfiled, possibly against the 'unknown package', and will not reach the maintainer unless reassigned. I'm reassigning it to the proper place now, but please try to be more careful in the future! Severity: wishlist Tags: patch Dear Maintainer, I'm forwarding a diff that adds DEP-8 tests to the package, originally submitted to Launchpad. See http://dep.debian.net/deps/dep8/ for details. https://code.launchpad.net/~vibhavp/ubuntu/raring/libiptcdata/add-autopkgtest/+merge/150504/+preview-diff/+files/preview.diff -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701683: libacpi: Added DEP-8 tests
Control: reassign -1 src:libacpi Vibhav Pant vibh...@ubuntu.com writes: Package: llibacpi When filing bug reports, please make sure you get the package name right, otherwise the report will end up misfiled, and has to be reassigned (like I'm doing now) to reach the maintainers. Thanks! Severity: wishlist Tags: patch Dear Maintainer, I'm forwarding a diff that adds DEP-8 tests to the package, originally submitted to Launchpad. See http://dep.debian.net/deps/dep8/ for details. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/libacpi/raring/diff/4 -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701203: n...@debian.org: Please broadcast the end of processes (i.e. people turning DDs) publicly
Control: reassign -1 nm.debian.org Arno Töll a...@debian.org writes: Package: n...@debian.org s/@/./; When filing bugs, please make sure you file it against the correct (pseudo-)package, otherwise it may end up in the void that is known as 'unknown-package', and has to be reassigned like I did just now. Using reportbug (which does have support for nm.debian.org) would be one option. Thanks in advance! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702004:
Control: reassign -1 php5 Michael Stucki michael.stu...@typo3.org writes: Sorry, I've set a wrong package name. Can someone change it to php5 please? Done. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702131: syslog-ng childs segfault, eventfd2: Invalid argument
Martin Zobel-Helas zo...@debian.org writes: Package: syslog-ng Version: 3.3.5-2 [...] when trying to start syslog-ng on gabrielli.debian.org I see the following error: root@gabrielli:/var/lib/syslog-ng# /etc/init.d/syslog-ng start [] Starting system logging: syslog-ngeventfd2: Invalid argument failed! root@gabrielli:/var/lib/syslog-ng# [...] This is a known problem in the underlying ivykis library, and can be fixed by applying a patch to lib/ivykis, something along these lines: https://github.com/buytenh/ivykis/commit/89f67f97477aeba24aebfc58ae1a17e5bea69724.patch It will need some minor changes, as the ivykis included with 3.3.5 is a bit different from upstream. I then can see syslog-ng master-process spawining childs, which segfault immidiatly: http://paste.debian.net/239439/ This sounds like another issue, also in ivykis, but a race condition: https://github.com/buytenh/ivykis/commit/144b88cbe4a04d53acbf4525d06cc1860571d36f.patch This should apply reasonably cleanly to lib/ivykis aswell. Both problems affect unstable aswell, but there the problem needs to be fixed in the ivykis library, I'll clone the bug report shortly. Since the syslog-ng maintainer already prepared an upload targeted at wheezy that fixes other RC bugs, these two patches should be added to that mix too. Nevertheless, I'll prepare an NMU later today and will prod the release team to let it through t-p-u (unstable has a whole new syslog-ng upstream version). Build-depends for syslog-ng for wheezy are installed on host gabrielli.debian.org in the wheezy chroot. I'll run some tests there with the fixes today, and will follow up with the results to this bug report. Thanks for reporting the help so far! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702131: syslog-ng childs segfault, eventfd2: Invalid argument
Gergely Nagy alger...@balabit.hu writes:
This is a known problem in the underlying ivykis library, and can be
fixed by applying a patch to lib/ivykis, something along these lines:
https://github.com/buytenh/ivykis/commit/89f67f97477aeba24aebfc58ae1a17e5bea69724.patch
It will need some minor changes, as the ivykis included with 3.3.5 is a
bit different from upstream.
The attached patch should fix the eventfd2 errors, and make the code
properly fall back to whatever it normally falls back to.
I then can see syslog-ng master-process spawining childs, which segfault
immidiatly:
http://paste.debian.net/239439/
This sounds like another issue, also in ivykis, but a race condition:
https://github.com/buytenh/ivykis/commit/144b88cbe4a04d53acbf4525d06cc1860571d36f.patch
This should apply reasonably cleanly to lib/ivykis aswell.
Turns out, this doesn't apply cleanly, or at all. It is not needed
either, as the code in syslog-ng's ivykis fork does not suffer from this
problem. The crash is likely due to something else, perhaps even related
to the eventfd fix.
I have not been able to reproduce the crash in the wheezy chroot on
gabrielli, unfortunately. I'm trying to figure something out using
valgrind on x86, perhaps that'll help.
Meanwhile, if I could get access to the core file that was generated,
that may help, or at least aid me in figuring out how to reproduce the
problem on my own.
--
|8]
--- iv_event_raw.c.orig 2013-03-03 17:11:37.548279231 +0100
+++ iv_event_raw.c 2013-03-03 17:11:00.664356074 +0100
@@ -91,7 +91,7 @@
ret = eventfd2(0, EFD_NONBLOCK | EFD_CLOEXEC);
if (ret 0) {
- if (errno != ENOSYS) {
+ if (errno != ENOSYS errno != EINVAL) {
perror(eventfd2);
return -1;
}
Bug#702131: syslog-ng childs segfault, eventfd2: Invalid argument
Control: tag -1 patch Gergely Nagy alger...@balabit.hu writes: I then can see syslog-ng master-process spawining childs, which segfault immidiatly: http://paste.debian.net/239439/ This sounds like another issue, also in ivykis, but a race condition: https://github.com/buytenh/ivykis/commit/144b88cbe4a04d53acbf4525d06cc1860571d36f.patch This should apply reasonably cleanly to lib/ivykis aswell. Turns out, this doesn't apply cleanly, or at all. It is not needed either, as the code in syslog-ng's ivykis fork does not suffer from this problem. The crash is likely due to something else, perhaps even related to the eventfd fix. Turns out, it *is* related to the eventfd bug. What happens is, syslog-ng tries to register an event, but that doesn't work, and instead of aborting, it goes and and tries to post that event, which results in a segfault. Since ivykis can now fall back to $whatever, the event registration succeeds, and all is well. I reproduced the original issue on gabrielli, and after fixing the eventfd bug, I could not reproduce the crash anymore, either. So the patch I attached earlier should be enough. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702195: symlink conffiles are not supported, causing problems for dpkg on upgrade/removal and incorrect debsums reports
Laszlo Boszormenyi (GCS) g...@debian.hu writes: On Wed, 2013-03-06 at 13:17 +0100, Michael Biebl wrote: 1/ as you no longer mark the symlinks as conffiles, the cleanup in syslog-ng-core.postrm is not necessary. Removed. 2/ you need to remove the existing conffile symlinks in syslog-ng-core.preinst so dpkg converts it to non-conffiles on upgrades Remove those in preinst. 3/ please drop the line ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service from syslog-ng.service. The systemd-kmsg-syslogd.service service has been removed a long time ago and future versions of systemd will generate an error if you stop a non-existing service. Gergely told he had this change in his Git repo already. Line removed, added other fixes from the Git repo. I checked just now, and some things were picked from the merge-queue/3.5 branch (the default branch on github), namely Type=notify - that is not supported by syslog-ng 3.3, and will be new in 3.5. Other than that, Michael already said what I would've, just better. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699280: libopendmarc: README.Debian talks about opendkim (nowhere is openDMARC mentioned)
Control: reassign -1 libopendmarc0 Jonas Smedegaard d...@jones.dk writes: Package: libopendmarc When filing bug reports, please make sure you file it against a package that exists, otherwise the BTS gets confused and upset, and refuses to figure out where to send the report to, leaving it lingering in the void that is known as the 'unknown package'. Think of the BTS, think of the poor, lost bug reports! Thank you. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700191: drracket: No mime types defined in drracket.desktop
Control: reassign -1 racket Frederik Himpe fhi...@telenet.be writes: Package: drracket Severity: normal When filing bugs, please file it against a package, not against a binary. reportbug(1) can help with that, as it will look up the package a binary belongs to (provided the package is installed). Misfiled bugs will not be automatically forwarded to the maintainer, unless someone reassigns like I did now. So, to make it easier for everyone, and get your issue fixed sooner, please, in the future, make sure that the bug you file is filed against the correct package. Thanks -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700451: iso_3166: [INTL:pt] Updated Portuguese translation for program
Control: reassign -1 iso-codes Traduz - Portuguese Translation Team tra...@debianpt.org writes: Package: iso_3166 Version: n/a Tags: l10n, patch Severity: wishlist When filing bug reports, please make sure you file it against a package that exists, otherwise it will not reach the maintainer unless reassigned (like I did just now). In this case, the correct package appears to be iso-codes (maintainer CC'd). Thanks! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700709: false alarm
Alexey Kuznetsov kuznetsov.ale...@gmail.com writes: and it seems like it is dead or something is wrong with it. [...] so i'm going to replace the drive. Does that mean that the issue can be closed? I'm asking because the bug you filed ended up being filed against an unknown package (linux-image does not exist, you probably want src:linux, or the full linux-image-$blah name), and if the bug can be closed, I don't need to reassign it. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672111: git2cl: Command examples in manpage can't be copy-pasted as-is
Package: git2cl Version: 2.0+git200808271242-1 Severity: normal While evaluating git2cl, I stumbled upon an issue with the manual page, namely that the example commands therein, when pasted into a shell session, do not work. This is because the manpage uses \[em], while the commands expect a double-dash. Please update the man page to use \-\- or some similar solution, so that the commands can be pasted to a shell as-is. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672130: RFP: wi_tray -- Tray for wmii
reassign 672130 wnpp thanks Somelauw somel...@gmail.com writes: Subject: RFP: wi_tray -- Tray for wmii Package: wi_tray When reporting RFP bugs, please follow the guideline explained here[1], and report these bugs against the correct pseudo-package: wnpp. I have reassigned the package there now, but in the future, please be more careful, so your bug reports end up being filed where they should be filed, instead of hanging lonely in the big dark void. [1]: http://www.debian.org/devel/wnpp/#l2 -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672244: debian-system-monitor: Graph Update interval value is not working as expected
reassign 672244 gnome-system-monitor thanks Vladimir Radev vbra...@gmail.com writes: Package: debian-system-monitor Version: gnome-system-monitor When filing bugs, please make sure you file it against the correct package, and correct version. There is no 'debian-system-monitor' package in Debian, let alone one with 'gnome-system-monitor' as its version. I have reassigned your report to gnome-system-monitor, but in the future, please try to file reports against the correct package. Filing it against something that does not exist makes the bug end up being assigned to nothing, so the developers won't get notified of it either, unless someone reassigns the bug to the proper place like I did now. Thanks! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668367: Please do not depend on wine{,-unstable} transitional packages
Jari Aalto jari.aa...@cante.net writes: The only solution I can think of in situation where package wine does not exists in system, is to download winetricks directly from the project's version control. There's another option: faking a wine package. The equivs package comes handy in cases like this. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668367: Please do not depend on wine{,-unstable} transitional packages
On Thu, May 10, 2012 at 11:28 AM, Jari Aalto jari.aa...@cante.net wrote: 2012-05-10 09:07 Gergely Nagy alger...@madhouse-project.org: | Jari Aalto jari.aa...@cante.net writes: | | The only solution I can think of in situation where package wine does not | exists in system, is to download winetricks directly from the project's | version control. | | There's another option: faking a wine package. The equivs package comes | handy in cases like this. Nice. The *-4 release of winetricks will have depends on wine-dummy with these instructions in package Description: No need to. wine | wine-unstable is fine, you can use equivs to create dummy packages named wine or wine-unstable, and all will be well. Depending on packages outside of the archive (even if it's only one of the three possibilities that satisfy a depends) is frowned upon in the best case. I do not think there is anything that needs to be changed in winetricks. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668367: Please do not depend on wine{,-unstable} transitional packages
On Thu, May 10, 2012 at 12:01 PM, Jari Aalto jari.aa...@cante.net wrote: 2012-05-10 12:39 Gergely Nagy alger...@madhouse-project.org: | On Thu, May 10, 2012 at 11:28 AM, Jari Aalto jari.aa...@cante.net wrote: | | 2012-05-10 09:07 Gergely Nagy alger...@madhouse-project.org: | | Jari Aalto jari.aa...@cante.net writes: | | | | The only solution I can think of in situation where package wine does not | | exists in system, is to download winetricks directly from the project's | | version control. | | | | There's another option: faking a wine package. The equivs package comes | | handy in cases like this. | | Nice. | | The *-4 release of winetricks will have depends on wine-dummy with these | instructions in package Description: | | No need to. wine | wine-unstable is fine, you can use equivs to create | dummy packages named wine or wine-unstable, and all will be well. | | Depending on packages outside of the archive (even if it's only one of | the three possibilities that satisfy a depends) is frowned upon in the | best case. | | I do not think there is anything that needs to be changed in winetricks. Actually I could create new package in winetricks::debian/control: winetricks-wine And add depends Depends: winetricks-wine | wine-unstable | wine To make wineticks self sufficient as it was for users that install wine from sources. I think that users who install wine from source, should be able to use equivs themselves. There's absolutely no need to add dirty tricks to the winetricks package - we could pretty much do that for every other package then, to support from-source dependencies. Leave it as is, and whoever wants to use the packaged winetricks with self compiled wine, can use equivs. Create a wiki page on wiki.d.o or so to help them, but I don't think Debian packages should have explicit support for this kind of thing. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672457: syslog-ng: FTBFS on non-linux architectures, due to missing systemd symlinks
Source: syslog-ng Version: 3.3.5-1 Severity: serious Justification: Fails to build from source on non-linux architectures syslog-ng fails to build from source on non-linux architectures, due to the systemd symlinks under /etc/systemd being in debian/syslog-ng-core.conffiles. These symlinks are only installed on Linux, however: ifeq (linux,$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)) install -d debian/syslog-ng-core/etc/systemd/system/multi-user.target.wants ln -sf /lib/systemd/system/syslog-ng.service \ debian/syslog-ng-core/etc/systemd/system/syslog.service ln -sf /lib/systemd/system/syslog-ng.service \ debian/syslog-ng-core/etc/systemd/system/multi-user.target.wants/ cp -r debian/tmp/lib debian/syslog-ng-core/ endif This should be changed to run unconditionally, on all architectures, and instead of copying debian/tmp/lib to the syslog-ng-core package, install the service file ourselves, not relying on the upstream build system to do it (since it will only do that on linux, when systemd is enabled). I'll submit a patch later to do just this. Sadly, the FTBFS is my fault, the above code is mine. Should've realized that we need to install the files in .conffiles, or things will break. Next time, I'll test my changes on kFreeBSD Hurd aswell. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages syslog-ng depends on: ii syslog-ng-core 3.3.5-1 ii syslog-ng-mod-json 3.3.5-1 ii syslog-ng-mod-mongodb 3.3.5-1 ii syslog-ng-mod-sql 3.3.5-1 syslog-ng recommends no packages. syslog-ng suggests no packages. -- no debconf information -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672457: syslog-ng: FTBFS on non-linux architectures, due to missing systemd symlinks
tags 672457 + patch
thanks
The attached patch should - I believe - fix the issue. It will result in
shipping the systemd control files and the symlinks on every arch, even
when systemd is not used, even when support is not compiled into
syslog-ng.
They do no harm, and if any of these non-linux platforms grow systemd
support overnight, we'll have the files there. Plus, our conffiles are
consistent over architectures this way, which is great.
--
|8]
--- a/debian/rules 2012-05-11 12:00:38.213446208 +0200
+++ b/debian/rules 2012-05-11 12:00:42.813469008 +0200
@@ -129,14 +129,13 @@
override_dh_auto_install:
dh_auto_install
${MAKE} -C debian/build-tree/lib/ivykis install DESTDIR=$(CURDIR)/debian/tmp
-ifeq (linux,$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS))
- install -d debian/syslog-ng-core/etc/systemd/system/multi-user.target.wants
+
ln -sf /lib/systemd/system/syslog-ng.service \
debian/syslog-ng-core/etc/systemd/system/syslog.service
ln -sf /lib/systemd/system/syslog-ng.service \
debian/syslog-ng-core/etc/systemd/system/multi-user.target.wants/
- cp -r debian/tmp/lib debian/syslog-ng-core/
-endif
+ install -m 0644 contrib/systemd/syslog-ng.service \
+ debian/syslog-ng-core/lib/systemd/system/
##
#* Overrides for other debhelper commands
diff --git a/debian/syslog-ng-core.dirs b/debian/syslog-ng-core.dirs
index b2c4a17..73a42f6 100644
--- a/debian/syslog-ng-core.dirs
+++ b/debian/syslog-ng-core.dirs
@@ -1 +1,3 @@
/etc/syslog-ng/conf.d/
+/etc/systemd/system/multi-user.target.wants/
+/lib/systemd/system/
Bug#672477: dh_strip --dbg-package broken
Ondřej Surý ond...@debian.org writes: Package: debhelper Version: 9.20120509 Severity: grave Tags: sid Hi, the recent debhelper update broke every dh_strip --dbg-package out there, unless of course the .build-id/* is intentional: debhelper (8.9.13) unstable; urgency=low [...] * dh_strip: Use build-id in /usr/lib/debug in v9. Closes: #642158 Thanks, Jakub Wilk And why would .build-id/ break anything, when it is supported by gdb? (The 'recent' update is from december 2011, by the way) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672697: libmikmod: New Beta version from upstream
Andreas Tscharner a...@vis.ethz.ch writes: Package: libmikmod2 Version: 3.1.12-4 Severity: wishlist File: libmikmod Tags: upstream Dear Maintainer, Upstream has, after many years of inactivity a beta of new upcoming version 3.2.0. Please consider using it as fast as possible, because it contains ALSA support. Oh, nice, I'll have a look and if all goes well, prepare an upload to experimental at least. Thanks for the notice! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672873: Missing link against GLU library
reassign 672873 src:qwtplot3d 0.2.7+svn191-6 thanks Felix Geyer debfx-...@fobos.de writes: Package: libqwtplot3d-qt4 Version: 0.2.7+svn191-6 Tags: patch The package name is missing a -0 from the end, so it did not get filed against the appropriate package. I've reassigned it to the soruce instead, since the bug is in the packaging, and the build-deps need adjustment anyway. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672701: partial review
Hi! I'd suggest we keep this to the bugreport, no need to Cc mentors: whoever is interested, can post to the bug. I haven't reviewed the whole bug log yet, but one part caught my attention: On Mon, May 14, 2012 at 5:58 PM, Andrew Shadura bugzi...@tut.by wrote: * You should also consider using DEP5 for your copyright. May be or may not be needed. It's optional at this moment, so I don't use it widely (yet). It's in the packaging manual, and it's been accepted. You should be taking it more seriously. It's perhaps not a requirement, but it's a good thing to have. It's been accepted but it wasn't promoted to thing which is required. I see no real reason to use it yet, at least here, sorry. While it is, indeed, not required, a DEP5 copyright file has a number of advantages, which, I believe, make it strongly desirable, and worthy of spending effort converting to it. On one hand, some sponsors prefer DEP5, and wouldn't spend time looking at non-DEP5 sponsor requests (I'm one of these, see my other reasons further along). The main reason I prefer DEP5 is because it pretty much forces one to look through the licenses and copythights THROUGHLY, which makes both my job easier when reviewing, and the ftpmaster's job when they process the package through NEW. Being machine-readable is a good thing too, but the main selling point of DEP5 for me is its granularity. So many times I've seen copyrights and licenses missed in a debian/copyright file, because one did not look further than the top level LICENSE file... DEP5 makes one dig deeper. Of course, one can do that without the format, but.. if you're going through it all throughly, and documenting it anyway... might as well do so in a format that's standardized in Debian Policy. So I would strongly urge you to reconsider, and use DEP5. In the long run, I believe it's worth the effort. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672929: fancy output result should be on the right
Peter Eisentraut pet...@debian.org writes: Package: lsb-base Version: 4.1+Debian2 Severity: wishlist The new fancy output is neat and all, but it looks backwards, because it's [ ok ] Doing something where the ok comes after the doing. The normal progression should go from left to right, and so the ok should be on the right side. This has also been long established practice in other distributions (last time I checked), so I don't see why Debian needs to do this differently. Please rethink this. If changing it, please make it configurable. I *hate* it on the far right. On a wide screen, the status and the rest of the text are far apart, which makes reading it harder. Having the status on the left, closer to the message itself is much easier to read at a glance, in my opinion. That the rest of the world does it wrong is no reason for us to follow, when it can be done right ;) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672571: Workaround
I ran into this as well upon dist-upgrade. My current workaround was to remove python4-kde package and all its dependents. Not sure if this bug should be reassigned to that pkg. Anyway, plasma seems working fine now. Gergo
Bug#690067: syslog-ng-core: symlink conffile issues
Enrico Zini enr...@enricozini.org writes: On Mon, Oct 15, 2012 at 11:56:16AM +0200, Gergely Nagy wrote: Mostly for myself, but replacing the symlinks with real conffiles that .include the former symlink targets may be an even better course of action. I'll test that over the next few days, and see how upgrades behave. Hi, any news? Sorry, I forgot to follow up on this it seems. I tested the unit files that simply .include'd the real ones, and that works nicely. Tested the upgrade path too, seems smooth. I promised the maintainer to prepare patches suitable for wheezy, including this one, but did not get around to do them yet. With a bit of luck, I'll have some free time to make this happen around next week. (For what it's worth, the fix is available in my git tree at [1] and [2]) [1]: https://github.com/algernon/syslog-ng/commit/cd7611244c818ccc14328cddb20467adb9d7851f.patch [2]: https://github.com/algernon/syslog-ng/commit/da0cd112858fef0b6263233877edee13ff890d90.patch -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690381: Insane packaging of pax
Thorsten Glaser t...@mirbsd.de writes: Neil Williams dixit: Just what is wrong with old-style debhelper like: And in fact, it has limitations (such as not being able to rename in dh_install) and other requirements which, for mksh, throw a stone in my way more often than help. FWIW, you do not need to use purely debhelper. For cases where it does not support what you wisht to do, you can still fall back to good old mv/cp. Building on dh_* is fine, but one does not need to be constrained by its limitations, there's nothing wrong with adding a cp/mv line to d/rules. (I would also mention dh9+ and dh-exec, but that would probably result in very angry thoughts aimed at my person from all parties involved here :P) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694707: ITP: ruby-ci-reporter -- CI::Reporter is an add-on to Test::Unit, RSpec and Cucumber that allows you to generate XML reports of your test, spec and/or feature runs
Control: reassign -1 wnpp Addy Singh addy...@gmail.com writes: package: ruby-ci-reporter When filing ITP bugs, please follow the recommendation[1], and file it against the wnpp pseudo-package. Doing otherwise will not make the ITP visible, it will not reach the appropriate lists, either. I have reassigned the report now, but please be more careful in the future (or use reportbug, which has explicit support for filing ITPs). [1]: http://www.debian.org/devel/wnpp/#l2 -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694711: ITP: ruby-creole -- Creole is a lightweight markup language
Control: reassign -1 wnpp jaseem abid jaseema...@gmail.com writes: package: ruby-creole When filing ITP bugs, please follow the recommendation[1], and file it against the wnpp pseudo-package. Doing otherwise will not make the ITP visible, it will not reach the appropriate lists, either. I have reassigned the report now, but please be more careful in the future (or use reportbug, which has explicit support for filing ITPs). [1]: http://www.debian.org/devel/wnpp/#l2 -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694710: ITP: ruby-libwebsocket -- Universal Ruby library to handle WebSocket protocol
Control: reassign -1 wnpp Vipin Nair swv...@gmail.com writes: package: ruby-libwebsocket When filing ITP bugs, please follow the recommendation[1], and file it against the wnpp pseudo-package. Doing otherwise will not make the ITP visible, it will not reach the appropriate lists, either. I have reassigned the report now, but please be more careful in the future (or use reportbug, which has explicit support for filing ITPs). [1]: http://www.debian.org/devel/wnpp/#l2 -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694757: libmdb is not packaged in debian
Control: reassign -1 wnpp Control: title -1 RFP: libmdb -- OpenLDAP Memory-Mapped Database Control: severity -1 wishlist Quanah Gibson-Mount qua...@zimbra.com writes: Package: libmdb Version: 0.9.4 When filing bugs requesting that a package be packaged for Debian, please file it against the wnpp pseudo-package. You can find more information about the procedure at: http://www.debian.org/devel/wnpp/#l1 I have reassigned retitled this bug, but in the future, please file it appropriately. Thanks in advance! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695020: Package superseded by python-traitsui
Control: reassign -1 python-traitsgui 3.6.0-3 Jerome Vouillon jerome.vouil...@pps.univ-paris-diderot.fr writes: Package: python-traitsbackendgui When filing bugs, please make sure it is filed against a package that exists in the archive, otherwise it has to be manually reassigned in order for it to reach the maintainer (like I did just now). The reportbug tool will warn you if you try submitting a report against a package it can't find, it might be worth considering making use of this tools features. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716905: RFS: goodbye/0.3-1 [ITP]
Adam Borowski kilob...@angband.pl writes: Let's add some WTF to FTPmasters' day! :) This package is a perfect fit for a personal archive, but if anyone wants to upload it: you're in for a race for the fastest REJECT ever. We have enough WTFs a day already, thankyouverymuch. But I'm in a good mood today, so here's some criticism: * debian/rules without arguments does not behave sanely: make: *** No targets. Stop. It should at least do something, but no targets is unexpected. It says the same when tcc is not installed too, instead of failing violently for build-deps not being present. * It unconditionally rewrites debian/control This is REJECT reason alone. You simply don't do that. * debian/rules with an invalid target name still works: debian/rules binary == debian/rules yranib It should produce an error. This kind of unexpected behaviour is confusing, and not something we want in the archive. We already have CDBS for that[1], thank you. * There is no error checking: Trying to build the package in a chroot that doesn't have enough space: it will result in an empty, invalid package. The return value of mkdir(), system() and all that needs to be checked, or you're not complying with Policy 4.6. * d/rules can be exploited by an overly long version string * The binary created by d/rules is invalid: algernon@hadhodrond:/tmp/b$ dget -x -u http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc dget: retrieving http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1440 100 14400 0 342k 0 --:--:-- --:--:-- --:--:-- 703k dget: retrieving http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3.orig.tar.xz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1824 100 18240 0 471k 0 --:--:-- --:--:-- --:--:-- 1781k dget: retrieving http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.debian.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 3133 100 31330 0 133k 0 --:--:-- --:--:-- --:--:-- 145k dpkg-source: info: extracting goodbye in goodbye-0.3 dpkg-source: info: unpacking goodbye_0.3.orig.tar.xz dpkg-source: info: unpacking goodbye_0.3-1.debian.tar.gz algernon@hadhodrond:/tmp/b$ cd goodbye-0.3/ algernon@hadhodrond:/tmp/b/goodbye-0.3$ debian/rules binary ar: creating ../goodbye_0.3-1_all.deb doing: [binary]\n algernon@hadhodrond:/tmp/b/goodbye-0.3$ dpkg-deb -c ../goodbye_0.3-1_all.deb dpkg-deb: error: archive has no newlines in header And indeed, debian-binary contains 2.0\n, and no newline. * Debugging d/rules is unnecessarily hard I can' easily attach gdb to figure out what's wrong. stracing it is painful too. * root:root owner is not enforced in the control.tar.gz: algernon@hadhodrond:/tmp/b/goodbye-0.3$ tar tzvf control.tar.gz -rw-r--r-- algernon/algernon 723 2013-07-15 17:35 control This is reject worthy too. -- |8] [1]: I'm just picking on CDBS, because I can. Feel free to substitute anything else, dh short form, dbs, dpatch, dh-exec, you name it. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc4bq172.fsf@algernon.balabit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727683: lintian: erroneously reports a warning on :-separated RPATHs
Package: lintian Version: 2.5.19 Severity: normal While working on my unofficial syslog-ng packages[1], I came across a spurious warning when running Lintian on the results: E: syslog-ng-core: binary-or-shlib-defines-rpath usr/lib/syslog-ng/3.5.0rc1/libcryptofuncs.so /usr/lib/syslog-ng:/usr/lib/syslog-ng/3.5.0rc1 This seemed strange, as the RPATH some of the binaries set (/usr/lib/syslog-ng:/usr/lib/syslog-ng/3.5.0rc1) is, by the letter of policy, allowed: both components are under /usr/lib/$srcpkg. The reason lintian fails is because it's prepared to find multiple RPATHs set within an object, but not for the case where a single record uses : as a separator (a'la PATH). It ends up checking that the rpath is either /usr/lib/$srcpkg or /usr/lib/$srcpkg/: the ':' confuses it. I will submit a patch in a few minutes that corrects lintian by splitting the rpath into components first. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-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 lintian depends on: ii binutils 2.23.90.20130927-1 ii bzip2 1.0.6-5 ii diffstat 1.57-1 ii file 1:5.14-2 ii gettext0.18.3.1-1 ii hardening-includes 2.4 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b1 ii libarchive-zip-perl1.30-7 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.35-1 ii libdigest-sha-perl 5.85-1+b1 ii libdpkg-perl 1.16.12 ii libemail-valid-perl1.192-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-1+b2 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.06~01-2 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii man-db 2.6.5-2 ii patchutils 0.3.2-2 ii perl [libdigest-sha-perl] 5.18.1-4 ii t1utils1.37-2 Versions of packages lintian recommends: ii libautodie-perl 2.21-1 ii libperlio-gzip-perl 0.18-1+b3 ii perl-modules [libautodie-perl] 5.18.1-4 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.16.12 ii libhtml-parser-perl3.71-1+b1 ii libtext-template-perl 1.46-1 ii xz-utils 5.1.1alpha+20120614-2 -- 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#727683: patch
Control: tag -1 patch
Attached is a patch that fixes the problem, by splitting the RPATH into
components before doing any checks on it. The patch includes a test case
too.
I would appreciate if this could be applied soonish, as I need to add an
override to syslog-ng until this is in backports, as
binary-or-shlib-defines-rpath is on the ftp-master (soft) autoreject list.
--
|8]
From 34fe711c42cf21d9f2d3fe86322a8e40b71594b2 Mon Sep 17 00:00:00 2001
From: Gergely Nagy alger...@balabit.hu
Date: Fri, 25 Oct 2013 13:00:06 +0200
Subject: [PATCH] c/binaries.pm: Add support for multi-component RPATHs
The RPATH setting works similar to PATH, and supports multiple
components, separated by a colon. As such, Lintian should be able to
handle those, and split the RPATH into components before making any
checks on those.
This patch does just that, and adds a test case to trigger the original
issue too.
Signed-off-by: Gergely Nagy alger...@balabit.hu
---
checks/binaries.pm | 2 +-
debian/changelog | 2 ++
t/tests/binaries-general/debian/Makefile | 3 +++
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/checks/binaries.pm b/checks/binaries.pm
index c57e431..122657d 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -359,7 +359,7 @@ sub run {
if (exists $objdump-{RPATH}) {
foreach my $rpath (
map {File::Spec-canonpath($_)}
-keys %{$objdump-{RPATH}}
+map {split(/:/, $_)} keys %{$objdump-{RPATH}}
) {
next
if $rpath
diff --git a/debian/changelog b/debian/changelog
index d58061a..176d908 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ lintian (2.5.20) UNRELEASED; urgency=low
* checks/cruft.{desc,pm}:
+ [BR] Check files for under a non-distributable Nvidia
license. (Closes: #724930)
+ * checks/binaries.pm:
++ [GN] Add support for multi-component RPATHs. (Closes: #727683)
* data/binary/embedded-libs:
+ [RG] Detect embedded copies of poppler/xpdf. (Closes: #724733)
diff --git a/t/tests/binaries-general/debian/Makefile b/t/tests/binaries-general/debian/Makefile
index ac5bd0f..5f0f442 100644
--- a/t/tests/binaries-general/debian/Makefile
+++ b/t/tests/binaries-general/debian/Makefile
@@ -10,6 +10,8 @@ all:
$(COMPILE) -o basiclibrpath basic.c -Wl,--rpath,/usr/lib
# non-special rpath shipped in the package
$(COMPILE) -o basicshippedrpath basic.c -Wl,--rpath,/usr/share/foo
+ # special rpath shipped in the package, multiple paths
+ $(COMPILE) -o basicshippedrpathmore basic.c -Wl,--rpath,/usr/lib/binaries-general:/usr/lib/binaries-general/bar
# static version of basic for debugging checks
$(COMPILE) -static -o basic.static basic.c
# version with debug
@@ -27,6 +29,7 @@ install:
strip -s $(DESTDIR)/usr/lib/debug/usr/share/foo/basic
install -m 755 -c basiclibrpath $(DESTDIR)/usr/lib/foo/basiclibrpath
install -m 755 -c basicshippedrpath $(DESTDIR)/usr/lib/foo/basicshippedrpath
+ install -m 744 -c basicshippedrpathmore $(DESTDIR)/usr/lib/foo/basicshippedrpathmore
objcopy --only-keep-debug basic $(DESTDIR)/usr/lib/debug/basic
install -d $(DESTDIR)/usr/lib/debug/.build-id/`$(GETBUILDID) -s basicdebug`
install -m 755 -c basicdebug $(DESTDIR)/usr/share/foo/basicdebug
--
1.8.4.rc3
Bug#727683: Updated patch
This is an updated patch that changes objdump_info() in
Lintian::Collect::Binary instead of checks/binaries.pm, so that
everything that uses $objdump-{RPATH} will benefit from the change.
--
|8]
From 60f978fcfcc8f3477b22453479ab005061d3d84f Mon Sep 17 00:00:00 2001
From: Gergely Nagy alger...@balabit.hu
Date: Fri, 25 Oct 2013 13:24:19 +0200
Subject: [PATCH] L::C::Binary: Add support for multi-component RPATHs
The RPATH setting works similar to PATH, and supports multiple
components, separated by a colon. As such, Lintian should be able to
handle those, and split the RPATH into components before making any
checks on those.
This patch does just that, and adds a test case to trigger the original
issue too.
Signed-off-by: Gergely Nagy alger...@balabit.hu
---
debian/changelog | 2 ++
lib/Lintian/Collect/Binary.pm| 2 +-
t/tests/binaries-general/debian/Makefile | 3 +++
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index d58061a..2628e7c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,6 +20,8 @@ lintian (2.5.20) UNRELEASED; urgency=low
* lib/Lintian/Check.pm:
+ [RG] Detect a few more spelling mistakes by removing some
suffixes before looking them up in the list of spelling mistakes.
+ * lib/Lintian/Collect/Binary.pm:
++ [GN] Add support for multi-component RPATHs. (Closes: #727683)
-- Niels Thykier ni...@thykier.net Thu, 26 Sep 2013 09:35:27 +0200
diff --git a/lib/Lintian/Collect/Binary.pm b/lib/Lintian/Collect/Binary.pm
index a4e2b5b..022eb9b 100644
--- a/lib/Lintian/Collect/Binary.pm
+++ b/lib/Lintian/Collect/Binary.pm
@@ -393,7 +393,7 @@ sub objdump_info {
# Here we just need RPATH and NEEDS, so ignore the rest for now
my ($header, $val) = split m/\s++/, $data;
if ($header eq 'RPATH') {
-$info{$header}-{$val} = 1;
+map {$info{$header}-{$_} = 1;} split m/:/, $val;
} elsif ($header eq 'NEEDED' or $header eq 'SONAME') {
push @{ $info{$header} }, $val;
} elsif ($header eq 'TEXTREL') {
diff --git a/t/tests/binaries-general/debian/Makefile b/t/tests/binaries-general/debian/Makefile
index ac5bd0f..5f0f442 100644
--- a/t/tests/binaries-general/debian/Makefile
+++ b/t/tests/binaries-general/debian/Makefile
@@ -10,6 +10,8 @@ all:
$(COMPILE) -o basiclibrpath basic.c -Wl,--rpath,/usr/lib
# non-special rpath shipped in the package
$(COMPILE) -o basicshippedrpath basic.c -Wl,--rpath,/usr/share/foo
+ # special rpath shipped in the package, multiple paths
+ $(COMPILE) -o basicshippedrpathmore basic.c -Wl,--rpath,/usr/lib/binaries-general:/usr/lib/binaries-general/bar
# static version of basic for debugging checks
$(COMPILE) -static -o basic.static basic.c
# version with debug
@@ -27,6 +29,7 @@ install:
strip -s $(DESTDIR)/usr/lib/debug/usr/share/foo/basic
install -m 755 -c basiclibrpath $(DESTDIR)/usr/lib/foo/basiclibrpath
install -m 755 -c basicshippedrpath $(DESTDIR)/usr/lib/foo/basicshippedrpath
+ install -m 744 -c basicshippedrpathmore $(DESTDIR)/usr/lib/foo/basicshippedrpathmore
objcopy --only-keep-debug basic $(DESTDIR)/usr/lib/debug/basic
install -d $(DESTDIR)/usr/lib/debug/.build-id/`$(GETBUILDID) -s basicdebug`
install -m 755 -c basicdebug $(DESTDIR)/usr/share/foo/basicdebug
--
1.8.4.rc3
Bug#710473: bats: 0.3.1 status?
Hi! I have recently started playing with the idea of using BATS, and came across your ITP and RFS. However, for my use, I'd need a more recent version (0.3.1+). Could you update your packaging to that version? I'd be happy to review and sponsor it afterwards. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728591: ITP: riemann-c-client -- C language client library for the Riemann event stream processor
Package: wnpp Severity: wishlist Owner: Gergely Nagy alger...@madhouse-project.org * Package name: riemann-c-client Version : 1.0.1 Upstream Author : Gergely Nagy alger...@madhouse-project.org * URL : https://github.com/algernon/riemann-c-client/ * License : LGPL-3+ Programming Lang: C Description : C language client library for the Riemann event stream processor Riemann is a network event stream processor, intended for analyitics, metrics and alerting; and to glue various monitoring systems together. . This library provides a C language client, with a simple but convenient API, to connect to Riemann, send events and run queries against it. I already have the debianisation complete, it just needs to be uploaded. This is a dependency of the syslog-ng-incubator project which I also plan to upload shortly after syslog-ng 3.5 made it into unstable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728592: RFA: mikmod -- Portable tracked music player
Package: wnpp Severity: normal I request an adopter for the mikmod package. The package recently got a new upstream maintainer, and a new release has been made with quite a lot of important improvements (such as working ALSA support). Unfortunately, I lack the time to properly take care of the new upstream release and package it, so I'm looking for a someone to take it over (along with libmikmod, as they go hand in hand). The package description is: Mikmod is a very portable tracked music player which supports a wide variety of module formats including compressed sample Impulse Tracker modules. It also supports many archive formats, as well as on the fly decompression. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728593: RFA: libmikmod -- Portable sound library
Package: wnpp Severity: normal I request an adopter for the libmikmod package. It recently got a new upstream maintainer and new, much improved releases have been made, which should be packaged. I lack the time to take good care of the package, hence the request for a new maintainer. This goes hand in hand with the mikmod package, which is also up for adoption, and should be maintained by the same person or team. The package description is: This library is capable of playing samples as well as module files and was originally written by Jean-Paul Mikkers (MikMak) for DOS. It has subsequently been hacked by many hands and now runs on many Unix flavours. It uses the OSS /dev/dsp driver included in all recent kernels for output, and will also write wav files. . Supported file formats include mod, stm, s3m, mtm, xm, and it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Elmar Stellnberger estel...@elstel.org writes: Am 04.11.13 18:43, schrieb Paul Tagliamonte: On Mon, Nov 4, 2013 at 12:42 PM, Paul Tagliamonte paul...@debian.org mailto:paul...@debian.org wrote: On Mon, Nov 04, 2013 at 06:22:15PM +0100, Elmar Stellnberger wrote: Is it really a problem? If yes then I can add an exception for distributors like Debian. Perhaps you're interesting in reading our guidelines: http://www.debian.org/social_contract#guidelines point 8 is License Must Not Be Specific to Debian. We could possibly allow any distribution to distribute patches without notifying the original authors as far as the term distribution can be defined clearly and doubtlessly (i.e. to only apply this restriction to individuals and organizations who do not distribute their software for free to the public; if that would help us). That will not be possible, due to DFSG#3 (derived works): The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Which means that whoever gets the software through Debian MUST be able to redistribute it under the very same terms Debian did. Furthermore, there are many distributions derived from Debian, asking all of them to send you patches whenever they make the tiniest modification (even to packaging!) is not going to work, neither for you, nor for Debian, nor for any of the distributions based on it. I would strongly suggest you reconsider your license, or at least this requirement, as it will never, ever work as you expect it to: people will just not use your software, because requiring them to send patches back no matter what is so huge a pain in the backside that noone in their right mind will do it. It's a much smaller effort to find an alternative (like schroot, in this case) or roll your own. Furthermore, there's this part of the license: If you want to develop a separate branch of this program you need to ask the original authors for permission. That goes against DFSG#4, which permits the author to require distribution under a different name, but still requires the license to allow distributing patched versions. The quoted paragraph prevents that, so much so, that it's far too strict even for non-free: if we ever want to do a non-maintainer upload for whatever reason, it's not possible, because that may very well mean develop a separate branch, and thus require asking for permission. Furthermore, the quoted paragraph also has a loophole: it only requires one to ask the original authors for permission, it does not say that the permission needs to be granted too. In a strict reading of the text, just asking for permission and not waiting for an answer is ok. Even better, asking, but receiving a negative answer is still ok, because one asked. Going further: Distribution of the program by third parties must be done free of charge apart from fees for the physical reproduction of the data medium This goes against DFSG#1: The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. While this part may be okay for non-free, it definitely is a no-go for main. The exceptions given do not matter. The way distribution is defined is also a bit odd: The term distribution describes shipping of a given set of software and its documentation with adherent materials. So if I strip away parts of the software (like documentation), and publish that, does that count as distribution? Strictly reading the license: no, because adherent materials are not shipped with it. Availablity free of charge or costs includes tools, software and manuals needed to download or obtain the distribution in a finally usable state as well as the possibility to verify the integrity of the download securely but not general connectivity to the internet. This part is also quite vague. Lets imagine the following scenario: there's Joe Average user, installing GNU/Linux for the first time. He has absolutely no idea how to do it, so he buys a book about the topic. To install additional software, such as those covered by this license, he uses tools and techniques described in the manual, for which he paid for. In this case, the distribution is not allowed to let Joe Average install programs covered by this license, because he needed a paid-for manual to install the distribution and the software covered by the license in question. That's not going to work, either. However what I want is being noticed somehow about changed versions of my programmes. That's OK. It just means you need to upload to non-free. I hope that will not pose an unnecessary restriction to the re-distribution as the program may f.i. also be especially
Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Elmar Stellnberger estel...@gmail.com writes: S-FSL v1.3.3 uploaded at http://www.elstel.org/license/ Having clearly considered your critics I have published a reworked edition of S-FSL which should more strictly adhere to the terms of OSS-software. As you can understand and as I have already partially described there are still issues to me which discourage me from using an existing license like f.i. GPL or BSD. I wouldn't mind hearing the full explanation, because I honestly see far more issues with a new license than with using any of the existing, battle-tested ones. I will review the current (1.3.3) license, but that's about as much time as I'm willing to spend on it. I would recommend getting your license OSI[1] approved, to make things much easier for distributors like Debian. [1]: http://opensource.org/approval So, about that review: This program may be used free of charge. It has been designed as research work and comes without claim for fitness to any particular usage purpose and completely without warranty or any kind of liability such as lost revenues, profits, harm or damage of any kind. So far, so good. The program may be distributed by a third party given that the program is distributed in its original state completely without any kind of modifications or patches. This fails DFSG#3 and DFSG#4, but... If you need to re-distribute a patched version of this program you need to distribute the patches separately from the original so that the pristine version can be restored at any time. Any derived work must carry the name of the distributor, vendor or the product in its name (or a unique shothand for it) preceded by the original unchanged name of the software and its version. With this clarification, it passes DFSG#3 and DFSG4, but only barely. Modifications applied to this program may not affect the name, original version, copyright or any reference given to the authors such as their email addresses or their web presence and/or page in any part of the program or any files attached to the program. What exactly does this mean? Does that mean that if someone makes a modification in form of a patch, he can't add his copyright to the modified files? Or does that mean that they can't modifiy the original copyright license notes? Or, another question: what if a software under this license is included in something like Debian, where after the freeze, you're not supposed to upload new versions of the software, but the upstream webpage moves, or e-mail address changes, and for some reason, the maintainer wants to correct that in the package. She then has to modify the email addresses and URLs in the package, which would - in my reading - go against the license. You may only extend or modify this program given that you do also consent with the following terms. As far as you are not a public distributor you are oblidged to send a copy of your patches to the original authors referred to herein as the authors of the first version of the program as being listed in the changelog or program header whenever you publish or exchange your patches with other people. This is against DFSG6: no discrimination against fields of endeavor. It discriminates non-public distributors (whatever they may be), which makes the license non-free at best. It also is unclear about what a public distributor is (ok, that's explained a bit better later, see my comments there). Consider that Debian is not a legal entity, either. Software within Debian are distributed using a mirror network, some of which are operated by commercial entities. There are also private mirrors of Debian (my company has one too, for internal use), which would not be able to carry software under this license, since they're not public distributors. In this reading, it's not ok for non-free, either, as it cannot be distributed by Debian at all. Also, the wording is unclear: whenever you publish or exchange your patches with other people is very vague. If someone downloads the patches from a mirror, that can be considered exchange. Do I, as a distributor, need to send the same patch every time someone downloads it? Do I, as a developer, need to send the patch every time I send it in for internal review? Do I need to send work in progress patches too? (It's a patch, and I'm sharing it with collegues, after all!) That is unreasonable and unenforcable, and clearly goes against the spirit of free software. Furthermore, trying to force out such strict control of the software is very discouraging for potential contributors. By distributing patches you do consent apart from this that the original authors may incorporate your patches into future versions of this program. The patched parts of the program and the patches themselves will also become subject to this licensing and may even be used for free in other programs or in the same program under different licensing as soon
Bug#702131: syslog-ng childs segfault, eventfd2: Invalid argument
Right, this affects unstable too, as I wrote before, but in unstable, there's nothing in syslog-ng that needs fixing, except a recompile against a newer ivykis (= 0.36.1). However, 0.36.1 is only in experimental so far. Once wheezy is out, I'll upload it to unstable, and then syslog-ng can be recompiled against it, and this bug can then be closed for good. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705982: Wireless connection drops and will NOT re-connect -- Debian/Wheezy RC1 64 bit
Control: reassign -1 general Wayno bluefigto...@pobox.com writes: Package: Unknown When submitting a bug, please file it against either a package that does exist, or against the general pseudo-package, otherwise your report will not reach any maintainer at all, and will get lost unless reassigned (which I did now). If you do not know which package may be responsible, guessing or using general is still preferable than filing it against something that the BTS does not know about. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705998: unopkg: zotero-libreoffice-integration not working after upgrade
Control: reassign -1 libreoffice-common Michele Cane michele.c...@gmail.com writes: Package: unopkg Version: libreoffice-common When filing bugs, please make sure that the package mentioned in the Package field is the actual package, not the name of the binary (reportbug can assist with this), otherwise your report may end up misfiled, and will not reach the maintainers unless reassigned (which I did now). Thanks! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729575: syslog-ng-core: bogus date for kernel messages
Jakub Wilk jw...@debian.org writes: Package: syslog-ng-core Version: 3.5.1-1 syslog-ng has just logged this: 1961-02-05T20:15:59+01:00 borsuk kernel: usb 1-2: USB disconnect, device number 5 The timestamp is obviously bogus. My system date is correct, and non-kernel messages are logged with correct timestamps. According to my logs this started happening after the 3.3.9-1 - 3.5.1-1 upgrade. Likely not relevant, but are you using systemd? Do all kernel messages have bogus dates, or only a few ones? -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729991: syslog-ng-core uninstallable
Andrei POPESCU andreimpope...@gmail.com writes: On Mi, 20 nov 13, 00:19:49, Martin Bagge / brother wrote: [...] [] Starting system logging: syslog-ngUnable to determine how to monitor this file, follow_freq() unset and it is not possible to poll it with the current ivykis polling method. Set follow-freq() for regular files or change IV_EXCLUDE_POLL_METHOD environment variable to override the automatically selected polling method; filename='/dev/kmsg', fd='9' Error initializing message pipeline; failed! invoke-rc.d: initscript syslog-ng, action start failed. The file() thing here comes from the system() source. system() is expanded at run-time, depending on the OS/platform/whatever syslog-ng is running on. You can run syslog-ng --preprocess-into=/dev/stdout -s to see what it does with the config file. You'll find the file(/dev/kmsg) thing there. Can you tell me the kernel version you have? And does this happen in a container, VM, or on bare metal? As a quick workaround, you can remove the system() line from the config, and replacing it with whatever it expands to (see the command above), without the /dev/kmsg part. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729991: syslog-ng-core uninstallable
Martin Bagge / brother brot...@bsnet.se writes: On 2013-11-20 15:57, Gergely Nagy wrote: The file() thing here comes from the system() source. system() is expanded at run-time, depending on the OS/platform/whatever syslog-ng is running on. You can run syslog-ng --preprocess-into=/dev/stdout -s to see what it does with the config file. You'll find the file(/dev/kmsg) thing there. root@drake~# syslog-ng --preprocess-into=/dev/stdout -s root@drake~# echo $? 0 Right, looks like /dev/stdout is a thing in my shell. Can you try syslog-ng -s --preprocess-into=/tmp/processed-config.txt, and send the /tmp/processed-config.txt to me? Can you tell me the kernel version you have? And does this happen in a container, VM, or on bare metal? root@drake~# uname -a Linux drake 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux VM on top of VMware ESXI 4.1 Thanks, I'll test with that and see if I can reproduce the problem. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729991: syslog-ng-core uninstallable
Control: tag -1 upstream I managed to reproduce the problem using a 3.2 kernel, I know how to fix it, and I'm now working on a patch (it's not trivial to make the fix nice). I expect I'll be able to do a 3.5.2 release early next week, and the package will hit unstable a few hours later. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725668: syslog-ng: Space in ident ends up in msg instead of the program macro
Control: found -1 3.5.1-1
Allan Wind allan_w...@lifeintegrity.com writes:
If ident contains space (like fail2ban does) then the space and the ':'
separator ends up in msg. Configured syslog-ng with the following:
template tagged {
template(r_isodate=$R_ISODATE host=$HOST program=$PROGRAM pid=$PID
msg=$MSG\n);
};
destination debug {
file(/tmp/syslog-ng.log frac_digits(3) template(tagged));
};
log {
source(input);
destination(debug);
};
and logging an ident with space:
allan@pawan:~$ logger --tag 'test ' msg
results in this log event:
r_isodate=2013-10-07T03:09:46.652-04:00 host=pawan program=test pid=
msg=: msg
where I expected program = 'test ' and msg='msg' (no quotes).
Unfortunately, the BSD syslog protocol is weird and not exactly clear.
The RFC (3164) says this:
Most commonly, the first character of the CONTENT field that signifies
the conclusion of the TAG field has been seen to be the left square
bracket character ([), a colon character (:), or a space character.
This is explained in more detail in Section 5.3.
In practice, if we ignored whitespace between : and the program name,
we may break other, legacy applications. I would rather suggest fixing
fail2ban to not send a space.
I tried to take a look at the fail2ban sources, but couldn't find where
it puts the space into the message. Can you perhaps send me a sample?
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729575: syslog-ng-core: bogus date for kernel messages
Control: tag -1 upstream Found the issue, I'm pushing a fix into git, fixed package should hit unstable early next week latest. Thanks for the report and the assistance! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729575: syslog-ng-core: bogus date for kernel messages
Jakub Wilk jw...@debian.org writes:
* Gergely Nagy alger...@balabit.hu, 2013-11-15, 17:05:
syslog-ng has just logged this:
1961-02-05T20:15:59+01:00 borsuk kernel: usb 1-2: USB disconnect, device
number 5
The timestamp is obviously bogus. My system date is correct, and
non-kernel messages are logged with correct timestamps.
According to my logs this started happening after the 3.3.9-1 -
3.5.1-1
upgrade.
Likely not relevant, but are you using systemd?
Nope, the good old sysvinit.
Do all kernel messages have bogus dates, or only a few ones?
All of them.
Hm... I have not been able to reproduce it yet... can you change your
template to include ${.linux.timestamp} too, and send me a sample?
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729575: syslog-ng-core: bogus date for kernel messages
Jakub Wilk jw...@debian.org writes:
* Gergely Nagy alger...@balabit.hu, 2013-11-21, 14:42:
Hm... I have not been able to reproduce it yet...
I suspect the bug might be architecture-specific. I can reproduce it
on i386, but not on amd64.
Mhm, great, then I have a suspicion where the problem lies.
can you change your template to include ${.linux.timestamp} too, and
send me a sample?
With
template($YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC (${.linux.timestamp})
$MSG\n);
I've got this:
1961-02-05 14:29:55 (2278410933) fb1: VESA VGA frame buffer device
Good, good, so parsing is correct, computing the date is off, though.
Thanks, this narrows things down considerably!
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730314: ITP: syslog-ng-incubator -- Extra modules for syslog-ng
Package: wnpp Severity: wishlist Owner: Gergely Nagy alger...@madhouse-project.org * Package name: syslog-ng-incubator Version : git master (or whatever I call it by the time I get there) Upstream Author : BalaBit IT Security Ltd. * URL : https://github.com/balabit/syslog-ng-incubator * License : GPL2+ Programming Lang: C Description : Extra modules for syslog-ng The syslog-ng module incubator is a collection of tools and modules for syslog-ng that for one reason or the other, are not part of the official repository. This serves both as a staging ground for experimental modules, and as a repository of plugins that are not aimed at upstream inclusion. It's also an example of a third party syslog-ng module. The package would contain the Riemann destination, a trigger-source for debugging, a couple of new template functions and various small utilities. The packaging is reasonably complete, needs some polishing, and riemann-c-client[1] to get through NEW. Maintenance will be under the umbrella of the syslog-ng maintainers[2]. [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728591 [2]: https://alioth.debian.org/projects/syslog-ng/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730333: php-opencloud: VCS- links are 404
Source: php-opencloud Version: 1.6.0+dfsg-1 The VCS fields in the package reference a repository that does not exist. As far as I see, an s/pkg-opencloud/pkg-php/g; needs to be applied to it. (If anyone reading this on unknown-package@, php-opencloud just cleared NEW, and the maintainer is CC'd.) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722746: syslog-ng: afsmtp plugin not compiled in
Control: severity -1 wishlist Myron Davis myr...@gmail.com writes: Package: syslog-ng Version: 3.1.3-3 Severity: normal afsmtp (which provides the smtp() driver) in syslog-ng is not included or available via a package to add The SMTP driver is only available in 3.4, which will be available in unstable soonish. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635659: Any progress? (Was: Re: RFA: libdbi)
Hi! I was wondering if there's any progress in adopting the package, and packaging the new upstream version? syslog-ng could really use an updated (0.9.0+) version. If there's no progress, I would like to update the package to the new upstream version, and bring it under collab-maint/ on git.d.o. (And possibly adopt it, for the time being) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635659: Any progress?
Control: retitle -1 ITA: libdbi -- DB Independent Abstraction Layer for C Thomas Goirand z...@debian.org writes: On 01/15/2014 06:03 PM, Gergely Nagy wrote: Hi! I was wondering if there's any progress in adopting the package, and packaging the new upstream version? syslog-ng could really use an updated (0.9.0+) version. If there's no progress, I would like to update the package to the new upstream version, and bring it under collab-maint/ on git.d.o. (And possibly adopt it, for the time being) Hi, Please go ahead and adopt libdbi and libdbi-drivers. Since these 2 packages are high in the popcon, it is important that the work is done well, with care, taking enough time to do so. I did fill a RFA for that reason: I don't have time to maintain it correctly (I already maintain too many packages in Debian). If you adopt it and put it in the git of collab-maint, then great! Please keep me in the uploaders list then. They will be taken good care of. Since it is something we need at $work, I'll have enough time to do a good job. I'll keep you in uploaders for both packages. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635658: ITA
Control: retitle -1 ITA: libdbi-drivers -- Database drivers for libdbi As mentioned in #635659, I'll be adopting libdbi, and this package too. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635659: Any progress?
Prach Pongpanich prach...@gmail.com writes: I have been waiting for your response for long time. I can put you both as Uploaders. Or even better, I'd be happiest if I didn't have to adopt the package at all. If a 0.9.0 packaging can be done and upload within a week, that's fine with me. The less I need to do, the better. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635659: libdbi{,-drivers} maintenance
László Böszörményi (GCS) g...@debian.org writes: I'm the maintainer of sqlite and sqlite3 and back then I was the only syslog-ng maintainer. Thus when I saw libdbi and libdbi-drivers is up for adoption, started working on them. It was March, last year. When almost finished, I put it down, I don't know the reason. Still, yesterday I've made the last bits. Both build fine with pbuilder. You can grab them[1][2] for testing. May I be their maintainers, adding whoever wants it as uploader or is there anyone else to continue the packaging? As I said before, the less work I need to do, the better, so since the update is all done and seems to be well, I'm happy. I think the lot of you are enough to be Uploaders, I don't need to be there. So as far as I'm concerned, go ahead and upload! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736240: libdbi: debian/copyright file mistakes
Source: libdbi Version: 0.8.4-6 The debian/copyright file lists the license of libdbi as LGPLv2.1, while in reality, it is LGPLv2.1+. Also, there are a couple of files that have a diferent license (at least in 0.9.0-1), namely: * src/asprintf.c: This one says ripped from gcc - it would be nice to figure out the proper license for this. * src/atoll.c: This one is (C) MySQL AB, and is LGPLv2+, where the L is Library, not Lesser. The copyright file also seems to be a bit of a mess, you don't need to list *why* a person has copyright on a file. But this is just nit picking, and likely personal preference. The above three problems do need a fix, though. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch
Source: libdbi-drivers Version: 0.9.0-1 Severity: grave Justification: renders package unusable libdbi1 0.9.0-1 is built with a multi-arch, and will search for drivers in a multi-arch directory, but the binaries produced from libdbi-drivers still produce packages that use the old, non-multiarch directory. This renders any software using libdbi unusable, as they will not be able to find drivers. (Originally reported by Matt Zagrabelny mzagr...@d.umn.edu on the syslog-ng mailing list) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD
Source: sysvinit Version: 2.88dsf-50 Severity: serious The change introduced in sysvinit 2.88dsf-50, which turns /etc/init.d/skeleton into a script that has /lib/init/init-d-script as interpreter fails on kFreeBSD, because on that platform, interpreters cannot be other scripts. To demonstrate: ,[ test.sh ] | #!/lib/init/init-d-script | DAEMON=/bin/uname ` On linux, running ./test.sh prints the usage. On kFreeBSD (as tested locally and on falla.d.o), it prints nothing, because the #! line will be ignored, it being a script and all. If you want to do this kind of thing, you will either need a binary wrapper at least on kFreeBSD, or you'll need to use sourcing. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD
Petter Reinholdtsen p...@hungry.com writes: [Gergely Nagy] The change introduced in sysvinit 2.88dsf-50, which turns /etc/init.d/skeleton into a script that has /lib/init/init-d-script as interpreter fails on kFreeBSD, because on that platform, interpreters cannot be other scripts. Oh. I tested on Linux and Hurd, and did not imagine that kFreeBSD was that different from these two. :) It's Linux (since 2.6), Hurd and Minix being different from anything else :) If you want to do this kind of thing, you will either need a binary wrapper at least on kFreeBSD, or you'll need to use sourcing. Right. Back to the drawing board. :) Can you test this construct instead of #!/lib/init/init-d-script: #!/bin/sh if [ true != $INIT_D_SCRIPT_SOURCED ] ; then set $0 $@; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script fi I can try it tomorrow or so. If you want, you can try it on the kfreebsd porter boxes, it's easily reproducible there. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.
Sebastian Ramacher sramac...@debian.org writes: Package: syslog-ng-core Version: 3.5.6-1 Severity: grave Justification: renders package unusable Today the upgrade from 3.5.5-2 to 3.5.6-1 failed with: | Processing triggers for syslog-ng-core (3.5.6-1) ... | Job for syslog-ng.service canceled. | invoke-rc.d: initscript syslog-ng, action stop failed. | dpkg: error processing package syslog-ng-core (--configure): | subprocess installed post-installation script returned error exit status 1 Uncommenting invoke-rc.d syslog-ng stop || exit $? in line 6 of the postinst script and running apt install -f fixes the issue and lets the installation complete. I've also seen this issue while installing syslog-ng-core for the first time on another system. Both systems are running systemd if that matters. Let me know if you want more info. My other system waits to be upgraded. What does systemctl status syslog-ng.service print? -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757903: [Syslog-ng-maintainers] Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.
% systemctl status syslog-ng.service; dpkg-reconfigure syslog-ng-core syslog-ng.service - System Logger Daemon Loaded: loaded (/lib/systemd/system/syslog-ng.service; enabled) Active: active (running) since Tue 2014-08-12 20:42:04 CEST; 1s ago Docs: man:syslog-ng(8) Main PID: 24163 (syslog-ng) CGroup: /system.slice/syslog-ng.service └─24163 /usr/sbin/syslog-ng -F Aug 12 20:42:04 mercury2 systemd[1]: Started System Logger Daemon. Aug 12 20:42:04 mercury2 systemd[1]: Started System Logger Daemon. + [ configure = triggered ] + dpkg-trigger register-syslog-ng-plugin + deb-systemd-helper unmask syslog-ng.service + deb-systemd-helper --quiet was-enabled syslog-ng.service + deb-systemd-helper enable syslog-ng.service + [ -x /etc/init.d/syslog-ng ] + update-rc.d syslog-ng defaults 10 90 + exit 0 Processing triggers for syslog-ng-core (3.5.6-1) ... + [ triggered = triggered ] + invoke-rc.d syslog-ng stop Job for syslog-ng.service canceled. invoke-rc.d: initscript syslog-ng, action stop failed. + exit 1 dpkg: error processing package syslog-ng-core (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: syslog-ng-core I was suspecting a systemd rate limit at first, but the upgrade that failed today didn't include any other packages shipping anything systemd related. See the attached history.log for the packages involved in the failing upgrade. Turns out this is a known issue with systemd and socket activated services (such as syslog-ng), see #736258 and #751744. However, we do not use the recommended --restart-after-upgrade mechanism, and I'm unsure whether that would fix the issue. Nevertheless, I have a far better idea of what is happening, and will try to reproduce the issue locally. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757903: [Syslog-ng-maintainers] Bug#757903: Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.
Control: reassign 757903 dh-systemd Control: forcemerge 751741 757903 Control: affects + 751741 syslog-ng-core Gergely Nagy alger...@balabit.hu writes: Turns out this is a known issue with systemd and socket activated services (such as syslog-ng), see #736258 and #751744. However, we do not use the recommended --restart-after-upgrade mechanism, and I'm unsure whether that would fix the issue. I'm changing syslog-ng-core to use --restart-after-upgrade, but that will likely not solve the problem completely (although I have not been able to reproduce it locally), so I'm reassigning the bug to dh-systemd, and merging it with other similar issues. 3.5.6-2 will likely hit unstable by tonight, I would be very interested in hearing whether the problem persists with that version. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745014: src:syslog-ng: please update build-depends from libjson0-dev to libjson-c-dev
Ondřej Surý ond...@debian.org writes: the json-c upstream has dropped an compatibility layer from libjson0(-dev) to libjson-c2(-dev) in current upstream release. Please update your build-depends from libjson0-dev to libjson-c-dev. Thanks for the notice, it will be corrected with the next syslog-ng upload. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747020: syslog-ng-core: Add /var/log/error to /etc/logrotate.d/syslog-ng
Facundo Aguirre facu...@creativadigital.com.ar writes: I think that /var/log/error should be in /etc/logrotate.d/syslog-ng like all the others files that are managed by the default configuration of syslog-ng-core. Thanks for noticing this omission, it will be fixed in the next upload! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744182: syslog-ng: include option should be befor the log paths in the main syslog-ng.conf file
jdossan...@docs.homelinux.org writes: The @include /etc/syslog-ng/conf.d/ option is on the bottom of the syslog-ng.conf file, but it should be befor the log paths, as example: Good catch, I'll consider updating the default config with the next syslog-ng upload. Thanks for the suggestion! (Putting the includes at the end had other, beneficial properties, so moving them further up isn't as straightforward as one might imagine. It can easily break existing configurations, which is something I'd rather avoid. But I'll explore my options anyway!) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds edmo...@debian.org writes: riemann-c-client Rebuilt by hand successfully against protobuf-c 1.0.0~rc2-1 from experimental. Has an unversioned build dependency on libprotobuf-c0-dev. This needs to be updated to libprotobuf-c-dev eventually. I can switch that to libprotobuf-c-dev | libprotobuf-c0-dev in the next upload (I'd like to be able to compile the package on wheezy without changes, hence the alternative). Since I just released a new upstream version of the library, I'll be doing an upload at some point anyway, I'll try to make it so that binNMUs won't be required after. Has a build dependency on protobuf-c-compiler and runs protoc-c during the build. No protoc-c generated symbols are exported by libriemann-client0. The libriemann-client-dev package exports the following header files generated by protoc-c: /usr/include/riemann/proto/riemann.pb-c.h However, I have not found any packages in the Debian archive which utilize this file. The various riemann-c-client headers in /usr/include/riemann include proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from syslog-ng-incubator) that uses the library, thus, the generated header too, transitively. I would recommend that the upstream developers ship a .proto file instead. I'd rather not ship a .proto file, if at all possible. I'll see if I can hide it completely. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds edmo...@debian.org writes:
The various riemann-c-client headers in /usr/include/riemann include
proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
syslog-ng-incubator) that uses the library, thus, the generated header
too, transitively.
Ah, right. From a brief look at the source code for that module it
looks like it doesn't require a (bin-)NMU at all, if I'm understanding
the libriemann-client API correctly.
Yep, I agree. syslog-ng-incubator should not need a bin-NMU, as it uses
everything through the libriemann-client API, and never touches the
protobuf structures directly.
I would recommend that the upstream developers ship a .proto file
instead.
I'd rather not ship a .proto file, if at all possible. I'll see if I can
hide it completely.
This would eliminate the problem, too.
It looks like you typedef the structures generated by protoc-c and wrap
them in your own API, e.g. from riemann/query.h:
#include riemann/proto/riemann.pb-c.h
typedef Query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
(Query is from typedef struct _Query Query in riemann.pb-c.h.)
If your API callers always use the *_new(), *_free(), etc. functions and
never try to dereference or calculate sizeof() on the wrapped struct's
it might be possible to remove the #include of the .pb-c.h file and
change your typedef to, e.g.:
typedef struct _Query riemann_query_t;
And then have riemann_query_t be an opaque type. Though this depends
on protoc-c continuing to generate structure tags with leading
underscores, which may not always be the case. (I've wanted to get rid
of the leading underscores for a while now.)
(Similiarly for the other riemann_*_t types that wrap protoc-c generated
structures.)
It might also be possible to wrap the structure types generated by
protoc-c in your own opaque structure type and expose that wrapper type
via your API. Something like:
typedef struct riemann_query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
(In riemann/query.h.)
#include proto/riemann.pb-c.h
struct riemann_query {
Query query;
};
/* rest of the implementation... */
(In lib/riemann/query.c.)
That's a bit uglier since you have to update accesses to go via the
wrapper but would provide the maximum amount of insulation between the
libriemann-client API and the underlying structures generated by the
protoc-c code generator.
I gave this some more thought, and there's a problem: while generating
riemann events and similar can be done with opaque types, if I do a
query, then I want to access the results, and to do that with opaque
types would mean I need a lot of getter functions (and an API + ABI
bump). So I'll stick to how it is done today, for the foreseeable
future.
But I'll keep your suggestions in mind in case I end up writing another
library that uses protobuf, I'll hide the protobuf stuff deeper then! :)
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755887: ITP: adderall -- a miniKanren implementation in Hy
Package: wnpp Severity: wishlist Owner: Gergely Nagy alger...@madhouse-project.org * Package name: adderall Version : 0.1.2 Upstream Author : Gergely Nagy alger...@madhouse-project.org * URL : https://github.com/algernon/adderall * License : LGPL Programming Lang: Hy Description : a miniKanren implementation in Hy This is a dependency of Hydiomatic, a Hy code transformer. But it's useful in its own right too. I've yet to come up with a reasonable long description, though. The module will be packaged under the umbrella of pkg-hy, along with its dependency (monaxhyd) and Hydiomatic. Binary packages created will likely be called python-hy-adderall and python3-hy-adderall. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755212: transition: protobuf-c
Robert Edmonds edmo...@debian.org writes:
Emilio Pozuelo Monfort wrote:
On 18/07/14 22:19, Robert Edmonds wrote:
* The header file (protobuf-c.h) which compiled .pb-c.h files must
include. This is shipped in the libprotobuf-c0-dev package
(protobuf-c 1.0.0), or the libprotobuf-c-dev package (protobuf-c
= 1.0.0). (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which
smoothes the transition for packages with an unversioned
build-dependency on libprotobuf-c0-dev.)
I just realized that that's not going to work, because the old
libprotobuf-c0-dev is still available, and so packages that build-depend on
that
will get libprotobuf-c0-dev. So they'll need sourceful uploads to
build-depend
on the new (unversioned) libprotobuf-c-dev.
Hi, Emilio:
Are you sure about that? protobuf-c-compiler has:
Depends: ${shlibs:Depends}, ${misc:Depends}, libprotobuf-c-dev (=
${binary:Version})
I believe the problem arises when you (build-)depend on
libprotobuf-c0-dev, without protobuf-c-compiler. That happened with
riemann-c-client:
* I changed the build-dependency to libprotobuf-c-dev |
libprotobuf-c0-dev + protobuf-c-compiler.
* On unstable, that correctly pulled in libprotobuf-c-dev
* Headers were generated using the new protobuf-c-compiler
* The libriemann-client-dev package still had a dependency on
libprotobuf-c0-dev, though.
* syslog-ng-incubator build-depends on libriemann-client-dev, which
pulled in libprotobuf-c0-dev and libprotobuf-c1!
* syslog-ng-incubator FTBFS'd because of the generated header
conflicted.
I ended up changing the libriemann-client-dev dependency to
libprotobuf-c-dev, and all is well.
So another thing to pay attention to is transitive build-dependency, as
that can - and will - break if one's not forcing libprotobuf-c-dev onto
the system.
I think all of the packages I listed in my original email had a
build-dep on either protobuf-c-compiler only, or protobuf-c-compiler and
libprotobuf-c0-dev. (I don't think there are any with just
libprotobuf-c0-dev.)
Not directly, but transitively, syslog-ng-incubator build-depends on
libriemann-client-dev, which depended on libprotobuf-c0-dev only,
without protobuf-c-compiler. I'm not sure if there are other packages
like this, but the riemann-c-client + syslog-ng-incubator combo has been
taken care of.
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739932: aalib: FTBFS with clang instead of gcc
Hi! Arthur Marble art...@info9.net writes: Using the rebuild infrastructure, your package fails to build with clang (instead of gcc). I checked the patch, but it returns 2, while the comment above the function says that it should return 0 on failure, and it is used as such later. Returning 2 there will result in buggy behaviour. I'll change it to return 0, and upload a fixed version in a couple of hours. Thanks for the bug report and the effort! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763725: git-flow: Bad variable name when space characters in path
Peter van der Does pe...@avirtualhome.com writes: On Thu, 02 Oct 2014 09:30:33 +0200 Jeremie Burtin jere...@jeremieburtin.fr wrote: Package: git-flow Version: 1.7.0-1 Severity: grave Tags: upstream Justification: renders package unusable Hi, When trying to perform git flow feature start feature_name, the script fails with a Bad variable name error. It seems to come from the fact the path to the directory where I'm working contains space characters (ie : 2 - Developpement) The same repository in another path with no space does not fail. This was a bug in version 1.7, it's fixed in version 1.8. P.S. I develop git-flow AVH Edition, but do not maintain the Debian package. Thanks for the report, and the heads-up on the fix being available in 1.8! I'll update the Debian package today. -- |8] pgpUWAd0lnz5U.pgp Description: PGP signature
Bug#760426: [systemd] Logs gone after moving to systemd
Control: retitle -1 syslog-ng: Remove dangling syslog.service symlink in preinst Control: tag -1 help The same dance will need to be done for syslog-ng-core (which ships syslog-ng.service) that rsyslog will be doing (see #741496). It's blocked until the proper steps to do the syslog.service transfer are figured out. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727649: syslog-ng memory leak when using templated filenames and rewrite rules
Control: forwarded -1 https://github.com/balabit/syslog-ng/issues/308 Control: tag -1 upstream Control: found -1 3.5.6-2 Control: found -1 3.6.1-1 I managed to reproduce the problem on the latest upstream version too, and forwarded it upstream. During my tests, it seemed that the unix-stream() source file was opened many many times, which would easily explain the leak. Can you check what happens in your case? Also, does the problem persist if you use unix-dgram() for /dev/log, instead of unix-stream()? -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768634: ITA: propellor -- property-based host configuration management in haskell
Control: retitle -1 ITA: propellor -- property-based host configuration management in haskell I intend to adopt propellor. I'm starting to use it at work, and at home too, would be a shame to let it fall out of Debian. It's also a great excuse to learn more about Haskell packaging. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703639: [Syslog-ng-maintainers] Bug#703639: kill -HUP $(cat /var/run/syslog-ng.pid) can cause duplicate logging issues
Evgeni == Evgeni Golov evg...@debian.org writes: Evgeni Hi, Evgeni On Fri, Mar 22, 2013 at 03:59:11PM +0100, Gergely Nagy wrote: * Fixing the configuration and reloading gets things back in order, no matter how many times messages were duplicated before. Evgeni I have a heavily customized config, which does not throw any errors, Evgeni but triggers the issue on a wheezy box. Evgeni The config is for a central log-server, which gets syslog via UDP from Evgeni quite a few hosts and sorts these accordingly. Every day at logrotate Evgeni a SIGHUP is issued and my /var/log gets full. The ratio is about 1 real Evgeni message to 3000 (yes, three thousand!) duplicates :/ Evgeni A real restart solves the issue. Evgeni I hope this is helful for you to track down the issue. I didn't have time to reproduce the problem yet, but I'm going to forward it upstream. Are you using the wheezy version of syslog-ng? If so, can you try the 3.5.6 backport from wheezy-backports, and see if the problem persists? (A lot of things that may result in this kind of behaviour have been fixed between 3.3.5 in wheezy and 3.5.6 in backports.) -- |8] signature.asc Description: PGP signature
Bug#769452: docker.io compat symlink removed
Joey == Joey Hess i...@joeyh.name writes: Joey propellor's docker support uses the docker.io command, but this Joey turns out to have been a deprecated compat symlink which was removed in Joey docker.io 1.3.1~dfsg1-2. Which has already migrated to testing. Joey This is fixed in propellor 0.9.2, which has not migrated and contains Joey other, unrelated changes. The commit fixing the problem is Joey 9755b761bb46bc40d19a2723165424a1f8a27cbb Joey I'm glad I don't have to worry about whether this is RC or how to fix Joey it. ;) The correct way is through t-p-u, I'll handle the paperwork ~tomorrow, if all goes well. And this is - in my opinion - not RC, because propellor is perfectly usable without docker support. Nevertheless, it's a trivial fix. -- |8] signature.asc Description: PGP signature
Bug#770801: RFA: libmongo-client -- Alternate C driver for MongoDB
Package: wnpp Severity: normal I am looking for a new maintainer for libmongo-client (both Debian and upstream, but they do not have to be the same person). It is an alternative C language driver for the MongoDB NoSQL database, used by both rsyslog and syslog-ng for their respective MongoDB supporting modules. The library and the packaging is - I believe - in reasonably good shape. The reason for RFA-ing is that I do not use neither the library, nor MongoDB anymore, but there are a fair number of users of it who deserve better maintenance than what I can provide. Description of the main package follows: Description-en: Alternate C driver for the MongoDB document-oriented datastore MongoDB is a high-performance, open source, schema-free document-oriented data store. . This library provides an alternative C language driver, focusing on stability, ease of use, striving to make the most common use cases as convenient as possible. . Among its features are: . * Well documented, easy, clean and stable API. * Support for asynchronous operation. * ReplicaSet support, with support for automatic reconnecting and discovery. * Safe-mode support, to optionally enable extra safety checks on writes. If interested, either in upstream or Debian maintenance, please contact me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]
Jörg == Jörg Frings-Fürst deb...@jff-webhosting.net writes: Jörg I am looking for a sponsor for my package libmongo-client Jörg Package name: libmongo-client Jörg Version : 0.1.8-2 As the former maintainer and upstream, there are a few issues I see with the packaging (also sent earlier in private mail, but repeating here in case someone was looking at the package and wanting to sponsor it). * Instead of disabling the watch file, if you tweak the regexp to only match upstream releases, then it will work, and not catch my old debian/ tags: , | version=3 | | https://github.com/algernon/libmongo-client/releases .*/libmongo-client-([\d\.]+)\.tar\.gz ` * The build: target was there for a reason. Without it, we will build the arch-indep stuff by default too, which is something we want to avoid. For example, it will FTBFS on buildds, because they do not install build-depends-indep. And we really don't want doxygen and graphviz in B-D, because those pull in a shitload of stuff, to build docs that will be discarded by buildds anyway. * Why move --dbg-package from DH_OPTIONS to an override? -- |8] signature.asc Description: PGP signature
Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]
Jörg == Jörg Frings-Fürst deb...@jff-webhosting.net writes: * The build: target was there for a reason. Without it, we will build the arch-indep stuff by default too, which is something we want to avoid. For example, it will FTBFS on buildds, because they do not install build-depends-indep. And we really don't want doxygen and graphviz in B-D, because those pull in a shitload of stuff, to build docs that will be discarded by buildds anyway. Jörg I fully agree with you. Jörg But where are the problem? The package has no FTBFS and I don't change Jörg your -arch / -indep division. Jörg Please can you specify your minds. Ah, yes, now I remember. This was done for backporting purposes, so the package could be built on older releases where sbuild didn't call build-arch yet, but used build. For unstable, dropping the build target as you did is fine, indeed. * Why move --dbg-package from DH_OPTIONS to an override? Jörg --dbg-package is only needed in dh_strip[1]. Yes. But it works fine in DH_OPTIONS too, without any ill side-effects, and is shorter there. (Personal thing, but I hate overrides, and if there's another way to do what I want, which isn't convoluted, I'd choose that) But override or DH_OPTIONS, in this case, doesn't matter. The updated package looks fine, good job! One thing you may wish to change is the Source: stanza in debian/copyright. While I intend to restore the git URL there (I just need to reinstall cgit), it currently doesn't work, and github is the canonical one nowadays. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772464: unblock: propellor/0.9.1.1 (pre-approval)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi! I'd like to upload propellor 0.9.1.1 (version pending approval from Joey Hess) to testing-proposed-updates to fix #769452, and adopt the package (#768634). It can't go via unstable, because that has 0.9.2 already, with unrelated changes. The source diff is attached. unblock propellor/0.9.1.1 -- |8] diff --git a/debian/changelog b/debian/changelog index c580b3b..e1cac4b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,15 @@ +propellor (0.9.1.1) testing-proposed-updates; urgency=medium + + [ Joey Hess ] + * Docker: Stop using docker.io; that was a compat symlink in +the Debian package which has been removed in docker.io 1.3.1~dfsg1-2. +(Closes: #769452) + + [ Gergely Nagy ] + * New maintainer. (Closes: #768634) + + -- Gergely Nagy alger...@madhouse-project.org Sun, 07 Dec 2014 15:14:05 +0100 + propellor (0.9.1) unstable; urgency=medium * Docker: Add ability to control when containers restart. diff --git a/src/Propellor/Property/Docker.hs b/src/Propellor/Property/Docker.hs index d9d5f19..5a7a084 100644 --- a/src/Propellor/Property/Docker.hs +++ b/src/Propellor/Property/Docker.hs @@ -567,7 +567,7 @@ readIdentFile cid = fromMaybe (error bad ident in identFile) . readish $ readFile (identFile cid) dockercmd :: String -dockercmd = docker.io +dockercmd = docker report :: [Bool] - Result report rmed
Bug#773168: [Syslog-ng-maintainers] Bug#773168: remove afsql from default modules
Control: reassign -1 syslog-ng-core Control: forcemerge -1 650814 Matus == Matus UHLAR - fantomas uh...@fantomas.sk writes: Matus the module afsql is listed as default, although split into different Matus package. That causes syslog complain about missing default module everytime Matus it's reloaded. Please remove the module from list of default Matus modules. This is the same as #650814, which has been fixed in syslog-ng = 3.4 (and thus in testing and sid, and in wheezy-backports too). There are no plans to fix the issue in the 3.3 branch. If you wish to stick with 3.3 (and not use 3.5 from backports), I'd recommend either installing syslog-ng-mod-sql, or passing --default-modules to syslog-ng, to override its default. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776937: dpatch: please make the build reproducible
Chris == Chris Lamb la...@debian.org writes: Chris While working on the reproducible builds effort [1], we have noticed Chris that dpatch could not be built reproducibly. Thanks for the patch, I will apply it, and upload the fixed package soonish. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783689: bustle-pcap: Manual is in the wrong package
Source: bustle Version: 0.4.7-3 With bustle-pcap being moved out into a separate package, the corresponding manual page should have been moved too. But it remained in the original bustle package (noticed by lintian). Please fix that at some point. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783694: mrrescue: Small suggestion for the packaging
Source: mrrescue Version: 1.02c-1 Severity: wishlist Hi! I have a small suggestions regarding the mrrescue packaging: you can work around debhelper bug #719359 in a different way: put the files in debian/data/, and change debian/mrrescue.install to search for the script to run the game and the desktop file in debian/data/ instead of debian/. This allows you to get rid of a lintian override, and the dh_installinit override in debian/rules too. Just a suggestion, feel free to close this report if you disagree. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787696: syslog-ng-core: syslog-ng not supporting RFC5424
Package: syslog-ng-core Version: 3.6.1+git20141206-g4d90138-4 Severity: important Owner: Michael Bushey mich...@realtymogul.com (Submitting on behalf of Michael Bushey) Dear Maintainer, From a remote machine, this does not work: logger --tcp --port 514 -n l01 --tag scrub -p 6 Scrub test from logger This does work: logger --rfc3164 --tcp --port 514 -n l01 --tag scrub -p 6 Scrub test from logger ii bsdutils 1:2.26.2-5amd64 basic utilities from 4.4BSD-Lite What led up to the situation: Upgraded from bsdutils 1:2.25.2-6 to 1:2.26.2-5 What exactly did you do (or not do) that was effective (or ineffective): added --rfc3164 to logger I just upgraded syslog-ng to 3.6.1 in an attempt to fix the problem, 3.5.6 did the same thing. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.0.4-x86_64-linode57 (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 syslog-ng-core depends on: ii init-system-helpers1.23 ii libc6 2.19-18 ii libcap21:2.24-8 ii libevtlog0 0.2.12-7 ii libglib2.0-0 2.44.1-1 ii libivykis0 0.36.2-1 ii libnet11.1.6+dfsg-3 ii libpcre3 2:8.35-5 ii libssl1.0.01.0.2a-1 ii libsystemd0215-18 ii libwrap0 7.6.q-25 ii syslog-ng-mod-journal 3.6.1+git20141206-g4d90138-4 ii util-linux 2.26.2-5 Versions of packages syslog-ng-core recommends: ii logrotate 3.8.7-2 Versions of packages syslog-ng-core suggests: ii syslog-ng-mod-amqp 3.6.1+git20141206-g4d90138-4 ii syslog-ng-mod-geoip 3.6.1+git20141206-g4d90138-4 pn syslog-ng-mod-graphite none ii syslog-ng-mod-json 3.6.1+git20141206-g4d90138-4 ii syslog-ng-mod-mongodb 3.6.1+git20141206-g4d90138-4 ii syslog-ng-mod-redis 3.6.1+git20141206-g4d90138-4 pn syslog-ng-mod-riemann none ii syslog-ng-mod-smtp 3.6.1+git20141206-g4d90138-4 ii syslog-ng-mod-sql 3.6.1+git20141206-g4d90138-4 ii syslog-ng-mod-stomp 3.6.1+git20141206-g4d90138-4 -- no debconf information -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774351: sbuild: patch to fail when hooks fail
Hi!
A friend of mine recently ran into this issue too, so I tried to come up
with a quick dirty patch to make hooks abort the build if they fail. I
haven't tested it yet, mind you. In any case, patch is attached. When I
hear back from either my friend, or from anyone reading this, that the
patch works, I'll clean it up and resubmit.
--
|8]
From 2fc906196c67cb71fb79f8e517b28d830f59d4fc Mon Sep 17 00:00:00 2001
From: Gergely Nagy alger...@madhouse-project.org
Date: Fri, 29 May 2015 09:01:24 +0200
Subject: [PATCH] Sbuild::Build: Abort when a hook fails
Signed-off-by: Gergely Nagy alger...@madhouse-project.org
---
lib/Sbuild/Build.pm | 48 ++--
1 file changed, 30 insertions(+), 18 deletions(-)
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index cda5cf3..00513a7 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -367,9 +367,11 @@ sub run_chroot_session {
# Run pre build external commands
$self-check_abort();
- $self-run_external_commands(pre-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+my $returnval;
+ $returnval = $self-run_external_commands(pre-build-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
$self-check_abort();
if (!$session-begin_session()) {
@@ -512,9 +514,10 @@ sub run_chroot_session_locked {
# Run specified chroot setup commands
$self-check_abort();
- $self-run_external_commands(chroot-setup-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+ my $returnval = $self-run_external_commands(chroot-setup-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
$self-check_abort();
@@ -702,9 +705,11 @@ sub run_fetch_install_packages {
# Run specified chroot cleanup commands
$self-check_abort();
- $self-run_external_commands(chroot-cleanup-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+ my $returnval = $self-run_external_commands(chroot-cleanup-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self-check_abort();
if ($self-get('Pkg Status') eq successful) {
$self-log_subsection(Post Build);
@@ -715,9 +720,11 @@ sub run_fetch_install_packages {
# Run post build external commands
$self-check_abort();
- $self-run_external_commands(post-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+ my $returnval = $self-run_external_commands(post-build-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self-check_abort();
}
};
@@ -1473,9 +1480,12 @@ sub build {
return 0;
}
-$self-run_external_commands(starting-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+my $returnval;
+$returnval = $self-run_external_commands(starting-build-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self-check_abort();
$self-set('Build Start Time', time);
$self-set('Build End Time', $self-get('Build Start Time'));
@@ -1666,9 +1676,11 @@ sub build {
$self-log(Build finished at $finish_date\n);
-$self-run_external_commands(finished-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+my $retval = $self-run_external_commands(finished-build-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self
