Bug#704320: ITA: archipel packages -- Virtual Machine Orchestration
retitle 704320 ITA: archipel-core -- Virtual Machine Orchestration (Core) owner 704319 ! owner 704319 ! owner 704319 ! owner 704320 ! thanks As it seems I will have to manage several VMs over the network, I plan to adopt these packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704330: ITA: twitter-bootstrap -- HTML, CSS and JS toolkit from Twitter
retitle 704330 ITA: twitter-bootstrap -- HTML, CSS and JS toolkit from Twitter owner ! thanks I'm intend to use it in my projects and one of my friends already do. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703465: closed by Laszlo Boszormenyi (GCS) g...@debian.hu (Bug#703465: fixed in sqlite3 3.7.16-1)
On Wed, 2013-03-27 at 00:34 +, Philip Martin wrote: Are you planning to update testing before the release? Not in the general way. The previous uploads of 3.7.14 and 3.7.15 didn't migrate. Sure. Uploads migrate automatically if the following is true. There's no freeze, the package doesn't have any new RC bugs, day delays passed depending on the urgency of the upload (ten, five or two days). Currently testing is frozen. The current stable is 3.7.3-1 and doesn't have this bug. The current testing is 3.7.13-1 and it does have the bug. The next stable would be better with a patched 3.7.13 or 3.7.16. I can ask Release Managers. Freeze is in effect for a while and some days ago it became deep freeze. While this bugfix seems very important, you are the only one who's affected. Especially when you see that the testing version is available for stable as well. This bug can cause multi-threaded servers to create files with world read/write access. [...] Any files created by other threads in that apache process while the umask is 0 will be world read/write by default. Do you get any word writable files then or it's just a possibility? Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690067: Bug#702195: symlink conffiles are not supported, causing problems for dpkg on upgrade/removal and incorrect debsums reports
On Mon, 2013-03-25 at 23:34 +0100, Michael Biebl wrote: Am 25.03.2013 23:23, schrieb Michael Biebl: Am 09.03.2013 20:27, schrieb Laszlo Boszormenyi (GCS): On Wed, 2013-03-06 at 22:31 +0100, Michael Biebl wrote: On Thu, 2013-03-07 at 15:53 +0100, Gergely Nagy wrote: 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. Updated. It builds fine in Wheezy pbuilder and if you do agree, I'll upload it[1]. Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/syslog-ng_3.3.5-3.dsc are you planning on uploading those fixes to unstable as well? Answering your previous mail, -4 is uploaded and accepted to Wheezy by Julien. I plan to upload the fixes for unstable as well. I wait for the fix of #703639 [1]. Filed as normal severity, but duplicated messages after a SIGHUP reload can be RC as well. Algernon could reproduce it with a minimum configuration. As I know, he is working on the fix. I would like to wait for it and upload all the fixes at once for Sid and an other t-p-u for Wheezy. those fixes: of course for unstable the preinst has to be changed accordingly, as those are real files in sid and not symlinks. It's passed midnight here, so don't count on me; but as far as I remember, the fix includes a package version check already. Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703639 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703780: ITP: node-shelljs -- portable implementation of Unix shell commands on top of the Node.js API
Package: wnpp Owner: Laszlo Boszormenyi g...@debian.hu Severity: wishlist * Package name: node-shelljs Version : 0.1.2 Upstream Author : Artur Adib aa...@mozilla.com * URL : http://documentup.com/arturadib/shelljs * License : BSD-3-clause Programming Lang: JavaScript Description : portable implementation of Unix shell commands on top of the Node.js API You can use it to eliminate your shell script's dependency on Unix while still keeping its familiar and powerful commands. Node.js is an event-based server-side javascript engine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702195: unblock: syslog-ng/3.3.5-3
On Sun, 2013-03-17 at 15:37 +, Jonathan Wiltshire wrote: On Sun, Mar 17, 2013 at 03:06:17PM +, Jonathan Wiltshire wrote: On Sun, Mar 03, 2013 at 08:02:32PM +, Laszlo Boszormenyi (GCS) wrote: There are several important, RC bugfix over syslog-ng/3.3.5-2 in Wheezy. Approved the t-p-u upload, thanks. Actually, not. With the lack of threading and my trying to catch up on my mailbox, I hadn't yet seen the discussion about this one. Please prepare an updated t-p-u upload. Done. 3.3.5-4 is uploaded to t-p-u. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620602: ITP: python-googleapi -- Google API client for Python
package wnpp owner 620602 ! retitle 620602 ITP: python-googleapi -- Google API client for Python thanks Hi, I plan to package this in the coming days. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622960: Freeplane package + JMapViewer dependency
On Fri, 2013-03-15 at 21:13 +1100, Andrew Harvey wrote: I've just pushed some updates to the packaging to clean it up and updated to the latest upstream version. Cool! I was beginning to think about hijacking it. I'm happy to maintain it (unless upstream makes big changes which make harder to package). However a DD will need to sponsor it's upload if we want it included in Debian. Lastly, my apologies to Laszlo who offered to sponsor it's upload back in August last year, but I never got around to fixing up the package. Hopefully the latest updates I've made will mean it can be sponsored and uploaded into Debian. Sure, it looks OK. Still, there's some things to fix. Why do you use Java 6? Java 7 is in Debian now, see the openjdk-7-jre package. Copyright format is now official, please use its format line[1]. BSD-2 license text lines are too long, please use a 80 chars width one. It would be nice to 'beautify' debian/rules . The second line can show the file format if set to: '# -*- makefile -*-'. Override targets should be listed in the '.PHONY: ...' line at the end. The debian/watch is essentially empty, delete it or make use of it. Worst is that JMapViewer_Demo.jar is empty, contains only MANIFEST.MF . Is it an upstream build problem? Cheers, Laszlo/GCS [1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692830: preliminary Nemo package
Hi Tao, Long time no see. But to answer your question, the preliminary package is available from the git tree[1]. It contains 1.7.1 ATM, the source tar.gz is available from upstream[2]. Package builds and works as expected. Laszlo/GCS [1] git clone git://anonscm.debian.org/pkg-cinnamon/nemo.git [2] https://github.com/linuxmint/nemo/tags -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690067: Bug#702195: symlink conffiles are not supported, causing problems for dpkg on upgrade/removal and incorrect debsums reports
On Wed, 2013-03-06 at 22:31 +0100, Michael Biebl wrote: I think something like this should do: if [ $1 = upgrade ] dpkg --compare-versions $2 lt 3.3.5-3; then .. fi Done. On Thu, 2013-03-07 at 15:53 +0100, Gergely Nagy wrote: 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. Updated. It builds fine in Wheezy pbuilder and if you do agree, I'll upload it[1]. Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/syslog-ng_3.3.5-3.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690067: Bug#702195: symlink conffiles are not supported, causing problems for dpkg on upgrade/removal and incorrect debsums reports
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. Please re-check it from: dget -x http://www.barcikacomp.hu/gcs/syslog-ng_3.3.5-3.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690067: Bug#702195: symlink conffiles are not supported, causing problems for dpkg on upgrade/removal and incorrect debsums reports
On Tue, 2013-03-05 at 21:05 +0100, Michael Biebl wrote: On 03.03.2013 22:53, Michael Biebl wrote: Seeing the poor handling of symlinked conffiles, I'm wondering if we should also remove them for the other affected packages, which do that: [...] After a closer look, all those packages do *not* mark the symlinks as conffiles, so are not affected by this problem. So I wouldn't suggest any changes at this stage of the release. As for syslog-ng-core, I think the simplest solution for wheezy is to add the symlinks back to the package /etc/systemd/system/syslog.service /etc/systemd/system/multi-user.target.wants/syslog-ng.service but does *not* mark them as conffiles. + the usual cleanup of the existing conffiles via preinst. The first iteration is ready to check[1]. I don't recall previous conffiles, but on purge the files are removed. Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/syslog-ng_3.3.5-3.dsc -- 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
On Sun, 2013-03-03 at 09:37 +0100, Gergely Nagy wrote: 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. The first segment (static int grab_eventfd), doesn't seem to be present in the version bundled with 3.3.5 . The second segment can be applied clean. 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. It seems this doesn't apply to the Wheezy version. The mutex is locked for the while loop. The mutex unlock that the patch removes is not present here. 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). You mean let the fixes go in two step? It's OK from my side if you would like. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702170: ITP: zopfli -- zlib (gzip, deflate) compatible compressor
Package: wnpp Owner: Laszlo Boszormenyi g...@debian.hu Severity: wishlist * Package name: zopfli Version : git version Upstream Author : Lode Vandevenne lode.vandeve...@gmail.com * URL : http://code.google.com/p/zopfli/ * License : Apache-2.0 Programming Lang: C Description : zlib (gzip, deflate) compatible compressor Zopfli Compression Algorithm is a new zlib (gzip, deflate) compatible compressor. This compressor takes more time (~100x slower), but compresses around 5% better than zlib and better than any other zlib-compatible compressor we have found. -- 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
On Sun, 2013-03-03 at 17:17 +0100, Gergely Nagy wrote: Gergely Nagy alger...@balabit.hu writes: 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. Thanks for confirming my observations. I've prepared an update for t-p-u . Tested and builds fine in a Wheezy pbuilder chroot. Can it be uploaded? Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/syslog-ng_3.3.5-3.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702195: unblock: syslog-ng/3.3.5-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
thanks
Hi Release Team,
There are several important, RC bugfix over syslog-ng/3.3.5-2 in Wheezy.
First is virtual console differences between Linux and kFreeBSD[1]. It's
tty10 on the former and ttyva on the latter. Without fixing #697042 ,
syslog-ng would flood kFreeBSD logs with:
Error opening file for writing; filename='/dev/tty10', error='Operation not
supported (45)'
The default syslog-ng configuration used wrong path for mail related
logs, as noted in #692056 [2].
Don't use symlinked systemd configuration files, as noted in
#690067 [3]. This caused all short of problems as dpkg doesn't support
it.
Last but not least the one which affects the DSA team is #702131 [4].
The fix is to handle EINVAL as well for eventfd2 errors.
The fixes are small and usually one liners. Debdiff is attached.
Thanks,
Laszlo/GCS
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697042
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692056
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690067
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702131
diff -Nru syslog-ng-3.3.5/debian/changelog syslog-ng-3.3.5/debian/changelog
--- syslog-ng-3.3.5/debian/changelog 2012-05-13 00:47:21.0 +0200
+++ syslog-ng-3.3.5/debian/changelog 2013-03-03 19:22:00.0 +0100
@@ -1,3 +1,22 @@
+syslog-ng (3.3.5-3) testing-proposed-updates; urgency=low
+
+ [ Gergely Nagy alger...@madhouse-project.org ]
+ * Don't mark systemd symlinks in /etc as conffiles.
+ * Instead of installing systemd service file symlinks, install a
+conffile, that includes the real service file (closes: #690067).
+ * Do not forcibly remove the systemd service files, that code is not
+needed anymore.
+ * Use the standard /var/log/mail.{info,err,warn} location for the various
+mail-related logs (closes: #692056).
+ * Use /dev/ttyva on kFreeBSD as the target of the d_console_all
+destination (closes: #697042).
+
+ [ Laszlo Boszormenyi (GCS) ]
+ * Fix ivykis fallback on eventfd2 errors with the addition of
+ivykis_fallback_fix.patch (closes: #702131).
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu Sun, 03 Mar 2013 17:57:00 +0100
+
syslog-ng (3.3.5-2) unstable; urgency=low
[ Gergely Nagy alger...@madhouse-project.org ]
diff -Nru syslog-ng-3.3.5/debian/patches/ivykis_fallback_fix.patch syslog-ng-3.3.5/debian/patches/ivykis_fallback_fix.patch
--- syslog-ng-3.3.5/debian/patches/ivykis_fallback_fix.patch 1970-01-01 01:00:00.0 +0100
+++ syslog-ng-3.3.5/debian/patches/ivykis_fallback_fix.patch 2013-03-03 17:53:25.0 +0100
@@ -0,0 +1,31 @@
+Description: make ivykis properly fallback on eventfd2 errors
+ The Linux glibc eventfd() wrapper function (around the SYS_eventfd{,2}
+ system calls) returns EINVAL if it is given a nonzero flags argument
+ and SYS_eventfd2 (which is the variant of SYS_eventfd that takes a flags
+ argument) isn't implemented, while iv_event_raw was expecting to get
+ either ENOSYS or success.
+ .
+ Instead of falling back on SYS_eventfd by calling the eventfd() wrapper
+ again with a zero flags argument and then setting the O_NONBLOCK and
+ O_CLOEXEC flags by hand, disable use of eventfd on systems that have
+ SYS_eventfd but not SYS_eventfd2 as a minimally invasive fix for the
+ stable branches.
+ Taken from: https://github.com/buytenh/ivykis/commit/89f67f97477aeba24aebfc58ae1a17e5bea69724.patch
+Author: Lennert Buytenhek buyt...@wantstofly.org
+Bug-Debian: http://bugs.debian.org/702131
+Forwarded: not-needed
+Last-Update: 2012-12-09
+
+---
+
+--- syslog-ng-3.3.5.orig/lib/ivykis/modules/iv_event_raw.c
syslog-ng-3.3.5/lib/ivykis/modules/iv_event_raw.c
+@@ -91,7 +91,7 @@ int iv_event_raw_register(struct iv_even
+
+ ret = eventfd2(0, EFD_NONBLOCK | EFD_CLOEXEC);
+ if (ret 0) {
+- if (errno != ENOSYS) {
++ if (errno != ENOSYS errno != EINVAL) {
+ perror(eventfd2);
+ return -1;
+ }
diff -Nru syslog-ng-3.3.5/debian/patches/series syslog-ng-3.3.5/debian/patches/series
--- syslog-ng-3.3.5/debian/patches/series 2012-05-03 10:25:19.0 +0200
+++ syslog-ng-3.3.5/debian/patches/series 2013-03-03 17:48:08.0 +0100
@@ -1 +1,2 @@
no_make_in_debian.patch
+ivykis_fallback_fix.patch
diff -Nru syslog-ng-3.3.5/debian/rules syslog-ng-3.3.5/debian/rules
--- syslog-ng-3.3.5/debian/rules 2012-05-13 00:49:52.0 +0200
+++ syslog-ng-3.3.5/debian/rules 2013-03-03 18:52:18.0 +0100
@@ -26,7 +26,7 @@
# to it.
##
ifneq (,$(filter debug,$(DEB_BUILD_OPTIONS)))
- EXTRA_CONFIGURE_OPTS += --enable-debug
+EXTRA_CONFIGURE_OPTS += --enable-debug
endif
DEFAULT_MODULES = affile,afprog,afsocket,afuser,afsql,basicfuncs,csvparser,dbparser,syslogformat
@@ -129,10 +129,6 @@
override_dh_auto_install:
dh_auto_install
${MAKE} -C debian/build-tree/lib/ivykis install DESTDIR=$(CURDIR)/debian/tmp
- ln -sf /lib/systemd/system/syslog-ng.service
Bug#702131: syslog-ng childs segfault, eventfd2: Invalid argument
On Sun, 2013-03-03 at 18:30 +0100, Martin Zobel-Helas wrote: On Sun Mar 03, 2013 at 17:17:33 +, Laszlo Boszormenyi (GCS) wrote: On Sun, 2013-03-03 at 17:17 +0100, Gergely Nagy wrote: 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. Thanks for confirming my observations. I've prepared an update for t-p-u . Tested and builds fine in a Wheezy pbuilder chroot. Can it be uploaded? You should discuss that part with the release team rather than we me. My question went to Algernon (Gergely Nagy). For the last check of two things. 3.3.5-3 contains several RC fixes, not just the one for this. I don't know if it's a secret or not, but he is upstream of syslog-ng . Got ACK, package is uploaded. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698972: about php5-xhprof packaging
On Thu, 2013-02-21 at 16:22 -0500, Antoine Beaupré wrote: On 2013-02-02, Laszlo Boszormenyi (GCS) wrote: Please check it[1]. I'm open for any suggestions or packaging problems you may find. Here's a late review, sorry for the delay! No problem, there's no rush. It won't be part of Wheezy and Wheezy+1 is far to go. First thing, please sign your package with your PGP key. But I guess you know that - I thought you weren't a DD! :) I didn't want to reveal that! :) Then, why is there a git20130123 timestamp in there? Shouldn't we aim to package a stable release at first, then maybe a git snapshot in experimental? As far as I can remember, the stable release doesn't build. The fixes are mandatory from the git tree. Patches are not an option as there are too many changes to consider. The description in xhprof should probably have only the paragraph, so I would turn this: +1 on this. jquery should probably be removed from the package, which should have a +dfsg flag I can't show you proof, but as I know, embedded (F)OSS libraries can remain in the source until the following apply. The library is readable (ie, it's not compressed/obfuscated) and it's not installed as-is. If you check, jQuery*.js are readable and I don't include them in the binary. I take it you don't need a sponsor... :) Well, at least not now. :) I may leave Debian someday, but that won't be soon I hope. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699767: Processed (with 1 errors): ITA: ulogd -- The Netfilter Userspace Logging Daemon
Hi Maykel, On Tue, 2013-02-05 at 00:38 +0100, Maykel Moya wrote: Please take a look at bug 395302[1] and previous ITP[2]. I see. Your work have good parts, but contains trivial mistakes as well. In short, what's your plans? Do you want to do it yourself or let me to do it? In the latter, do you allow me to use parts of your works? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699767: ITA: ulogd -- The Netfilter Userspace Logging Daemon
On Tue, 2013-02-05 at 04:22 +0100, Maykel Moya wrote: El 05/02/13 03:22, Laszlo Boszormenyi (GCS) escribió: I see. Your work have good parts, but contains trivial mistakes as well. In short, what's your plans? Do you want to do it yourself or let me to do it? In the latter, do you allow me to use parts of your works? My plans are basically learn packaging by doing and trying to improve the current ulogd situation in Debian. A challenge for a newcomer. As you write, it'll be a big challenge for you. Easier and smaller packages would suit you better IMHO. I have no problem with you to use part of my works but with respect to the you-or-me thing, do you have any inconvenience with working together on this? Of course, I'll credit whatever I'll use from your work. We can work together, no problem. Still, I advise you to check and learn other, smaller packages as well. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698972: about php5-xhprof packaging
Hi Antoine, On Fri, 2013-02-01 at 16:19 -0500, Antoine Beaupré wrote: On 2013-01-26, Laszlo Boszormenyi (GCS) wrote: Are you interested to review it Antonie? Any progress here? Can you upload the package yourself or do you need a sponsor? If the latter, where can I review the package? Please check it[1]. I'm open for any suggestions or packaging problems you may find. PS: I noticed you Cc'd cont...@bugs.debian.org - I think it's usually preferable to Bcc it, otherwise replies of other people may end up sending garbage to it... I agree that Bcc is better. I've seen false mails sent to control@ on replies. On the other hand a simple Cc can be more visual that you sent the commands there. Regards, Laszlo/GCS [1] dget -x http://barcikacomp.hu/gcs/xhprof_0.9.2+git20130123-1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699123: about packaging python-sh
Hi Ben, How the packaging goes? I've a package, ready to be uploaded. But the ITP is yours, I only take over it if you all me to do so. The same is for python-srp , I may take over that ITP as well. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697054: ITP: pyro4 -- distributed object middleware for Python (RPC)
Package: wnpp Owner: Laszlo Boszormenyi g...@debian.hu Severity: wishlist * Package name: pyro4 Version : 4.17 Upstream Author : Irmen de Jong ir...@razorvine.net * URL : http://pypi.python.org/pypi/Pyro4/ * License : MIT Programming Lang: Python Description : distributed object middleware for Python (RPC) Pyro means PYthon Remote Objects. It is a library that enables you to build applications in which objects can talk to eachother over the network, with minimal programming effort. You can just use normal Python method calls, with almost every possible parameter and return value type, and Pyro takes care of locating the right object on the right computer to execute the method. It is designed to be very easy to use, and to generally stay out of your way. But it also provides a set of powerful features that enables you to build distributed applications rapidly and effortlessly. Pyro is written in 100% pure Python and therefore runs on many platforms and Python versions, including Python 2.x, Python 3.x, IronPython, Jython and Pypy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696470: php5-suhosin: php5-common make php5-suhosin defective
Hi Stefano, On Fri, 2012-12-21 at 10:00 +0100, stefano wrote: the package conflicts with php5-common 5.4.4-11 (the last of sid) but in aptitude the phpapi-20100525 (requests by php-suhosin) seems provided by php5-cgi 5.4.4-11 (for example). It is known and intentional. As php5-suhosin doesn't work with the current release of PHP5. Actually it never had a stable release that was worked with PHP 5.4, but upstream was working on it. Now s/he is missing for seven months. :( Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692797: unblock: python-greenlet/0.3.1-2.1
Hi Adam,
On Wed, 2012-12-19 at 19:55 +, Adam D. Barratt wrote:
On Sat, 2012-11-24 at 13:34 +, Adam D. Barratt wrote:
On Fri, 2012-11-09 at 23:08 +0100, Jelmer Vernooij wrote:
On Fri, 2012-11-09 at 06:08 +, Adam D. Barratt wrote:
It also itself FTBFS on a few architectures - see
https://buildd.debian.org/status/package.php?p=python-greenletsuite=wheezy
; armel and mips{,el} are regressions from the current testing package.
Thanks, I should've noticed that but hadn't. This is quite surprising
too, I don't see anything in the NMU that might be the cause of this.
I suspect the issue was already there - see #665890, which is also fixed
in sid already.
Laszlo, any chance of a fixed version?
The good is that upstream uses git, I could check the individual
commits. The bad is that the places where it FTBFS are assembly codes.
Upstream reworked that parts with the relevant C code as well. So it's
not easy, I'd say impossible for me to backport those changes. I don't
speak ARM nor Sparc ASM at least.
Would it be acceptable to let 0.4.0-1 migrate to Wheezy? It fixes all
the problems, in the archive since August without any problem. Last, but
not least it fixes several packaging problems as well.
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681549: Still present in 1.2.0-3
Hi Dane, On Fri, 2012-12-07 at 09:07 +, Dane Elwell wrote: This bug seems to still exist in CouchDB 1.2.0-3 update that was pushed out recently in Wheezy. It's caused by -2 . If you install -3 from scratch or delete /var/run/couchdb/ after -2 is stopped, it'll start normally. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692295: RFS: couchdb/1.2.0-2.1 [NMU] [RC]
Hi Dominik, On Tue, 2012-11-27 at 09:41 +0100, Dominik George wrote: Ask the person who wrote the RFS template generator. On the other hand, it's the Debian communities package. Maybe it should say my version xyz of package foo. If you take any offence on this, I really pity you. I don't take it as an offence, I was just curious why did you write it as your package. Why do you NMU immediately when I'm known for quick reply? First, because I can, second, because that's what the DDs at the BSP told me to do. It's always friendly to ask the maintainer first, s/he may have other things waiting in the queue and/or know a better way to achieve the same goal. Why do you ignore other fixes that I've mentioned to you in my previous mail? That includes collation with RMs. You did not mention any fixes. You mentioned a pending upload. I thought you were referring to the pending upload of 1.2.0-2 to *wheezy*, which does not include any fix for the issue we are discussing. I gave you the URL to check and you noted that it doesn't fix the bug you are referring to. For me, it was look like you checked the attached diff before answering. There's no need to do an extra upload to make an already uploaded version available in testing (Wheezy this time). A freeze exception is enough from a release manager. How about being a bit more specific next time? I also find that you failed to post any details of your fix to the BTS. Even though you may be known for quick reply, other parties might be interested in how to fix the problem beforehand. You even may want testers for a patch before uploading it. In any case, the BTS report log lacks any hint whatsoever about your fix. ? Please check again #682172 [1], it contains details and attached diff files. Sure, I'll CC everything next time to the relevant bugreports. Anyway, I've included your patch in -3, even if I'm not convinced about it. I think it would have been better to send HUP signal first, then after a specified time send TERM signal to couchdb. Abusing SIGHUP for shutdown in my opinion is a major violation of well-estabished standards that should be discussed with upstream. As noted, it's not CouchDB upstream, but the Erlang VM. It does not ignore SIGHUP itself, but inherit that mask from apt-get . The Erlang VM actually doesn't have any possibility to change the signal ignorance mask as I know. Thus even if I note it to upstream, it's a language barrier and known already. In conclusion, Debian is a community-effort. I am very convinced that no single person owns any part of it, so no single person should ever take offence on someone else helping them. I agree on this. As a community effort, it needs coordination. You missed to ask the maintainer first, that you've an RC bugfix, would s/he upload soon or an NMU would be better after twenty-four hours. Instead, you immediately ignored the maintainer and asked everyone for NMU sponsorship. I asked questions to learn what I can do better next time to prevent misunderstanding. It was you who make offence and even CC to a closed bugreport. If you had e-mailed your own patch for the problem to the BTS right when you wrote it, also mentioning that you are about to upload it, would have both solve the problem you see *and* saved me and the fellows at the BSP quite a few hours of work. A discussion was going on an other bugreport and you were given with an URL of that. You are right that only when I've learnt you are working on that issue. I had the presupposition that you'll check it and when you replied that doesn't fix the issue, I thought you did. Please note that you posted your tiny little hint about some pending upload only *after* you realized that we were doing work on the issue. I agree on this, I should have tag the bug as pending. The little hint about upload pending contained the URL with the attached diff and the information release managers are involved in discussion. Please also realize that Frank and I spent almost two full days on the issue, discussing with dpkg and apt developers and shell gurus all possible ways of solving this issue in a way that does *not* violate upstream's ideas of signal handling. Although you included the fix in the end, and although you claim to be *quick* at it, please try to recognize your fellow community members' work and also try to understand if they like to get credits for it. I do note others work in changelogs, see some quick examples[2][3][4]. About the SIGHUP change, you mentioned '[varacanero]', that I couldn't parse. On the other hand, you are noted in couchdb_sighup.patch as it was your work and I do honor it. Regards, Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682172 [2] http://packages.qa.debian.org/s/sqlite3/news/20120516T212014Z.html [3] http://packages.qa.debian.org/p/python-eventlet/news/20121117T144838Z.html [4]
Bug#692295: Not release critical
On Sun, 2012-11-25 at 10:34 +0100, Dominik George wrote: we are investigating this bug at BSP Essen. Please be noted that an upload is pending. Waiting for RM answer, see #682172 [1]. Regards, Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682172 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682172: unblock: couchdb/1.2.0-2
On Wed, 2012-11-21 at 19:36 +0100, Julien Cristau wrote:
On Tue, Nov 20, 2012 at 21:17:21 +, Laszlo Boszormenyi (GCS) wrote:
Thanks, I think that should be acceptable.
OK, -3 will be uploaded if you nod on the s/couchdb/$COUCHDB/ change.
See below.
- logrotate will properly own the rotated files.
OK, I guess. Though why is the dir owned by couchdb in the first place
instead of root?
It's common for daemons to own their logdir and logfiles, even weird
owners do exist. See Apache2, its logdir is root:adm /var/log/apache2/ ,
for Exim it's Debian-exim:adm /var/log/exim4/ . But for the former, see
MongoDB: mongodb:mongodb /var/log/mongodb/ ,
MySQL: mysql:adm /var/log/mysql/ , Redis: redis:redis /var/log/redis/ .
CouchDB uses the same, its logdir is couchdb:couchdb /var/log/couchdb/ ,
can't give you a special reason for that.
+--- couchdb-1.2.0.orig/etc/init/couchdb.tpl.in
couchdb-1.2.0/etc/init/couchdb.tpl.in
+@@ -102,6 +102,8 @@ stop_couchdb () {
+ # Stop the running Apache CouchDB process.
+
+ run_command $COUCHDB -d /dev/null
++while [ $(couchdb -s 2/dev/null | grep -c process) -eq 1 ]; \
++do echo -n .; sleep 1; done;
+ }
+
+ display_status () {
Slightly weird to use $COUCHDB everywhere except in this one place where
you write couchdb.
Tested on the CLI, then copied late in the evening. Will be:
++while [ $($COUCHDB -s 2/dev/null | grep -c process) -eq 1 ]; \
++do echo -n .; sleep 1; done;
Is it okay to upload -3 with the discussed changes?
Cheers,
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682172: unblock: couchdb/1.2.0-2
On Wed, 2012-11-21 at 21:44 +0100, Michael Biebl wrote: On 21.11.2012 21:39, Laszlo Boszormenyi (GCS) wrote: Tested on the CLI, then copied late in the evening. Will be: ++while [ $($COUCHDB -s 2/dev/null | grep -c process) -eq 1 ]; \ ++do echo -n .; sleep 1; done; Is it okay to upload -3 with the discussed changes? Thanks, that looks a bit better. My only concern now would be, that you can end up in a endless loop if the couchdb instance doesn't want to die. Can such a situation happen or will couchdb -d forcefully kill the processes automatically? I don't think it'll be forcefully killed, but not sure. I'm not good in Erlang. But I propose the following then just to be sure: RET=1; for i in $(seq 1 30); do status=`$COUCHDB -s 2/dev/null | grep -c process`; if [ $status -eq 0 ]; then RET=0; break; fi; echo -n .; sleep 1s; done; return $RET Should the time be increased or maybe decreased? Half a minute sounds acceptable for me, but you may think otherwise. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682172: unblock: couchdb/1.2.0-2
On Mon, 2012-11-19 at 11:07 +0100, Julien Cristau wrote:
On Mon, Nov 19, 2012 at 01:18:34 +, Laszlo Boszormenyi (GCS) wrote:
Agree. That's an other thing upstream should fix. However I don't think
that would happen soon, at least not for Wheezy. I'll ask about it.
Until then this sleep may fixes the majority (maybe all) of the
problems.
Why can't this be fixed in your init script if upstream won't fix it in
time?
Touché! First I thought it's not possible. 'couchdb -d' sends a signal
to the running process that it should stop. It returns immediately and
doesn't wait until it completely ends. Then found 'couchdb -s' which
display the status of the daemon. While it's not my initscript, I've
changed that to wait until the status is running.
Changes between the current Wheezy version and the planned 1.2.0-3
upload is attached.
In short, it fixes four RC bugs:
- now properly create a couchdb owned rundir,
- wait for complete stop of the daemon, and this allows to:
- purge the package properly,
- restart the service without failing,
- logrotate will properly own the rotated files.
Hope it's now ready to go and will have the promise to be unblocked when
its time comes.
Regards,
Laszlo/GCS
diff -Nur couchdb-1.2.0-1/debian/changelog couchdb-1.2.0-3/debian/changelog
--- couchdb-1.2.0-1/debian/changelog 2012-06-29 20:31:16.0 +0200
+++ couchdb-1.2.0-3/debian/changelog 2012-11-20 21:36:00.0 +0100
@@ -1,3 +1,17 @@
+couchdb (1.2.0-3) unstable; urgency=low
+
+ * Rework couchdb own run directory (updates: #681549).
+ * Wait until complete stop of service (closes: #692295).
+ * Use couchdb user for logrotate (closes: #652172).
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu Sun, 18 Nov 2012 12:24:24 +0100
+
+couchdb (1.2.0-2) unstable; urgency=low
+
+ * Make couchdb user own its run directory (closes: #681549).
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu Thu, 19 Jul 2012 20:13:25 +0200
+
couchdb (1.2.0-1) unstable; urgency=low
* New major upstream release (closes: #672141).
diff -Nur couchdb-1.2.0-1/debian/patches/couchdb_own_rundir.patch couchdb-1.2.0-3/debian/patches/couchdb_own_rundir.patch
--- couchdb-1.2.0-1/debian/patches/couchdb_own_rundir.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0-3/debian/patches/couchdb_own_rundir.patch 2012-11-18 21:32:47.0 +0100
@@ -0,0 +1,20 @@
+Description: Initscript creates RUN_DIR , make sure it's owned by couchdb
+ Use install to make COUCHDB_USER own the RUN_DIR being created.
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/681549
+Last-Update: 2012-11-18
+
+---
+
+--- couchdb-1.2.0.orig/etc/init/couchdb.tpl.in
couchdb-1.2.0/etc/init/couchdb.tpl.in
+@@ -83,7 +83,8 @@ run_command () {
+ start_couchdb () {
+ # Start Apache CouchDB as a background process.
+
+-mkdir -p $RUN_DIR
++test -e $RUN_DIR || \
++install -m 755 -o $COUCHDB_USER -g $COUCHDB_USER -d $RUN_DIR
+ command=$COUCHDB -b
+ if test -n $COUCHDB_STDOUT_FILE; then
+ command=$command -o $COUCHDB_STDOUT_FILE
diff -Nur couchdb-1.2.0-1/debian/patches/logrotate_as_couchdb.patch couchdb-1.2.0-3/debian/patches/logrotate_as_couchdb.patch
--- couchdb-1.2.0-1/debian/patches/logrotate_as_couchdb.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0-3/debian/patches/logrotate_as_couchdb.patch 2012-11-18 21:31:42.0 +0100
@@ -0,0 +1,16 @@
+Description: Use logrotate as couchdb user
+ Use su and create to make logfiles owned by couchdb
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/652172
+Last-Update: 2012-11-18
+---
+
+--- couchdb-1.2.0.orig/etc/logrotate.d/couchdb.tpl.in
couchdb-1.2.0/etc/logrotate.d/couchdb.tpl.in
+@@ -6,4 +6,6 @@
+compress
+notifempty
+missingok
++ su couchdb couchdb
++ create 0640 couchdb couchdb
+ }
diff -Nur couchdb-1.2.0-1/debian/patches/series couchdb-1.2.0-3/debian/patches/series
--- couchdb-1.2.0-1/debian/patches/series 2011-11-27 09:19:17.0 +0100
+++ couchdb-1.2.0-3/debian/patches/series 2012-11-20 21:35:33.0 +0100
@@ -1 +1,4 @@
force-reload.patch
+couchdb_own_rundir.patch
+logrotate_as_couchdb.patch
+wait_for_couchdb_stop.patch
diff -Nur couchdb-1.2.0-1/debian/patches/wait_for_couchdb_stop.patch couchdb-1.2.0-3/debian/patches/wait_for_couchdb_stop.patch
--- couchdb-1.2.0-1/debian/patches/wait_for_couchdb_stop.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0-3/debian/patches/wait_for_couchdb_stop.patch 2012-11-20 21:52:18.0 +0100
@@ -0,0 +1,20 @@
+Description: Wait for complete stop of CouchDB
+ Check if CouchDB is already stopped and wait for a second if not before
+ checking again.
+ .
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/692295
+Last-Update: 2012-11-20
+---
+
+--- couchdb-1.2.0.orig/etc/init/couchdb.tpl.in
couchdb-1.2.0/etc/init/couchdb.tpl.in
+@@ -102,6 +102,8 @@ stop_couchdb
Bug#682172: unblock: couchdb/1.2.0-2
On Mon, 2012-11-12 at 21:28 +, Adam D. Barratt wrote:
On Fri, 2012-10-12 at 05:22 +, Laszlo Boszormenyi (GCS) wrote:
On Thu, 2012-10-11 at 23:18 +0200, Julien Cristau wrote:
[ about CouchDB storing its PID file as root ]
Ping. Is this getting fixed?
Upstream knows about this issue, promised a fix which won't be easy as
I can remember. Now they are busy with releasing 1.3.0 and a bugfix
branch of 1.2.0 . Don't know exactly if it's included, but will ping
them.
Any news on that?
Nope. :( Upstream is still busy on how 1.3.0 should be released. I
don't get any answer as of yet.
Asking about upload permission of -3 targeting Wheezy with the attached
changes.
Fixes four RC bugs. The first one is that couchdb needs some time to
stop. Added three seconds wait time to stop in initscript and to postrm
(the latter comes from Ubuntu). Otherwise couchdb can't be restarted and
can't be purged.
The rundir is now created with the help of 'install', only if it doesn't
existed before.
Last, but not least the logrotate configuration is fixed. Now creates
and rotates logfiles as couchdb.
Regards,
Laszlo/GCS
diff -Nur couchdb-1.2.0-1/debian/changelog couchdb-1.2.0-3/debian/changelog
--- couchdb-1.2.0-1/debian/changelog 2012-06-29 20:31:16.0 +0200
+++ couchdb-1.2.0-3/debian/changelog 2012-11-18 21:11:08.0 +0100
@@ -1,3 +1,22 @@
+couchdb (1.2.0-3) unstable; urgency=low
+
+ * Rework couchdb own run directory (updates: #652172).
+ * Wait a bit for complete stop of service (closes: #692295).
+ * Use couchdb user for logrotate (closes: #652172).
+
+ [ Jason Gerard DeRose ]
+ * Added a short sleep delay in couchdb.postrm so couchdb is more likely to
+have actually terminated by the time we `deluser couchdb`, which is needed
+for `sudo apt-get purge couchdb` to work when couchdb is running
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu Sun, 18 Nov 2012 12:24:24 +0100
+
+couchdb (1.2.0-2) unstable; urgency=low
+
+ * Make couchdb user own its run directory (closes: #681549).
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu Thu, 19 Jul 2012 20:13:25 +0200
+
couchdb (1.2.0-1) unstable; urgency=low
* New major upstream release (closes: #672141).
diff -Nur couchdb-1.2.0-1/debian/patches/couchdb_own_rundir.patch couchdb-1.2.0-3/debian/patches/couchdb_own_rundir.patch
--- couchdb-1.2.0-1/debian/patches/couchdb_own_rundir.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0-3/debian/patches/couchdb_own_rundir.patch 2012-11-18 21:32:47.696128156 +0100
@@ -0,0 +1,20 @@
+Description: Initscript creates RUN_DIR , make sure it's owned by couchdb
+ Use install to make COUCHDB_USER own the RUN_DIR being created.
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/681549
+Last-Update: 2012-11-18
+
+---
+
+--- couchdb-1.2.0.orig/etc/init/couchdb.tpl.in
couchdb-1.2.0/etc/init/couchdb.tpl.in
+@@ -83,7 +83,8 @@ run_command () {
+ start_couchdb () {
+ # Start Apache CouchDB as a background process.
+
+-mkdir -p $RUN_DIR
++test -e $RUN_DIR || \
++install -m 755 -o $COUCHDB_USER -g $COUCHDB_USER -d $RUN_DIR
+ command=$COUCHDB -b
+ if test -n $COUCHDB_STDOUT_FILE; then
+ command=$command -o $COUCHDB_STDOUT_FILE
diff -Nur couchdb-1.2.0-1/debian/patches/logrotate_as_couchdb.patch couchdb-1.2.0-3/debian/patches/logrotate_as_couchdb.patch
--- couchdb-1.2.0-1/debian/patches/logrotate_as_couchdb.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0-3/debian/patches/logrotate_as_couchdb.patch 2012-11-18 21:31:42.084124771 +0100
@@ -0,0 +1,16 @@
+Description: Use logrotate as couchdb user
+ Use su and create to make logfiles owned by couchdb
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/652172
+Last-Update: 2012-11-18
+---
+
+--- couchdb-1.2.0.orig/etc/logrotate.d/couchdb.tpl.in
couchdb-1.2.0/etc/logrotate.d/couchdb.tpl.in
+@@ -6,4 +6,6 @@
+compress
+notifempty
+missingok
++ su couchdb couchdb
++ create 0640 couchdb couchdb
+ }
diff -Nur couchdb-1.2.0-1/debian/patches/series couchdb-1.2.0-3/debian/patches/series
--- couchdb-1.2.0-1/debian/patches/series 2011-11-27 09:19:17.0 +0100
+++ couchdb-1.2.0-3/debian/patches/series 2012-11-18 21:16:56.0 +0100
@@ -1 +1,4 @@
force-reload.patch
+couchdb_own_rundir.patch
+logrotate_as_couchdb.patch
+wait_for_couchdb_stop.patch
diff -Nur couchdb-1.2.0-1/debian/patches/wait_for_couchdb_stop.patch couchdb-1.2.0-3/debian/patches/wait_for_couchdb_stop.patch
--- couchdb-1.2.0-1/debian/patches/wait_for_couchdb_stop.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0-3/debian/patches/wait_for_couchdb_stop.patch 2012-11-18 21:20:05.0 +0100
@@ -0,0 +1,17 @@
+Description: Wait three seconds to let couchdb really stop
+ As couchdb needs some time to stop, wait a bit for that.
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/692295
+Last
Bug#682172: unblock: couchdb/1.2.0-2
On Mon, 2012-11-19 at 01:56 +0100, Michael Biebl wrote: On 18.11.2012 21:42, Laszlo Boszormenyi (GCS) wrote: Fixes four RC bugs. The first one is that couchdb needs some time to stop. Added three seconds wait time to stop in initscript and to postrm (the latter comes from Ubuntu). Otherwise couchdb can't be restarted and can't be purged. Such sleeps are really icky. Who says 3 seconds are enough? That entirely depends on your hardware and in what situation your system is in (load, etc). If couchdb -d, which is used on stop, does not block until the server has been safely shutdown, then this needs to be fixed, properly. Agree. That's an other thing upstream should fix. However I don't think that would happen soon, at least not for Wheezy. I'll ask about it. Until then this sleep may fixes the majority (maybe all) of the problems. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693065: vice: new upstream version 2.4 available
Hi Andreas, On Mon, 2012-11-12 at 16:21 +0100, Andreas Wirooks wrote: Package: vice Version: 2.4.dfsg-1 Severity: wishlist Tags: upstream version 2.4 is out. I'm aware of it and already have a package of it. However I would like to fix a nasty bug in 2.3 for Wheezy. Unfortunately upstream is not communicative. They made their mailing list hidden. Even if I know its name and location, I'm not allowed to subscribe. :( Good old times when I personally knew one of its contributor, Ettore Perazzoli. May he rest in peace! Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691609: ITP: tcplay -- a free (BSD-licensed), pretty much fully featured and stable TrueCrypt implementation
retitle 691609 ITP: tcplay -- a free (BSD-licensed), pretty much fully featured and stable TrueCrypt implementation owner 691609 ! thanks Hi, I've created a package of TrueCrypt with the name RealCrypt, but never uploaded. Now created a package out of tcplay, upload is coming shortly. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690182: about takeover of ITA: git-cola -- highly caffeinated git GUI
owner 690182 ! thanks Hi Daniel, On Tue, 2012-10-16 at 20:39 +0100, Iulian Udrea wrote: On 16 October 2012 20:36, Laszlo Boszormenyi (GCS) g...@debian.hu wrote: However I don't want to be harsh with you. Asking for your permission to take over this ITA. Regards, Laszlo/GCS Brilliant. Thanks a lot Laszlo! Well, a day has passed and no answer from Daniel. As you, the previous maintainer seems to be agree with the takeover I do that now. An upload is coming soon. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690182: about takeover of ITA: git-cola -- highly caffeinated git GUI
Hi Daniel, I'm a Debian Developer and have a working v1.8.0 package of git-cola ready to be uploaded. I've fixed everything, the new homepage, move to dh_python2 and link to jQuery and Underscore javascript libraries. The watch file is also updated and the package now conforms to v3.9.3 of Standards-Version. However I don't want to be harsh with you. Asking for your permission to take over this ITA. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682172: unblock: couchdb/1.2.0-2
On Thu, 2012-10-11 at 23:18 +0200, Julien Cristau wrote: [ about CouchDB storing its PID file as root ] Ping. Is this getting fixed? Upstream knows about this issue, promised a fix which won't be easy as I can remember. Now they are busy with releasing 1.3.0 and a bugfix branch of 1.2.0 . Don't know exactly if it's included, but will ping them. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646525: take over of ITP: sizzle -- Pure-JavaScript CSS selector engine designed to be easily dropped in to a host library
package wnpp owner 646525 ! thanks Hi, This ITP is inactive for almost a year. I've a package ready to upload. Will upload after the BTS reply. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615614: take over of ITP: setuptools-git -- setuptools revision control system plugin for git
package wnpp owner 615614 ! thanks Hi, After everyone let me take over this ITP, I do it and upload the package right away. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615614: take over of ITP: setuptools-git -- setuptools revision control system plugin for git
Hi! I will take over this ITP on Monday if no one objects. The original ITP is open for a while without any visible activity. I've a package ready to upload. It is based on the work of Chuck Short, but builds the Python3 variant as well. Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Bug#670680: test python-greenlet/0.4.0-1 on armhf
Hi Al, I plan to take over python-greenlet and upload a new upstream release. Can you please check if 0.4.0-1 [1] fixes this bug for you? Thanks, Laszlo/GCS [1] dget -xu http://www.barcikacomp.hu/gcs/python-greenlet_0.4.0-1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683746: rspamd packaging
On Mon, 2012-08-27 at 19:04 +0400, Vsevolod Stakhov wrote: I've fixed this issue and reuploaded the package to m.d.net. ... and I've uploaded your package to the official archives. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640577: missing egg-info in python-greenlet cause FTBFS of python-eventlet in Wheezy
unarchive 640577 tag 640577 wheezy affects 640577 python-eventlet thanks Hi, The addition of egg-info file to python-greenlet still affects python-eventlet . As the former bugfix do not migrate to Wheezy due to an other RC bug in python-greenlet . I plan to NMU[1] this to wheezy-proposed-updates. Regards, Laszlo/GCS [1] http://www.barcikacomp.hu/gcs/python-greenlet_0.3.1-2.1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683746: rspamd packaging
On Thu, 2012-08-23 at 18:33 +0400, Vsevolod Stakhov wrote: I've updated rspamd and package to 0.5.2 version. The packaging is good now. One missing bit however that you missed to close your ITP in the changelog. Preferably in the first, 0.4.3-1 entry please close #683746 . After that, I'll upload it. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685853: unblock: cvs2svn/2.3.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception thanks Hi Release Team, Previously cvs2svn tests were failing due to a subversion behavior change. The fix is from upstream[1] SVN r5381 . The debdiff is attached. Regards, Laszlo/GCS [1] http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1716dsMessageId=2950121 diff -u cvs2svn-2.3.0/debian/changelog cvs2svn-2.3.0/debian/changelog --- cvs2svn-2.3.0/debian/changelog +++ cvs2svn-2.3.0/debian/changelog @@ -1,3 +1,10 @@ +cvs2svn (2.3.0-3) unstable; urgency=low + + * Fix some test cases to deal with non-deterministic dump output +(closes: #665028), thanks to Salvatore Bonaccorso for the heads-up. + + -- Laszlo Boszormenyi (GCS) g...@debian.hu Sat, 25 Aug 2012 13:21:49 +0200 + cvs2svn (2.3.0-2) unstable; urgency=low * Pass '--prefix=/usr' to 'setup.py install' needed for the upcoming Python diff -u cvs2svn-2.3.0/debian/rules cvs2svn-2.3.0/debian/rules --- cvs2svn-2.3.0/debian/rules +++ cvs2svn-2.3.0/debian/rules @@ -29,7 +29,8 @@ python setup.py clean # clean up - rm -rf $(CURDIR)/build/ $(CURDIR)/tmp/ $(CURDIR)/cvs2svn-tmp/ + rm -rf $(CURDIR)/build/ $(CURDIR)/tmp/ $(CURDIR)/cvs2svn-tmp/ \ + $(CURDIR)/svn-test-work/local_tmp/ rm -f $(CURDIR)/svntest/*.pyc \ $(CURDIR)/cvs2svn_rcsparse/*.pyc $(CURDIR)/cvs2svn_lib/*.pyc rm -rf $(CURDIR)/debian/locale/ only in patch2: unchanged: --- cvs2svn-2.3.0.orig/run-tests.py +++ cvs2svn-2.3.0/run-tests.py @@ -3174,19 +3174,15 @@ verify that --use-internal-co works rcs_conv = ensure_conversion( - 'main', args=['--use-rcs', '--default-eol=native'], + 'main', args=['--use-rcs', '--default-eol=native'], dumpfile='use-rcs-rcs.dump', ) conv = ensure_conversion( - 'main', args=['--default-eol=native'], + 'main', args=['--default-eol=native'], dumpfile='use-rcs-int.dump', ) if conv.output_found(r'WARNING\: internal problem\: leftover revisions'): raise Failure() - rcs_lines = run_program( - svntest.main.svnadmin_binary, None, 'dump', '-q', '-r', '1:HEAD', - rcs_conv.repos) - lines = run_program( - svntest.main.svnadmin_binary, None, 'dump', '-q', '-r', '1:HEAD', - conv.repos) + rcs_lines = list(open(rcs_conv.dumpfile, 'rb')) + lines = list(open(conv.dumpfile, 'rb')) # Compare all lines following the repository UUID: if lines[3:] != rcs_lines[3:]: raise Failure() @@ -3199,19 +3195,17 @@ rcs_conv = ensure_conversion( 'internal-co', args=['--use-rcs', '--exclude=BRANCH', '--default-eol=native'], + dumpfile='internal-co-exclude-rcs.dump', ) conv = ensure_conversion( 'internal-co', args=['--exclude=BRANCH', '--default-eol=native'], + dumpfile='internal-co-exclude-int.dump', ) if conv.output_found(r'WARNING\: internal problem\: leftover revisions'): raise Failure() - rcs_lines = run_program( - svntest.main.svnadmin_binary, None, 'dump', '-q', '-r', '1:HEAD', - rcs_conv.repos) - lines = run_program( - svntest.main.svnadmin_binary, None, 'dump', '-q', '-r', '1:HEAD', - conv.repos) + rcs_lines = list(open(rcs_conv.dumpfile, 'rb')) + lines = list(open(conv.dumpfile, 'rb')) # Compare all lines following the repository UUID: if lines[3:] != rcs_lines[3:]: raise Failure()
Bug#685319: ITA: python-eventlet
On Tue, 2012-08-21 at 18:14 +0200, Stefano Rivera wrote: I previously contacted my co-maintainers, and got an ACK on moving it to the OpenStack team from Monty, but no replies from anyone else.I suggest you remove all of the existing Uploaders when you take this over, unless anyone explicitly asks to stay involved. OK, will remove them, unless hear otherwise. BTW, there's one open RC Bug that needs some attention/coordination: #684852 I think python-greenlet needs to be fixed for Wheezy. Its bug will affect everyone, not just python-eventlet. Only the relevant bugfix should be uploaded to wheezy-proposed or something that fits this case. I can fix it in python-eventlet , the test should be run with the '--without-greenlet' switch and it'll build. But still downloads greenlet. :( This seconds that python-greenlet should be fixed. By the way, Örjan, do you still maintain your package? May I take over it? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682172: unblock: couchdb/1.2.0-2
On Fri, 2012-07-27 at 22:55 +0200, Julien Cristau wrote: On Thu, Jul 19, 2012 at 23:43:56 +, Laszlo Boszormenyi (GCS) wrote: On new installs /var/run/couchdb is created to store the pidfile in, but as root:root . Then the couchdb user can't store its pid there, due to owner problems. Filed as important, but can be RC as couchdb fails to start if can't store the pidfile. The fix is oneliner: +++ couchdb-1.2.0/etc/init/couchdb.tpl.in mkdir -p $RUN_DIR +chown -R $COUCHDB_USER $RUN_DIR command=$COUCHDB -b Can't the pidfile be written to before dropping privs? chown -R feels rather ick, I can't see why the -R should be necessary and I can see a few ways it could be bad. Agree, -R can be problematic. What about [ -d $RUN_DIR ] || (mkdir -p $RUN_DIR; chown $COUCHDB_USER $RUN_DIR) ? It would change ownership only at creation time, own that dir only to $COUCHDB_USER . Doesn't change anything below that directory and in fact, after its creation it'll be empty anyway. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685319: ITA: python-eventlet
retitle 685319 ITA: python-eventlet -- concurrent networking library for Python owner ! thanks Hi, I would like to adopt for several reasons. I plan to use it for my own projects. Also plan to be part of the OpenStack team, for Ceph packaging and for other things as well. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685178: ITP: android tools -- adb and fastboot tools for Android
Package: wnpp Owner: Laszlo Boszormenyi (GCS) g...@debian.hu Severity: wishlist * Package name: android-tools Version : 4.1.1 Upstream Author : The Android Open Source Project * URL : https://android.googlesource.com/platform/system/core https://android.googlesource.com/platform/system/extras * License : Apache 2.0 Programming Lang: C Description : adb and fastboot tools for Android Package is ready and accepted to Ubuntu. I would like to add it to Debian as well. It has two binary packages, one for adb and other for fastboot. ATM the packages will be amd64 and i386 only. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#459219: android-tools packaging
On Wed, 2012-08-15 at 16:07 +0200, Adnan Hodzic wrote: On Tue, Aug 14, 2012 at 8:01 PM, Laszlo Boszormenyi (GCS) g...@debian.hu wrote: I think this ITP should be several ones. One for command like tools like adb , one for Eclipse plugin and one for the emulator at least. ATM Adnan's work is great. I'm a DD and just changed bits in his packaging to be perfect. Thank you for appreciating my work. Which bits did you change because I don't see any chances in the code. I've my own package, not yet uploaded to anywhere. Attached a diff what I've changed. I was wrong by the way, it's Marcin who made a very good package of android-tools. He tries to outsmart debhelper and do some parts by hand. It's not needed, just show debhelper where it can find the files. Also, install manpage as is, not with the binary. I would be happy to maintain android-tools with him or me for Debian and he is for Ubuntu but with the same package base. Also why do you think we should separate them in couple of pieces instead of having the installer which could let you select which pieces you want and which you don't? I personally would like to have it all in a single package, thus why I started working on this installer. Still didn't check your installer in detail. But why do you want to be outsmart apt-get and dpkg? It would be similar like a gnome-all package, where you choose you need for example evince, but not gome-terminal. How do you handle Eclipse dependency? One package has one dependency line in it. If you set the package need Eclipse, it would be an overkill for ones they don't need the Android plug-in in general. If you miss it, you will install the plug-in without the editor that uses it. Also, you'll just kill GUI based package installers. Those won't handle that you ask question on CLI. May add more CLI tools to android-tools package, but currently it seems to be a good start. In case we do decide to the way you suggested above, besides being an uploader do you mind me being a maintainer together with you? Because I really do have great interest in future of this package. Maintainer and uploader have the same rights and can be changed anytime one doesn't want contribute to the package anymore. Laszlo/GCS diff -Nru android-tools-4.1.1+git20120801/debian/android-tools-adb.install android-tools-4.1.1+git20120801/debian/android-tools-adb.install --- android-tools-4.1.1+git20120801/debian/android-tools-adb.install 2012-07-16 16:14:25.0 +0200 +++ android-tools-4.1.1+git20120801/debian/android-tools-adb.install 2012-08-14 15:02:29.0 +0200 @@ -1,2 +1 @@ -usr/bin/adb -usr/man/* +core/adb/adb usr/bin/ diff -Nru android-tools-4.1.1+git20120801/debian/android-tools-adb.manpages android-tools-4.1.1+git20120801/debian/android-tools-adb.manpages --- android-tools-4.1.1+git20120801/debian/android-tools-adb.manpages 1970-01-01 01:00:00.0 +0100 +++ android-tools-4.1.1+git20120801/debian/android-tools-adb.manpages 2012-08-14 15:05:26.0 +0200 @@ -0,0 +1 @@ +debian/adb.1 diff -Nru android-tools-4.1.1+git20120801/debian/android-tools-fastboot.install android-tools-4.1.1+git20120801/debian/android-tools-fastboot.install --- android-tools-4.1.1+git20120801/debian/android-tools-fastboot.install 2012-07-16 16:14:25.0 +0200 +++ android-tools-4.1.1+git20120801/debian/android-tools-fastboot.install 2012-08-14 15:04:16.0 +0200 @@ -1 +1 @@ -usr/bin/fastboot +core/fastboot/fastboot usr/bin/ diff -Nru android-tools-4.1.1+git20120801/debian/changelog android-tools-4.1.1+git20120801/debian/changelog --- android-tools-4.1.1+git20120801/debian/changelog 2012-08-01 12:30:36.0 +0200 +++ android-tools-4.1.1+git20120801/debian/changelog 2012-08-14 14:40:55.0 +0200 @@ -1,3 +1,10 @@ +android-tools (4.1.1+git20120801-1) unstable; urgency=low + + * Initial upload to Debian (closes: #459219), based on the work of Marcin +Juszkiewicz. + + -- Laszlo Boszormenyi (GCS) g...@debian.hu Tue, 14 Aug 2012 12:24:28 + + android-tools (4.1.1+git20120801-0ubuntu1) quantal; urgency=low * Updated upstream code: diff -Nru android-tools-4.1.1+git20120801/debian/control android-tools-4.1.1+git20120801/debian/control --- android-tools-4.1.1+git20120801/debian/control 2012-07-16 16:30:08.0 +0200 +++ android-tools-4.1.1+git20120801/debian/control 2012-08-14 15:10:10.0 +0200 @@ -1,8 +1,8 @@ Source: android-tools Section: devel Priority: extra -Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com -XSBC-Original-Maintainer: Marcin Juszkiewicz marcin.juszkiew...@linaro.org +Maintainer: Laszlo Boszormenyi (GCS) g...@debian.hu +Uploaders: Marcin Juszkiewicz marcin.juszkiew...@linaro.org Build-Depends: debhelper (= 9), zlib1g-dev Standards-Version: 3.9.3 Homepage: http://developer.android.com/guide/developing/tools/adb.html diff -Nru android-tools-4.1.1+git20120801/debian/rules android-tools-4.1.1+git20120801/debian/rules --- android-tools-4.1.1
Bug#459219: android-tools packaging
Hi Marcin, Adnan, I think this ITP should be several ones. One for command like tools like adb , one for Eclipse plugin and one for the emulator at least. ATM Adnan's work is great. I'm a DD and just changed bits in his packaging to be perfect. I think it should be uploaded (ie, the android-tools package). Most users will need only adb and fastboot. The other parts can be packaged later. Would you let me file an ITP for android-tools and upload it? I've set myself as the maintainer and Adnan as uploader. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683746: rspamd packaging
On Thu, 2012-08-09 at 17:56 +0400, Vsevolod Stakhov wrote:
Fixed them, thank you!
Getting close. Found some spelling fixes, patch attached.
I've uploaded the package: http://mentors.debian.net/package/rspamd
Seems to be good. Please add the also attached watch file.
Regards,
Laszlo/GCS
diff -Nur orig.rspamd-0.5.1/src/dkim.c rspamd-0.5.1/src/dkim.c
--- orig.rspamd-0.5.1/src/dkim.c 2012-08-09 13:40:26.0 +0200
+++ rspamd-0.5.1/src/dkim.c 2012-08-09 23:15:05.168196938 +0200
@@ -475,7 +475,7 @@
}
break;
default:
-g_set_error (err, DKIM_ERROR, DKIM_SIGERROR_UNKNOWN, invalid dkim param lenght: %zd, taglen);
+g_set_error (err, DKIM_ERROR, DKIM_SIGERROR_UNKNOWN, invalid dkim param length: %zd, taglen);
state = DKIM_STATE_ERROR;
break;
}
diff -Nur orig.rspamd-0.5.1/src/lua/lua_redis.c rspamd-0.5.1/src/lua/lua_redis.c
--- orig.rspamd-0.5.1/src/lua/lua_redis.c 2012-08-09 13:40:26.0 +0200
+++ rspamd-0.5.1/src/lua/lua_redis.c 2012-08-09 23:16:44.964202086 +0200
@@ -343,7 +343,7 @@
}
}
else {
- msg_info (function requred as 4-th argument);
+ msg_info (function required as 4-th argument);
lua_pushboolean (L, FALSE);
}
}
diff -Nur orig.rspamd-0.5.1/src/main.c rspamd-0.5.1/src/main.c
--- orig.rspamd-0.5.1/src/main.c 2012-08-09 13:40:26.0 +0200
+++ rspamd-0.5.1/src/main.c 2012-08-09 23:15:51.076199305 +0200
@@ -1074,14 +1074,14 @@
#endif
if (do_terminate) {
do_terminate = 0;
- msg_info (catch termination signal, waiting for childs);
+ msg_info (catch termination signal, waiting for children);
pass_signal_worker (rspamd_main-workers, SIGTERM);
break;
}
if (child_dead) {
child_dead = 0;
msg_debug (catch SIGCHLD signal, finding terminated worker);
- /* Remove dead child form childs list */
+ /* Remove dead child form children list */
wrk = waitpid (0, res, 0);
if ((cur = g_hash_table_lookup (rspamd_main-workers, GSIZE_TO_POINTER (wrk))) != NULL) {
/* Unlink dead process from queue and hash table */
diff -Nur orig.rspamd-0.5.1/src/plugins/lua/ip_score.lua rspamd-0.5.1/src/plugins/lua/ip_score.lua
--- orig.rspamd-0.5.1/src/plugins/lua/ip_score.lua 2012-08-09 13:40:26.0 +0200
+++ rspamd-0.5.1/src/plugins/lua/ip_score.lua 2012-08-09 23:17:15.308203651 +0200
@@ -171,5 +171,5 @@
rspamd_config:register_post_filter(ip_score_set)
end
else
- rspamd_logger.err('cannot register module ip_score as it requres at least 9 version of lua API and rspamd = 0.4.6')
+ rspamd_logger.err('cannot register module ip_score as it requires at least 9 version of lua API and rspamd = 0.4.6')
end
version=3
https://bitbucket.org/vstakhov/rspamd/downloads .+rspamd-(\d+[\d\.]*).tar.gz
Bug#660141: Update Regarding php-mongo
owner 660141 ! thanks On Wed, 2012-08-08 at 19:30 +0200, Rajmund Zawiślak wrote: My package uploaded to mentors didn't found sponsor for 20 weeks and was deleted, so feel free to package it by yourself. Too bad. :( There are a lot of good software that don't get into Debian as no one notices their importance. I try to package rockmongo - WWW interface do database based on php, what you think about it? Will look into it. How it goes? On Wed, 2012-08-08 at 20:49 +0200, Rajmund Zawiślak wrote: More info: After installing phpunit from upstream source, extension mongo.so compiled and installed from pecl didn't pass phpunit tests written by authors of this extension. My question is: Does software which doesn't pass their own tests, is worthy to be packaged for Debian? Well, upstream should be noted about the failures. Those can be for several reasons. Bad version of PHP installed, testcase failures, some dependency is missing or not set up correctly. I'm using php with mongo on production system with heavy load, and there are was not any troubles, but I would be careful. The answer is two folds. Testcase errors don't necessary means the result is faulty. See your case, it works in real environment. Also, Debian has a queue before release. Packages go to unstable, which shows it's a new version and may have problems. If it passes ten days there, it can enter to testing. After several months, a new stable release happen. Any time it has a serious problem, it is removed from the list of packages that are ready to be released. In short, let it go to unstable, ask upstream about build failures and see how they can be fixed. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611660: tomb vs cryptmount
Hi Bert, On Tue, 2012-08-07 at 13:03 +0200, berta...@ptitcanardnoir.org wrote: I'd say that one of the most important difference is the use of the steghide tool to hide access keys in an image. Also Tomb has some Gtk integration. The steghide sounds good! However there are plenty of softwares in the Debian archive that provide almost the same features, so I'm not sure to get the point of this question. Some DDs would argue, as this is not the optimal state. There are a _lot of_ packages in Debian, but not all of them maintained correctly. Smaller number but more competent packages would help in general. Better packaging, easier to write HOWTOs for a specific task and so on. But to stay on topic, the question was more user oriented this time. I use and like cryptmount and I like CLI applications better. On the other hand, if tomb is better in many ways, I may migrate to it. Will do my tests then. About to create a package of tomb first. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683746: rspamd packaging
Hi Vsevolod, On Mon, 2012-08-06 at 16:30 +0400, Vsevolod Stakhov wrote: On 08/05/2012 10:46 AM, Laszlo Boszormenyi (GCS) wrote: [ about the hardened build failure ] Well, I've tried the same on my ubuntu dev box and cannot repeat this issue. Can you please try it again with modified package? Version 0.5.1 still fails with hardening enabled. gcc is: gcc-4.7.real (Debian 4.7.1-5) 4.7.1 cmake is: cmake version 2.8.8 Related messages: [ 10%] Building C object lib/CMakeFiles/rspamd-util.dir/__/src/mem_pool.c.o cd /root/compile/rspamd/rspamd-0.5.1/obj-x86_64-linux-gnu/lib /usr/bin/cc -O0 -fstrict-aliasing -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -DLINUX -fPIC -fpic -g -W -Wall -Wpointer-arith -Wno-unused-parameter -Wno-unused-function -Wunused-variable -Wno-pointer-sign -Wstrict-prototypes -pedantic -std=c99 -I/usr/include/x86_64-linux-gnu -I/usr/include/lua5.1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gmime-2.6 -I/root/compile/rspamd/rspamd-0.5.1/compat -I/root/compile/rspamd/rspamd-0.5.1/src -I/root/compile/rspamd/rspamd-0.5.1/obj-x86_64-linux-gnu/src -I/root/compile/rspamd/rspamd-0.5.1/contrib/hiredis -I/root/compile/rspamd/rspamd-0.5.1/lib/src-fno-strict-aliasing -o CMakeFiles/rspamd-util.dir/__/src/mem_pool.c.o -c /root/compile/rspamd/rspamd-0.5.1/src/mem_pool.c [...] Linking C shared library libkvstorageclient.so cd /root/compile/rspamd/rspamd-0.5.1/obj-x86_64-linux-gnu/lib /usr/bin/cmake -E cmake_link_script CMakeFiles/kvstorageclient.dir/link.txt --verbose=1 /usr/bin/cc -fPIC -O0 -fstrict-aliasing -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -DLINUX -fPIC -fpic -g -W -Wall -Wpointer-arith -Wno-unused-parameter -Wno-unused-function -Wunused-variable -Wno-pointer-sign -Wstrict-prototypes -pedantic -std=c99 -shared -Wl,-soname,libkvstorageclient.so -o libkvstorageclient.so CMakeFiles/kvstorageclient.dir/kvstorage/libkvstorageclient.c.o librspamd-util.a -lm -lrt -ldl -lutil -lpcre -lgmodule-2.0 -lrt -ldl -lutil -lpcre -lgmodule-2.0 -lglib-2.0 -lffi -levent /usr/bin/ld.bfd.real: librspamd-util.a(mem_pool.c.o): relocation R_X86_64_PC32 against symbol `memory_pool_alloc' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld.bfd.real: final link failed: Bad value collect2: error: ld returned 1 exit status Where does memory_pool_alloc come from? Maybe its source is not compiled with -fPIC / -fpic . I've fixed that as well. Thought FreeBSD port system is more tolerative in this aspect affording addition of the upstream changelog to a port's changelog, so why I thought that debian/changelog should be the same. FreeBSD uses the port system, it needs to list upstream changes as well. For us, the file is named _debian_/changelog . On Tue, 2012-08-07 at 16:24 +0400, Vsevolod Stakhov wrote: On 08/06/2012 04:30 PM, Vsevolod Stakhov wrote: Well, I've fixed all issues you pointed and committed them to rspamd mercurial repository. I think I'll release 0.5.1 version soon and the package would be for it, not for 0.5.0. It seems there are still issues with debian/copyright . Please see the attached patch. Well, I've released 0.5.1 version in which I've fixed all problems you pointed me out. So what should be my next steps - go to the mentors.debian.net and upload packages? If you fix the mentioned bits, then please upload the package to mentors.debian.net and notify me. I'm going to sponsor it. Regards, Laszlo/GCS diff -Nur rspamd-0.5.1.orig/debian/copyright rspamd-0.5.1/debian/copyright --- rspamd-0.5.1.orig/debian/copyright 2012-08-06 19:41:57.0 +0200 +++ rspamd-0.5.1/debian/copyright 2012-08-07 20:12:01.0 +0200 @@ -3,9 +3,9 @@ Source: https://bitbucket.org/vstakhov/rspamd Files: contrib/lgpl/* -Copyright: 1999, 2000 Scott Wimer -Copyright: 2004, Matthias Clasen mcla...@redhat.com -Copyright: 2005 - 2007, Marco Barisione ma...@barisione.org +Copyright: 1999, 2000 Scott Wimer, + 2004Matthias Clasen mcla...@redhat.com, + 2005 - 2007 Marco Barisione ma...@barisione.org License: LGPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public @@ -51,9 +51,16 @@ Files: * Copyright: 2008-2012 Vsevolod Stakhov vsevo...@highsecure.ru -License: BSD +License: BSD-2-Clause Redistribution and use in source and binary forms, with or without - modification, are permitted under the terms of the BSD License. + modification, are permitted provided that the following conditions are met: + . + Redistributions of source code must retain the above copyright notice, this + list of conditions and the following disclaimer. + . + Redistributions in binary form must reproduce the above copyright notice, + this list of conditions
Bug#611660: tomb vs cryptmount
Hi Bert, On Tue, 2012-08-07 at 14:20 +0200, berta...@ptitcanardnoir.org wrote: On Tue, Aug 07, 2012 at 12:00:59PM +, Laszlo Boszormenyi (GCS) wrote: You make a point. If I asked for the status of this packaging, it's because I was willing to stand up for maintaining it if no one was wiling to do so. I've packaged it and it's ready to upload. After reconsider everything, I say just drop it. Two shell scripts for a package simply doesn't worth it IMHO. Especially that both are zsh specific (the user have to install zsh to run them) and it needs root rights. This can break anytime a called binary changes it's command line flags or differ in its output. Great, don't hesitate to tell me what you think about it, I'm curious too. Upstream already did some packaging work in its debian0 branch. Also if you need any help, I'd be glad to. Including co-maintaining it if you're willing to include it in Debian. God forbid, but even if I upload it, I think two shell scripts don't worth more than one maintainer. I say cryptmount should be used instead. They differ in several ways, but it is a much better solution in general. Sorry for the noise, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660141: Update Regarding php-mongo
Hi Martin, On Mon, 2012-08-06 at 13:03 +0100, Martin Meredith wrote: I'm looking to work with php-mongo in Debian - and actually require to build a package ASAP. Is there any progress on either of your packages? If not, I'm happy to look @ sponsoring the upload of these ? I've a package, ready to upload[1]. Please check if it meets DFSG and other rules. Otherwise, I intend to hijack the ITP. Please don't. If the package meets your needs, I'll upload it. Regards, Laszlo/GCS [1] dget -ux http://www.barcikacomp.hu/gcs/php-mongo_1.2.12-1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611660: tomb vs cryptmount
Hi, Without too much reading, it seems tomb and cryptmount somewhat similar. The latter is already in the archives and stable. What's the most important differences (if any)? Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660141: Update Regarding php-mongo
Hi Martin, On Mon, 2012-08-06 at 19:38 +0100, Martin Meredith wrote: Hi Laszlo - I can't find you in db.debian.org Please don't make me unknown to Debian. I'm a DD[1] since 2005-01-19, also an application manager[2]. When I search about myself[3] and type 'gcs' as login, I can find myself. Have some packages[4] in the archive. If you check the signatures on my GnuPG keys (ie A51A4FDD and BBAA47C9), you can see that I know other DDs in person like Steve Langasek, Stefano Zacchiroli, Tom Marble, Bdale Garbee or Enrico Zini. Also some RedHat employees, but that's the other side. and from the way you've been talking about this package - I'm presuming you won't actually have rights to upload. Quoting myself: If the package meets your needs, I'll upload it.. Where do you read that I don't have rights to upload? Can you please push your package onto mentors.debian.net - it'll help me with doing some basic packaging checks, rather than having to do them all manually. That sound strange for me. Never trust an external source in things that you can check yourself. A pbuilder chroot can make sure that build-dependencies are correct, you can check d/*, etc. Please upload the package to mentors by yourself if you still want to go that way. I didn't want to be harsh, sorry if this mail sounds like that. Regards, Laszlo/GCS [1] https://nm.debian.org/public/person/gcs [2] https://nm.debian.org/public/managers [3] https://db.debian.org/ [4] http://qa.debian.org/developer.php?login=g...@debian.hu signature.asc Description: This is a digitally signed message part
Bug#683746: rspamd packaging
Hi Vsevolod, On Sat, 2012-08-04 at 23:53 +0400, Vsevolod Stakhov wrote: Thanks for taking care of it! I'm using this package for my machines, but I'm not very familiar with debian packaging policies unfortunately. Hmmm, do you really want to learn and package it? Learning is always good, I don't want to hijack it from you. It's strange as rspamd is built with -fpic -fPIC flags if they are supported on the targeted architecture. How can I repeat this bug using my debian system? Sure, I've seen that you use -fpic and -fPIC as well for compilation. The patch I've sent to you contains everything. Just uncomment the export DEB_BUILD_MAINT_OPTIONS=hardening=+all line in debian/rules . I think one of your source files might not be compiled with the PIC flags and that's the problem. Library is only used for rspamd client (rspamc), so maybe it would be better to link it statically for debian package? I think a development package is only useful when there is any external software that uses the normal package's API. I do agree with your lines. Either make the binary statically linked and without the header file or consider the package split. Do you intend to use plug-ins or whatever external to spamc? There's no problem if nobody else will use the separated library, but it'll be rejected from the official archives if you keep it as-is. Acknowledged. So on upgrades of this package I should only inlcude lines like 'Update to version x.x.x', rigth? Sure, 'initial release', 'new upstream release', 'fixed compilation on 64 bit machines' or anything related to the packaging itself is OK. The code related ones like 'added IPv6 support', 'many bugfixes', 'rework events system' and 'write plugin for ...' are not. The latter ones can go to toplevel_dir/ChangeLog with a date and version number added. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622960: freemind packaging needs jmapviewer
Hi Andrew, On Sun, 2012-08-05 at 20:24 +1000, Andrew Harvey wrote: On 05/08/12 00:07, Laszlo Boszormenyi (GCS) wrote: How goes the jmapviewer packaging? As I see, there's a git repository[1], but it seems it was never uploaded nor update for eight months now. I don't think it was uploaded to Debian because I couldn't find a DD to sponsor it. However, I believe it still needs some more work anyway. Now you've found a DD who would upload it. Sure, it needs to be updated to the newest stable version and conforms to the latest Debian policy. Are you still interested to maintain it or should I finish packaging that as well? I don't know if I can commit to anything, but I can try to help out with its packaging. So happy to either co-maintain, or co-contribution of packaging work. Well, somehow you created it. You are set as owner and it seems you did some commit to it. Which version of jmapviewer does freemind need? Because I noticed that if I updated the alioth packaging for jmapviewer to the latest, it would pull in an embedded MapQuest logo, so we would need to either cut it out, or ensure it is DFSG compliant. Sure, the image should be DFSG compliant as well. I don't know the required version number, even if freemind contains the source jar for jmapviewer. I couldn't find its version number. Is there any release at all? What I could find is: http://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/2011-02-19/ Nothing more. No version number, just a date. I'm more than happy to try to help out or for you to work directly off http://anonscm.debian.org/gitweb/?p=pkg-osm/jmapviewer.git;a=summary I'm not exactly sure how much time I'll have to look into it. I'll try, but feel free to jump ahead and work on it yourself. So you mean I can be its maintainer and set you as uploader? Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622960: freemind packaging needs jmapviewer
Hi Andrew, How goes the jmapviewer packaging? As I see, there's a git repository[1], but it seems it was never uploaded nor update for eight months now. I intend to adopt freemind[2] and almost ready packaging its newest release, 1.0.0~beta5. However it needs jmapviewer to build correctly. Are you still interested to maintain it or should I finish packaging that as well? Regards, Laszlo/GCS [1] http://anonscm.debian.org/gitweb/?p=pkg-osm/jmapviewer.git;a=summary [2] http://freemind.sourceforge.net/wiki/index.php/Main_Page -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683746: rspamd packaging
Hi Vsevolod, I've seen your ITP of rspamd and thought I may package it instead of you. But as I see, it's close to ready. I send a patch to make it better. Contains the following fixes: - make it rebuildable with deleting src/modules.c between builds - fixing debian/copyright (the BSD license text is still not 100% correct) - install the correct binaries and not symlinks to specific versioned ones - fix spelling mistake in debian/rules - correct build-dependencies for Sid - add patch to build with newer gmime (v2.6) - update standards-version to the current one - take a step toward build hardening build I couldn't build it with hardening enabled due to this error: /usr/bin/ld.bfd.real: librspamd-util.a(mem_pool.c.o): relocation R_X86_64_PC32 against symbol `memory_pool_alloc' can not be used when making a shared object; recompile with -fPIC The package should be split to lib, -dev and binary. Please don't use debian/changelog as upstream changelog. It's only for packaging changes and nothing else. Regards, Laszlo/GCS diff -Nur rspamd-0.5.0.orig/debian/control rspamd-0.5.0/debian/control --- rspamd-0.5.0.orig/debian/control 2012-06-09 14:35:05.0 +0200 +++ rspamd-0.5.0/debian/control 2012-08-04 20:01:52.0 +0200 @@ -2,8 +2,8 @@ Section: mail Priority: extra Maintainer: Vsevolod Stakhov vsevo...@highsecure.ru -Build-Depends: debhelper (= 7.0.50~), cmake, libevent1-dev(= 1.3), libglib2.0-dev (= 2.16.0), libgmime-2.4-dev, liblua5.1-0-dev, libpcre3-dev, cdbs -Standards-Version: 3.9.1 +Build-Depends: debhelper (= 7.0.50~), dpkg-dev (= 1.16.1~), cmake, libevent-dev (= 1.3), libglib2.0-dev (= 2.16.0), libgmime-2.6-dev, liblua5.1-0-dev, libpcre3-dev, cdbs +Standards-Version: 3.9.3 Homepage: https://bitbucket.org/vstakhov/rspamd/ Vcs-Hg: https://bitbucket.org/vstakhov/rspamd/ Vcs-Browser: https://bitbucket.org/vstakhov/rspamd/src diff -Nur rspamd-0.5.0.orig/debian/copyright rspamd-0.5.0/debian/copyright --- rspamd-0.5.0.orig/debian/copyright 2012-06-09 14:35:05.0 +0200 +++ rspamd-0.5.0/debian/copyright 2012-08-04 19:51:37.0 +0200 @@ -3,15 +3,47 @@ Source: https://bitbucket.org/vstakhov/rspamd Files: contrib/lgpl/* -Copyright: 1999, 2000 Scott Wimer -Copyright: 2004, Matthias Clasen mcla...@redhat.com -Copyright: 2005 - 2007, Marco Barisione ma...@barisione.org +Copyright: 1999, 2000 Scott Wimer, + 2004, Matthias Clasen mcla...@redhat.com, + 2005 - 2007 Marco Barisione ma...@barisione.org License: LGPL-2+ - + This package is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + . + This package is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + . + You should have received a copy of the GNU Library General Public + License along with this package; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + . + On Debian systems, the complete text of the GNU Library General + Public License can be found in `/usr/share/common-licenses/LGPL-2'. Files: * Copyright: 2008-2011 Vsevolod Stakhov vsevo...@highsecure.ru License: BSD + Redistribution and use in source and binary forms, with or without + modification, are permitted under the terms of the BSD License. + . + THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + SUCH DAMAGE. + . + On Debian systems, the complete text of the BSD License can be + found in `/usr/share/common-licenses/BSD'. Files: debian/* Copyright: 2011 Vsevolod Stakhov vsevo...@highsecure.ru diff -Nur rspamd-0.5.0.orig/debian/patches/gmime-2.6.patch rspamd-0.5.0/debian/patches/gmime-2.6.patch --- rspamd-0.5.0.orig/debian/patches/gmime-2.6.patch 1970-01-01 01:00:00.0 +0100 +++ rspamd-0.5.0/debian/patches/gmime-2.6.patch 2012-08-04 20:06:18.741331505 +0200 @@ -0,0 +1,20 @@ +Description: build with gmime-2.6 + CMake checks for gmime-2.4 , change it to gmime-2.6 to build with that + version. + . +Author: Laszlo Boszormenyi
Bug#597899: ITP: yii-framework -- High-performance component-based PHP framework
retitle 597899 ITP: yii-framework -- High-performance component-based PHP framework owner 597899 ! thanks Hi, I've a package already, just need to recheck debian/copyright and may rework to official copyright format 1.0 . Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676396: ITP: libjs-d3 -- JavaScript library for manipulating documents
retitle 676396 ITP: libjs-d3 -- JavaScript library for manipulating documents thanks Hi all, I would like to package libjs-d3 and actually already did that. It needs some more love, but basically it needs node-jsdom 0.2.14 or newer. Asked David Paleino if he wants to keep it and updated or handle that to me. I've a package of it ready to upload if he let me to take over. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683666: help with gradle packaging
Hi Miguel, I'm new to gradle, but intend to help. First I've to check it in details and start with the 1.1 upstream release. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660141: php-mongo packaging
Hi Rajmund, Your ITP doesn't have any activity for months. I've a package ready to upload. If you let me take over this ITP or you don't answer say, for five days, I'll upload my package version. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682172: unblock: couchdb/1.2.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
thanks
Hi,
Please unblock couchdb/1.2.0-2 which fixes #681549 [1].
On new installs /var/run/couchdb is created to store the pidfile in, but
as root:root . Then the couchdb user can't store its pid there, due to
owner problems. Filed as important, but can be RC as couchdb fails to
start if can't store the pidfile.
The fix is oneliner:
+++ couchdb-1.2.0/etc/init/couchdb.tpl.in
mkdir -p $RUN_DIR
+chown -R $COUCHDB_USER $RUN_DIR
command=$COUCHDB -b
But complete debdiff is attached.
Thanks,
Laszlo/GCS
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681549
diff -Nru couchdb-1.2.0/debian/changelog couchdb-1.2.0/debian/changelog
--- couchdb-1.2.0/debian/changelog 2012-06-29 20:31:16.0 +0200
+++ couchdb-1.2.0/debian/changelog 2012-07-19 20:35:03.0 +0200
@@ -1,3 +1,9 @@
+couchdb (1.2.0-2) unstable; urgency=low
+
+ * Make couchdb user own its run directory (closes: #681549).
+
+ -- Laszlo Boszormenyi (GCS) g...@debian.hu Thu, 19 Jul 2012 20:13:25 +0200
+
couchdb (1.2.0-1) unstable; urgency=low
* New major upstream release (closes: #672141).
diff -Nru couchdb-1.2.0/debian/patches/couchdb_own_rundir.patch couchdb-1.2.0/debian/patches/couchdb_own_rundir.patch
--- couchdb-1.2.0/debian/patches/couchdb_own_rundir.patch 1970-01-01 01:00:00.0 +0100
+++ couchdb-1.2.0/debian/patches/couchdb_own_rundir.patch 2012-07-19 20:57:00.0 +0200
@@ -0,0 +1,18 @@
+Description: Initscript creates RUN_DIR , make sure it's owned by couchdb
+ Add chown after the mkdir to make COUCHDB_USER own the RUN_DIR being created.
+Author: Laszlo Boszormenyi (GCS) g...@debian.hu
+Bug-Debian: http://bugs.debian.org/681549
+Last-Update: 2012-07-19
+
+---
+
+--- couchdb-1.2.0.orig/etc/init/couchdb.tpl.in
couchdb-1.2.0/etc/init/couchdb.tpl.in
+@@ -84,6 +84,7 @@ start_couchdb () {
+ # Start Apache CouchDB as a background process.
+
+ mkdir -p $RUN_DIR
++chown -R $COUCHDB_USER $RUN_DIR
+ command=$COUCHDB -b
+ if test -n $COUCHDB_STDOUT_FILE; then
+ command=$command -o $COUCHDB_STDOUT_FILE
diff -Nru couchdb-1.2.0/debian/patches/series couchdb-1.2.0/debian/patches/series
--- couchdb-1.2.0/debian/patches/series 2011-11-27 09:19:17.0 +0100
+++ couchdb-1.2.0/debian/patches/series 2012-07-19 20:46:55.0 +0200
@@ -1 +1,2 @@
force-reload.patch
+couchdb_own_rundir.patch
Bug#658139: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
Answering to my own mail. On Tue, 2012-07-17 at 05:38 +, Laszlo Boszormenyi (GCS) wrote: On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote: 2) Install in Alioth's collab-maint a git repository made with the --debsnap option of git-import-dscs, unless we try to go deeper in time ? Set up commits emails to go to the PTS. I've created an empty git collab-maint repository on Alioth, still not visible over the web interface. As I know, it just need some time. It is now visible: http://anonscm.debian.org/gitweb/?p=collab-maint/mime-support.git;a=summary Empty at the moment. I used git-debimport , the result is at GitHub for review: https://github.com/gcsideal/mime-support If it's OK, I'll rebase to git.debian.org . Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Bug#658139: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
Hi Cyril, On Mon, 2012-07-16 at 22:49 +0200, Cyril Brulebois wrote: Charles Plessy ple...@debian.org (16/07/2012): If nobody else volunteers, I propose to start a maintenance group for the mime-support package, that I would store in a Git repository on Alioth's collab-maint group. Just for the record, Charles has an advanced knowledge regarding MIME in general. Hope we can work together. I think that's a perfect use case for collab-maint. László, do you really need a dedicated group for that? My intention was to limit people who can commit to mime-support. It seems there are multiple viewpoints for example about application/x-httpd-* types. One may do more harm with a commit if not consulted by a group of more advanced people. But I'm fine with normal collab-maint as well if you and Charles would like that. Cheers, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Bug#658139: Using FreeDesktop MIME entries directly in mime-support (Re: Fixing the mime horror ini Debian).
On Mon, 2012-07-16 at 23:35 +0200, Cyril Brulebois wrote: Laszlo Boszormenyi (GCS) g...@debian.org (16/07/2012): My intention was to limit people who can commit to mime-support. It seems there are multiple viewpoints for example about application/x-httpd-* types. One may do more harm with a commit if not consulted by a group of more advanced people. But I'm fine with normal collab-maint as well if you and Charles would like that. As someone processing alioth-related requests, I would find it nice to use collab-maint for such projects; but I'm willing to hear about arguments against that. As a random developer, I would really hate to see people fight through commits. In case that would happen, I think that can be fixed, IIRC collab-maint has some abuse clauses or something similar. (IOW: I'm not convinced you need a dedicated group; quite the contrary.) I already wrote my reason and that a normal collab-maint place is fine with me. So I just need to login to git.debian.org and create a repository under /git/collab-maint/ right? Charles, I would add myself as Maintainer and you as an uploader or the vica-versa whichever suits you better. Is this OK with you? Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Bug#658139: Collaborative maintenance of mime-support (was Re: Using FreeDesktop MIME entries directly in mime-support).
On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote: how about the following (inspired by http://dep.debian.net/deps/dep2/) Maintainer: mime-supp...@packages.debian.org Uploaders: Laszlo Boszormenyi (GCS) g...@debian.org, Charles Plessy ple...@debian.org, Hope Brian will also join. May we add you? I propose the following action plan. 0) We subscribe to the PTS (done for me). For me as well, I assume Brian is also subscribed. 1) Upload to experimental an adopted package with the updated maintainer and uploaders list, the VCS fields updated, and the patch for #497779 applied. +1 2) Install in Alioth's collab-maint a git repository made with the --debsnap option of git-import-dscs, unless we try to go deeper in time ? Set up commits emails to go to the PTS. I've created an empty git collab-maint repository on Alioth, still not visible over the web interface. As I know, it just need some time. Made the config to send commits to the PTS. So, how deep should be the package import? The full history from snapshot.debian.org or just the last upload is enough? We will have the file history, but not the comment why happened and what. 3) Make crystal clear in the source package's READMEs that uncoordinated commits are an abuse of the collab-maint Alioth group. But perhaps we can allow developers to create topic branches related to bugs in the BTS if they like ? +1 , but I assume you know that others may create free and public git trees elsewhere, for example on GitHub. They may send a merge request when their work is done. The tree is still visible, separated and can be merged if needed. 4) Postpone any other change on the main branch until either #681687 (tech. comittee) is solved or Wheezy released. +1 Lastly, I would like to thank Brian for his impressively 16-years long work on mime-support. Brian, feel free to stay among the uploaders ! I join as well. Thanks Brian for your previous work! Hope you will be still close to the package and the recent events don't turn you down. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678987: vice: Shift-up not recognized under KDE4
Hi Torsten, On Mon, 2012-06-25 at 17:13 +0200, Torsten Crass wrote: when running any of the VICE programs x64, x64sc, x128, xvic or xplus4 under KDE4, the emulator seems to get stuck in shift pressed mode after any of the shift keys is, well, pressed. In other words: once a shift-ed character has been typed, all following key presses will also be interpreted as shiftet, no matter whether the shift key has meanwhile be released or not. The problem seems to occur under KDE4 only; when I tried x64 under XFCE or a plain Openbox session (without KDE4), the shift key worked as expected. Please note that xpet and xcbm2 are not affected by this problem. Strange bug, happens with Enlightenment 0.17 as well. Please test me something. Start your emulator of choice and press shift. Now all coming chars are shifted. Then only move the mouse cursor out of the emulator window, then back. Type some characters again. Are they normal or still shifted characters? Thanks, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678942: linux-patch-grsecurity2: doesn't apply against Debian kernel sources, documentation misleading
Hi Yves-Alexis, On Mon, 2012-06-25 at 11:17 +0200, Yves-Alexis Perez wrote: I noticed your upload of the latest Grsecurity patches to Debian. While I would very much like to have decent Grsecurity support in Debian, I'm not quite sure this package, in the current state, really helps that (I'm not sure shipping the patch itself makes sense anyway). Users without decent internet connection may need this. Right now, the documentation mentions dh-kpatches and make-kpkg, and implies the patch could be applied to the Debian sources. That's just wrong. No, please see README.2.4.2x . It states that since 2003, it just won't apply to Debian kernels. First you have to unpatch the Debian modifications. Right now, the only difference with downloading upstream sources directly seems to be that you lack the GPG signature. Again no, please see the source package, which contains the GPG signatures. I guess you might want to tune the package, either to adapt it to debian sources, or to properly document how to build the kernel (replacing make-kpkg by make deb-pkg for example), or maybe something else. Maybe the package needs a tool added, which build the vanilla kernel with grsecurity applied. But I'm afraid right now the package, although now up2date, is just useless and confusing for users. What do you propose? Drop make-kpkg stuff and add an own build tool? Sorry if the tone is a bit rude, it's not intended, I'm very much interested in ways to improve Grsecurity support in Debian. Until we can discuss the views of the package, I don't count it as rude. Please note that it would require way too much expertise and time to always merge Debian changes with grsecurity. All in all, I think SELinux is more common if you need restrictions on your Linux OS. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678699: ITP: sidplayfp -- Fork of sidplay2, a C64 and C128 music player
Package: wnpp Owner: Laszlo Boszormenyi (GCS) g...@debian.hu Severity: wishlist * Package name: sidplayfp Version : 0.3.1 Upstream Author : Leandro Nini drfiem...@users.sourceforge.net * URL : http://bel.fi/~alankila/c64-sw/index-cpp.html * License : GPL-2.0+ Programming Lang: C++ Description : Fork of sidplay2, a C64 and C128 music player sidplayfp is a fork of sidplay2, a C64 music player which integrates the reSID SID chip emulation into a cycle-based emulator environment, started with primary purpose to improve emulation of the C64 system and the SID chips. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678700: ITP: libsidplayfp -- Library to play Commodore 64 music based on libsidplay2
Package: wnpp Owner: Laszlo Boszormenyi (GCS) g...@debian.hu Severity: wishlist * Package name: libsidplayfp Version : 0.3.5 Upstream Author : Leandro Nini drfiem...@users.sourceforge.net * URL : http://bel.fi/~alankila/c64-sw/index-cpp.html * License : GPL-2.0+ Programming Lang: C++ Description : Library to play Commodore 64 music based on libsidplay2 Libsidplayfp (and its console frontend sidplayfp) is a fork of sidplay2 born with the aim to improve the quality of emulating the 6581, 8580 chips and the surrounding C64 system in order to play SID music better. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678644: Outdated version of Zoph in Debian
Hi Henrique, Jeroen, On Sat, 2012-06-23 at 13:05 -0300, Henrique de Moraes Holschuh wrote: On Sat, 23 Jun 2012, Jeroen Roos wrote: I am the maintainer of Zoph, a webbased program to organize photos. ... The current version in Debian has several issues, including a few security-related of which some are severe. All of these are fixed in the latest release, 0.9 which will be released today. As I see, 0.9 is released then. Looking into the feature list, it would be a shame to let it fade away. Because Edelhard seems to be unwilling and/or unable to fix this, I am requesting you to either find a new maintainer or remove it from the package database. Although I'm not one of its users, but will package 0.9 after I slept a bit. I was looking for a similar program _on the desktop_. Couldn't find any, even if I know Shotwell. Popcon says that the outdated Debian package doesn't have many users: http://qa.debian.org/popcon.php?package=zoph Jeroen, can you share some insight? Users gave up on the outdated package, it's just not known, has some drawbacks? If the current maintainer (or a new maintainer) doesn't show up very soon with an upload of the new upstream version, it is probably best to remove it from Debian, as apparently the users have already given up on the Debian-packaged zoph and are probably using upstream packages directly. I'm asking for advice. To be honest, #556573 [1] needs some luck to be fixed for Wheezy. There's an usability bug, as one dependency of Zoph is not even packaged. As I see, the NEW queue is long, even if I package that, may not reach testing and then stable. Without that, the very first step, importing photos won't work. May the FTP Team be asked to review and hopefully accept that Perl package per priority? What are RMs say? Regards, Laszlo/GCS [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556573 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677626: ceph - Unwarranted restriction of architectures
Hi Bastian, Alessio, On Fri, 2012-06-15 at 15:33 +0200, Bastian Blank wrote: The ceph upload in NEW tells: | * Limit archs to build on as leveldb dependency doesn't support all. The leveldb package is clearly not restricted to specific architectures, so this is not allowed. While I agree with this, I don't see the point how leveldb and ceph will migrate to testing. In my opinion, leveldb should be limited to architectures that it builds on. Do the porting in the background and enable others when they are ready. If I upload ceph and it can't be built because of leveldb doesn't support that particular architecture, then the effect is similar. I just put a job on buildds that it won't even start. In short, what's the leveldb plans for Wheezy? Will it build on all archs? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676912: ITP: libs3 -- C Library and Tools for Amazon S3 Access
Package: wnpp Owner: Laszlo Boszormenyi g...@debian.hu Severity: wishlist * Package name: libs3 Version : 2.0 Upstream Author : Bryan Ischo br...@ischo.com * URL : http://libs3.ischo.com/index.html * License : GPL-3 Programming Lang: C Description : C Library and Tools for Amazon S3 Access Includes the libs3 shared object library, needed to run applications compiled against libs3, and additionally contains the s3 utility for accessing Amazon S3. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672141: couchdb: Please package the new upstream version 1.2
Hi, On Fri, 2012-06-01 at 03:38 +0900, Kouhei Maeda wrote: I build CouchDB 1.2.0 If László-san wouldn't upload it, I want to upload it as NMU. I've packaged it a while. But realized that it contains other projects under src/ . Including Snappy and YAJL both are already packaged in Debian. This means code duplication in CouchDB and the risk that a CVE would remain unfixed in them, as they are hidden from the security team. I've already asked upstream about this, but can't recall if I get an answer. :( I would like to build CouchDB with the packaged libraries. Can't find out how I may achieve this. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662637: closed by Laszlo Boszormenyi (GCS) g...@debian.hu (Bug#662637: fixed in php-suhosin 0.9.33-2)
Hi Alexander, Jan, On Tue, 2012-05-29 at 22:28 +0200, Alexander Wirt wrote: On Tue, 22 May 2012, Jan Wagner wrote: we (Alexande and I) wished, that an adopter had contacted us about his intention befor just uploading a new package. It was not really my intention to do it silent. I've serious email problems for a while. My Evolution crashes on startup and can't fix it. It calls a function which ends in glibc functions, coded in x64 assembly. Now I installed it in a Wheezy chroot. Still not good, but better than nothing. Anyways .. looking into your php54_fixes.patch doesn't convince me, that is a appropriate fix. For more info please have a look into: In short, I know it's not a finished and polished patch. Stefan Esser gave no ETA for the finished PHP 5.4 support. All I would like to give users a chance to evaluate it, find things that may break and so on. Wheezy freeze is coming and Suhosin needs testing, even if not yet ready for production environments. Ok, given your bad done uploads I revert the maintainership back to us. Tomorrow I'll upload the package back to the state of 0.9.33-1. It was a RFA and you never talked about it to us. And you made exactly the errors we wanted to prevent. While I agree that 0.9.33-2 contained a bad mistake, I would like to learn and fix everything as soon as possible. Of course, it's your call if you give me a helping hand in this or take over the package. Thanks for your patience. Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Bug#672678: (cryptmount #672678) unmet dependency on libdevmapper
Hi all, On Thu, 2012-05-24 at 02:50 +0300, Touko Korpela wrote: On Wed, May 23, 2012 at 11:31:33PM +0300, Touko Korpela wrote: This bug blocks lvm2 from migrating to testing. Maybe cryptmount should temporarily removed from testing? Or are tools wrong, and lvm2 update don't make situation any worse than it's now? Has release managers opinion about this? I'm the sponsor of Richard, the maintainer of cryptmount. He has fixed this issue some days ago and asked me about to upload that. However it changes old debian/copyright entries. He changes the 'closes: #xxx reason' lines to 'reason, closes: #xxx' ones. It's a bit unclear for me if it's advised or not. Can't recall any policy about this, but AFAICR, it should not be changed. In short, may I upload the package despite the altering of changelog wording? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658228: downgrade php5-suhosin bug severity
package php5-suhosin severity 658228 important thanks Hi, Asked for more information, none given for a month. Known workaround exists. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672575: sqlite3: Please drop build dependency on hardening-wrapper
Hi Mike, On Sat, 2012-05-12 at 10:00 +0200, Mike Hommey wrote: Since you're using /usr/share/dpkg/buildflags.mk and export its CFLAGS, you don't need that. You may need to add DPKG_EXPORT_BUILDFLAGS=1, though, for the LDFLAGS, but you don't need DEB_BUILD_HARDENING. What's wrong with hardening-wrapper? If I drop it, even with DEB_BUILD_HARDENING set to 1, I get a normal executable and not a position independent executable. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670999: ITA: libapache2-mod-geoip
retitle 670999 ITA: libapache2-mod-geoip -- GeoIP support for apache2 thanks I've a new package version which compiles clean to Apache 2.4 but needs testing. Hopefully will upload in some days. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665363: sqlite3: diff for NMU version 3.7.11-2.1
Hi Tobias, On Mon, 2012-04-30 at 09:59 +0200, t...@coldtobi.de wrote: I've prepared an NMU for sqlite3 (versioned as 3.7.11-2.1) and will upload (via sponsor) to DELAYED/10. Please feel free to tell me if I should delay it longer. I'm on this issue, an NMU is not necessary. Will upload a new package version today. Upstream is not really communicative on this issue, so the best will be to disable the usage of malloc_usable_size() . Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665363: Bug#664078: transition: tokyocabinet
Hi Julien,
On Sun, 2012-04-29 at 19:05 +0200, Julien Cristau wrote:
On Wed, Apr 11, 2012 at 08:07:54 +0200, Tobias Frost wrote:
seems that bogofilter can be fixed soon, it seems that Steven found an
workaround in the sqlite3 library. (See #665363)
What's up with that?
The bug lies in SQLite3, in commit 2e8ab3cedf [1]. As src/mem1.c
adds malloc_usable_size() to sqlite3MemSize() to get the available
memory to use. On my amd64 system, malloc() calls are rounded up to n*24
bytes and that size may be usable. However as the manpage states:
Returns the number of bytes available in the dynamically
allocated buffer ptr, which may be greater than the requested
size (but is guaranteed to be at least as large, if the request was
successful). Typically, you should store the requested allocation
size rather than use this function.
So in general nothing is wrong if you use the size reported by this
function. However when you set MALLOC_CHECK_ to 1 or 2, glibc enforces
the requested size. This is where the problem lies. SQLite3 use the
memory normally, a bit larger size than originally requested but not
more than the maximum available. This is normal and doesn't cause memory
corruption. But when asked via the MALLOC_CHECK_ setting, glibc detects
the difference and issue a warning only (=1) or aborts (=2).
Bogofilter asks for this check in src/tests/t.frame in line 173 and 174.
It may be debatable where to fix this. Do not set glibc malloc
enforcement in Bogofilter or disable this memory use in SQLite3 itself.
Let's go on with the latter.
By the way, attached a small example that demonstrates this problem on
64 bit archs. Compile with 'gcc -o check check.c' and run check with
MALLOC_CHECK_ set to 0 and later set to 2.
Regards,
Laszlo/GCS
[1] http://www.sqlite.org/src/info/2e8ab3cedf
#include stdio.h
#include stdlib.h
#include malloc.h
#include string.h
int main(void)
{
void *p = NULL;
size_t size = 7;
/* allocate a small size of memory and inform the user */
printf(Size to malloc(): %u\n, size);
p = malloc(size);
/* check how much memory we got */
size = malloc_usable_size(p);
printf(Size reported by malloc_usable_size(): %u\n, size);
/* use that memory */
memset(p, 0x0, size);
/* we don't need the memory anymore */
free(p);
/* just inform the user about the exit */
printf(Program ends normally.\n);
return 0;
}
Bug#666099: google-perftools: makes ceph FTBFS due to a packaging problem
Package: google-perftools Version: 2.0-1 Severity: important Tags: patch Hi Daigo, Some header files are moved to a different location with the 2.0 upstream release. They are not packaged, which makes my package, ceph FTBFS. The attached patch fixes the problem. Please upload a new package revision. I may NMU it after a week if I don't get a response from you. Thanks, Laszlo/GCS --- google-perftools-2.0/debian/rules 2012-03-28 18:54:06.0 +0200 +++ google-perftools-2.0-1.1/debian/rules 2012-03-28 18:47:19.753363781 +0200 @@ -28,7 +28,7 @@ DEB_INSTALL_DIRS_libgoogle-perftools4 += $(lib_dir) DEB_INSTALL_DOCS_libgoogle-perftools4 += debian/README.Debian -DEB_INSTALL_DIRS_libgoogle-perftools-dev += $(lib_dir) usr/include/google +DEB_INSTALL_DIRS_libgoogle-perftools-dev += $(lib_dir) usr/include/google usr/include/gperftools DEB_INSTALL_DOCS_libgoogle-perftools-dev += $(DEB_SRCDIR)/doc/* -Xpprof.1 DEB_INSTALL_DIRS_google-perftools += $(bin_dir) $(man_dir) @@ -56,6 +56,7 @@ find usr/lib -name '*.a' -o -name '*.so') | \ xargs dh_movefiles -p$(cdbs_curpkg) dh_movefiles -p$(cdbs_curpkg) usr/include/google + dh_movefiles -p$(cdbs_curpkg) usr/include/gperftools install/google-perftools:: (cd $(CURDIR)/debian/tmp/usr/bin \
Bug#661270: muffin packaging
Hi Bas, Clement, I've always looking for experience with Linux Mint. I'm a Debian Developer and such, I don't want to leave it. I've started packaging Cinnamon and dependencies. Muffin packaging is ready, even if it still has some edges. Looking for two things. First is an official release of Muffin 1.0.2 . Downloaded the git tag, but that's suboptimal I think. Also I would like to ask for review and testers of packages. Bas has the ITP for muffin, but can't see any activity from him. May I take over of #661270 ? Beware, I don't have experience with Cinnamon and I may not maintain it in the long run if I'm disappointed with it. Cheers, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665363: bogofilter FTBFS with newer sqlite3 package versions
Hi, I have compiled both SQLite3 and bogofilter in a not so up-to-date testing chroot, I could triage it down to the memory model usage in SQLite3. It seems the normal malloc()/free() usage is failing there. As it has support for memory pools and when I've switched to it, everything was working. On the other hand, in an up-to-date unstable chroot, no matter what memory model I choose. Building bogofilter always fail the same way. However sqlite3 binary is fixed when compiled with the lookaside (pooling) memory model. In short, it seems some other factors involved in this bug. Checking existing bugreports and current SCM tree for fixes. Then will contact upstream. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657796: sidplay-libs: diff for NMU version 2.1.1-11.1
Hi Benjamin, On Sat, 2012-02-04 at 23:23 +0100, Benjamin Drung wrote: I've prepared an NMU for sidplay-libs (versioned as 2.1.1-11.1) and uploaded it to DELAYED/5. I've updated the package, but it's again middle of the night when I tend to make mistakes. Waiting for your feedback if it makes VLC compile cleanly or not. I'll update the debian/rules clean target, but that should not affect you. If your feedback is positive, I'll upload this version. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657796: sidplay-libs: diff for NMU version 2.1.1-11.1
On Sat, 2012-02-04 at 23:23 +0100, Benjamin Drung wrote: I've prepared an NMU for sidplay-libs (versioned as 2.1.1-11.1) and uploaded it to DELAYED/5. Yes, mistakes. Package is at: dget -x http://www.routers.hu/gcs/sidplay-libs_2.1.1-12.dsc /GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607969: Ping re sqlite removal?
Hi Micah, On Mon, 2012-02-06 at 22:07 -0600, Micah Gersten wrote: On 08/28/2011 12:03 AM, Laszlo Boszormenyi wrote: On Sat, 2011-08-27 at 21:32 -0500, Micah Gersten wrote: Just noticed this bug, and as Squeeze has been released, is it time to remove this? Indeed, sqlite should be removed. It's unsupported a long time ago. The last upstream release was on 19th December of 2005 (yes, almost six years ago)[1]. [1] http://www.sqlite.org/changes.html Did you want me to file the removal bug? Will do it in the afternoon with other related bugreports. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656346: cryptmount --prepare fails Debian bugreport
tags 656346 - l10n severity 656346 thanks Hi all, First, forgive me Richard, as this is not my bug report but le me share my thoughts. It seems you both overlook two things. First, there won't be libc.mo in en nor in en_US directories. Programs print messages in English and such, don't need to translate to the same language. Also libc.mo is _not_ for cryptmount, but for locales. It would be cryptmount.mo and it is for French and German translations. Removing l10n tag. The real problem is this: Jan 16 20:33:04 far-star kernel: [ 690.357274] device-mapper: table: 254:0: crypt: Error allocating crypto tfm Jan 16 20:33:04 far-star kernel: [ 690.357284] device-mapper: ioctl: error adding target to table It means, he has a configuration which needs a cryptographic module for the kernel. It can't be loaded or simply does not exist. Please post the following: $ grep cipher /etc/cryptmount/cmtab $ cat /proc/crypto Try to load the mentioned crypto modules mentioned in the cipher, ie: # modprobe aes Then try 'cryptmout --prepare'. Hope this will fix your problem. Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Bug#654662: FTBFS: pkgIndex.tcl seems to be wrong
Hi Thorsten, On Thu, 2012-01-05 at 00:09 +, Thorsten Glaser wrote: Source: sqlite3 Version: 3.7.9-3 Severity: serious Justification: fails to build from source (but built successfully in the past) with my “m68k buildd” hat on, your package FTBFS. It also does that on most release architectures, with the same error: It was built previously, but the pkgIndex.tcl was generated incorrectly. I've added a self test (mentioned in the changelog) for this. Will ask for a chroot environment on m68k (or on any arch where it fails) to figure out the exact reason. Seems I'll leave today, but hopefully I'll be back on Sunday. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650961: libsqlite3-tcl: pkgIndex.tcl is empty and can not be generated
On Sun, 2011-12-04 at 19:51 +0300, Alexander Galanin wrote: File /usr/lib/tcltk/sqlite3/pkgIndex.tcl is empty, so package sqlite3 can not be loaded in Tcl programs. Indeed. On all platforms, it doesn't contain the package ifneeded ... line. A simple rebuild fixes this issue. I've asked the release team for a binary NMU, but they are on hold at the moment. I'm not home ATM and will arrive back on 30th only. Will ask them for a binNMU again. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650961: libsqlite3-tcl: pkgIndex.tcl is empty and can not be generated
tag 650961 + unreproducible moreinfo thanks Hi Alexander, On Sun, 2011-12-04 at 19:51 +0300, Alexander Galanin wrote: Version: 3.7.9-2 Severity: grave File /usr/lib/tcltk/sqlite3/pkgIndex.tcl is empty, so package sqlite3 can not be loaded in Tcl programs. What do you mean by empty? Zero length or just comments? Strange is that it has comments only for me and does not have package ifneeded sqlite3 3.7.9 [list load [file join $dir libtclsqlite3.so]] in it. I am unable to generate this file by hands because command # echo 'pkg_mkIndex -verbose' | sudo tclsh8.5 gives the following error: warning: error while loading libtclsqlite3.so: couldn't load file libtclsqlite3.so: libtclsqlite3.so: cannot open shared object file: No such file or directory I can't reproduce it. For me # echo 'pkg_mkIndex -verbose' | sudo tclsh8.5 gives: no files matched glob patterns *.tcl *.so while still on amd64 arch. If I rebuild it in an up-to-date chroot, then the 'package ifneeded [...]' line is present. I may ask for a binary only rebuild, but I'm not sure that's your problem. Try to add the mentioned line to your pkgIndex.tcl . But file is present and ldd-able: What kind of *.tcl files do you have in your current work directory? If you are already root (prompt is #), why do you use sudo? What do you get with the # echo 'pkg_mkIndex -verbose' | tclsh8.5 command? Can you post the output of the $ dpkg -l tcl8.5 command? -- System Information: Debian Release: wheezy/sid APT prefers testing Is your system up-to-date? Do you have pending packages or anything on hold? Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650394: preliminary tigervnc 1.1.0 package
Hi Yaroslav, I've made a preliminary tigervnc package[1]. It builds and seems to be working. However it has some problems, like debian/copyright is not DEP5 compatible and due to upstream issues it can't be build two times in a row. Even worse, upstream tarball contains embedded code of libjpeg and zlib1g. Only libjpeg seems to be used from the system. Cheers, Laszlo/GCS [1] dget -x http://www.routers.hu/gcs/tigervnc_1.1.0-1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642584: [FTBFS] sqlite3: Mismatching at libsqlite3-0.symbols
package sqlite3 tag 642584 + moreinfo thanks Hi Hiroyuki, On Sat, 2011-09-24 at 16:25 +0900, Hiroyuki Yamamoto wrote: Package: sqlite3 Version: 3.7.8-1 Severity: serious Tags: patch Mismatching at libsqlite3-0.symbols. Can you be please be more specific? According to the Debian buildds[1], it builds on all architectures. Regards, Laszlo/GCS [1] https://buildd.debian.org/status/logs.php?pkg=sqlite3arch=alllver=3.7.8-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
