Bug#733564: pu: apache2 with ECDHE support
Am Montag, 30. Dezember 2013, 15:23:17 schrieb Kurt Roeckx: On Mon, Dec 30, 2013 at 01:41:31PM +0100, Cyril Brulebois wrote: Stefan Fritsch s...@sfritsch.de (2013-12-30): Am Sonntag, 29. Dezember 2013, 23:58:54 schrieb Kurt Roeckx: Adding ECDHE support in apache will probably require backporting the patches for that. I'm not sure how much work that is going to be and wether someone like redhat might have already done that. I don't know how quickly upgrades are ususally adopted in MacOS land, but considering that 10.8.5 is out I think it would be even acceptable to update apache without that openssl workaround, as long as the readme contains exact instructions how to disable ECDHE in case of problems. But of course having the openssl workaround would be even better. Some statistics at http://update.omnigroup.com/ (click on minor versions for 10.8) gives 16.1% of macosx users using 10.8.x and 1.3% using 10.8.x with x = 3. Personally, I don't think we need special provisions for those 1.3% of macosx users, which is = 0.1% of total users. But I would of course be fine with Kurt backporting the workaround. If we're going to end up adding ECDHE support, and if it isn't supported everywhere yet, I'm pretty sure support for it all shouldn't be enabled automatically upon upgrades, and that it should be enabled manually by admins instead, following instructions that include incompatibility warnings (hello, page 51 of the draft at https://bettercrypto.org/). If you want an overview of what browser support, you can see see that on ssllabs. The only way I know of getting that info for other browser is going to a random website and then selecting the browser. About the only thing not supporting ECDHE is java 6 and internet explorer on windows XP. Internet explorer is also the only one that doesn't have ECDHE (or even DHE) at the top the prefered ciphers. Browser support in itself is not the interesting factor here. We are not disabling other ciphers, so clients not supporting ECDHE will just continue to work. The question is how many browsers have broken implemetations AND still use it as the preffered cipher. And the only ones that we know of are those MacOS versions mentioned above. I would however not go the way of requiring the admin to explicitly enable support on upgrades. The problem is that the default configured cipher suite is HIGH:MEDIUM:!aNULL:!MD5 which includes ECDHE if supported. To make the change opt-in, we would either need to change the conffiles during upgrade, I would like to avoid, or we would need to make the configuration incompatible with upstream by requiring something special. I would like to have another upgrade for apache2 for the next wheezy point release in any case. Therefore I would appreciate some feedback from the release team if they would accept a change to include ECDHE support. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735202: speakup freezes system when trying to paste
Ben, I downloaded upstream kernel 3.12.17 and reproduced the issue. Then I patched it and using this patched kernel I see no ways to reproduce the issue. Pasting always works, even in scenario reported in bug #744015. Now I'll try to reproduce this other bug with and without the patch with kernel 3.14. Paul, thanks for the snapshot link. I couldn't find this useful archive by myself. I wanted to add that preparing a kernel from source works like a charm. I haven't seen any project that would be easier to build. It takes quite long, that's a different story. 11 hours. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744015 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740375: transition: poppler 0.24
On Mon, Apr 7, 2014 at 17:49:15 +0200, Pino Toscano wrote: - gdcm cannot be built on s390x due to the ongoing (and un-ACKed...) mpich transition (#742821), so maybe that transition should be brought forward (luckly it affects mostly s390x and mips/mipsel) So I've rebuilt boost1.54 to be able to rebuild vtk to be able to rebuild gdcm. Not much luck there, vtk FTBFS. Cheers, Julien signature.asc Description: Digital signature
Bug#744102: debian-maintainers: Please add Graham Inggs as a Debian Maintainer
Package: debian-maintainers Severity: normal Please add my key to the DM keyring, the jetring changeset is attached. add-AFCFEC8E669CE1C2 Description: Binary data
Bug#470900: pulseaudio: switching forth the sink - ok, switch back - hangs client(s)
Pe 04.04.2014 22:42, Felipe Sateler fsate...@debian.org a scris: Hi, Eddy Petrișor wrote: Sjoerd Simons a scris: On Tue, Apr 08, 2008 at 09:32:59AM +0300, Eddy Petri??or wrote: Could it have to do with the fact the remote sink was running etch's pulseaudio while the local was lenny's? The local machine was an amd64 running lenny, while the remote was and i386 running etch. I am still wondering if this is the cause. Is there any backport of PA? (I need to bring my laptop to work, which I don't do that often lately, but will report back when I'll take it.) Any updates on this ? Sorry, currently is really difficult for me to test this issue. OTOH I can try to test using my and my wife's laptop, although the set up might be different since they both run amd64 lenny. This bug is very old, and was reported against a very old version of pulseaudio. Can you still reproduce this issue? If yes, please reply so we can debug it. Otherwise I will close this bug if you can't reproduce it anymore, as it may have been fixed already. Please close it. It is almost impossible for me to reproduce this in a reasonable time frame due to various factors. -- Saludos, Felipe Sateler
Bug#729696: gearman-job-server: locks up quickly
Hello there, On Fri, Nov 15, 2013 at 11:33:23PM +0100, Florian Ernst wrote: [...] I see that the NEW queue contains 1.0.6-3, but from the changelog I wouldn't expect this version to make any difference wrt the experienced Well, I tested, and it didn't. breakage. However, I'm at liberty to test/debug freely, so if there is anything I should try please don't hesitate to mention it. Considering the lack of response, I take it there isn't anything I could or should do? That'd be a shame, as for me (and presumably not only for me) gearman as-is (and thus mod-gearman) became unusable ... Cheers, Flo signature.asc Description: Digital signature
Bug#732427: poppler-utils: 'pdftohtml -v' returns an exit code greater zero
Hi, this seems to be still an issue, even with development versions of Poppler. Would it be possible to report this upstream? https://bugs.freedesktop.org, product poppler and component utils. Thanks for your report, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744011: Bug# #744011: ITP: cpl-plugin-muse -- ESO data reduction pipeline for MUSE
Hi Julian, On Wed, Apr 09, 2014 at 07:11:43PM +0200, Julian Taylor wrote: * Package name: cpl-plugin-muse The software is not officially released yet. However, a prerelease is available on the ESO FTP server. I intend to put this into experimental to collect experiences until the official release is made. Debian is no place for pre-release software you found on some ftp server ... I urge you and your sponsors not to upload it. Every package increases the workload of the QA teams of Debian and its derivatives. In how far are packages in experimental increasing the workload ot the QA teams (which one(s) do you mean exactly) and its derivatives? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744066: AW: Bug#744066: scli: use autotools-dev to update config.{sub,guess} for new arches
-Ursprüngliche Nachricht-
Von:Logan Rosen lo...@ubuntu.com
Dear Maintainer,
Please use autotools-dev to update config.{sub,guess} for new architectures.
For example, we needed these updates in Ubuntu for the new arm64 and ppc64el
architectures.
Hi Logan,
I would like to use dh_autoreconf instead of autotools-dev. That should also be
acceptable - right?
Cheers.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743332: Also afects DN mentioned as remote IDs in config file
It is my understanding that the patch supplied only fixes IDs for DNs extracted from certs. What about IDs from DNs mentioned as (left|right)id in config file? As far as I can see, they get scrambled too. Scenario is a CA-based authentication where each peer is using a CA-signed cert and leftid=%fromcert. Rightid is set to double-quoted remote peer's DN, which now shows as a binary (0x) string in 'ipsec auto --status' whereas it used to be the human-readable before. O course, this breaks connections too What should I patch to oevercome this? Thanks regards Guillaume
Bug#741548: mruby FTBFS: build failed on post-compile-test on mips/mipsel
Hello Nobuhiro and Akira,
At Imagination Technologies (http://imgtec.com) Dejan Latinovic have
found a solution to Debian bug #741548.
https://bugs.debian.org/741548
My NMU patch for mruby_1.0.0-1.1 is below, at the end of this message.
With the changes in the NMU patch mruby builds successfully on mips,
mipsel and amd64.
Please let me know if I should not go ahead with this NMU.
Regards,
Aníbal
--
Aníbal Monsalve Salazar anibal.monsalvesala...@imgtec.com
debdiff mruby_1.0.0-1.dsc mruby_1.0.0-1.1.dsc
diff -Nru mruby-1.0.0/debian/changelog mruby-1.0.0/debian/changelog
--- mruby-1.0.0/debian/changelog2014-03-21 16:33:35.0 +
+++ mruby-1.0.0/debian/changelog2014-04-10 07:48:08.0 +0100
@@ -1,3 +1,13 @@
+mruby (1.0.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Define log of zero.
+Add define-log-of-zero.patch.
+Patch by Dejan Latinovic.
+Closes: #741548
+
+ -- Anibal Monsalve Salazar ani...@debian.org Thu, 10 Apr 2014 07:47:33
+0100
+
mruby (1.0.0-1) unstable; urgency=low
* New upstream release(1.0.0).
diff -Nru mruby-1.0.0/debian/patches/define-log-of-zero.patch
mruby-1.0.0/debian/patches/define-log-of-zero.patch
--- mruby-1.0.0/debian/patches/define-log-of-zero.patch 1970-01-01
01:00:00.0 +0100
+++ mruby-1.0.0/debian/patches/define-log-of-zero.patch 2014-04-10
07:47:23.0 +0100
@@ -0,0 +1,27 @@
+From: Dejan Latinovic dejan.latino...@imgtec.com
+Subject: mruby FTBFS: build failed on post-compile-test on mips/mipsel
+Date: Wed, 9 Apr 2014 15:09:35 +
+
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741548
+
+I have backported changes related to this issue from the newest
+version from github, and created a patch that solves it for
+mips/mipsel.
+
+diff -uNr a/src/numeric.c b/src/numeric.c
+--- a/src/numeric.c2014-01-10 12:49:57.0 +
b/src/numeric.c2014-04-09 15:38:07.0 +
+@@ -141,7 +141,12 @@
+ *(c++) = '-';
+ }
+
+-exp = (int)log10(n);
++if (n != 0.0) {
++ exp = (int)log10(n);
++}
++else {
++ exp = 0;
++}
+
+ if ((exp 0 ? -exp : exp) max_digit) {
+ /* exponent representation */
diff -Nru mruby-1.0.0/debian/patches/series mruby-1.0.0/debian/patches/series
--- mruby-1.0.0/debian/patches/series 2013-12-19 00:46:40.0 +
+++ mruby-1.0.0/debian/patches/series 2014-04-09 07:30:34.0 +0100
@@ -1 +1,2 @@
enable_verbose_build.patch
+define-log-of-zero.patch
signature.asc
Description: Digital signature
Bug#744087: pluma: does not start - missing scheme installation
Hi Adrian, On Thu, 10 Apr 2014, John Paul Adrian Glaubitz wrote: The reason why pluma is still on version 1.6.2 is because it has been in the NEW queue for quite a long time and was packaged and Oookkk, got the point. Know the problem. I normally handle that with uploads to experimental, and as soon as all packages are accepted in experimental I make a new upload to unstable which goes through immediately. That helps to keep unstable a bit stable ;-) Thanks, I will wait for the new releases! Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744103: ecj: failed to build with gcj with_sourcebuild for mips64el
Package: ecj When try to build ecj for mips64el Here, if use gcj-4.8, it will failed with lots of errors set -e; \ for list in $$(find build/bin -name 'ecj-sources.*'); do \ echo building files in $$list ...; \ echo ecj-gcj -d build/bin -C -g \ -I/usr/share/ant$(ant_version)/lib/ant.jar \ -Ibuild/bin \ $$(cat $$list); \ ecj-gcj -v -d build/bin -C -g \ -I/usr/share/ant$(ant_version)/lib/ant.jar \ -Ibuild/bin \ $$(cat $$list); \ done While, when use ecj-gcj, it can built successful. Have no idea why. -- Yunqiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744011: ITP: cpl-plugin-muse -- ESO data reduction pipeline for MUSE
Hi Julian, On 09.04.2014 19:11, Julian Taylor wrote: On 09.04.2014 09:45, Ole Streicher wrote: Package: wnpp * Package name: cpl-plugin-muse The software is not officially released yet. However, a prerelease is available on the ESO FTP server. I intend to put this into experimental to collect experiences until the official release is made. Debian is no place for pre-release software you found on some ftp server ... I do not agree here. From the Debian Developer's reference [1]: The experimental distribution is a special distribution. It is not a full distribution in the same sense as stable, testing and unstable are. Instead, it is meant to be a temporary staging area for highly experimental software where there's a good chance that the software could break your system, or software that's just too unstable even for the unstable distribution (but there is a reason to package it nevertheless). Users who download and install packages from experimental are expected to have been duly warned. In short, all bets are off for the experimental distribution. So, there *is* a designated place for early bird software, and I think it is a good practice to do early releases, even if a software is not complete yet [2]. Debian, and also Ubuntu, have a lot of pre-release software. Just think of Wine, which was in a almost-always-crashing prerelease state for years. I helped to have it in Debian to stabilize. If we would limit Debian to released software, lots of software would never have packaged. Just search for software releases with git or svn in the version string. I urge you and your sponsors not to upload it. Every package increases the workload of the QA teams of Debian and its derivatives. I would put cpl-plugin-muse to experimental until ESO publishes an official release or I myself consider it stable enough for testing. I don't see that this really increases the QA team workload. But the opposite: The package will get some stabilization during its existence in experimental; it will be packaged for different architectures, people will punish it with clang etc. So, when the official version comes out, it will already be a bit mature, actually *decreasing* the workload for the QA team. Is there even any free data for MUSE available? So far I know the proprietary phase for ESO data is one year. Thats when we earliest have any use this software. At least the Science Verification Data will be immediately available [3], enabling users to gain some experiences with the instrument and its pipeline. Best regards Ole [1] https://www.debian.org/doc/manuals/developers-reference/resources#experimental [2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html [3] https://www.eso.org/sci/activities/vltsv/svdoc.pdf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744104: ecj: bootstrap/eclipse-ecj.tar has no
Package: src:ecj
Version: 3.9.0-1
When built on mips64el,
time gij-4.8 \
-classpath
build/bootstrap/eclipse-ecj.jar:/usr/share/ant/lib/ant.jar \
org.eclipse.jdt.internal.compiler.batch.Main \
-bootclasspath /usr/share/java/libgcj-4.8.jar \
build/bin
Exception in thread main java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.Main
at gnu.java.lang.MainThread.run(libgcj.so.14)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.Main not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:build/bootstrap/eclipse-ecj.jar,file:/usr/share/ant/lib/ant.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.14)
at java.lang.ClassLoader.loadClass(libgcj.so.14)
at java.lang.ClassLoader.loadClass(libgcj.so.14)
at gnu.java.lang.MainThread.run(libgcj.so.14)
Command exited with non-zero status 1
After add /usr/share/java/eclipse-ecj.jar, it works now.
--
Yunqiang Su
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744105: audacity: Audacity burns CPU time
Package: audacity
Version: 2.0.5-1
Severity: normal
Dear Maintainer,
When idle, Audacity uses about 2% CPU time needlessly. It doesn't
matter whether freshly started or after closing projects. strace
shows the following repeated endlessly:
recvmsg(3, 0x7fffc8a25860, 0) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6,
events=POLLIN|POLLPRI}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}],
5, 0) = 0 (Timeout)
recvmsg(3, 0x7fffc8a25860, 0) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6,
events=POLLIN|POLLPRI}, {fd=9, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}],
5, 16) = 0 (Timeout)
So the timeout should probably be much higher, especially when
no project is loaded. It should be trivial to reproduce.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages audacity depends on:
ii audacity-data 2.0.5-1
ii libasound21.0.27.2-3
ii libc6 2.18-4
ii libexpat1 2.1.0-4
ii libflac++61.3.0-2
ii libflac8 1.3.0-2
ii libgcc1 1:4.8.2-16
ii libglib2.0-0 2.40.0-2
ii libgtk2.0-0 2.24.22-1
ii libid3tag00.15.1b-10build2
ii libmad0 0.15.1b-8
ii libmp3lame0 1:3.99.5-dmo2
ii libogg0 1.3.1-1
ii libportaudio2 19+svn20140130-1
ii libportsmf0 0.1~svn20101010-4
ii libsbsms102.0.1-1
ii libsndfile1 1.0.25-9
ii libsoundtouch01.7.1-5
ii libsoxr0 0.1.1-1
ii libstdc++64.8.2-16
ii libtwolame0 0.3.13-1
ii libvamp-hostsdk3 2.5+repack0-2
ii libvorbis0a 1.3.2-1.3
ii libvorbisenc2 1.3.2-1.3
ii libvorbisfile31.3.2-1.3
ii libwxbase2.8-02.8.12.1+dfsg2-1
ii libwxgtk2.8-0 2.8.12.1+dfsg2-1
audacity recommends no packages.
Versions of packages audacity suggests:
ii swh-plugins [ladspa-plugin] 0.4.15+1-7
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741548: mruby FTBFS: build failed on post-compile-test on mips/mipsel
Hi, Anibal.
Please go ahead.
Thanks for your work!
Best regards,
Nobuhiro
2014-04-10 16:38 GMT+09:00 Aníbal Monsalve Salazar ani...@debian.org:
Hello Nobuhiro and Akira,
At Imagination Technologies (http://imgtec.com) Dejan Latinovic have
found a solution to Debian bug #741548.
https://bugs.debian.org/741548
My NMU patch for mruby_1.0.0-1.1 is below, at the end of this message.
With the changes in the NMU patch mruby builds successfully on mips,
mipsel and amd64.
Please let me know if I should not go ahead with this NMU.
Regards,
Aníbal
--
Aníbal Monsalve Salazar anibal.monsalvesala...@imgtec.com
debdiff mruby_1.0.0-1.dsc mruby_1.0.0-1.1.dsc
diff -Nru mruby-1.0.0/debian/changelog mruby-1.0.0/debian/changelog
--- mruby-1.0.0/debian/changelog2014-03-21 16:33:35.0 +
+++ mruby-1.0.0/debian/changelog2014-04-10 07:48:08.0 +0100
@@ -1,3 +1,13 @@
+mruby (1.0.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Define log of zero.
+Add define-log-of-zero.patch.
+Patch by Dejan Latinovic.
+Closes: #741548
+
+ -- Anibal Monsalve Salazar ani...@debian.org Thu, 10 Apr 2014 07:47:33
+0100
+
mruby (1.0.0-1) unstable; urgency=low
* New upstream release(1.0.0).
diff -Nru mruby-1.0.0/debian/patches/define-log-of-zero.patch
mruby-1.0.0/debian/patches/define-log-of-zero.patch
--- mruby-1.0.0/debian/patches/define-log-of-zero.patch 1970-01-01
01:00:00.0 +0100
+++ mruby-1.0.0/debian/patches/define-log-of-zero.patch 2014-04-10
07:47:23.0 +0100
@@ -0,0 +1,27 @@
+From: Dejan Latinovic dejan.latino...@imgtec.com
+Subject: mruby FTBFS: build failed on post-compile-test on mips/mipsel
+Date: Wed, 9 Apr 2014 15:09:35 +
+
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741548
+
+I have backported changes related to this issue from the newest
+version from github, and created a patch that solves it for
+mips/mipsel.
+
+diff -uNr a/src/numeric.c b/src/numeric.c
+--- a/src/numeric.c2014-01-10 12:49:57.0 +
b/src/numeric.c2014-04-09 15:38:07.0 +
+@@ -141,7 +141,12 @@
+ *(c++) = '-';
+ }
+
+-exp = (int)log10(n);
++if (n != 0.0) {
++ exp = (int)log10(n);
++}
++else {
++ exp = 0;
++}
+
+ if ((exp 0 ? -exp : exp) max_digit) {
+ /* exponent representation */
diff -Nru mruby-1.0.0/debian/patches/series mruby-1.0.0/debian/patches/series
--- mruby-1.0.0/debian/patches/series 2013-12-19 00:46:40.0 +
+++ mruby-1.0.0/debian/patches/series 2014-04-09 07:30:34.0 +0100
@@ -1 +1,2 @@
enable_verbose_build.patch
+define-log-of-zero.patch
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743332: Info received (Patch for #743332)
* Guillaume Lécroart wrote on 09 Apr 2014: It is my understanding that the patch supplied only fixes IDs for DNs extracted from certs. No! The supplied patch is *not* limited for fixing IDs for DNs extracted from certs. The patch fixes the atodn() function. This function is used for *any* parsing of an ID_DER_ASN1_DN subject: - rightid/leftid in /etc/ipsec.conf - rightcert/leftcert in /etc/ipsec.conf - Parsing of remote Peer ID (on inbound connections) signature.asc Description: Digital signature
Bug#744106: scli/0.4.0-5 [ITP]
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package scli. As always checked
with lintian.
* Package name: scli
Version : 0.4.0-5
Upstream Author :Schoenwaelder, Juergen
(j.schoenwael...@jacobs-university.de)
* URL : www.ibr.cs.tu-bs.de/projects/scli/
* License : GPL
Section : net
It builds those binary packages:
scli - collection of SNMP command line management tools
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/scli
Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/s/scli/scli_0.4.0-5.dsc
More information about *scli* can be obtained from
www.ibr.cs.tu-bs.de/projects/scli/
Changes since the last upload:
* Use autotools-dev to update config.{sub,guess} for new archs
Thanks Logan Rosen (Closes: #744066)
* Setup lintian override as upstream is not providing gpg sigs
Regards,
Stefan Bauer
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743332: Please Ignore my previous message
Sorry, I put too much confidence into make. Re-applied the patch on a clean apt-get source and rebuilt : fixed the issue. patch did not apply automatically though (patch -p1 at the root of the src, got rejected), I just removed the line myself. Thanks for your support BR Guillaume
Bug#744108: mysql-proxy: major memory leak introduced in wheezy
Package: mysql-proxy Version: 0.8.1-1.1+b1 Severity: important The upgrade to wheezy introduced a fairly major memory leak in mysql-proxy. It needs a restart at least once a week to avoid OOM. We are running mysql-proxy with what I expect to be fairly standard options, --plugins=proxy --log-use-syslog --log-level=message and four proxy backends. Upstream claims to have fixed a suitably serious sounding memory leak in 0.8.4 (http://docs.oracle.com/cd/E17952_01/mysql-proxy-relnotes-en/mysql-proxy-news-0-8-4.html), is it possible to backport the patch from there and update the package in stable? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744107: Transmageddon 1.0 crashes at startup : Could not find any typelib for GUdev
Package: transmageddon Version: 1.0-1 Hi, I tried to launch the new transmageddon version (1.0) but I got that error in terminal : ~$ transmageddon ERROR:root:Could not find any typelib for GUdev Traceback (most recent call last): File transmageddon.py, line 33, in module from gi.repository import GUdev ImportError: cannot import name GUdev I am using Debian GNU/Linux Sid with some packages from Experimental Linux debian 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux libc6 2.18-4 Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726965: workaround
Removing acceleration works, in the sense that I get a usable display. However, the speed is ridiculous, it takes almost a second to move a window... with acceleration the old system was instead quite snappy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602944: output filenames should embed standardized datestamps
forwarded 602944 https://bugzilla.gnome.org/show_bug.cgi?id=727940 thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731724: hmm...
Four months passed and a simplest typo still not corrected? Strange.
Bug#744078: [Pkg-telepathy-maintainers] Bug#744078: empathy: Empathy crashes at start
tags 744078 + moreinfo
reassign 744078 libfolks-eds25
found 744078 0.9.6-2
thanks
I think this is most likely to be a Folks bug; reassigning.
On 09/04/14 20:57, Guilhem Bonnefille wrote:
Core was generated by `empathy'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f2c22793bd4 in ?? () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) where
#0 0x7f2c22793bd4 in ?? () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#1 0x7f2c227966c9 in g_date_time_to_timezone ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x7f2c2279673c in g_date_time_to_utc ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x7f2bf54aa302 in _edsf_persona_update ()
from /usr/lib/x86_64-linux-gnu/libfolks-eds.so.25
#4 0x7f2bf54ab9fe in ?? ()
from /usr/lib/x86_64-linux-gnu/libfolks-eds.so.25
#5 0x7f2c22a7f2e4 in ?? ()
from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
I can't reproduce this crash. Please install debugging symbols for at
least GLib and folks (packages: libglib2.0-0-dbg, libfolks-eds-dbg,
libfolks-dbg) and try to get a backtrace again. Using the gdb command
thread apply all bt full instead of where might also provide useful
information.
You can probably see this crash without Empathy by installing
folks-tools and running folks-inspect. If it doesn't crash immediately,
wait a few seconds; if it still hasn't crashed, type individuals at
the prompt and see whether that crashes. If folks-inspect crashes, then
it's confirmed to be a Folks bug.
Upgrading libfolks25, libfolks-eds25 and related packages to the version
from unstable (0.9.6-3) might also be useful.
If you run empathy from a command-line (gnome-terminal or similar), do
you get any warnings before it crashes?
What accounts (local? Google? Owncloud? Facebook? etc.) do you have
configured in evolution-data-server?
Seems related to an arch bug:
https://bugs.archlinux.org/task/39200?string=glibproject=1type%5B0%5D=sev%5B0%5D=pri%5B0%5D=due%5B0%5D=reported%5B0%5D=opened=dev=closed=duedatefrom=duedateto=changedfrom=
That looks as though it could be the same bug. However, the Arch bug
helpfully says In the internet it is stated that... and Since this is
stated to be fixed in 0.9.7... without providing any links or upstream
bug references. Folks 0.9.7 doesn't actually exist yet; if there's a fix
for this in the upstream git repository (which might have confused the
Arch bug submitter by being marked as will be fixed in 0.9.7), then we
can cherry-pick it, but I can't find anything obviously related to this
crash.
Looking at the source code, the only to_utc() calls I can see are here:
var d = new DateTime (Persona._local_time_zone,
(int) bday.year, (int) bday.month, (int) bday.day, 0, 0, 0.0);
if (this._birthday == null ||
(this._birthday != null
!((!) this._birthday).equal (d.to_utc (
{
this._birthday = d.to_utc ();
this.notify_property (birthday);
}
so the only way I can see for that to crash is if d was NULL, which
could happen if one of bday.year, bday.month, bday.day is out-of-range.
Do you have any contacts whose birthday (as seen in Evolution) is an
impossible date like 2000-02-31?
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744109: investigate use of tinyxml in sipxtapi
Package: sipxtapi Version: 3.3.0~test16 The sipxtapi source includes a copy of tinyxml This is not really used and triggers the embedded-library lintian error Can it be moved to the upstream contrib section so it is not in the main source tarball at all? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743810: libcogl20: Visual artifacts in gnome shell activities view
This bug seems to be related to the use of the debian default desktop background (wallpaper). I love it, so I never tried to change it… Using gnome-tweak-tool I realized that the path for the default wallpaper is /usr/share/images/desktop-base/joy.xml The XML points to four different SVGs for different screen resolutions. When I use gnome-tweak-tool to choose /usr/share/images/desktop-base/joy-wallpaper_1920x1080.svg directly I can't reproduce this issue. The same applies to using any other SVG, PNG oder JPG I tried. I can reproduce this issue simply by changing the path for the desktop background to /usr/share/images/desktop-base/joy.xml again. For now I'm going to reassign this bug to desktop-base. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729696: gearman-job-server: locks up quickly
Florian Ernst florian_er...@gmx.net writes: Considering the lack of response, I take it there isn't anything I could or should do? That'd be a shame, as for me (and presumably not only for me) gearman as-is (and thus mod-gearman) became unusable ... I've not seen this on any of my icinga+mod-gearman installations, so I can't reproduce it myself. I've got other problems with mod-gearman/gearmand, but a lock up is not one of them. Apart from turning up log verbosity everywhere, looking at the logs, and trying to send and receive messages manually through gearman-job-server, I'm not sure what to propose. -- Stig Sandbeck Mathisen s...@debian.org signature.asc Description: PGP signature
Bug#741171: Wallpaper on background disappears when I have icons on my desktop
Hey, The problem is not resolved with the last package of gnome-shell, version 3.8.4-8 . It seems that the problem is due to an incompatibility between nautilus (current version 3.8.4-2 in testing) and gnome-shell as icons on the desktop are managed by nautilus. I read on a forum that a user has uninstalled nautilus to replace nemo no longer has the problem.
Bug#744066: scli: use autotools-dev to update config.{sub,guess} for new arches
-Ursprüngliche Nachricht-
Von:Logan Rosen lo...@ubuntu.com
Dear Maintainer,
Please use autotools-dev to update config.{sub,guess} for new architectures.
For example, we needed these updates in Ubuntu for the new arm64 and ppc64el
architectures.
After digging a bit deeper, i agree with your solution. Packages are on the way
to unstable.
Thank you
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744110: vim-gtk: gvim netrw does not correctly ask for password
Package: vim-gtk Version: 2:7.4.225-1 Severity: normal Tags: upstream Dear Maintainer, * What led up to the situation? :e sftp://user@hostname works in vim (asks password in commandline) but does not work in gvim: if x11-ssh-askpass is not installed, it hangs if x11-ssh-askpass is installed it hangs, when the window is closed however, x11-ssh-askpass is spawned. * What exactly did you do (or not do) that was effective (or ineffective)? use public-key authentication Thank you Fulvio Ciriaco -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk /usr/bin/vim is /usr/bin/vim.gtk /usr/bin/gvim is /usr/bin/vim.gtk -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim-gtk depends on: ii libacl1 2.2.52-1 ii libc6 2.18-4 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-02.40.0-2 ii libgpm2 1.20.4-6.1 ii libgtk2.0-0 2.24.23-1 ii libice6 2:1.0.8-2 ii liblua5.1-0 5.1.5-5 ii libpango-1.0-0 1.36.3-1 ii libperl5.18 5.18.2-2+b1 ii libpython2.72.7.6-8 ii libruby1.9.11.9.3.484-2 ii libselinux1 2.2.2-1 ii libsm6 2:1.2.1-2 ii libtcl8.6 8.6.1-6 ii libtinfo5 5.9+20140118-1 ii libx11-62:1.6.2-1 ii libxt6 1:1.1.4-1 ii vim-common 2:7.4.225-1 ii vim-gui-common 2:7.4.225-1 ii vim-runtime 2:7.4.225-1 vim-gtk recommends no packages. Versions of packages vim-gtk suggests: pn cscopenone ii gnome-icon-theme 3.12.0-1 ii ttf-dejavu2.34-1 pn vim-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744078: [Pkg-telepathy-maintainers] Bug#744078: Bug#744078: empathy: Empathy crashes at start
On 10/04/14 09:42, Simon McVittie wrote: the only way I can see for that to crash is if d was NULL, which could happen if one of bday.year, bday.month, bday.day is out-of-range. If you can reproduce this crash, you can confirm or disprove my theory with these gdb commands: (gdb) frame 3 (gdb) p *bday If the birthday is something that GDateTime considers to be invalid (year 1, year , month 1, month 12, day 1, or day too large for the month) then I understand the reason for this crash, and it should be easy to fix. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744111: vim: netrw erroneously reconstructs scp url
Package: vim Version: 2:7.4.225-1 Severity: normal Dear Maintainer, * What led up to the situation? :e scp://fulvio@puccini brings to the error: ssh: Could not resolve hostname fulviopuccini: Name or service not known netrw is apparently mangling the username and the hostname. :e sftp://fulvio@puccini works fine. Thank you Fulvio -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk /usr/bin/vim is /usr/bin/vim.gtk /usr/bin/gvim is /usr/bin/vim.gtk -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim depends on: ii libacl1 2.2.52-1 ii libc62.18-4 ii libgpm2 1.20.4-6.1 ii libselinux1 2.2.2-1 ii libtinfo55.9+20140118-1 ii vim-common 2:7.4.225-1 ii vim-runtime 2:7.4.225-1 vim recommends no packages. Versions of packages vim suggests: pn ctagsnone pn vim-doc none pn vim-scripts none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704032: Transition to 1.55
On Fri, Feb 28, 2014 at 22:26:49 -0600, Steve M. Robbins wrote: Hi, 1.55 has been in testing for a month now and has somewhat better support for recent glibc -- e.g. it doesn't suffer from .#739807 and #739904. I'd like to switch the boost-defaults to 1.55. Any objections? Please file a new transition bug for this. Thanks, Julien signature.asc Description: Digital signature
Bug#741221: Licensing clarification
tags 741221 confirmed upstream pending thanks Hi, Due to lack of response from kanjidic’s upstream, and after careful reviewing of its documentation (which further restricts the licensing terms), tagainijisho’s upstream author has decided to remove support for SKIP codes from his software and remove SKIP codes from the embedded kanjidic file. A new version of tagainijisho will be prepared in the coming days and uploaded as soon as possible. T-Bone -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590070: Closing #590070
Version: 1.0-1 Hi there, I'm closing this as upstream has properly documented the creation of custom profiles, and I think it's fair enough. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744093: awstats: Using the multiple-config schema results in cron spamming with errors
On 10/04/14 11:36, Sergey B Kirpichev wrote: On Thu, Apr 10, 2014 at 04:08:06AM +0200, Martín Ferrari wrote: I have configured awstats using one of the recommended schemes in README.Debian, namely: using one small conffile per virtual-host that also includes the default awstats.conf. There is no such a scheme. Please read this: --8-- [...] --8-- So, in this scheme - you should modify the default awstats.conf as well. Well, it does not make much sense, it would be inconsistent with the rest.. Also, you are encouraged to put all your local changes in awstats.conf.local, to have painless upgrades. This is a great way to have tidy configuration files, but it has a very annoying drawback: the cronjobs still try to use the unmodified awstats.conf file, and send me an email about this every 10 minutes. Can you fix these emails by configuring awstats.conf as one of vhosts? Yes, I could. But then again, which one is it? Also, if I make changes in that file, I need to make sure to revert them in all the other files which include it.. It is not good for maintenance, it is confusing and a bit untidy. Please reopen this bugreport if the answer is no. Also, if you find the documentation is not clear about the awstats.conf in this use case - please suggest changes (patches welcome). I think it is not clear in that sense, because it is not what one would expect. I would add a explicit warning about this. Which still does not make me very happy... Me, I will keep modified scripts, which then I will need to repatch on every upgrade.. -- Martín Ferrari (Tincho) signature.asc Description: OpenPGP digital signature
Bug#743332: Applying Patch
* Guillaume Lécroart wrote on 09 Apr 2014: patch did not apply automatically though (patch -p1 at the root of the src, got rejected) Sorry, vim slurped the tabs into spaces... Description: Fixed parsing of ID_DER_ASN1_DN in X.509 certificates The fix for CVE-2013-2053 (#709144) introduced a bug when parsing the ID_DER_ASN1_DN of a X.509 certificate (local and remote). In the atodn function a boundary check failed, when the full distinguished name if given in ipsec.conf (leftid or rightid). This results in a garbled peer id and in revoking connections. This patch fixes the boundary check. Bug-Debian: http://bugs.debian.org/743332 Origin: other Author: Alexander Hosfeld i...@hosfeld.de Last-Update: 2014-04-10 diff -ru openswan-2.6.37.orig/lib/libopenswan/x509dn.c openswan-2.6.37/lib/libopenswan/x509dn.c --- openswan-2.6.37.orig/lib/libopenswan/x509dn.c 2014-04-10 10:50:33.0 +0200 +++ openswan-2.6.37/lib/libopenswan/x509dn.c 2014-04-10 10:51:19.524173326 +0200 @@ -866,7 +866,6 @@ chunkcpy(dn_ptr, name); /* accumulate the length of the distinguished name sequence */ - dn_seq_len += 1 + asn1_rdn_set_len.len + rdn_set_len; dn_seq_len += rdn_len; /* reset name and change state */ signature.asc Description: Digital signature
Bug#742728: curl: CVE-2014-0138 CVE-2014-0139
On mer, mar 26, 2014 at 06:50:41 +0100, Salvatore Bonaccorso wrote:
Package: curl
Version: 7.21.0-1
Severity: grave
Tags: security upstream fixed-upstream
Hi Alessandro,
For having this referenced also in the Debian BTS, the following
vulnerabilities were published for curl.
CVE-2014-0138[0]:
libcurl wrong re-use of connections
CVE-2014-0139[1]:
libcurl IP address wildcard certificate validation
Here are the (old)stable debdiffs (better late than nothing, I guess... I had
troubles adapting the patches for the older releases :/).
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
diff -Nru curl-7.21.0/debian/changelog curl-7.21.0/debian/changelog
--- curl-7.21.0/debian/changelog 2014-01-29 19:17:17.0 +0100
+++ curl-7.21.0/debian/changelog 2014-04-09 19:48:14.0 +0200
@@ -1,3 +1,15 @@
+curl (7.21.0-2.1+squeeze8) squeeze-security; urgency=medium
+
+ * Fix multiple security issues (Closes: #742728):
+- Fix connection re-use when using different log-in credentials
+ as per CVE-2014-0138
+ http://curl.haxx.se/docs/adv_20140326A.html
+- Reject IP address wildcard matches as per CVE-2014-0139
+ http://curl.haxx.se/docs/adv_20140326B.html
+ * Set urgency=high accordingly
+
+ -- Alessandro Ghedini gh...@debian.org Wed, 09 Apr 2014 19:47:38 +0200
+
curl (7.21.0-2.1+squeeze7) squeeze-security; urgency=high
* Fix re-use of wrong HTTP NTLM connection as per CVE-2014-0015
diff -Nru curl-7.21.0/debian/patches/CVE-2014-0138.patch curl-7.21.0/debian/patches/CVE-2014-0138.patch
--- curl-7.21.0/debian/patches/CVE-2014-0138.patch 1970-01-01 01:00:00.0 +0100
+++ curl-7.21.0/debian/patches/CVE-2014-0138.patch 2014-04-09 19:48:14.0 +0200
@@ -0,0 +1,58 @@
+Description: Fix connection re-use when using different log-in credentials
+ In addition to FTP, other connection based protocols such as IMAP, POP3,
+ SMTP, SCP, SFTP and LDAP require a new connection when different log-in
+ credentials are specified. Fixed the detection logic to include these
+ other protocols.
+Origin: upstream, http://curl.haxx.se/libcurl-bad-reuse.patch
+Forwarded: not-needed
+Author: Steve Holme steve_ho...@hotmail.com
+Last-Update: 2014-04-09
+
+--- a/lib/http.c
b/lib/http.c
+@@ -162,7 +162,7 @@
+ ZERO_NULL,/* perform_getsock */
+ ZERO_NULL,/* disconnect */
+ PORT_HTTPS, /* defport */
+- PROT_HTTP | PROT_HTTPS | PROT_SSL /* protocol */
++ PROT_HTTP | PROT_HTTPS | PROT_SSL | PROTOPT_CREDSPERREQUEST/* protocol */
+ };
+ #endif
+
+--- a/lib/url.c
b/lib/url.c
+@@ -2986,11 +2986,11 @@
+ continue;
+ }
+ }
+-if((needle-protocol PROT_FTP) ||
++if((!(needle-protocol PROTOPT_CREDSPERREQUEST)) ||
+((needle-protocol PROT_HTTP)
+ (data-state.authhost.want CURLAUTH_NTLM))) {
+- /* This is FTP or HTTP+NTLM, verify that we're using the same name
+- and password as well */
++ /* This protocol requires credentials per connection or is HTTP+NTLM,
++ so verify that we're using the same name and password as well */
+ if(!strequal(needle-user, check-user) ||
+ !strequal(needle-passwd, check-passwd)) {
+ /* one of them was different */
+--- a/lib/urldata.h
b/lib/urldata.h
+@@ -721,6 +721,8 @@
+ #define PROT_EXTMASK 0xff
+
+ #define PROT_SSL (129) /* protocol requires SSL */
++#define PROTOPT_CREDSPERREQUEST (130) /* requires login creditials per request
++ as opposed to per connection */
+
+ /* these ones need action before socket close */
+ #define PROT_CLOSEACTION (PROT_FTP | PROT_IMAP | PROT_POP3)
+--- a/tests/data/DISABLED
b/tests/data/DISABLED
+@@ -2,5 +2,6 @@
+ # test cases are run by runtests.pl. Just add the plain test case numbers, one
+ # per line.
+ # Lines starting with '#' letters are treated as comments.
++519
+ 563
+ 564
diff -Nru curl-7.21.0/debian/patches/CVE-2014-0139.patch curl-7.21.0/debian/patches/CVE-2014-0139.patch
--- curl-7.21.0/debian/patches/CVE-2014-0139.patch 1970-01-01 01:00:00.0 +0100
+++ curl-7.21.0/debian/patches/CVE-2014-0139.patch 2014-04-09 19:48:14.0 +0200
@@ -0,0 +1,40 @@
+Description: Reject IP address wildcard matches
+ There are server certificates used with IP address in the CN field, but
+ we MUST not allow wildcard certs for hostnames given as IP addresses
+ only. Therefore we must make Curl_cert_hostcheck() fail such attempts.
+Origin: upstream, http://curl.haxx.se/libcurl-reject-cert-ip-wildcards.patch
+Forwarded: not-needed
+Author: Daniel Stenberg dan...@haxx.se
+Last-Update: 2014-04-09
+
+--- a/lib/ssluse.c
b/lib/ssluse.c
+@@ -53,6 +53,7 @@
+ #include select.h
+ #include sslgen.h
+ #include rawstr.h
++#include inet_pton.h
+
+ #define _MPRINTF_REPLACE /* use the internal
Bug#726262: any progress on this front?
Hi, I wanted to use salt, but stumbled over this dependency issue. Unfortunately, the upstream bug has also seen no activity for half a year already, so I wonder how to make progress now. I mean, in the absence of a usable PyCrypto integration, and with M2Crypto gone, it very much looks like salt is becoming a no-go in Debian - right? Please enlighten me! Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744022: gearman-job-server logrotate doesn't work
Alexei Pastuchov alexei.pastuc...@telecolumbus.de writes: as described here https://bugs.launchpad.net/gearmand/+bug/1223994 gearmand doesn't support current gearman-job-server logrotate entry copytruncate added in /etc/logrotate.d/gearman-job-server was a workaround in my case too. Hello, Thanks for the bug report, I'll get it updated. -- Stig Sandbeck Mathisen s...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744089: xemacs21: watchfile with pgp signature support
tag 744089 - patch kthxbye the public key of Vin Shelton, the upstream release manager, to allow diff -rN xemacs21-21.4.22/debian/upstream/signing-key.asc xemacs21-21.4.22-diff/debian/upstream/signing-key.asc 0a1,27 -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.3 (GNU/Linux) I'm sorry but this patch is unparsable - when I try to apply it patch always says things like: | $ patch /tmp/watch_with_key.patch | patch: Only garbage was found in the patch input. and similarly with -p1 and so on. Please use unified diff format (-u), this is the most robust format for patches and also the most human readable. signature.asc Description: Digital signature
Bug#744112: cura-engine shipped with debian is incompatible with the cura client from ultimaker
Package: cura-engine Version: 14.01-2 Severity: normal Dear Maintainer, The current packaged version of cura-engine, 14.01-2 is incompatible with the current shipping version of cura from Ultimaker. Cura 14.03 expects the -p option to be available in CuraEngine. Upgrading CuraEngine to a newer version (14.03) should solve this issue. While Cura is not yet packaged, and the supplied .deb by ultimaker has a matching CuraEngine, having the proper CuraEngine in debian makes packaging the cura client easier. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-23-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744113: don't include uploaded binary packages (build on developer machines) in the archive
package: ftp.debian.org Hi, this bug is for tracking this drama. Please don't close it, maybe reassign it to a more fitting package. (And as a last ressort, assign it to general please.) Since some time (=years) there is broad agreement that we shouldn't do this - where this is pushing binaries build on some random developers random machine into the archive, yet we still do it and don't even have a clear idea what the status and plan is to fix this. I've had a discussion about this with some buildd admins and ftpmasters a few months ago, so if the current status does not magically appear in this bug report, I will dig that up and update the report... for now I hope for magic^wyour update. cheers, Holger P.S.: yes, for bootstraping an architecture it might occasionally be useful to be able to upload whatever .debs - but that's clearly an exception and should be handled as such. signature.asc Description: This is a digitally signed message part.
Bug#744093: awstats: Using the multiple-config schema results in cron spamming with errors
Well, it does not make much sense, it would be inconsistent with the rest.. But it is consistent with one host scenario (i.e. without awstats.*.conf). Also, you are encouraged to put all your local changes in awstats.conf.local, to have painless upgrades. Can you quote this? Yes, I could. But then again, which one is it? Use common sence, please. Options you want to modify in every awstats.*.conf - should go to awstats.conf. E.g. SiteDomain. Everything else - to awstats.conf or awstats.conf.local at your discretion. Also, if I make changes in that file, I need to make sure to revert them in all the other files which include it.. Can you provide any example? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744114: Has an unnecessary hard dependency on systemd stuff
Package: network-manager Version: 0.9.8.8-5 Severity: normal There's *no* reason for the libpam-systemd dependency to be a hard Depends: Network Manager works just fine for me without it, and bringing in libpam-systemd actually *breaks* stuff (I don't want my network to die every time I close the laptop lid!). This should clearly be a Recommends: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager depends on: ii adduser3.113+nmu3 ii dbus 1.8.0-3 ii init-system-helpers1.18 ii isc-dhcp-client4.2.4-7 ii libc6 2.18-4 ii libdbus-1-31.8.0-3 ii libdbus-glib-1-2 0.102-1 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.40.0-2 ii libgnutls262.12.23-13 ii libgudev-1.0-0 204-8 ii libmm-glib01.0.0-4 ii libnl-3-2003.2.24-1 ii libnl-genl-3-200 3.2.24-1 ii libnl-route-3-200 3.2.24-1 ii libnm-glib40.9.8.8-5 ii libnm-util20.9.8.8-5 pn libpam-systemd none ii libpolkit-gobject-1-0 0.105-4 ii libsoup2.4-1 2.46.0-2 ii libsystemd-login0 204-8 ii libuuid1 2.20.1-5.7 ii lsb-base 4.1+Debian12 ii policykit-10.105-4 ii udev 204-8 ii wpasupplicant 1.1-1 Versions of packages network-manager recommends: pn crda none ii dnsmasq-base 2.68-1 ii iptables 1.4.21-1 pn modemmanager none ii ppp 2.4.5+git20130610-4 Versions of packages network-manager suggests: pn avahi-autoipd none -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619521: Uwaga - zostały ostatnie 3 dni
Informujemy, że w dniach 09-12.04.2014 odbędzie się nabór na kurs języka angielskiego. Jest to IV edycja projektu Każdy Dorosły Polak Mówi po angielsku Kod upoważniający do 61% zniżki na szkolenie: E1404 Liczba miejsc ograniczona, decyduje kolejnść zgłoszeń. Zajęcia: - Angielski dla początkujących (A1/A2), - Angielski dla średnio-zaawansowanych (B1) Zajęcia trwają 12 miesięcy. Wszyscy studenci objęci są opieką metodyczną. Szkoła Językowa Dobra Zuza jest placówką kształcenia ustawicznego wpisaną do ewidencji szkół i placówek niepublicznych prowadzonej przez m. st. Warszawa pod numerem 1052 K. Zaświadczenia o ukończeniu kursu wydawane są na podstawie §18 ust. 2 rozporządzenia Ministra Edukacji Narodowej z dnia 11 stycznia 2012 r. w sprawie kształcenia ustawicznego w formach pozaszkolnych (Dz. U. poz. 186, z późniejszymi zmianami). Na zajęcia można zapisywać się indywidualnie lub grupowo. Istnieje możliwość otrzymania faktury. Szczegółowe informacje o naborze dostępne są na stronie: http://www.akademiajezykowaonline.co.pl Dodatkowych informacji udziela sekretariat szkoły pod numerem: +48 22 379 65 67 (w godzinach od 8:00 do 17:00) Zrezygnuj z otrzymywania wiadomści: http://www.akademiajezykowaonline.co.pl/mailing/unsubscribe.php?email=619...@bugs.debian.org
Bug#744115: codeblocks: Please update to use wxwidgets3.0
Package: codeblocks Version: 13.12-3 Severity: normal Tags: patch User: freewx-ma...@lists.alioth.debian.org Usertags: wx3.0 Dear maintainer, We're aiming to migrate the archive to using wxwidgets3.0 instead of wxwidgets2.8. I've rebuilt your package using the attached patch and did some simple testing. Everything looks good to me, though I'm not a codeblocks user, and I don't have an actual project to test it with. However it built cleanly without any upstream changes, which for this complex an application must mean upstream has tested it with wx 3.0, or at least with the wx 2.9.x development releases which lead up to 3.0. I'm happy to NMU this change if you wish me to - just let me know. Cheers, Olly diff -Nru codeblocks-13.12/debian/changelog codeblocks-13.12/debian/changelog --- codeblocks-13.12/debian/changelog 2014-01-27 17:31:25.0 +1300 +++ codeblocks-13.12/debian/changelog 2014-03-21 18:23:12.0 +1300 @@ -1,3 +1,10 @@ +codeblocks (13.12-3.1) unstable; urgency=low + + * Non-maintainer upload. + * Update to use wxWidgets 3.0. + + -- Olly Betts o...@survex.com Fri, 21 Mar 2014 18:23:12 +1300 + codeblocks (13.12-3) unstable; urgency=medium * Add depends on libgamin0 to codeblocks-contrib. (Closes: #726761) diff -Nru codeblocks-13.12/debian/control codeblocks-13.12/debian/control --- codeblocks-13.12/debian/control 2014-01-27 17:33:03.0 +1300 +++ codeblocks-13.12/debian/control 2014-03-21 18:23:30.0 +1300 @@ -6,8 +6,7 @@ Vincent Cheng vch...@debian.org Build-Depends: debhelper (= 8~) , dh-autoreconf - , libwxgtk2.8-dev - , wx-common + , libwxgtk3.0-dev , zip , libbz2-dev , zlib1g-dev @@ -32,8 +31,7 @@ , gdb , xterm Suggests: - libwxgtk2.8-dev - , wx-common + libwxgtk3.0-dev , codeblocks-contrib Description: Code::Blocks integrated development environment (IDE) Code::Blocks is a cross-platform Integrated Development Environment (IDE). signature.asc Description: Digital signature
Bug#704805: Does partial upgrade between stable and testing must be supported ?
On Sat, Apr 05, 2014 at 09:21:33PM +0200, Vincent Danjean wrote: The disagreement comes from the fact that the maintainer does not think that he must declare this incompatibility. For now, if you install a r package from testing, it will pull the r-base-core from testing (due to dependency such as Depends: r-base-core (= 3.0.2-1)) But, when r-base-core from testing is installed, the system keeps other r related packages from stable (no conflict, break, ...) and these packages won't work anymore. The maintainer think that he does not need to do anything about that. Then the maintainer is very wrong, if only because an upgrade from stable to testing *involves* a partial upgrade. Let's say during a dist-upgrade from wheezy to jessie, r-cran-foo is upgraded after r-base-core. This is possible, because there is no dependency relationship preventing that currently. Assume another package X which depends on r-cran-foo, and which does something in its postinst which needs r-cran-foo to work. This is allowed: at the point when the postinst of X is ran, r-cran-foo is configured and thus assumed to work. However, because of the broken r-cran-foo - r-base-core dependency, the said postinst of X will fail. This will cause the upgrade as a whole to fail, in a pretty hard to debug way, especially for sysadmins who don't understand R. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Drupal7 - minified JavaScript
Hi Gunnar, I just saw your comment on this bug from February 18 Personally, I don't think it is enough to say that a package is not using some artifacts from the source tarball - while it is a technically valid argument, it would make it far more difficult for FTP masters to inspect source packages and badness could start to creep in as a consequence of any generosity they show in this area. Repackaging upstream tarballs is becoming a common problem with minified JavaScript, maybe we need to have some automated way of doing this. For upstreams who use git and who release the exact contents of their tags (without any autotools bootstrapping, etc), it should be fairly easy to create some system on alioth that mirrors all the upstreams and pro-actively generates +dfsg versions of their tags ready for maintainers to work with. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744101: indent: debian/copyright - Sources URL no longer exists
On 2014-04-10 11:16, Santiago Vila wrote: | On Thu, 10 Apr 2014, Jari Aalto wrote: | | Source: indent | Version: 2.2.11-4 | Severity: minor | | URL mentioned in debian/copyright as is unaccessible. | | http://indent.isidore-it.eu/indent-2.2.11.tar.gz | | Please update location. | | I'd love to, but there is not any official URL to update the copyright | file, so it will have to be kept as is. May I suggest adding something like: NOTE: as of -MM-DD this URL no longer exist http://indent.isidore-it.eu/indent-2.2.11.tar.gz That'd make it clear. Thanks, Jari -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Charles Plessy writes (Bug#741573: Two menu systems): The underlying question is: who should spend the time writing these files and keeping them up to date ? The answer is, whoever wants to. In the first instance the maintainer may choose to do so; if they don't, then it falls to those contributors who care about the menu. In the case of missing manual pages, the policy (§ 12.1) does not require the package maintainer to write one. 12.1 says: | Each program, utility, and function should have an associated manual | page included in the same package. Policy does not in general say who should do any particular piece of work. Therefore, I think that the “should” of §9.6, paragraph 2 should be relaxed. I think we should use similar wording about trad menu entries to that we use about manpages. That means using should just as we do about manpages. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729073: icedove won't start
Package: icedove
Version: 24.4.0-1
Followup-For: Bug #729073
Dear Maintainer,
I'm getting the same or similar bug after the most recent update.
Ironically, I first realised I had the problem after trying to debug icedove,
in relation to another bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=963114 ). Icedove started and
first and showed the checking extensions compatibility dialogue. It said the
lightning (calendar) addon needed updating, which I did. It sorted that, and
then dissappeared. After that it wouldn't start again.
However, I can open just the address book - and it seems to open in safe mode.
Here's what terminal says:
--
:~$ icedove
(process:16673): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size
== 0' failed
(icedove:16673): GLib-GObject-WARNING **: Attempt to add property GnomeProgram
::sm-connect after class was initialised
(icedove:16673): GLib-GObject-WARNING **: Attempt to add property GnomeProgram
::show-crash-dialog after class was initialised
(icedove:16673): GLib-GObject-WARNING **: Attempt to add property
GnomeProgram::display after class was initialised
(icedove:16673): GLib-GObject-WARNING **: Attempt to add property GnomeProgram
::default-icon after class was initialised
[calBackendLoader] Using libical backend at
/home/nick/.icedove/pa0xb8lr.default/extensions/{e2fda1a4-762b-4020-b5ad-
a41df1933103}/components/libical.manifest
enigmail.js: Registered components
mimeVerify.jsm: module initialized
icedove: relocation error:
/home/nick/.icedove/pa0xb8lr.default/extensions/{e2fda1a4-762b-4020-b5ad-
a41df1933103}/components/Linux_x86_64-gcc3/libcalbasecomps.so: symbol
_ZN2js13CheckedUnwrapEP8JSObjectb, version xul24 not defined in file libxul.so
with link time reference
--
UPDATE: ok, so it looks very likely it's the calendar extension / lightning, as
I just disabled that and it opens normally.
I'll attach the debugging logs as well.
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages icedove depends on:
ii debianutils 4.4
ii fontconfig2.11.0-2
ii libasound21.0.27.2-3
ii libatk1.0-0 2.12.0-1
ii libc6 2.18-4
ii libcairo2 1.12.16-2
ii libdbus-1-3 1.8.0-3
ii libdbus-glib-1-2 0.102-1
ii libevent-2.0-52.0.21-stable-1
ii libffi6 3.1~rc1+r3.0.13-12
ii libfontconfig12.11.0-2
ii libfreetype6 2.5.2-1
ii libgcc1 1:4.8.2-16
ii libgdk-pixbuf2.0-02.30.6-1
ii libglib2.0-0 2.40.0-2
ii libgtk2.0-0 2.24.22-1
ii libhunspell-1.3-0 1.3.2-7
ii libnspr4 2:4.10.4-1
ii libnss3 2:3.16-1
ii libpango-1.0-01.36.3-1
ii libpangocairo-1.0-0 1.36.3-1
ii libpangoft2-1.0-0 1.36.3-1
ii libpixman-1-0 0.32.4-1
ii libsqlite3-0 3.8.4.1-1
ii libstartup-notification0 0.12-3
ii libstdc++64.8.2-16
ii libvpx1 1.3.0-2
ii libx11-6 2:1.6.2-1
ii libxext6 2:1.3.2-1
ii libxrender1 1:0.9.8-1
ii libxt61:1.1.4-1
ii psmisc22.21-2
ii zlib1g1:1.2.8.dfsg-1
Versions of packages icedove recommends:
ii myspell-en-gb [myspell-dictionary] 1:3.3.0-4
ii myspell-en-us [myspell-dictionary] 1:3.3.0-4
Versions of packages icedove suggests:
ii fonts-lyx 2.0.6-1
ii libgssapi-krb5-2 1.12.1+dfsg-1
-- no debconf information
la.sh: command not found
run-mozilla.sh: Cannot execute [-safe-mode].
MOZILLA_FIVE_HOME=/usr/lib/icedove
LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
LIBRARY_PATH=
SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
LIBPATH=/usr/lib/icedove:/usr/lib/icedove
ADDON_PATH=
MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
MOZ_TOOLKIT=
moz_debug=1
moz_debugger=
moz_debugger_args=
/usr/bin/gdb --args /usr/lib/icedove/icedove-bin
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from
Bug#735630: What about the legacy drivers?
Hi. It was already somewhat mentioned in comment #59, but the same problem exists for legacy drivers. At least in Testing installing the 173xx DKMS drivers and modprobing results in: nvidia: Unknown symbol acpi_os_wait_events_complete (err 0) Will the legacy drivers also be updated to solve this problem? -- Regards, Piotr MoroS Mrożek
Bug#744093: awstats: Using the multiple-config schema results in cron spamming with errors
On 10/04/14 12:16, Sergey B Kirpichev wrote: Well, it does not make much sense, it would be inconsistent with the rest.. But it is consistent with one host scenario (i.e. without awstats.*.conf). That's why I am saying to enable this only when using multiple hosts. Also, you are encouraged to put all your local changes in awstats.conf.local, to have painless upgrades. Can you quote this? Probably I was confused about the upgrades, but you are still encouraged to leave the main file untouched: This way you can leave awstats.conf alone, and put your server-specific settings into awstats.conf.local, and your site-specific settings into each awstats.[site_name_here].conf file. Yes, I could. But then again, which one is it? Use common sence, please. Options you want to modify in every awstats.*.conf - should go to awstats.conf. E.g. SiteDomain. Everything else - to awstats.conf or awstats.conf.local at your discretion. Also, if I make changes in that file, I need to make sure to revert them in all the other files which include it.. Can you provide any example? If my main host has some extra settings. Say, SkipHosts, because it gets many hits from a monitoring tool, or you want to enable a plugin for it... Where should I put that? If it is in awstats.conf, it gets included everywhere. So I should be cautious to undo that setting in all the other configs. If it is a plugin setting, I don't think there is even a way to revert that setting. If I add it in awstats.conf.local, it is the same thing, it gets added everywhere. In fact, that's supposedly the purpose of the .local file. So, the only way to do this, is to copy *all* the settings in every file, and not include awstats.conf at all. What you are suggesting goes contrary to what is suggested in the README. So, I think you should either remove those suggestions, or fix this issue. -- Martín Ferrari (Tincho) signature.asc Description: OpenPGP digital signature
Bug#742728: curl: CVE-2014-0138 CVE-2014-0139
On Thu, Apr 10, 2014 at 12:01:03PM +0200, Alessandro Ghedini wrote: On mer, mar 26, 2014 at 06:50:41 +0100, Salvatore Bonaccorso wrote: Package: curl Version: 7.21.0-1 Severity: grave Tags: security upstream fixed-upstream Hi Alessandro, For having this referenced also in the Debian BTS, the following vulnerabilities were published for curl. CVE-2014-0138[0]: libcurl wrong re-use of connections CVE-2014-0139[1]: libcurl IP address wildcard certificate validation Here are the (old)stable debdiffs (better late than nothing, I guess... I had troubles adapting the patches for the older releases :/). If this now passes the test suite, please upload. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
Hi Shigio, Thanks for your reply. Since I don't use the htags functionality I appreciate your clarifications. I have a On Thu, Apr 10, 2014 at 1:53 AM, Shigio YAMAGUCHI shi...@gnu.org wrote: Hello, 2014-04-09 22:38 GMT+09:00 Punit Agrawal punitagra...@gmail.com: Ron's, rather short, reply pointed out that a distro package requiring users to run a generated script as root isn't an acceptable interface. It's a misunderstanding. I just offered a means to leave the admin user to update the system directory (sitekeys directory). It is only a default; it is not required. You can change it by configure script as follows: $ ./configure --with-sitekeys-mode=777 This command line executes 'chmod 777 'localstatedir/gtags/sitekeys'. I just fixed a bug with packaging which failed to create 'localstatedir/gtags/sitekeys'. But... localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. If you have write permission for the directory, you need not invoke bless.sh after executing htags. Of course, root permission is not required. Please see 'FILES' section of htags(1). I am not sure how actively this feature is used, but in the interest of updating the package I proposed to drop generating the script and print a message for now. I've not received any further reply to my request for clarification or the proposed changes. Bless.sh script is needed for moving the project directory. Just making 'sitekeys' directory writable, everything goes well. # # Builds a hypertext of a project # $ cd /usr/src/project $ htags -f --system-cgi=key # = CGI works (bless.sh is not needed) # # Moves the project to another place # $ mv /usr/src/project /home/user # = CGI does not work $ cd /home/user/project/HTML $ sh bless.sh # = CGI works (bless.sh is needed) From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? Watch this space for further progress and do let me know if you face any problems trying to use the package from the linked repository. [0] http://anonscm.debian.org/gitweb/?p=collab-maint/global.git;a=summary Great! I am very glad to hear that new Debian GLOBAL will be released soon. I appreciate your efforts. Thanks for your comments. I appreicate your explanation and the encouragement here. Punit Regards, Shigio -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744093: awstats: Using the multiple-config schema results in cron spamming with errors
On Thu, Apr 10, 2014 at 12:53:32PM +0200, Martín Ferrari wrote: Also, you are encouraged to put all your local changes in awstats.conf.local, to have painless upgrades. Can you quote this? Probably I was confused about the upgrades, but you are still encouraged to leave the main file untouched: This way you can leave awstats.conf alone, and put your server-specific settings into awstats.conf.local, and your site-specific settings into each awstats.[site_name_here].conf file. I fail to see the words all local changes. Instead, I see exactly same what I told you below: Yes, I could. But then again, which one is it? Use common sence, please. Options you want to modify in every awstats.*.conf - should go to awstats.conf. E.g. SiteDomain. Everything else - to awstats.conf or awstats.conf.local at your discretion. Also, if I make changes in that file, I need to make sure to revert them in all the other files which include it.. Can you provide any example? If my main host has some extra settings. Say, SkipHosts, because it gets many hits from a monitoring tool, or you want to enable a plugin for it... Where should I put that? Put this in some awstats.*.conf. Why you want to make this host to be the default one (main host)? So, the only way to do this, is to copy *all* the settings in every file, and not include awstats.conf at all. As I said - you have at least one another option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741823: NMU for bpython
Hi, I have NMU the package in delayed queue (5 days). The changes are in the collab-maint git if you want to check it out. Anyway, I've just added a build-depends: python3-all as Hideki Yamane suggested, and a debian/gbp.conf to make sure the git packaging is using pristine-tar. David, if you want me to dcut rm the package before the next 5 days, let me know. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741823: NMU for bpython
On Thu, 10 Apr 2014 19:01:58 +0800, Thomas Goirand wrote: Hi, I have NMU the package in delayed queue (5 days). The changes are in the collab-maint git if you want to check it out. Anyway, I've just added a build-depends: python3-all as Hideki Yamane suggested, and a debian/gbp.conf to make sure the git packaging is using pristine-tar. David, if you want me to dcut rm the package before the next 5 days, let me know. No need to, please go ahead :) (just had no time to do it myself) -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Bug#729073: icedove won't start
Hello Nick, Am 10.04.2014 12:51, schrieb Nick: I'm getting the same or similar bug after the most recent update. Ironically, I first realised I had the problem after trying to debug icedove, in relation to another bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=963114 ). Icedove started and first and showed the checking extensions compatibility dialogue. It said the lightning (calendar) addon needed updating, which I did. It sorted that, and then dissappeared. After that it wouldn't start again. you have installed the Lightning extension from Mozilla? Lightning *and* Icedove won't work together after version 24 because of internally symbol mismatch. Please use iceowl-extension from the Debian repositories instead of the Mozilla Lightning extension. The backtrace shows exactly the same error as bug #724688 [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724688 -- Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744093: awstats: Using the multiple-config schema results in cron spamming with errors
On 10/04/14 13:03, Sergey B Kirpichev wrote: On Thu, Apr 10, 2014 at 12:53:32PM +0200, Martín Ferrari wrote: Also, you are encouraged to put all your local changes in awstats.conf.local, to have painless upgrades. Can you quote this? Probably I was confused about the upgrades, but you are still encouraged to leave the main file untouched: This way you can leave awstats.conf alone, and put your server-specific settings into awstats.conf.local, and your site-specific settings into each awstats.[site_name_here].conf file. I fail to see the words all local changes. Instead, I see exactly same what I told you below: If you read leave awstats.conf alone, clearly that means not modifying it. It says clearly to put server settings in .local and site settings in the other files. Are you actually reading this? If my main host has some extra settings. Say, SkipHosts, because it gets many hits from a monitoring tool, or you want to enable a plugin for it... Where should I put that? Put this in some awstats.*.conf. Why you want to make this host to be the default one (main host)? Because it might make sense to do so. Or because some day I chosen that one to be the main host (only because you are asking me to do such a thing, since what I have been asking you is NOT TO MAKE THAT CHOICE), and then requirements change. So, the only way to do this, is to copy *all* the settings in every file, and not include awstats.conf at all. As I said - you have at least one another option. Now you are just being obtuse. If you want to close the bug, make my day. You either don't understand what I am writing or you only care about being right. In any case, you are harming Debian. -- Martín Ferrari (Tincho) signature.asc Description: OpenPGP digital signature
Bug#744101: indent: debian/copyright - Sources URL no longer exists
On Thu, 10 Apr 2014, jari wrote: On 2014-04-10 11:16, Santiago Vila wrote: | I'd love to, but there is not any official URL to update the copyright | file, so it will have to be kept as is. May I suggest adding something like: NOTE: as of -MM-DD this URL no longer exist http://indent.isidore-it.eu/indent-2.2.11.tar.gz That'd make it clear. That would be a good suggestion in the general sense (for dead URLs), but in this particular case it happens that GNU indent has two new upstream maintainers and they tell me that there will be a new release soon (this is the reason why one of them, who is also a Debian developer, has recently tagged as pending several Debian indent bugs). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744113: don't include uploaded binary packages (build on developer machines) in the archive
also sprach Holger Levsen hol...@layer-acht.org [2014-04-10 12:19 +0200]: Since some time (=years) there is broad agreement that we shouldn't do this - AFAICT, we're going to turn 10 in September! https://lists.debian.org/debian-security/2004/09/msg00014.html -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#744116: meep-mpich2: rebuild against new libmpich version?
Package: meep-mpich2 Version: 1.1.1-10 Severity: normal Hi, meep-mpich2 is built against libmpich2-3 in unstable. However, libmpich2-3 comes from the mpich2 (1.4.1-4.2) source package, most of whose binary packages have been taken over by the mpich (3.1-4) source package, which builds libmpich12. I infer that the mpich2 source package is due to be removed once nothing depends on its remaining binary package any more. libmpich doesn't seem to use versioned symbols, so it's probably not safe to load two different versions of it into the same process; under the usual rules I think that would mean that meep-mpich2 could only switch to a new version if it changed its own SONAME at the same time. However, right now, libmeep-mpich2-6 has no reverse-dependencies other than meep-mpich2, and that depends on mpich2 which eventually ends up depending on the new libmpich; so it may well be broken right now anyway and I think you could safely rebuild it. If you agree, a reupload shouldn't be necessary, and the release team should be able to do a binNMU for you on request. But if there is a problem, then I think you need to sort out some other strategy, because at the moment any upload of meep-mpich2 will cause it to link against the new libmpich. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742728: curl: CVE-2014-0138 CVE-2014-0139
On gio, apr 10, 2014 at 12:47:39 +0200, Moritz Muehlenhoff wrote:
On Thu, Apr 10, 2014 at 12:01:03PM +0200, Alessandro Ghedini wrote:
On mer, mar 26, 2014 at 06:50:41 +0100, Salvatore Bonaccorso wrote:
Package: curl
Version: 7.21.0-1
Severity: grave
Tags: security upstream fixed-upstream
Hi Alessandro,
For having this referenced also in the Debian BTS, the following
vulnerabilities were published for curl.
CVE-2014-0138[0]:
libcurl wrong re-use of connections
CVE-2014-0139[1]:
libcurl IP address wildcard certificate validation
Here are the (old)stable debdiffs (better late than nothing, I guess... I
had
troubles adapting the patches for the older releases :/).
If this now passes the test suite, please upload.
Well, it passes the test suite only because the broken test was disabled, but it
can't be helped (the alternative would be enabling the fork() support in the
server used for testing, but that may introduce more breakage). SUSE has done
the same thing (in fact the SUSE maintainer suggested this) and upstream says
it should be safe (in fact, the fact that the disabled test freezes is probably
a good sign, since it means that the patch does what it's supposed to).
Anyway, uploaded.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#744117: mail-notification: Needs porting for new evolution-3.12 API
Source: mail-notification Version: 5.4.dfsg.1-9 Severity: important Hi Stephen, We want to start a new evolution transition soon, and m-n is one of the two packages needing work to adapt to the new API. Can you either port m-n to the new API or disable evolution support for the time being, in order to ease the transition? Thanks, Jordi -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-rc7-amd64 (SMP w/4 CPU cores) Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Josselin Mouette writes (Bug#741573: Two menu systems): Le mercredi 09 avril 2014 à 15:04 +0100, Ian Jackson a écrit : Matthias Klumpp writes (Bug#741573: Two menu systems): Also think about HIDPI-screens in particular, where these small icons don't make sense at all (in fact, they are so small that you often can't even tell what they display). In situations like this, presumably the icons would need to be scaled. Faced with such nonsensical words, let’s give a real-life example. Please don't be unpleasant. The three attached files are: 1. the evolution icon, optimized by upstream to 32×32, and converted to XPM format with 1 bit of transparency (as mandated by the Debian menu) 2. the original evolution icon, scaled at 96×96 pixels (the GNOME shell menu size) 3. the XPM icon as scaled by GNOME Shell (before we rip it of the Debian menu) to 96×96 I don’t think “antique” is an overstatement. And I do mean it in a pejorative way. It's certainly clear that scaling a 96x96 icon down to 32x32 and back isn't going to make it prettier. This has little to do with the xpm format; it's mostly because of the size restriction. I agree that this isn't as nice as it could be. But, as I have explained, the underlying reason for this is that the trad menu format is a much lower common denominator. That comes directly from its goal of being easily consumable by a very wide range of window managers. If you don't like the trad menu, you don't have to use it. Nor do you have to do any significant amount of work to support it. All that is being asked is that you take other people's patches to support it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743995: libc-bin: Error using synaptic: GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid 0' failed
El 09/04/14 22:57, Aurelien Jarno escribió: reassign 743995 synaptic retitle 743995: synaptic: Error using synaptic: GLib-CRITICAL **: thanks On Wed, Apr 09, 2014 at 02:48:38AM +0200, advocatux wrote: Package: libc-bin Version: 2.18-4 Severity: important I'm getting this error every time I'm updating a package using synaptic (GLib-CRITICAL **: g_child_watch_add_full: assertion 'pid 0' failed). This is clearly not a glibc bug, reassigning the bug to synaptic. Fine for me. I've just wanted to keep consistency with the bug report in Ubuntu's bug report system (https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1282542) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744118: fcrackzip: Use libunzip instead of system()
Package: fcrackzip Version: 1.0-5 Severity: wishlist I've found this patch [1] which uses libunzip instead of calling unzip via system and claims to speed up fcrackzip by a factor of 1000. Please consider releasing a new version with that patch applied! [1] https://github.com/hyc/fcrackzip/commit/156ee9793cc2c79e6d39b3354f39b2d0fccdbbaa -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), (100, 'saucy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-19-generic (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fcrackzip depends on: ii libc6 2.17-93ubuntu4 fcrackzip recommends no packages. Versions of packages fcrackzip suggests: ii unzip 6.0-9ubuntu1 ii wamerican [wordlist] 7.1-1 ii wbritish [wordlist] 7.1-1 ii wngerman [wordlist] 20120607-1 ii wogerman [wordlist] 1:2-28 ii wswiss [wordlist] 20120607-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744115: codeblocks: Please update to use wxwidgets3.0
Hi Olly, On Thu, Apr 10, 2014 at 3:31 AM, Olly Betts o...@survex.com wrote: Package: codeblocks Version: 13.12-3 Severity: normal Tags: patch User: freewx-ma...@lists.alioth.debian.org Usertags: wx3.0 Dear maintainer, We're aiming to migrate the archive to using wxwidgets3.0 instead of wxwidgets2.8. I've rebuilt your package using the attached patch and did some simple testing. Everything looks good to me, though I'm not a codeblocks user, and I don't have an actual project to test it with. However it built cleanly without any upstream changes, which for this complex an application must mean upstream has tested it with wx 3.0, or at least with the wx 2.9.x development releases which lead up to 3.0. I'm happy to NMU this change if you wish me to - just let me know. My understanding is that upstream is working towards porting codeblocks for wx 3.0, but it's currently not fully stable yet (e.g. #736368). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574947: Status and progress
Hi Punit, localstatedir resolves to '/usr/var' which throws a lintian warning as this location doesn't conform to Debian File Hierarchy Standard. Can you please explain what is the role of this folder and how it is used? Perhaps there is a more standard debian location where I can install this to. The role of localstatedir is defined in the GNU's standards. Please see the following site: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html Htags uses 'localstatedir/gtags/sitekeys/' as a database of project directories. From my understanding, bless.sh writes the location of the current folder (pwd) into 'localstatedir/gtags/sitekeys/key'. Can you explain how this information is used then? The current folder means 'HTML' directory in the project. Since the --system-cgi option uses CGI programs in the system area which is out of the project, the programs need a help for reach there. Please ask me again, if my explanation is insufficient. -- Shigio YAMAGUCHI shi...@gnu.org PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
Bug#744119: RFP: libonion - HTTP server library in C designed to be lightweight and easy to use
Package: libonion, libonion-dev, libonion-tools, libonion-examples Severity: wishlist I'm the developer of libonion, a C HTTP server library with bindings for C++. I would love to see it packaged for Debian. It has a working debian directory that packages all needed files. https://github.com/davidmoreno/onion License is both GPLv2+ and Apache2 for the main library. AGPLv3 for the examples and tools. --David Moreno Montero dmor...@coralbits.com +34 658 18 77 17 +44 74 23 21 01 57 http://www.coralbits.com/ http://www.coralbits.com
Bug#744117: mail-notification: Needs porting for new evolution-3.12 API
Hi Jordi, Le 10/04/2014 13:39, Jordi Mallach a écrit : We want to start a new evolution transition soon, and m-n is one of the two packages needing work to adapt to the new API. Can you either port m-n to the new API or disable evolution support for the time being, in order to ease the transition? The Fedora maintainers have produced patches to allow building against the new API, so I'll add those to the package in the next couple of days. Regards, Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743417: ebook2cwgui FTBFS on hppa arch / patch attached
Many thanks for bringing this issue to my attention, Helge! I've prepared a new version of the package, dropping the libgcc1 and libstdc++6 from the build-dependencies. Christoph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744027: Please remove StartCom Certification Authority root certificate
On Wed, 9 Apr 2014, Geoffrey Thomas wrote: This only affects certs that were used on vulnerable versions of OpenSSL with allocation schemes that actually loaded the private key into freed memory that could be returned. I haven't seen a valid claim that this is anywhere near a significant fraction of the web. http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html Note that this has been updated by now. See also: Update: Errata Security's Robert Graham [12]has acknowledged that he was mistaken in his assessment, and that private keys could be at risk. The original story below has been marked up accordingly. […] In [17]a post to the Errata Security blog, Robert Graham explained that it is highly unlikely that private key data would be stored in the memory buffer that could be leaked using the Heartbleed exploit. “What you can eavesdrop on with Heartbleed hacks is dynamic stuff, stuff that was allocated only moments ago,” he wrote. But that assertion has been refuted, and Graham has since rescinded it, as noted above. […] Terrence Koeman of MediaMonks told Ars he found signs of attempts to use the exploit dating back to November 2013. He used the packet content of a successful exploit of the Heartbleed vulnerability to check inbound packets logged by his servers and found a number of incoming packets from a network suspected of harboring a number of “bot” servers that were apparently scans for the vulnerability—sending Heartbleed-style requests to two different development servers in requests that were about five minutes apart. [12] https://twitter.com/julianor/status/454015858042757120 By now, we must assume that private key material *can* have been leaked, and that this was being exploited five months ago already. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744115: codeblocks: Please update to use wxwidgets3.0
On Thu, Apr 10, 2014 at 04:59:25AM -0700, Vincent Cheng wrote: My understanding is that upstream is working towards porting codeblocks for wx 3.0, but it's currently not fully stable yet (e.g. #736368). The issue there is most likely because wx 3.0 enables WXDEBUG mode by default which includes checks for incorrect API usage, whereas with wx 2.8 you had to specify it explicitly when you built the library. In other words, codeblocks is misusing the wx API, but with 2.8 this gets quietly ignored by default, whereas 3.0 reports it by default. I bet if you rebuilt codeblocks using the WXDEBUG build of 2.8 (available in Debian in package libwxgtk2.8-dbg - despite the name, this isn't debug symbols, but a separate build of the library) you'd see this assertion too. The simplest way to address this is to build codeblocks with -DNDEBUG (pass it in CPPFLAGS usually), which makes wx 3.0 behave as a default build of 2.8 would. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Hi, On 04/10/2014 13:48, Ian Jackson wrote: That comes directly from its goal of being easily consumable by a very wide range of window managers. The number of consumers (window manager, menu applets, desktop environments) is much smaller than the number of providers (in theory every application). Shouldn't a menu format be designed to be easy to use for the *larger* group of application providers? Having a goal to be easy to use on the window manager side and being less friendly[1] to the larger group seems to be the wrong design... More so if you take into account that application maintainers aren't really interested in menus, but people implementing menu systems are and have to know all the details. Ansgar [1] This might include maintainers having to convert icons at package build time and so on. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744093: awstats: Using the multiple-config schema results in cron spamming with errors
reopen 744093 retitle 744093 provide a better documentation for miltiple stats tag 744093 -patch thanks On Thu, Apr 10, 2014 at 01:16:52PM +0200, Martín Ferrari wrote: Probably I was confused about the upgrades, but you are still encouraged to leave the main file untouched: This way you can leave awstats.conf alone, and put your server-specific settings into awstats.conf.local, and your site-specific settings into each awstats.[site_name_here].conf file. I fail to see the words all local changes. Instead, I see exactly same what I told you below: If you read leave awstats.conf alone, clearly that means not modifying it. It says clearly to put server settings in .local and site settings in the other files. Are you actually reading this? I see also: --8-- To handle multiple stats (eg. using VirtualHosts in Apache) you should... 1) Place all *additional* configs in /etc/awstats/. 2) Name the *new configs* awstats. + whatever you want + .conf (eg. awstats.example.com.conf). But avoid awstats.awstats.conf. [...] --8-- So, it's all about *additional* vhosts. The main vhost supposed to be already configured - please don't consider every single line of README.Debian separately. But I admit, it maybe a good idea to use better wording. If my main host has some extra settings. Say, SkipHosts, because it gets many hits from a monitoring tool, or you want to enable a plugin for it... Where should I put that? Put this in some awstats.*.conf. Why you want to make this host to be the default one (main host)? Because it might make sense to do so. Why? There is some design pattern for multiple hosts config: awstats.conf - main site awstats.*.conf - others, they include the first one. Can you understand this once and follow this pattern? Yes, you can. Can you suggest a better solution? (Keep in mind single-config scenario!) Then, please go ahead. But your patch is not acceptable for now. And I'm not sure if there is a documentation issue, that's why this bug was closed. End of story. In any case, you are harming Debian. Maybe. If you are sure you can do my job better - please go ahead, take the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743870: Excessive dependencies required on upgrade
On 09/04/14 19:14, Dominique Dumont wrote: Hello On Monday 07 April 2014 16:44:47 you wrote: Together, these are responsible for pulling in 53 PERL packages as dependencies of lcdproc on my system. I feel that this is excessive, especially considering the relatively minor functionality that these packages provide (namely, to be able to upgrade the configuration file on package upgrades). ok. many packages are installed, but you don't need to worry about them. I don't understand why you consider this is a problem. I consider this a problem because it's a lot of packages that simply are not going to be used on these systems. A number of drivers are split into the lcdproc-extra-drivers package to avoid all users having to install large parts of X11, I think it would be kind to users to allow them not to install a large number of optional packages. Can this functionality please be made optional at the very least? It is. You will be asked whether to allow automatic upgrade or not. Could the config model packages be turned into a Recommends rather than a Depends, so that they don't have to be installed at all? It's really helpful to those of us who would like to maintain as minimal a system as possible. For example, I'd like to use lcdproc on a firewall system, and keeping the attack surface as small as possible is a common goal for this type of system. Thanks, Chris -- Chris Boot deb...@bootc.net GPG: 8467 53CB 1921 3142 C56D C918 F5C8 3C05 D9CE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Ansgar Burchardt writes (Bug#741573: Two menu systems): [1] This might include maintainers having to convert icons at package build time and so on. I think this is something quite trivial that can be centralised and automated (dh_...). Moving work from install time on the user's computer, to build time, is generally a win. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723719: ghostscript: New Upstream Version 9.10 available
Hi, On Thu, Sep 19, 2013 at 10:13:09AM +0200, Jonas Smedegaard wrote: Quoting Thomas Kempf (2013-09-19 08:45:37) Package: ghostscript Version: 9.05~dfsg-6.3 Severity: wishlist Upstream released Version 9.10 with significant improvements Packaged has been prepared since some time - awaits newer libcms2, tracked in bug#701993. Any chance of getting a newer ghostscript now? I updated lcms2 because I wanted a newer ghostscript :) Thanks Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744120: ifupdown: man page interfaces(5) misleading WRT source statement
Package: ifupdown Version: 0.7.8 Severity: normal Dear Maintainer, the man page interfaces(5) is misleading regarding the source statment; it shows as an example source interfaces.d/machine-dependent This leads to the wrong conclusion that the expected file name is relative to the /etc/network directory, while in fact is is better given as an absolute filename. regards, cm. -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ifupdown depends on: ii dpkg 1.16.12 ii initscripts 2.88dsf-41+deb7u1 ii iproute 20120521-3+b3 ii libc62.13-38+deb7u1 ii lsb-base 4.1+Debian8+deb7u1 ifupdown recommends no packages. Versions of packages ifupdown suggests: ii isc-dhcp-client [dhcp-client] 4.2.2.dfsg.1-5+deb70u6 ii net-tools 1.60-24.2 ii ppp2.4.5-5.1+b1 pn rdnssd none -- debconf information: ifupdown/convert-interfaces: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: If you don't like the trad menu, you don't have to use it. Nor do you have to do any significant amount of work to support it. All that is being asked is that you take other people's patches to support it. That's not should in the Policy sense. Should in the Policy sense does, in fact, mean that you have to do work to support it, although the level of pressure is only mild rather than at the level of rejecting the package entirely. I don't think we currently have a Policy term for if you don't think this is important for your package, or if you're just not interested in working on it, you can ignore it, but you do need to merge patches if someone else wants to work on it. That would probably be useful. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Charles Plessy ple...@debian.org writes: The underlying question is: who should spend the time writing these files and keeping them up to date ? In the case of missing manual pages, the policy (§ 12.1) does not require the package maintainer to write one. Hm. I have never read that section of Policy that way. I do think that is intended to say that the package maintainer should write one, and that's the most common interpretation that I've seen in debian-mentors as well. They're not *required*, no, but that's true of any should. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: Ansgar Burchardt writes (Bug#741573: Two menu systems): [1] This might include maintainers having to convert icons at package build time and so on. I think this is something quite trivial that can be centralised and automated (dh_...). Moving work from install time on the user's computer, to build time, is generally a win. Until someone has actually done that work, I believe the possibility of it being done should be out of bounds for this Technical Committee discussion, unless the intended implication is that the Policy maintainers should go write such a tool (given that we're the ones affected directly by the judgement of the TC here). There are doubtless many things that could be done to make it easier for maintainers who largely prefer desktop files to support the traditional menu as well. Part of the reason why this bug was raised in Policy in the first place is that none of them have actually happened, and that didn't seem that likely to change. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Drupal7 - minified JavaScript
Daniel Pocock dijo [Thu, Apr 10, 2014 at 12:40:27PM +0200]: Hi Gunnar, I just saw your comment on this bug from February 18 Personally, I don't think it is enough to say that a package is not using some artifacts from the source tarball - while it is a technically valid argument, it would make it far more difficult for FTP masters to inspect source packages and badness could start to creep in as a consequence of any generosity they show in this area. Repackaging upstream tarballs is becoming a common problem with minified JavaScript, maybe we need to have some automated way of doing this. For upstreams who use git and who release the exact contents of their tags (without any autotools bootstrapping, etc), it should be fairly easy to create some system on alioth that mirrors all the upstreams and pro-actively generates +dfsg versions of their tags ready for maintainers to work with. Right. This bug was opened before the relevant discussion in d-devel, and I am also convinced the minified js should be removed from the source tarball. I have not had time to look into this, and any help you can give will be appreciated; a simple (or as simple as possible, at least) repack.sh script should do. Automating this sounds interesting, but I cannot do more than just say it sounds interesting right now :( signature.asc Description: Digital signature
Bug#741573: Two menu systems
Russ Allbery writes (Bug#741573: Two menu systems): Charles Plessy ple...@debian.org writes: The underlying question is: who should spend the time writing these files and keeping them up to date ? ... In the case of missing manual pages, the policy (§ 12.1) does not require the package maintainer to write one. Hm. I have never read that section of Policy that way. I do think that is intended to say that the package maintainer should write one, and that's the most common interpretation that I've seen in debian-mentors as well. They're not *required*, no, but that's true of any should. In practice there are lots and lots of packages in the archive with missing manpages. The policy goes on at some length about what to do when manpages are missing. It doesn't suggest that the right answer is not to upload the package. Of course providing a menu entry is far easier than providing a manpage. Some would argue it's correspondingly less useful. I wouldn't object to some wording in policy which made it clear that the maintainer isn't required to do the work to provide a menu entry if they find it inconvenient. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741573: Two menu systems
Russ Allbery writes (Bug#741573: Two menu systems): That's not should in the Policy sense. Should in the Policy sense does, in fact, mean that you have to do work to support it, although the level of pressure is only mild rather than at the level of rejecting the package entirely. As I say, policy doesn't say who should do the work. It just says what the package should look like. Whether a package that doesn't conform to all the shoulds in policy ought to be included in the archive is surely a decision for the packager. If you think this needs clarifying somewhere, I don't think anyone will object. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744122: iproute2: ss protocol family filter does not work properly
Package: iproute2 Version: 3.12.0-2 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Type in console a command below: * What exactly did you do (or not do) that was effective (or ineffective)? $ss -l -4 * What was the outcome of this action? Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port nl UNCONN 0 0 rtnl:charon/2239* nl UNCONN 0 0 rtnl:-4131 * nl UNCONN 0 0 rtnl:kernel * nl UNCONN 4352 0 tcpdiag:ss/16568* nl UNCONN 7680 tcpdiag:kernel * nl UNCONN 0 06:-4130 * nl UNCONN 0 06:charon/2239* nl UNCONN 0 06:kernel * nl UNCONN 0 07:kernel * nl UNCONN 0 09:kernel * nl UNCONN 0 0 10:kernel * nl UNCONN 0 0 11:kernel * nl UNCONN 0 0 15:udisksd/3610* nl UNCONN 0 0 15:Thunar/3577* nl UNCONN 0 0 15:-4134 * nl UNCONN 0 0 15:-4137 * nl UNCONN 0 0 15:kernel * nl UNCONN 0 0 15:404* nl UNCONN 0 0 15:colord/2995* nl UNCONN 0 0 15:-4135 * nl UNCONN 0 0 15:-4138 * nl UNCONN 0 0 15:systemd-logind/3409 * nl UNCONN 0 0 15:Xorg/2932* nl UNCONN 0 0 15:-4136 * nl UNCONN 0 0 16:2229 * nl UNCONN 0 0 16:kernel * nl UNCONN 0 0 18:kernel * p_dgr UNCONN 0 0*:dummy0 * p_dgr UNCONN 0 0*:eth0 * p_dgr UNCONN 0 0 arp:* * u_str LISTEN 0 0 /var/run/charon.ctl 7161 * 0 u_str LISTEN 0 0 /var/run/charon.lkp 7655 * 0 u_str LISTEN 0 0 /var/run/dbus/system_bus_socket 7728 * 0 u_str LISTEN 0 0 @/org/bluez/audio 7912 * 0 u_str LISTEN 0 0 @/tmp/.X11-unix/X0 8000 * 0 u_str LISTEN 0 0 /tmp/.X11-unix/X0 8001 * 0 u_str LISTEN 0 0 /var/run/cups/cups.sock 9055 * 0 u_str LISTEN 0 0 /var/run/acpid.socket 9231 * 0 u_str LISTEN 0 0 /var/run/charon.enfy 9237 * 0 u_str LISTEN 0 0 /tmp/ssh-sHv5nStfos2G/agent.3416 9804 * 0 u_str LISTEN 0 0 @/tmp/dbus-S42PhMPRo9 10155 * 0 u_str LISTEN 0 0 /var/run/sdp 10365 * 0 u_str LISTEN 0 0 @/tmp/.ICE-unix/3544 10767 * 0 u_str LISTEN 0 0 /tmp/.ICE-unix/3544 10768 * 0 u_str LISTEN 0 0 /tmp/gpg-qegRNV/S.gpg-agent 12505 * 0 u_str LISTEN 0 0 /tmp/ssh-jtI8qIKEbklV/agent.3465 12564 * 0 u_str LISTEN 0 0 @/tmp/dbus-btzGvMIKRa 12616 * 0 u_str LISTEN 0 0 /tmp/gpg-J71B6j/S.gpg-agent 12626 * 0 u_str LISTEN 0 0 /tmp/xmms-ipc-kjonca 28948 * 0 u_str LISTEN 0 0 /tmp/.vbox-kjonca-ipc/ipcd 45169 * 0 u_dgr LISTEN 0 0 /run/udev/control 5587 * 0 rawUNCONN 0 0*:icmp *:* tcpLISTEN 0 128 *:rsync *:* tcpLISTEN 0 50 *:8010 *:* tcpLISTEN 0 10
Bug#741573: Two menu systems
Russ Allbery writes (Bug#741573: Two menu systems): Ian Jackson ijack...@chiark.greenend.org.uk writes: Ansgar Burchardt writes (Bug#741573: Two menu systems): [1] This might include maintainers having to convert icons at package build time and so on. I think this is something quite trivial that can be centralised and automated (dh_...). Moving work from install time on the user's computer, to build time, is generally a win. Until someone has actually done that work, I believe the possibility of it being done should be out of bounds for this Technical Committee discussion, unless the intended implication is that the Policy maintainers should go write such a tool (given that we're the ones affected directly by the judgement of the TC here). I think you've misunderstood me. I felt Ansgar and I were discussing in the abstract what would be the most optimal situation. Certainly I'm not saying that policy should mandate the use of anything that doesn't currently exist. I think that whether the general machinery for converting icons etc. for the menu is sufficiently automatic/sophisticated is a matter for the submitters of trad menu integration patches. IMO if those patches aren't unreasonable then maintainers should accept them, even if they're slightly less automatic than would be ideal. There are doubtless many things that could be done to make it easier for maintainers who largely prefer desktop files to support the traditional menu as well. Part of the reason why this bug was raised in Policy in the first place is that none of them have actually happened, and that didn't seem that likely to change. Has anyone described any actual difficulties with supporting the traditional menu ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
[Michael Hanke 2012-06-30] Hi, Hi again. In our squeeze-based cluster enabling dependency-based booting causes certain daemons to have different SigIgn masks -- more to the point, they start ignoring SIGINT. As you can imagine that has all kinds of implications (for the daemons and the processes they start). Are you still able to reproduce this? I'm trying to write a test case to trigger this bug, but am unable to do so. This is the test code I use, and it always report SigIgn: for both test scripts. What am I doing wrong? Note that you need startpar version 0.59 just uploaded to unstable to have support for the -e and -d options to use startpar without running scripts in /etc/init.d/. :) #!/bin/sh set -e if [ -z $STARTPAR ] ; then STARTPAR=../startpar fi mkdir -p etc/init.d touch etc/insserv.conf cat etc/init.d/test 'EOF' #!/bin/sh set -e ### BEGIN INIT INFO # Provides: test # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: test script ### END INIT INFO echo success: the test script is running $1 echo signal mask for $$: cat /proc/$$/status | grep \(SigIgn\|Name\) EOF chmod a+rx etc/init.d/test cat etc/init.d/test2 'EOF' #!/bin/sh set -e ### BEGIN INIT INFO # Provides: test2 # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: test script ### END INIT INFO echo success: the test2 script is running $1 echo signal mask for $$: cat /proc/$$/status | grep \(SigIgn\|Name\) EOF chmod a+rx etc/init.d/test2 /sbin/insserv -p etc/init.d test /sbin/insserv -p etc/init.d test2 $STARTPAR -d etc/init.d -e etc -P 1 -R 2 -M start rm -rf etc -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#360970: graphviz-java debian package
Do we have graphviz-java debian package? Regards Prosenjit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744120: ifupdown: man page interfaces(5) misleading WRT source statement
Hello, On 10 April 2014 14:27, christian mock c...@coretec.at wrote: the man page interfaces(5) is misleading regarding the source statment; it shows as an example source interfaces.d/machine-dependent This leads to the wrong conclusion that the expected file name is relative to the /etc/network directory, while in fact is is better given as an absolute filename. In fact, that's correct; the file name can be both absolute or relative; when it's relative, it's relative to the directory in which the file having the statement is found; it was relative to the current directory in older versions, but that wasn't a very good decision however. I should document that better, I agree. -- Cheers, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Drupal7 - minified JavaScript
On 10/04/14 14:51, Gunnar Wolf wrote: Daniel Pocock dijo [Thu, Apr 10, 2014 at 12:40:27PM +0200]: Hi Gunnar, I just saw your comment on this bug from February 18 Personally, I don't think it is enough to say that a package is not using some artifacts from the source tarball - while it is a technically valid argument, it would make it far more difficult for FTP masters to inspect source packages and badness could start to creep in as a consequence of any generosity they show in this area. Repackaging upstream tarballs is becoming a common problem with minified JavaScript, maybe we need to have some automated way of doing this. For upstreams who use git and who release the exact contents of their tags (without any autotools bootstrapping, etc), it should be fairly easy to create some system on alioth that mirrors all the upstreams and pro-actively generates +dfsg versions of their tags ready for maintainers to work with. Right. This bug was opened before the relevant discussion in d-devel, and I am also convinced the minified js should be removed from the source tarball. I have not had time to look into this, and any help you can give will be appreciated; a simple (or as simple as possible, at least) repack.sh script should do. Automating this sounds interesting, but I cannot do more than just say it sounds interesting right now :( This automated repacking idea has significant overlap with one of the GSoC projects: https://wiki.debian.org/SummerOfCode2014/StudentApplications#Recursively_building_Java_dependencies_from_source Whether the embedded artifacts are called *.jar or *.min.js, the same script could probably help -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744123: pcmanfm: Pcmanfm always show hidden files at startup
Package: pcmanfm Version: 1.2.0-1 Severity: normal Dear Maintainer, Pcmanfm always show hidden files at startup if the last time you used the program you changed from personal folder to another folder. Furthermore, there is no way to erase the templates folder. This happens to me on my amd64 computer, not on my i386 computer. Thank you very much. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pcmanfm depends on: ii libatk1.0-0 2.12.0-1 ii libc62.18-4 ii libcairo21.12.16-2 ii libfm-gtk4 1.2.0-1 ii libfm4 1.2.0-1 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-0 2.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii libx11-6 2:1.6.2-1 Versions of packages pcmanfm recommends: ii gnome-icon-theme 3.12.0-1 ii gvfs-backends 1.20.0-1+b1 ii gvfs-fuse 1.20.0-1+b1 ii lxde-icon-theme 0.5.0-1 ii tango-icon-theme 0.8.90-5 pcmanfm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741361: [Pkg-kde-extras] Bug#741361: Bug#741361: Please migrate to xine-lib-1.2
On Wednesday 09 April 2014 23:05:16 Moritz Mühlenhoff wrote: [snip] kaffeine is now the only package left (beside pyxine, which is filed for removal), so it would be nice if you could either fix this soon or give me the green light to fix it myself (this is indirectly holding the libav10 transition) Moritz: please go ahead :) -- Passwords are like underwear. You shouldn’t leave them out where people can see them. You should change them regularly. And you shouldn’t loan them out to strangers. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#679630: insserv: Dependency-based boot changes SigIgn mask of daemons
Hi, On Thu, Apr 10, 2014 at 03:10:54PM +0200, Petter Reinholdtsen wrote: Are you still able to reproduce this? I'm trying to write a test case to trigger this bug, but am unable to do so. This is the test code I use, and it always report SigIgn: for both test scripts. What am I doing wrong? Note that you need startpar version 0.59 just uploaded to unstable to have support for the -e and -d options to use startpar without running scripts in /etc/init.d/. :) Thanks for keeping track of this one! Unfortunately, the issue is still present -- on an up-to-date Debian wheezy. I still have no clue who to trigger this behavior other than a reboot of those machines. I can still reliably fix it by a restart of the condor daemons once the machines are fully up. If there is anything I can try on those machines that would help you determine the problem please let me know. Thanks, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744124: postgresql-9.1 claims to test version 9.3.4
Package: debci Severity: normal Hi, on 2014-04-02, http://ci.debian.net/#package/postgresql-9.1 started listing 9.3.4-1. That's clearly wrong; 9.3.4 is from a different source package postgresql-9.3. The buildlogs in turn show that postgresql-9.1 9.1.13-1 is being downloaded. A second incarnation of this bug is that I've seen further mismatches there, the overview list claimed to target 9.1.11, while it was then downloading 9.1.13. The buildlog should mention at the very top the package name and version it is trying to test. And apt-get source $pkg should probably replaced by apt-get source $pkg=$version. Thanks for maintaining ci.debian.net! Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
