Bug#673765: dom4j FTBFS with openjdk-7
On 2012-05-23 10:19, James Page wrote: Hi Niels On 23/05/12 07:27, Niels Thykier wrote: However, I must admit I am a bit concerned in the use of of != with reals (floats/doubles)[0]. To my understanding (in at least C/C++) that is very likely to always be true due to even minor rounding errors[1]. Presumably this is why upstream used Math.round in the first place. It is possible that it only apply to expressions (and not stored values in variables) or Java handles this better, but in this case, I believe a comment in the code documenting this assertion would be prudent. I had the same concern when writing this patch but reading into this in a bit more detail I decided that this was actually OK for the following reason. The priority (see [0]) is always one of four values: -0.25 0.5 0.0 -0.5 I did a quick check and all four of these values can be represented accurately in Java (this is not true of all float/double literals). I'll update the patch with an appropriate comment to this effect. Cheers James [0] http://www.w3.org/TR/xslt11/#conflict Revisiting this, couldn't we use Double.compare(double, double) for this? This way we should be safe from changes (if any) in how doubles are handled in the future as well as any changes to the standard (possible exceptions include allowing the use NaN or INF values). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674004: lintian: doc-base-unknown-section Video should be known
tags 674004 + unreproducible thanks On 2012-05-22 15:23, Philipp Huebner wrote: Package: lintian Version: 2.5.7 Severity: minor While working on a new version of the package photofilmstrip I came across this lintian hint: W: photofilmstrip: doc-base-unknown-section photofilmstrip:5 Video Checking the available documentation and running install-docs --verbose --check debian/photofilmstrip.doc-base show that Video is indeed a valid section, hence Lintian is wrong. [...] Hi, I cannot reproduce this, I tested the deb photofilmstrip/1.9.91+dfsg-1 currently in sid. As far as I can tell, Lintian has known about the Video section since 2008 (according to git blame). So I am a bit puzzled about this report... ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560423: debhelper: Add debian/dh_norun file to list, commands not to run (ver 8?)
X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Joey Hess wrote: There is some potential for speeding up dh. Josh Tripplet and I once discussed: * Having dh optimize out calls to debhelper commands that will be no-ops. For a subset of commands, this can be determined just by looking for their config files. Some kind of metadata would be necessary for dh to tell which commands are in that subset. Hi, Perhaps the sequence modules could contain such information? This would allow third-party sequences to take advantage of this optimization as well. * Speed up dh_gencontrol, er, I mean dpkg-gencontrol, which by itself is responsible for more than 1/3 of the total runtime of dh binary in a package where the other debhelper commands are all no-ops. Can you remember what method you used to determine this? I would like to see if this is still the case, before I try look at optimizing it (if only to know when I am done ;) ). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681327: unblock: modsecurity-apache/2.6.6-2
On 2012-07-12 12:21, Alberto Gonzalez Iniesta wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package modsecurity-apache A change in the license went unnoticed. Just debian/copyright was updated. debdiff attached. unblock modsecurity-apache/2.6.6-2 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash + [...]; either version 2 of the License. Did you mean either version 2 or (at your choice any) later version of the License? (or however it is written...) According to your copyright file, any Debian patches will be under GPL-2 and cannot be applied. However, the Apache2 license is not compatible with GPL-2 (it seems to be with GPL-3)[1]. [1] http://www.apache.org/licenses/GPL-compatibility.html Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681346: ITP: libdigest-sha1-perl -- Perl interface to the SHA-1 algorithm
On 2012-07-12 16:04, Gergely Nagy wrote: Dmitry E. Oboukhov un...@debian.org writes: Package: wnpp Severity: wishlist Owner: Dmitry E. Oboukhov un...@debian.org Package name: libdigest-sha1-perl Version : 2.13 Upstream Author : Gisle Aas gi...@activestate.com URL : http://search.cpan.org/dist/Digest-SHA1/ License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl interface to the SHA-1 algorithm The Digest::SHA1 module allows you to use the NIST SHA-1 message digest algorithm from within Perl programs. The algorithm takes as input a message of arbitrary length and produces as output a 160-bit fingerprint or message digest of the input. . The Digest::SHA1 module provide a procedural interface for simple use, as well as an object oriented interface that can handle messages of arbitrary length and which can read files directly. Out of curiosity, how does this compare to Digest::SHA (libdigest-sha-perl), which is already in the archive, and supports SHA1 and a couple of others too? Digest::SHA appears to have a very similar interface too. Hi, The package has been in the archive before, but was removed (see #594273). As I understand it, Digest::SHA1 should be redundant, but I might have overlooked something. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560423: debhelper: Add debian/dh_norun file to list, commands not to run (ver 8?)
On 2012-07-12 12:41, Niels Thykier wrote: Joey Hess wrote: There is some potential for speeding up dh. Josh Tripplet and I once discussed: * Having dh optimize out calls to debhelper commands that will be no-ops. For a subset of commands, this can be determined just by looking for their config files. Some kind of metadata would be necessary for dh to tell which commands are in that subset. Hi, Perhaps the sequence modules could contain such information? This would allow third-party sequences to take advantage of this optimization as well. [...] ~Niels I have developed a prototype patch for optimizing out unused debhelper commands from a dh sequence. The basic idea it is to maintain a table in dh mapping skippable commands to their pkgfile-files. If a command is in the table and none of these files are present (for any package to be acted on), then the command is skipped. It gives backwards compatible semantics for add-on sequences (their commands are not present in the table). Commands are checked just before they are run, but after their override targets are run (if any). This allows the build to auto-generate the files and should be backwards compatible as far as I can tell. The prototype does /not/ include an API extension for sequence modules to add their commands to the auto skip table. However, it should be fairly trivial to create and I will happily add it if this approach is deemed reasonable. I have included a small print statement to inform when a command is skipped. I have no strong feelings for whether or not it should stay; I merely added it to assist the development. I have included the following skip rules (long lines truncated): dh_bugfiles = [qw(bug-script bug-control bug-presubj)], dh_install = [install], dh_installcron = [qw(cron.daily ...)], dh_installcatalogs = [sgmlcatalogs], dh_installemacsen = [qw(emacsen-install ...)], dh_installexamples = [examples], dh_installifupdown = [qw(if-up if-down ...)], dh_installinfo = [info], dh_lintian = [lintian-overrides], dh_installmenu = [menu, menu-method], dh_ucf = [ucf], The commands were added based on memory or/and a quick view in the manpage. It can most likely be extended and (to my knowledge) does not include commands that may do stuff based on what it is in debian/pkg (but do correct me if I am wrong). ~Niels sample.patch Description: application/wine-extension-patch
Bug#681377: unblock: libpdfbox-java/1:1.7.0+dfsg-2
On 2012-07-12 20:24, gregor herrmann wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libpdfbox-java. -2 fixes the (at least) important bug #680778, the only change is is an added dependency. Full debdiff attached. unblock libpdfbox-java/1:1.7.0+dfsg-2 Thanks in advance, gregor I notice it does not add a class-path change in the Jar file; is this class-path entry already present? According to the reporter, he also added a class-path for it to work. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681577: unblock: tkabber/0.11.1-3
On 2012-07-14 14:00, Konstantin Khomoutov wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package tkabber. The .desktop file referenced the application's icon using a wrong pathname which prevented that icon from showing up in menus and other parts of a DE interface. This has been corrected. unblock tkabber/0.11.1-3 [...] Please go ahead and upload it to sid and let us know when it has been accepted. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681712: xz-java: issue with d/xz.pom and d/copyright
Source: xz-java Severity: normal d/copyright claims d/xz.pom is licensed under Apache 2, but it is actually in public domain according the file itself. I am filing this bug as a reminder; please do NOT upload a fixed version until 1.0-2 has migrated to testing (as it makes the lives of the Release team much harder). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681448: unblock: nsd3/3.2.11-1
On 2012-07-13 10:37, Ondřej Surý wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package nsd3 Since this version will be the next supported I would like to push latest upstream, which: - add support for TLSA RR type - add support for ECDSA (Elliptic Curve algorithms) in DNSSEC Both of these will hopefully used in upcoming years: - EC algorithms have nice properties of being smaller and faster, so people will rollover to them once the support in DNSSEC validators is prevalent - TLSA allows certificate pinning (and even Debian would benefit from that as you can add trust anchor on the fly for self-signed CAs and certs). We hope to see support in browsers/MTAs/MUAs etc. start to growing as the protocol is almost a standard (in RFC-Editor queue for those who knows what that means :)). The upstream release also includes few minor fixes in IXFR code and new zone stats, which I haven't enabled since it's a new code. (I could cherry-pick these two main mentioned features, but I feel it's not worth it as NSD3 has no rev-deps and the codebase is stable.) unblock nsd3/3.2.11-1 [...] Hi, The changes sums up to: 79 files changed, 2907 insertions(+), 2130 deletions(-) Which is way more than I can sanely review. Can you generate a manual debdiff where you filter out the auto-generated files (e.g. configlexer.c)? That might give a better view of what is happening. I also noticed this gbp.conf change, which was probably unintented. -debian-branch = debian-sid +debian-branch = debian-backports -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681419: tech-ctte help needed: main dependencies on non-free/contrib
On 2012-07-17 19:35, Russ Allbery wrote: Hello all, [...] It would also be quite interesting, although much harder to determine, whether there are any scenarios where such a dependency would result in a non-free package being installed by default. If, for example, there's a dependency on foo | foo-nonfree and some packages conflict with foo but not with foo-nonfree such that a dependency resolver may pull in foo-nonfree in preference. Thanks! Hi, I suspect installability checking of all packages should find them if they are there. One run with non-free+contrib and one without - the newly uninstallable between the two runs should be set you are looking for. It does not catch issues like foo-nonfree | foo, but they would be caught by your other query. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681971: Syntax error in catalina.sh -security: java.security.policy==
On 2012-07-18 11:34, Christoph Berg wrote: Package: tomcat6-common Version: 6.0.35-1 Severity: grave Tags: security /usr/share/tomcat6/bin/catalina.sh line 276 reads -Djava.security.policy==$CATALINA_BASE/work/catalina.policy \ The double = looks like a mistake. When running with -security, the policy will not get loaded. Admittedly, I haven't tested it here, but I figured I should still file a bug because this just looks too obvious. If the second = is on purpose there, some comment should document that. Affected are both squeeze and unstable/testing. Christoph [...] Hi, I vaguely that there are special semantics regarding security settings and the use of ==, so its use may be legitimate. Admittedly it was a while back I last looked at security settings ... ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682060: jarjar: Embeds parts of libasm3-java
Package: jarjar Version: 1.1-3 Severity: important This embedded code caused #646600 and it is not really preferred. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682061: unblock: jarjar/1.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package jarjar, which fixes the RC bug #646600. The bug is that if you rebuild jarjar in SID it will construct an incomplete Java library. This is because it embeds a part of libasm3-java inself during build (I have filed a bug for that) and some of that moved to another Jar file breaking. I also took the liberity of removing a MIA uploader. unblock jarjar/1.1-3 ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682061: unblock: jarjar/1.1-3
On 2012-07-19 10:18, Niels Thykier wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jarjar, which fixes the RC bug #646600. The
bug is that if you rebuild jarjar in SID it will construct an
incomplete Java library.
This is because it embeds a part of libasm3-java inself during build
(I have filed a bug for that) and some of that moved to another Jar
file breaking.
I also took the liberity of removing a MIA uploader.
unblock jarjar/1.1-3
~Niels
... and the debdiff.
~Niels
changelog| 19 ++
control |2 -
patches/0006-remove-asm-commons-from-final-jar.patch | 25 ---
patches/series |1
4 files changed, 20 insertions(+), 27 deletions(-)
diff -Nru jarjar-1.1/debian/changelog jarjar-1.1/debian/changelog
--- jarjar-1.1/debian/changelog 2011-09-08 20:31:33.0 +
+++ jarjar-1.1/debian/changelog 2012-07-15 11:19:14.0 +
@@ -1,3 +1,22 @@
+jarjar (1.1-3) unstable; urgency=low
+
+ * Rember to actually remove Michael Koch from uploaders.
+
+ -- Niels Thykier ni...@thykier.net Sun, 15 Jul 2012 13:19:13 +0200
+
+jarjar (1.1-2) unstable; urgency=low
+
+ [ James Page ]
+ * Drop debian/patches/0006-remove-asm-commons-from-final-jar.patch:
+libasm3-java now ships correctly separated jar files so asm-commons
+must be included. (Closes: #646600)
+
+ [ Niels Thykier ]
+ * Remove Michael Koch from uploaders. Thanks for your work so far.
+(Closes: #654028)
+
+ -- Niels Thykier ni...@thykier.net Sun, 15 Jul 2012 12:42:56 +0200
+
jarjar (1.1-1) unstable; urgency=low
* Team upload
diff -Nru jarjar-1.1/debian/control jarjar-1.1/debian/control
--- jarjar-1.1/debian/control 2011-09-08 20:31:33.0 +
+++ jarjar-1.1/debian/control 2012-07-15 11:18:46.0 +
@@ -2,7 +2,7 @@
Section: java
Priority: optional
Maintainer: Debian Java Maintainers
pkg-java-maintain...@lists.alioth.debian.org
-Uploaders: Michael Koch konque...@gmx.de, Niels Thykier ni...@thykier.net
+Uploaders: Niels Thykier ni...@thykier.net
Build-Depends: debhelper (= 7), cdbs, ant, libasm3-java, default-jdk
Standards-Version: 3.9.2
Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/jarjar
diff -Nru
jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
--- jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
2011-09-08 20:26:25.0 +
+++ jarjar-1.1/debian/patches/0006-remove-asm-commons-from-final-jar.patch
1970-01-01 00:00:00.0 +
@@ -1,25 +0,0 @@
-From: Torsten Werner twer...@debian.org
-Date: Sun, 28 Feb 2010 12:45:45 +0100
-Subject: remove asm-commons from final jar
-
- build.xml |5 -
- 1 files changed, 0 insertions(+), 5 deletions(-)
-
-diff --git a/build.xml b/build.xml
-index bbae4da..160e9ee 100644
a/build.xml
-+++ b/build.xml
-@@ -79,11 +79,6 @@
- jarjar jarfile=${jarfile}
- fileset dir=build/main/
- zipfileset src=${asm.jar}/
-- zipfileset src=${asm-commons.jar}
--include name=org/objectweb/asm/commons/EmptyVisitor.class/
--include name=org/objectweb/asm/commons/Remap*.class/
--include
name=org/objectweb/asm/commons/LocalVariablesSorter.class/
--/zipfileset
- keep pattern=com.tonicsystems.jarjar.Main/
- keep pattern=com.tonicsystems.jarjar.JarJarTask/
- rule pattern=com.tonicsystems.jarjar.util.**
result=com.tonicsystems.jarjar.ext_util.@1/
---
diff -Nru jarjar-1.1/debian/patches/series jarjar-1.1/debian/patches/series
--- jarjar-1.1/debian/patches/series2010-02-28 11:52:52.0 +
+++ jarjar-1.1/debian/patches/series2012-07-15 10:36:37.0 +
@@ -3,4 +3,3 @@
0003-fix-path-in-build.xml.patch
0004-support-gnu-regexp.patch
0005-cast-null-to-java.io.File.patch
-0006-remove-asm-commons-from-final-jar.patch
Bug#682085: unblock: bdfresize/1.5-7
tags 682085 +moreinfo thanks On 2012-07-19 14:17, Tatsuya Kinoshita wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock bdfresize/1.5-7 to enable hardening flags for wheezy. Changes: * Update debhelper compat level to 9 to support hardening flags See also the attached debdiff. unblock bdfresize/1.5-7 Thanks, -- Tatsuya Kinoshita Hi, I am not sure we are ready to accept a debhelper bump at this time if we can avoid it. Would it be possible to use dpkg-buildflags directly? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541491: lintian: Override for specific files in patch-system-but-direct-changes-in-diff
Hi, I am interested in this feature; partly because it sounds like it can remove the need for manual emit-only-once code in various checks. Though, the current suggested solution works on a tag-level, but for (e.g.) hyphen-used-as-minus-sign we currently limit it X per file rather than X in total. Of course, the issue here is that we (currently) do not associate emitted tags with file triggering the tag, so it is not possible to solve currently. Also, are we going to add an extra tag saying (and X other instances) or do we leave a note in the end (e.g. Some emitted tags are not shown)? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670915: libiscwt-java: FTBFS with swt-gtk 3.8 (experimental)
Source: libiscwt-java
Version: 5.3.20100629-1
Severity: important
Hi,
libiscwt-java FTBFS with swt-gtk 3.8 (from experimental). Presumably
it is the use of /usr/share/java/swt-gtk-3.7.jar rather than
/usr/share/java/swt.jar.
Log attached.
~Niels
dpkg-buildpackage: source package libiscwt-java
dpkg-buildpackage: source version 5.3.20100629-1
dpkg-buildpackage: source changed by Torsten Werner twer...@debian.org
dpkg-source --before-build libiscwt-java-5.3.20100629
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh --with javahelper clean
dh_testdir
dh_auto_clean
jh_clean
dh_clean
dpkg-source -b libiscwt-java-5.3.20100629
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building libiscwt-java using existing
./libiscwt-java_5.3.20100629.orig.tar.gz
dpkg-source: info: building libiscwt-java in
libiscwt-java_5.3.20100629-1.debian.tar.gz
dpkg-source: info: building libiscwt-java in libiscwt-java_5.3.20100629-1.dsc
debian/rules build
dh --with javahelper build
dh_testdir
dh_auto_configure
jh_linkjars
dh_auto_build
jh_build
find src -name *.java -and -type f -print0 | xargs -0
/usr/lib/jvm/default-java/bin/javac -cp
/usr/share/java/isnativec.jar:/usr/share/java/isfreetype.jar:/usr/share/java/isrt.jar:rt.jar:/usr/share/java/swt-gtk-3.7.jar:debian/_jh_build.iscwt
-d debian/_jh_build.iscwt -source 1.5
src/de/intarsys/cwt/font/truetype/TTFontParser.java:175: warning: unmappable
character for encoding ASCII
* UFWORDadvanceWidthMaxMaximum advance width value in
?hmtx? table.
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:175: warning: unmappable
character for encoding ASCII
* UFWORDadvanceWidthMaxMaximum advance width value in
?hmtx? table.
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:176: warning: unmappable
character for encoding ASCII
* FWORDminLeftSideBearingMinimum left sidebearing
value in ?hmtx? table.
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:176: warning: unmappable
character for encoding ASCII
* FWORDminLeftSideBearingMinimum left sidebearing
value in ?hmtx? table.
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:187: warning: unmappable
character for encoding ASCII
* USHORTnumberOfHMetricsNumber of hMetric entries in
?hmtx? table; may be smaller than the total number of glyphs in the font.
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:187: warning: unmappable
character for encoding ASCII
* USHORTnumberOfHMetricsNumber of hMetric entries in
?hmtx? table; may be smaller than the total number of glyphs in the font.
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:351: warning: unmappable
character for encoding ASCII
* ULONGulUnicodeRange1Bits 0?31
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:352: warning: unmappable
character for encoding ASCII
* ULONGulUnicodeRange2Bits 32?63
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:353: warning: unmappable
character for encoding ASCII
* ULONGulUnicodeRange3Bits 64?95
^
src/de/intarsys/cwt/font/truetype/TTFontParser.java:354: warning: unmappable
character for encoding ASCII
* ULONGulUnicodeRange4Bits 96?127
^
src/de/intarsys/cwt/font/FontEnvironment.java:43: warning: sun.font.FontManager
is internal proprietary API and may be removed in a future release
import sun.font.FontManager;
^
src/de/intarsys/cwt/swt/image/ImageConverterSwt2Awt.java:36: package
org.eclipse.swt.graphics does not exist
import org.eclipse.swt.graphics.ImageData;
^
src/de/intarsys/cwt/swt/image/ImageConverterSwt2Awt.java:44: cannot find symbol
symbol : class ImageData
location: class de.intarsys.cwt.swt.image.ImageConverterSwt2Awt
private ImageData imageData;
^
src/de/intarsys/cwt/swt/image/ImageConverterSwt2Awt.java:46: cannot find symbol
symbol : class ImageData
location: class de.intarsys.cwt.swt.image.ImageConverterSwt2Awt
public ImageConverterSwt2Awt(ImageData imageData) {
Bug#669992: libdb5.3-java: arch-dependent files in, multiarch: same package
On Sun, Apr 22, 2012 at 15:19, Julien Cristau wrote: libdb5.3-java is marked as Multi-Arch: same, but contains files in arch-independent paths with arch-specific contents: [libdb5.3-java 5.3.15-3] usr/share/java/db-5.3.15.jar Hmm, I always thought that JAR files are arch-independent. If that's not the case, could you please point me to packaging instructions (or existing package) how to pack multiarch java archives? O. -- Ondřej Surý ond...@sury.org Hi, Presumably, the issue is the timestamp of files packed in the jar file (which will differ between architectures due to different build times). In rare cases upstreams actually do put different content/bytecode in the JARs based on the architecture (SWT is a known example). Assuming it is architecture independent, it may make sense to move the JAR file to an architecture independent package (or move the SO files to an architecture dependent package and make libdb5.3-java arch:all). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671058: lintian: DEP-3 From field - name preceeds email
block 671058 by 602304 tags 671058 + moreinfo tags 602304 + moreinfo thanks On 2012-05-01 16:51, Jari Aalto wrote: Package: lintian Version: 2.5.6 Severity: wishlist For debian/patches in DEP-3 format, please add some check to warn about headers like this (From/Author): From: d...@example.com Subject: Fix FTBFS Something like: I: patches-header-from-missing-person-name Hi, I believe I have already mentioned it in #602304, but DEP-3 does not mandate that the from header is in a specific format. Supposedly, the format m...@example.com (name) variant is allowed too. Also, we still (to my knowledge) cannot relibly detect DEP-3 from non-DEP-3 patches nor do we have a parser supporting the format (hench the block on 602304). The tag description could suggest that the person name would be written in full; at least consisting of two words before : From: Firstname Lastname d...@example.com Subject: Fix FTBFS There may be more than two words like in spanish names, but 99% of the cases people have at least two identification words for the first and last name/family name (like in Japan). I believe you are incorrect here - allegedly there are places where mononyms are common[1]. Personally I am aware of at least two people in Debian with a mononym. ~Niels [1] http://en.wikipedia.org/wiki/Mononym#Countries_where_mononyms_are_normal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642908: lintian: Add P: or X: check to recommend DEP 5 for debian/copyright
On 2011-09-26 00:32, Russ Allbery wrote: Jari Aalto jari.aa...@cante.net writes: Please add a check to recommend update old debian/copyright to DEP 5 format. I don't think this is appropriate, at least at this time. Some parts of Debian really like the format, but other maintainers really don't, and Lintian tries not to take a stance (even at the pedantic level) on issues of ongoing controversy. Personally, I agree with this and this is also why I have not looked at fixing #612610. I think it would be appropriate to add such a check in the profiles of specific packaging teams who want to use DEP-5 on all of their packages, but not centrally in Lintian's default profiles. Maybe we should block this (and #612610) on #359059? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643735: lintian: Add check for manual page to verify TH matches FILENAME.N
On 2011-09-29 07:11, Jari Aalto wrote: Package: lintian Version: 2.5.3 Severity: wishlist An example. Binary name /usr/bin/xsnap-ocr and manpage in .../man1/xsnap-ocr.1 reads: ! 64 .IX Title xsnap_ocr 1 ! 65 .TH xsnap_ocr 1 2011-09-29 xsnap-ocr User Commands 66 .\ For nroff, turn off justification. Always turn off hyphenation; it makes 67 .\ way too many mistakes in technical documents. 68 .if n .ad l 69 .nh 70 .SH NAME ! 71 xsnap_ocr \- OCR reader helper called by xsnap 72 .SH SYNOPSIS SUGGESTION It would be nice if there were a P: or X: check to verify that basename of manual page's filename (without suffix) matches the marked (!) lines. The above should have read: ! 64 .IX Title xsnap-ocr 1 ! 65 .TH xsnap-ocr 1 2011-09-29 xsnap-ocr User Commands ... ! 71 xsnap-ocr \- OCR reader helper called by xsnap -- System Information: [...] What about manpages re-used for multiple commands? gzip, gunzip and zcat uses the same manpage, how would you expect this to be handled? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643735: lintian: Add check for manual page to verify TH matches FILENAME.N
On 2011-10-12 13:44, jari wrote: [...] If it were classified X: and explanation reads certainty: not sure, I don't think there is not much problem. Jari I am not convinced there is a point in implementing this tag if we do not take common cases into consideration. I do not want X tags to stay experimental forever and I do not consider this proposal (so far) good enough to survive as a pedantic/wild-guess. If we can agree on how we can fairly reliably handle this case without too many false-positives, I will consider it. But otherwise I think our time is better spent on some of the other 170ish bugs. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645558: Improve britney2 auto-hinter
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: britney
Hi,
I have written a patch to improve britney2's auto-hinter. I noticed that
britney2 does not quite cope with complex cases.
The tree-circle-dependencies-huge-graph-no-hint[1] test case demonstrates this
issue. The current britney cannot solve this if the DEPTH and WIDTH (in
hooks/post-setup) are greater than 3. With the patch it solved the the 20x20
variant[2].
The basic algorithm for the auto-hinter in this patch is to transform the graph
of valid candidates into a DAG[3]. Using the DAG it will calculate which
components must migrate together.
The runtime complexity of this algorithm should be in O(|V| + |E|)[4], where
|V| is the number of validate candidates and |E| is the dependencies between
them (vertexes and edges in the graph, respectively).
~Niels
[1]
http://release.debian.org/~nthykier/britney-tests/t/tree-circle-dependencies-huge-graph-no-hint/
[2] In all my tests DEPTH and WIDTH were equal to each other.
[3] Using Strongly Connected Components, see
http://en.wikipedia.org/wiki/Directed_acyclic_graph#Relation_to_other_kinds_of_graphs
[4] I am assuming (on average) constant time hash-look up, append to lists,
linear time iteration over hashes. This should be a valid assumption. :)
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From c4f7c8b28cd0e1aa0bef74bf6dda749894b4cb05 Mon Sep 17 00:00:00 2001
From: Niels Thykier ni...@thykier.net
Date: Sun, 16 Oct 2011 20:02:18 +0200
Subject: [PATCH] Improve auto-hinter to handle harder cases
The auto-hinter will first generate a directed acycle graph (DAG) out
of the valid candidates[1]. Using the DAG the auto-hinter will then
calculate which of the components must migrate together and generate
easy hints for those.
With this patch, britney2[2] can solve the huge-graph test case[3].
[1] Any graph can be condensated into a DAG by calculating the
strongly connected components and looking at the egdes between these
components. See:
http://en.wikipedia.org/wiki/Directed_acyclic_graph#Relation_to_other_kinds_of_graphs
[2] Using --auto-hinter (and --compatiable)
[3] tree-circle-dependencies-huge-graph-no-hint
---
britney.py | 137 +---
1 files changed, 84 insertions(+), 53 deletions(-)
diff --git a/britney.py b/britney.py
index 351651a..822604f 100755
--- a/britney.py
+++ b/britney.py
@@ -2840,60 +2840,91 @@ class Britney:
self.__log( Processing hints from the auto hinter, type=I)
-# consider only excuses which are valid candidates
-excuses = dict([(x.name, x) for x in self.excuses if x.name in self.upgrade_me])
-
-def find_related(e, hint, circular_first=False):
-if e not in excuses:
-return False
-excuse = excuses[e]
-if e in self.sources['testing'] and self.sources['testing'][e][VERSION] == excuse.ver[1]:
-return True
-if not circular_first:
-hint[e] = excuse.ver[1]
-if len(excuse.deps) == 0:
-return hint
-for p in excuse.deps:
-if p in hint: continue
-if not find_related(p, hint):
-return False
-return hint
-
-# loop on them
-candidates = []
-for e in excuses:
-excuse = excuses[e]
-if e in self.sources['testing'] and self.sources['testing'][e][VERSION] == excuse.ver[1]:
- continue
-if len(excuse.deps) 0:
-hint = find_related(e, {}, True)
-if isinstance(hint, dict) and e in hint and hint not in candidates:
-candidates.append(hint.items())
-else:
-items = [ (e, excuse.ver[1]) ]
-for item, ver in items:
-# excuses which depend on item or are depended on by it
-items.extend( [ (x, excuses[x].ver[1]) for x in excuses if \
- (item in excuses[x].deps or x in excuses[item].deps) \
- and (x, excuses[x].ver[1]) not in items ] )
-if len(items) 1:
-candidates.append(items)
-
-to_skip = []
-for i in range(len(candidates)):
-for j in range(i+1, len(candidates)):
-if i in to_skip or j in to_skip:
-# we already know this list isn't interesting
+candidates = dict([(x.name, x) for x in self.excuses if x.name in self.upgrade_me])
+low = {}
+stack = []
+components = []
+commap
Bug#645558: Improve britney2 auto-hinter
On 2011-10-17 01:14, Niels Thykier wrote:
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: britney
Hi,
I have written a patch to improve britney2's auto-hinter. I noticed that
britney2 does not quite cope with complex cases.
The tree-circle-dependencies-huge-graph-no-hint[1] test case demonstrates
this issue. The current britney cannot solve this if the DEPTH and WIDTH
(in hooks/post-setup) are greater than 3. With the patch it solved the the
20x20 variant[2].
In case you would like a visual version of the set up, I have prepared
some dot graphs of the issue[1]. This is entirely binary package
relations (there are no source relations in this case). The source for
these graphs are generated in the test case
($rundir/$test/debug-deps-$suite.dot) as an image of before migration.
The setup is designed so that src-i-{0..WIDTH/2-1} forms a circular
dependency (so that is DEPTH loops of size WIDTH/2) and
src-i-{j/2..WIDTH} depends in a straight line into the circle on the
same row.
On top of this, each src-i-j depends on src-(i-1)-j, which forms a
non-circular graph on the j/2..WIDTH-nodes. As explained above, all of
these ends in the DEPTH circles. In the dot graphs the circles are on
the left and the non-circular part is on the right (not by design btw).
The 20x20 variant takes about 5.5 seconds on franck (with the live
britney). The patched version is not visibly faster (even for a 30x30,
the patched version only reduces the runtime from ~37 to ~36s on my
machine).
Auto-hinting before the main run has have an incredible effect on the
runtime in this test case[2], because the patched version would reduce
the main run to 0 packages. This is somewhat unrealistic in real
data. However considering how cheap auto-hinting is compared to the
main run, this might be worth it.
~Niels
[1]
4x4: http://release.debian.org/~nthykier/unstable-4x4.png
20x20: http://release.debian.org/~nthykier/unstable-20x20.png
Btw, I suspect that for graphs smaller than 4x4, the resulting relations
are generated wrong.
[2] Reducing the runtime of the patched britney to ~2 seconds from 36
seconds on the 30x30 variant. The 20x20 variant is less than a second.
The basic algorithm for the auto-hinter in this patch is to transform the
graph of valid candidates into a DAG[3]. Using the DAG it will calculate
which components must migrate together.
The runtime complexity of this algorithm should be in O(|V| + |E|)[4], where
|V| is the number of validate candidates and |E| is the dependencies between
them (vertexes and edges in the graph, respectively).
~Niels
[1]
http://release.debian.org/~nthykier/britney-tests/t/tree-circle-dependencies-huge-graph-no-hint/
[2] In all my tests DEPTH and WIDTH were equal to each other.
[3] Using Strongly Connected Components, see
http://en.wikipedia.org/wiki/Directed_acyclic_graph#Relation_to_other_kinds_of_graphs
[4] I am assuming (on average) constant time hash-look up, append to lists,
linear time iteration over hashes. This should be a valid assumption. :)
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.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#645781: Include how to compile information in INSTALL
Package: release.debian.org Severity: normal Tags: patch User: release.debian@packages.debian.org Usertags: britney To help the next poor schmuck trying to getting britney to work; a how to compile section in either the README or INSTALL might be useful. ~Niels From 3ebc3fc8e02f80448396543622f2462e1bdebe18 Mon Sep 17 00:00:00 2001 From: Niels Thykier ni...@thykier.net Date: Tue, 18 Oct 2011 17:02:20 +0200 Subject: [PATCH] Clarified how britney is compiled --- INSTALL |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/INSTALL b/INSTALL index 1d28cee..80ab1b0 100644 --- a/INSTALL +++ b/INSTALL @@ -8,3 +8,10 @@ Requirements: * Python APT/DPKG bindingsaptitude install python2.5-apt libapt-pkg-dev dpkg-dev * Python dev headers aptitude install python2.5-dev +Compiling: +-- + +Run make all in the lib directory and add a symlink called +britneymodule.so pointing to the freshly generated britneymodule.so in +the lib directory. + -- 1.7.6.3
Bug#645793: lprfax: Should this package be orphaned?
Package: lprfax Severity: serious Hi, lprfax have 2 RC bugs, which has been open for nearly a year and has not seen any maintainer feedback. If you are still interested in maintaining this package, then look at fixing these bugs. If you have trouble solving the RC bugs, consider tagging them help and/or request assistance on debian-de...@lists.debian.org. Alternatively, file a RFH bug against wnpp requesting a co-maintainer could also prove useful. :) If you no longer use this package or no longer have any interest it, please consider putting it up for adoption or orphaning it. If I do not hear anything from you (or see any progress on the RC bugs) within 14 days, I will assume you have lost interest in this package and put it up for adoption. Thanks in advance, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646385: javahelper: jh_build fails because of missing architecture in JVM path (openjdk on amd64)
On 2011-10-23 20:10, Benjamin Mesing wrote: Package: javahelper Version: 0.37 Severity: important Hi, when I use jh_build this results in : jh_build --no-javadoc umlet.jar sourcefiles/src find sourcefiles/src -name *.java -and -type f -print0 | xargs -0 /usr/lib/jvm/java-6-openjdk/bin/java xargs: /usr/lib/jvm/java-6-openjdk/bin/javac: No such file or directory This is due to the recent multiarch support in OpenJDK http://lists.debian.org/debian-java/2011/08/msg00164.html Best regards Ben [...] Hey, By the looks of it, jh_build uses JAVA_HOME if set. Otherwise it uses /usr/lib/jvm/default-java or /usr/lib/jvm/java-gcj (in order) if either of those are present. I see no mention of java-6-openjdk at all. The only problem I can spot in javahelper is jh_makepkg is still using java-6-openjdk, but as I recall umlet is already in the archive? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641468: lintian: update the lab layout (i.e. use pools)
On 2011-10-05 10:45, Niels Thykier wrote:
On 2011-09-13 18:04, Niels Thykier wrote:
Package: lintian
Severity: important
Jakub realized the source of a lot of our errors on lintian.d.o are
caused by limitations in the file-system. We should probably use
a pool or something similar to reduce the amount of elements in
each dirs.
~Niels
I guess it might be a good time for a little status update here.
Since no one has commented so far I have applied do-cracy and done stuff...
The lab-refactor branch is now working for simple use cases[1].
However, the lintian.d.o-style usage needs some attention.
In the master branch we use $lab/info/* as a list of what was in the
mirror last time we checked. Those files have been repurposed in the
lab-refactor branch, where their new meaning is what is currently in
the lab. This means that dist search[2] is currently broken.
To my knowledge there are *2* known cases where dist searches make
sense - lintian.d.o and lintian.debathena.o. I feel we should move that
functionality to a new frontend (such as the lintian-harness[3]) that
would focus lintian.d.o-like setups.
Note that repurposing is not entirely complete and therefore
reporting/harness is more or less broken right now. One of the issues
is that unpack/* still use the files in info/* as a dist list and not a
lab list.
dist search is now removed from lintian - the reporting stuff left
untouched and is therefore still broken. Yay for progress! :)
When I was looking at this, I realised two things. First a lot of
variables (and cmd-options) now appear to be redundant in
frontend/lintian. Namely all of LINTIAN_{ARCHIVEDIR,AREA,DIST} and
possibly also LINTIAN_ARCH. It has not been double checked, but I
strongly suspect them of being unused now.
Secondly, the current search rules were not sufficient. Basically, it
was only possible to match all packages with a given name. I have
solved this by creating a simple way of referring to packages in the Lab.
Originially I planned to accept both the current britney-style
format[1] and the filename-style[2]. However it occurred to me that
the filename-style is (for obvious reasons) impossible to reliably
distinguish from a normal file. As this could lead to confusion for the
users (i.e. principe of least surprise), I decided to not include the
filename-style. The britney-style format is described in
man/lintian.pod.in.
[1] [type:]package[/version[/arch]]
[2] package_version[_arch].ext
I also considered adding a file in info/ to keep track of lab-wide
(meta)data, such as the lab-format. In the old lab format, this is
stored in every entry. This makes is slightly more difficult to check
if we are dealing with a compatible lab.
Consider if you use an old lintian to use the new lab style - they
do not store the entries the same place, so it has no reliable way to
detect it is not compatible. I would prefer that an old lintian would
always be able to say The lab uses a newer lab-format that this version
of lintian supports - even if this case will probably never happen.
I have added a lab-wide data file stored as $LAB/info/lab-info. It
uses the deb822-style syntax and has two fields in the first paragraph:
Lab-Format: $format
Layout: pool
The Lab-Format field describes the current format of the lab[3]. The
Layout field describes how the packages are placed in the lab.
Currently only one layout exists (namely pool), which reflects the
layout in the current branch.
The Layout field allows us to implement and play with a new layout
side-by-side with the current one. Hopefully we will never need this
feature, but probably we will.
[3] Will be 11 when the development is done. Currently it is 10.1.
I am also wondering what we need in the per-entry lintian-status file.
In the master branch, we store Lintian-Version, Lab-Format, Package
(name), Version (package), Type (package) and Timestamp.
When we read the status file, we compare lab-format, package version
and timestamp. With the changes in lab-refactor branch, the lab always
supports multiple versions of the same package, thus the package version
comparision is a no-op.
As I understand it, the timestamp is there to make lintian re-unpack
the package if it changed since the last run. Currently it completely
removes the entry if the timestamp does not match. Though this code
only makes sense for personal static labs - on the lintian.d.o case,
the version of a package can not be reused (at least not in general).
The timestamp-part is not in the lab-refactor branch (yet?).
I am considering to replace the Lab-format value with an
entry-format-version. Not sure it makes sense, but I thinking it may
make migration to newer formats easier.
If I had not (ab)used the oppertunity to do optimizations in the
.lintian-status file (see below), the migration from the current to the
lab-format would basically just have been
Bug#645455: Warn about packages in section debug with priority other than extra
On 2011-10-16 15:30, Josh Triplett wrote: On Sun, Oct 16, 2011 at 01:22:28PM +0200, Jakub Wilk wrote: * Josh Triplett j...@joshtriplett.org, 2011-10-15, 18:03: The debug section contains debugging symbols, which should always have priority extra. Policy specifically mentions them in the description of priority extra. Please consider warning about any packages in section debug with any priority higher than extra. We do check all packages named *-dbg for that (debug-package-should-be-priority-extra). Ah, good to know. And it looks like lintian also already checks that any package containing debug symbols follows that naming convention, which together check that any package containing debug symbols has priority extra. :) Right, that's debug-package-should-be-named-dbg. Neither of those ensure that such packages have section debug, though. There is wrong-section-according-to-package-name, which should trigger for all *-dbg packages that are not in section debug. Oh, awesome, thanks. - Josh Triplett Hey, By the looks of this, there is nothing to be done. If so, I will close this bug. :) ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646861: java-wrappers: Installs shell scripts in /usr/lib, but is an architecture all package
Package: java-wrappers Severity: normal Hi, Obviously if they are moved, they need a symlink in the old location to avoid breaking existing packages. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646985: lintian: vcs-* fields containing new-lines
Package: lintian Severity: normal From lintian.d.o: libfax-hylafax-client-perl (1.02-1): [...] vcs-field-uses-unknown-uri-format vcs-browser \n http://svn.debian.org/wsvn/pkg-perl/trunk/libfax-hylafax-client-perl/ The check should probably ignore newlines. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646985: lintian: vcs-* fields containing new-lines
On 2011-10-29 02:56, Russ Allbery wrote: Niels Thykier ni...@thykier.net writes: From lintian.d.o: libfax-hylafax-client-perl (1.02-1): [...] vcs-field-uses-unknown-uri-format vcs-browser \n http://svn.debian.org/wsvn/pkg-perl/trunk/libfax-hylafax-client-perl/ The check should probably ignore newlines. I think there's another open bug about this somewhere. The question is whether it's safe to have newlines in those fields and if all the parsers handle it. This isn't something that one can necessarily assume; simple fields may not be folded, and there are quite a few simple fields in the debian/control syntax that will break some parsers if folded. True, but then we should emit a multiline-field tag instead of the \n $url error, which just looks like lintian is broken. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647014: gcc-defaults: Please provide a gcj-jdk-source package
Package: gcc-defaults Severity: wishlist Please provide a meta-package for the gcj-jdk-source. This will allow java-common to provide a default-jdk-source package that is not out of sync with gcc-defaults. See #641880 for more information. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629385: Request for TC to rule on a course of action for, supporting build-arch
Hi,
I have a 6th (?) proposal.
Lintian recently got checks for finding packages without build-arch and
build-indep targets. Currently it finds some 5600 packages and with the
current rate it will take nearly 2 years to fix all of them.
As pointed out earlier, only packages building both arch:all and
non-arch:all packages benefit from this. With this in mind, we can
trivially create a new lintian tag that finds source packages building
arch:all + non-arch:all packages without build-{arch,indep} targets.
My proposal is, implement the above mentioned lintian tag and make a
release goal focusing on fixing all packages emitting this tag.
Basically this is a weaker version of (4) and we can start on it now
without hardly any consequences.
Should a better solution be chosen before we are done with fixing
these packages, we can trivially cancel the release goal and remove the
lintian tag. Particularly, we are not left with a lot of RC buggy
packages nor will we have a new field that suddenly became redundant etc.
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647227: lintian: create separate tag for packages that could benefit from build-arch/build-indep
Package: lintian
Severity: wishlist
Tags: patch
Hi,
As I suggested in #629385, lintian could be used to detect packages
that could benefit from having the recommended build-arch and
build-indep packages.
The technical details are in the attached patch; though the tag
info (and possibly the name) could use some attention.
Also I am not sure it makes sense to make this an important/possible
tag. For the purpose of finding the relevant packages to update/NMU
any severity would do.
~Niels
diff --git a/checks/rules b/checks/rules
index 0c88104..decdae0 100644
--- a/checks/rules
+++ b/checks/rules
@@ -110,6 +110,8 @@ sub run {
my $pkg = shift;
my $type = shift;
my $info = shift;
+my $proc = shift;
+my $group = shift;
my $rules = $info-debfiles('rules');
@@ -359,14 +361,28 @@ while (RULES) {
close RULES;
unless ($includes) {
+my $rec = 0;
# Make sure all the required rules were seen.
for my $target (sort keys %required) {
tag 'debian-rules-missing-required-target', $target
unless $seen{$target};
}
for my $target (sort keys %recommended) {
-tag 'debian-rules-missing-recommended-target', $target
-unless $seen{$target};
+unless ($seen{$target}) {
+tag 'debian-rules-missing-recommended-target', $target;
+$rec++;
+}
+}
+
+if ($rec) {
+my $all = 0;
+my $notall = 0;
+foreach my $p ($group-get_processables) {
+next if $p-pkg_type eq 'source' or $p-pkg_type eq 'changes';
+$all++ if $p-pkg_arch eq 'all';
+$notall++ if $p-pkg_arch ne 'all';
+}
+tag 'package-would-benefit-from-build-arch-targets' if $all $notall;
}
}
diff --git a/checks/rules.desc b/checks/rules.desc
index 99f73de..291cb62 100644
--- a/checks/rules.desc
+++ b/checks/rules.desc
@@ -212,3 +212,9 @@ Info: The rules files appear to be reading or modifying a variable not
can be used by users, who wants to re-compile debian packages with
special (or non-standard) build flags.
+Tag: package-would-benefit-from-build-arch-targets
+Severity: important
+Certainty: possible
+Ref: #629385, https://wiki.debian.org/ReleaseGoals/BuildArchTarget
+Info: Please add a build-arch and build-indep target.
+
Bug#580048: lintian: FEATURE REQUEST - Check version against, debian/source/format type (quilt, native)
Hi, non-native-package-with-native-version already explains the issue with formats. native-package-with-dash-version does not explain that the source format triggers it, but I strongly suspect that the people working on native packages knows the versioning rules very well. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653195: transition: libarchive
On Dec 25, 2011 19:42 Andres Mejia mcita...@gmail.com wrote: I have finished checking what changes were required for gmameui, tuxcmd-modules, and deb-gview in order to build with both the current version of libarchive (2.8.5) and the latest version (3.0.2). Fortunately, all changes required are trivial. I filed bug reports and patches in the following locations. gmameui: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653231 tuxcmd-modules: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653233 deb-gview: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653237 As said before, all other packages simply need to be binNMUed. The package 'hydrogen' requires a sourceful upload for a seperate issue. With all this said, I am requesting a transition slot for the transition from libarchive 2.8.5 to libarchive 3.0.2. Hi, Thanks for rebuild testing the packages. I have setup a tracker for the libarchive transition at [1], please confirm it matches your expectations. In regards to timing, we will have to wait until the evolution3.2 transition is over[2]. We will get back to you when it is done. ~Niels [1] http://release.debian.org/transitions/html/libarchive.html [2] http://release.debian.org/transitions/html/evolution3.2.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648775: Re: Bug#648775: transition: mono 2.10
On Dec 22, 2011 23:27 Iain Lane la...@debian.org wrote: Hi there, On Tue, Dec 20, 2011 at 10:58:50PM +0100, Niels Thykier wrote: […] If you haven't already done so, please head to [1] (or [2]) to verify the list of affected source packages. I think that's right. Good, :) […] * Upload all of mono cli-common from experimental to unstable * Upload build tools (nant) * Remove mono-debugger * Get LO bindings disabled * No-change rebuild / binNMU all applications against the 4.0 profile * No-change rebuild / binNMU all libraries against the 4.0 profile, in leaf-first order Do you have a list/table of the ~30 binNMUable packages that tells us which of them are libs and which are not? Alternatively can we just go by dependency level from the transition tracker package (starting with the bottom/level 10)? No, but here is one: libraries - libindicate libgwibber gstreamer-sharp gdata-sharp gnome-desktop-sharp2 libgpod (U) gnome-sharp2 gnome-keyring-sharp gmime2.4 activiz.net (U) zeroc-ice libkarma (U) gtk-sharp2 mummy (U) plugins --- banshee-community-extensions applications fsgateway ikvm antlr tangerine gnome-do banshee tomboy mistelix longomatch gnome-subtitles f-spot bareftp gdcm There were some unclear cases, but you should be able to rebuild all applications once mono and nant are uploaded, the plugins after their applications are rebuilt and then finally the libraries, in leaf-first order (with the exception below). The main thing to remember is that once stuff has been rebuilt it will be 4.0, and 2.0 code cannot load 4.0. As an additional complication, some libraries are packaged 'unstable', (marked as (U) above) meaning that they are copied by their consumers at build time. These libraries should be rebuilt /before/ their library rdeps, otherwise you'll get 2.0 copies inside 4.0 libraries and have to do a second rebuild. This will be unavoidable in some cases where applications depend on unstable libraries. We can let you know when binNMUs should be issued if you like, as we'll be doing the no-change source uploads at the same time. I will take you up on that offer. :) Also I just noticed that mummy FTBFS with 2.10, and filed this as #652976. This is a new package since we prepared the transition. If not fixed by the maintainer, I'll look at NMUing. […] Cheers, We will need a couple of days more to sort out the vtk8.5 transition and then I will get back to you. :) ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649912: eclipse: FTBFS on various archs
severity 649912 important
retitle 649912 eclipse: FTBFS on arm
clone 649912 -1 -2
reassign -1 ftp.debian.org
retitle -1 RM: eclipse [armel] -- RoM; unsupported on arm
severity -1 normal
reassign -2 openjdk-6
retitle -2 Unimplemented opcode: 254 = unknown in eclipse/armel build
severity -2 normal
block 649912 by -2
thanks
Hi,
eclipse 3.7.1 fixes all FTBFS except on armel (and presumably also
armhf).
According to [1] eclipse cannot be build on arm at the moment due to
lack of memory support for processes. Such support requires linux 3.3
(or some cherry-picks[2] by the kernel maintainers) and after that, it
needs to be deployed on the buildds.
Furthermore, the latest build on armel fails with an Unimplemented
opcode: 254 = unknown[3].
In light of the above, I have decided to temporary request the removal
of eclipse/armel until it is buildable again. I will keep #649912
open to track the eclipse/arm{el,hf} status.
~Niels
[1] http://lists.debian.org/debian-java/2011/12/msg00083.html
[2] http://lists.debian.org/debian-java/2011/12/msg00090.html
[3]
https://buildd.debian.org/status/fetch.php?pkg=eclipsearch=armelver=3.7.1-1stamp=1325368264
[java] checkCompilationResults:
[java] [copy] Copying 1 file to
/build/buildd-eclipse_3.7.1-1-armel-cskBRe/eclipse-3.7.1/build/eclipse-3.7.1-src/plugins/org.eclipse.core.variables/@dot
[java] #
[java] # A fatal error has been detected by the Java Runtime Environment:
[java] #
[java] # Internal Error (cppInterpreter_arm.S:2707), pid=21912,
tid=1765799024
[java] # fatal error: *** Unimplemented opcode: 254 = unknown
[java]
[java] #
[java] # JRE version: 6.0_24-b24
[java] # Java VM: OpenJDK Zero VM (20.0-b12 mixed mode linux-arm )
[java] # Derivative: IcedTea6 1.11pre
[java] # Distribution: Debian GNU/Linux unstable (sid), package 6b24~pre2-1
[java] # An error report file with more information is saved as:
[java] #
/build/buildd-eclipse_3.7.1-1-armel-cskBRe/eclipse-3.7.1/hs_err_pid21912.log
[java] #
[java] # If you would like to submit a bug report, please include
[java] # instructions how to reproduce the bug and visit:
[java] # http://icedtea.classpath.org/bugzilla
[java] #
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688584: unblock: smuxi/0.8.10-3 (pre-approval)
On 2012-09-23 22:47, Mirco Bauer wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock This upload fixes #687014 which adds a missing build-dep that is responsible for enabling spellchecking as provided by the libgtkspell library. smuxi 0.8.10-2 to 0.8.10-3 reverted the Standards-Version bump and contains no further changes. Here is the debdiff against the package in testing. I did not upload the changes to unstable yet. diff -Nru smuxi-0.8.10/debian/changelog smuxi-0.8.10/debian/changelog --- smuxi-0.8.10/debian/changelog2012-06-30 17:01:03.0 +0200 +++ smuxi-0.8.10/debian/changelog2012-09-23 22:14:46.0 +0200 @@ -1,3 +1,17 @@ +smuxi (0.8.10-3) unstable; urgency=low + + * [d1b3dd5] Revert Bumped Standards-Version to 3.9.3 (no changes needed) I wouldn't bother with the revert - the change is just as long as the changelog entry for itself... [...] unblock smuxi/0.8.10-3 Feel free to ahead, please ping us again when it has been in sid for a couple of days. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636158: maradns: Debian default config is not robust to user change + upgrade
On 2012-10-25 23:21, Nicholas Bamber wrote: Dear Debian Release Team, Please could I have a stay of execution on maradns? I am somewhat overwhelmed with stuff at the moment but I am steadily working my way through it (including the Debian stuff). And the maradns RC bug came fairly late in the whole release cycle. I would also accept an NMU if one turns up. [...] Certainly. I have taken maradns off the list for now. Would an extra week enough? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691489: lintian: section: tasks seem to imply empty-binary-package
Package: lintian Version: 2.5.10.2 Severity: minor Packages in the tasks section should probably be considered ok even if they are empty[0]. ~Niels [0] http://lintian.debian.org/maintainer/debian-b...@lists.debian.org.html#tasksel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691395: unblock: opendkim/2.6.8-2
Control: tags -1 confirmed JFTR, Scott and I had a look at this today (at UDS). I asked him to upload it to unstable and ping us once it has been in sid for a couple of days. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691872: tpu: package fgfs-base/2.4.0-1+deb7u1
On 2012-10-30 16:07, David Prévot wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: tpu Control: tags 689785 patch Dear release team, Hi, In order to fix an RC-bug (#689785) in fgfs-base, would you consider the following trivial upload (patch attached) via tpu (a new upstream version is already in Sid). Yes, but please fix the sid version before doing the tpu. Thanks in advance, regards. David [...] ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677874: lintian: checks/manpages is unreasonably slow on some packages
On 2012-06-17 14:15, Niels Thykier wrote: Package: lintian Version: 2.5.9 Severity: normal Hi, I noticed [1] and decided to check what made Lintian a lengthy invariant. Processing the changes (and related files) took about a minute (accoriding to the shell built-in time). Running: $ time lintian -d -C manpages allegro4-doc_4.4.2-2_all.deb takes about 40 seconds. [...] I had a talk with Colin today at UDS and we came to the conclusion that there is nothing further to be done on the Lintian side (in 2.5.11). Colin is already working on some improvements on the man-db/libpipeline side. I will mark this as (being) fixed in 2.5.11. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692016: xfce4-session: Possibly memory leak in xfsm-legacy.c
Package: xfce4-session Version: 4.10.0-1 Severity: minor Tags: upstream Hi, I checked xfce4-session with cppcheck and it noticed a possible leak in xfce4-session/xfsm-legacy.c in the 4.10.0 (experimental) version. The leak appears to be happening in an inner loop[0], but given the name of the file (legacy) it is possibly a minor problem. ~Niels [0] So a leak based on the number of windows (screens * number of windows in that screen). --- xfce4-session/xfsm-legacy.c.orig 2012-11-01 11:23:53.228575912 +0100 +++ xfce4-session/xfsm-legacy.c 2012-11-01 11:28:37.624583205 +0100 @@ -306,8 +306,8 @@ SmWindow *sm_window; int n, i; int type; - gchar *wmclass1; - gchar *wmclass2; + gchar *wmclass1 = NULL; + gchar *wmclass2 = NULL; Window root, window; XEvent ev; int awaiting_replies = 0; @@ -374,6 +374,8 @@ sm_window = sm_window_new (leader, n, type, wmclass1, wmclass2); window_list = g_list_append (window_list, sm_window); + g_free(wmclass2); + g_free(wmclass1); } }
Bug#692018: xfdesktop4: Possible memory leak in settings/main.c
Package: xfdesktop4
Version: 4.8.3-2
Severity: normal
Tags: upstream
Hi,
cppcheck brought the following code snippet in settings/main.c to my
attention. Unlike #692016, this appears to be a real leak:
PreviewData *pdata = g_new0(PreviewData, 1);
pdata-model = g_object_ref(G_OBJECT(model));
if(TARGET_TEXT_URI_LIST != info
|| selection_data-format != 8
|| selection_data-length = 0)
{
gtk_drag_finish(context, FALSE, FALSE, time_);
return;
}
[...]
It seems to both cppcheck and me that pdata is leaked if the condition
for this if-statement is true. Also, model may be leaked due to the
g_object_ref call.
I cannot find any ownership passing (or any use) of pdata or model in
the body of the if-statement. I attached an untested proposed
solution, which is to defer memory allocation and ref'ing till after
the if (i.e. at the [...] part).
The code snippet appears in 4.10.0, so if you agree with my assertion,
4.10.0 is also affected.
~Niels
--- settings/main.c.orig 2012-11-01 11:54:34.540623096 +0100
+++ settings/main.c 2012-11-01 11:56:46.288626451 +0100
@@ -1087,9 +1087,7 @@
gboolean file_added;
gchar *p;
GtkTreeModel *model = gtk_tree_view_get_model(GTK_TREE_VIEW(widget));
-PreviewData *pdata = g_new0(PreviewData, 1);
-
-pdata-model = g_object_ref(G_OBJECT(model));
+PreviewData *pdata;
if(TARGET_TEXT_URI_LIST != info
|| selection_data-format != 8
@@ -1099,6 +1097,9 @@
return;
}
+pdata = g_new0(PreviewData, 1);
+pdata-model = g_object_ref(G_OBJECT(model));
+
p = (gchar *)selection_data-data;
while(*p) {
if(*p != '#') {
Bug#686526: unblock: lightdm/1.2.2-4
On 2012-11-01 12:56, Vlad Orlov wrote: Something's wrong... the PTS page doesn't show any unblock requests for this package. Is it possible to repeat it somehow? Hi, The PTS does not show unblock requests (only actual unblocks), because its data source (Britney) does not know about requests (only actual unblocks). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692030: xorg-server: Possible memory/resource leaks
Package: xorg-server
Version: 2:1.12.4-1
Severity: minor
Tags: upstream
Hi,
I noticed (thanks to cppcheck) a number of possible leaks in xorg-server.
I have tried to manually verify each of them and produce a possible
plug for them. I haven't actually used the changes here and would
appreciate someone with more knowledge of Xorg-server's internals
having a look at them (hench the lack of a patch tag).
cppcheck do find a few more leaks than the ones I have listed, but
some were false-positives and a few of them I wasn't sure how to deal
with.
~Niels
--- xorg-server-1.12.4.orig/glx/glxdri.c
+++ xorg-server-1.12.4/glx/glxdri.c
@@ -635,8 +635,10 @@
for (i = 0; i pScreen-numVisuals; i++, visual++)
if (visual-vid == glxConfig-visualID)
break;
-if (i == pScreen-numVisuals)
+if (i == pScreen-numVisuals) {
+free(context);
return NULL;
+}
context-hwContextID = FakeClientID(0);
only in patch2:
unchanged:
--- xorg-server-1.12.4.orig/glx/glxdri2.c
+++ xorg-server-1.12.4/glx/glxdri2.c
@@ -701,6 +701,7 @@
screen-fd, driverName, deviceName)) {
LogMessage(X_INFO,
AIGLX: Screen %d is not DRI2 capable\n, pScreen-myNum);
+free(screen);
return NULL;
}
only in patch2:
unchanged:
--- xorg-server-1.12.4.orig/hw/dmx/dmxfont.c
+++ xorg-server-1.12.4/hw/dmx/dmxfont.c
@@ -405,6 +405,7 @@
free(goodfps);
return FALSE;
}
+free(goodfps);
}
/* Find requested font on back-end server */
only in patch2:
unchanged:
--- xorg-server-1.12.4.orig/hw/dmx/config/dmxcompat.c
+++ xorg-server-1.12.4/hw/dmx/config/dmxcompat.c
@@ -228,5 +228,7 @@
break;
}
}
+if (filename)
+ fclose(str);
return entry;
}
only in patch2:
unchanged:
--- xorg-server-1.12.4.orig/hw/dmx/glxProxy/glxcmds.c
+++ xorg-server-1.12.4/hw/dmx/glxProxy/glxcmds.c
@@ -1978,6 +1978,7 @@
}
else {
client-errorValue = (visual ? visual : fbconfigId);
+free(pGlxPixmap-be_xids);
free(pGlxPixmap);
return BadValue;
}
@@ -1986,6 +1987,7 @@
}
if (!(AddResource(glxpixmapId, __glXPixmapRes, pGlxPixmap))) {
+free(pGlxPixmap-be_xids);
free(pGlxPixmap);
return BadAlloc;
}
only in patch2:
unchanged:
--- xorg-server-1.12.4.orig/hw/xfree86/common/xf86sbusBus.c
+++ xorg-server-1.12.4/hw/xfree86/common/xf86sbusBus.c
@@ -641,11 +641,12 @@
int i, index;
sbusCmapPtr cmap;
struct fbcmap fbcmap;
-unsigned char *data = malloc(numColors * 3);
+unsigned char *data;
cmap = SBUSCMAPPTR(pScrn-pScreen);
if (!cmap)
return;
+data = malloc(numColors * 3);
fbcmap.count = 0;
fbcmap.index = indices[0];
fbcmap.red = data;
only in patch2:
unchanged:
--- xorg-server-1.12.4.orig/hw/xfree86/os-support/bus/Sbus.c
+++ xorg-server-1.12.4/hw/xfree86/os-support/bus/Sbus.c
@@ -617,8 +617,10 @@
return 0;
strcpy(name, pathName);
name[i + 1] = 0;
-if (name[0] != '/')
+if (name[0] != '/') {
+free(name);
return 0;
+}
p = strchr(name + 1, '/');
if (p)
*p = 0;
@@ -629,8 +631,10 @@
*regstr++ = 0;
else
regstr = p;
-if (name + 1 == regstr)
+if (name + 1 == regstr) {
+free(name);
return 0;
+}
promGetSibling(0);
i = promWalkPathname2Node(name + 1, regstr, promRootNode, 0);
free(name);
Bug#691860: Bad fix for #691860
Control: reopen -1 Hi, The fix for #691860 intended to move afio to the end of a long alternatives. But instead it made afio an alternative to a strict (and unrelated) dependency on buffer. The situation before the NMU 1.2.1-6.1: afio | [...] | lzma (= 4.43-2) | rsync, buffer ^ The situation now: ... | lzma (= 4.43-2) | rsync, buffer | afio ^ The intended result ... | lzma (= 4.43-2) | rsync | afio, buffer ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689453: Pre-approval request, Gnuplot 4.6.1 for Wheezy
On 2012-10-02 22:03, Anton Gladky wrote: Thanks, Torquil, for the information. Hi, Sorry for the delay in getting back to you. Dear release-team, would you agree to unblock Gnuplot 4.6.1 for the Wheezy, if it will be packaged? [...] We generally do not make decisions based on the changelogs alone. Please send us a debdiff including the upstream changes[1] and we will have a look. If the diff is relatively large, please double check it actually reaches the list when you send it. We have had a number of cases, where the mail never reached us because lists.d.o /silently/ dropped the mail. However, keep in mind that if the diff is this huge, we usually cannot review it and will default to a no. In this case, we may still consider accepting a subset of the changes (cherry-picked fixes) for various bugs. ~Niels [1] Feel free to filter out .po files and auto-generated files like autoconf's configure via filterdiff if such appear in the diff. Though please mention if you do apply such a filter. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691257: Freeze exception request for js_of_ocaml 1.2-2
On 2012-10-26 10:35, Stéphane Glondu wrote: Dear Release Team, Bug #691257 made me realize that the upstream tarball of the Debian package is not the same as the one currently available on the upstream website, and the contents does not match tag 1.2 in the upstream repository either. There is one commit missing. It changes only changelog and version, and I would like to update the Debian package with it. Attached is a debdiff. Cheers, Hi, It does not seem important, but given it is a doc-only change I am willing to accept it if you are still willing to upload it. If you do upload it, please file an unblock bug after it has been in unstable for a couple of days. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692188: RM: ruby-pgplot/0.1.3-2
On 2012-11-03 07:09, Michael Gilbert wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: rm Severity: normal Please remove ruby-pgplot. It has all kind of unfixed build issues and multiple failed attempts at uploads to get the package in a working state after rc fix for #675390: https://buildd.debian.org/status/package.php?p=ruby-pgplot It is a leaf package in contrib and has not yet been in a stable release. Best wishes, Mike Hi, Could you please file an RC bug against ruby-pgplot about the build failure first? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692212: unblock (pre-approval): pike7.8/7.8.700-2
On 2012-11-03 16:05, Magnus Holmgren wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Hi, I request permission to upload pike7.8 7.8.700-2 to unstable, targeted at wheezy. It would be practically the same as 7.8.700-1, currently sitting in experimental. [...] Thanks for your consideration. I think we'd need to see a debdiff to determine if this is acceptable. Feel free to filter (e.g. w. filterdiff) autogenerated parts and translations (if those appear in the diff). Also if the diff is large, please check it actually reaches debian-release@l.d.o. We have had some cases where the mail got /silently/ dropped; though in these cases the diff tends to be too large for us to review anyway and we tend to default to no for those. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691158: unblock: gmpc/11.8.16-5
On 2012-11-04 15:14, David Prévot wrote: Hi, On Mon, Oct 22, 2012 at 12:44:56PM +0200, Etienne Millon wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package gmpc Hello, I just uploaded gmpc/11.8.16-5 to unstable. It contains only internationalization fixes for wheezy. Here is the last changelog entry : gmpc (11.8.16-5) unstable; urgency=low . * Update translations : - [ca] add Catalan translation - [ru] fix translation for volume (Closes: #687999) - [fr], [oc] import from Launchpad Here is the diffstat with the version in wheezy (full debdiff attached) : The debdiff was so big that it didn't made it to the list. Since it contains only translation stuff beside the above changelog, let make this mail go to the list. Thanks in advance, regards. David [...] Unblocked, thanks. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692341: unblock: libsysactivity/0.6.4-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libsysactivity
Upstream fixed a bug on Linux, where libsysactivty would not report
new network activity. As I understand it, it will simply keep
returning the initial network stats without this patch.
The bug has not been filed in Debian, but it got filed in Ubuntu (LP:
#1072398[0]) and against upstream [1] - in both cases against
sentinella instead of libsysactivity (which is the primary consumer
of the library).
I have decided to package the entire new upstream release as this bug
fix (+4 lines) is the only change.
unblock libsysactivity/0.6.4-1
[0] https://bugs.launchpad.net/bugs/1072398
[1]
https://sourceforge.net/tracker/?func=detailaid=3578869group_id=28atid=1179456
*** d libsysactivity
Base version: libsysactivity_0.6.3-1 from testing
Target version: libsysactivity_0.6.4-1 from unstable
No hints in place.
CHANGELOG |3 +++
CMakeLists.txt |2 +-
Doxyfile|2 +-
cmake/libsysactivityConfigVersion.cmake |4 ++--
debian/changelog|8
src/Linux/network.c |4
src/common/global.h |2 +-
7 files changed, 20 insertions(+), 5 deletions(-)
diff -Nru libsysactivity-0.6.3/CHANGELOG libsysactivity-0.6.4/CHANGELOG
--- libsysactivity-0.6.3/CHANGELOG 2012-05-21 17:27:55.0 +
+++ libsysactivity-0.6.4/CHANGELOG 2012-10-22 16:16:21.0 +
@@ -1,4 +1,7 @@
+libsysactivity 0.6.4 (released 2012-10-22)
+* Linux version of sa_reset_net_interfaces() was not realoading data.
+
libsysactivity 0.6.3 (released 2012-05-21)
* Minor fixes in linux/network and test code.
diff -Nru libsysactivity-0.6.3/cmake/libsysactivityConfigVersion.cmake
libsysactivity-0.6.4/cmake/libsysactivityConfigVersion.cmake
--- libsysactivity-0.6.3/cmake/libsysactivityConfigVersion.cmake
2012-05-21 17:27:55.0 +
+++ libsysactivity-0.6.4/cmake/libsysactivityConfigVersion.cmake
2012-10-22 16:16:21.0 +
@@ -9,9 +9,9 @@
if (${PACKAGE_FIND_VERSION_MAJOR} EQUAL 0) # == 0.y.z
if (${PACKAGE_FIND_VERSION_MINOR} GREATER 5) # 0.5.z
set(PACKAGE_VERSION_COMPATIBLE true)
- if (${PACKAGE_FIND_VERSION_MINOR} EQUAL 6 AND
${PACKAGE_FIND_VERSION_PATCH} EQUAL 3) # == 0.6.3
+ if (${PACKAGE_FIND_VERSION_MINOR} EQUAL 6 AND
${PACKAGE_FIND_VERSION_PATCH} EQUAL 4) # == 0.6.4
set(PACKAGE_VERSION_EXACT true)
- endif (${PACKAGE_FIND_VERSION_MINOR} EQUAL 6 AND
${PACKAGE_FIND_VERSION_PATCH} EQUAL 3)
+ endif (${PACKAGE_FIND_VERSION_MINOR} EQUAL 6 AND
${PACKAGE_FIND_VERSION_PATCH} EQUAL 4)
endif (${PACKAGE_FIND_VERSION_MINOR} GREATER 5)
endif (${PACKAGE_FIND_VERSION_MAJOR} EQUAL 0)
diff -Nru libsysactivity-0.6.3/CMakeLists.txt
libsysactivity-0.6.4/CMakeLists.txt
--- libsysactivity-0.6.3/CMakeLists.txt 2012-05-21 17:27:55.0 +
+++ libsysactivity-0.6.4/CMakeLists.txt 2012-10-22 16:16:21.0 +
@@ -2,7 +2,7 @@
cmake_minimum_required(VERSION 2.6.0)
project(libsysactivity C)
-set(LIBSA_VERSION 0.6.3)
+set(LIBSA_VERSION 0.6.4)
set(CMAKE_VERBOSE_MAKEFILE TRUE)
enable_testing()
diff -Nru libsysactivity-0.6.3/debian/changelog
libsysactivity-0.6.4/debian/changelog
--- libsysactivity-0.6.3/debian/changelog 2012-06-04 15:12:12.0
+
+++ libsysactivity-0.6.4/debian/changelog 2012-11-02 10:35:02.0
+
@@ -1,3 +1,11 @@
+libsysactivity (0.6.4-1) unstable; urgency=low
+
+ * New upstream release.
+- Made Linux version of sa_reset_net_interfaces reload data.
+ (LP: #1072398)
+
+ -- Niels Thykier ni...@thykier.net Fri, 02 Nov 2012 11:35:00 +0100
+
libsysactivity (0.6.3-1) unstable; urgency=low
* New upstream release.
diff -Nru libsysactivity-0.6.3/Doxyfile libsysactivity-0.6.4/Doxyfile
--- libsysactivity-0.6.3/Doxyfile 2012-05-21 17:27:55.0 +
+++ libsysactivity-0.6.4/Doxyfile 2012-10-22 16:16:21.0 +
@@ -31,7 +31,7 @@
# This could be handy for archiving the generated documentation or
# if some version control system is used.
-PROJECT_NUMBER = 0.6.3
+PROJECT_NUMBER = 0.6.4
# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
diff -Nru libsysactivity-0.6.3/src/common/global.h
libsysactivity-0.6.4/src/common/global.h
--- libsysactivity-0.6.3/src/common/global.h2012-05-21 17:27:55.0
+
+++ libsysactivity-0.6.4/src/common/global.h2012-10-22 16:16:21.0
+
@@ -27,7 +27,7 @@
#define SA_VERSION_MAJOR 0
#define SA_VERSION_SMALL 6
-#define SA_VERSION_MINOR 3
+#define SA_VERSION_MINOR 4
#if __GNUC__ = 4
#define SA_EXPORT
Bug#692377: unblock: ganglia-modules-linux
On 2012-11-05 15:12, Daniel Pocock wrote: Package: release.debian.org Severity: normal wheezy currently has 1.3.4-5 I've just built 1.3.4-6. I believe the changes (from changelog, debdiff attached) qualify for unblock as they are documentation changes: * Add VCS locations to control file. * Update copyright file to DEP-5 format, clarify BSD terms * Upstream move to github (update home page and watch file) Please confirm when I can upload to unstable The change can be reviewed in git too: Vcs-Git: git://git.debian.org/collab-maint/ganglia-modules-linux.git Vcs-Browser: http://git.debian.org/?p=collab-maint/ganglia-modules-linux.git;a=summary Hi, Those changes are fine and will not cause a problem. Feel free to upload it to sid. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676141: [request-tracker-maintainers] Bug#676141: rt4-extension-assettracker:, fails to upgrade from wheezy: updating database schema for 1.2.4...command, failed with code 2
Hi, Currently rt4-extension-assettracker is considered an RC-buggy leaf package[0] and will eventually be removed from testing unless this RC bug is dealt with (fixed, downgraded etc.). Mind you, the deadline listed in [0] is in the past. If I hadn't by chance noticed Bradley's mail claiming it is unreproducible, rt4-extension-assettracker would have been removed like 21 other packages. If this bug is unreproducible, please consider tagging it as such and consider downgrading it. Alternatively close it if it has been fixed now. ~Niels [0] https://lists.debian.org/debian-devel/2012/10/msg00373.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688259: zangband: modifies shipped files during postinst
Hi, Currently zangband is considered an RC-buggy leaf package[0] and will eventually be removed from testing unless this RC bug is dealt with (fixed, downgraded etc.). Mind you, the deadline listed in [0] is in the past. If I hadn't by chance noticed Drew's mail claiming he would upload a patch, zangband would have been removed like 21 other packages. Drew, if you still intend to upload a fix for this bug, please do it sooner rather than later. Otherwise, consider asking someone to NMU/fix this package for you. ~Niels [0] https://lists.debian.org/debian-devel/2012/10/msg00373.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692616: lintian: Check for the non-free JSON license in source packages
Package: lintian Severity: wishlist The non-free JSON license keeps re-appearing in main[0]. It would be helpful if Lintian could check for its appearance in the source package. The license appears to be very trivial to identify thanks to the non-free line: The Software shall be used for Good, not Evil. It is not enough to simply check the copyright file as it is usually not explicitly present there (which is a separate RC bug in these packages). ~Niels [0] http://codesearch.debian.net/search?q=The+Software+shall+be+used+for+Good%2C+not+Evil -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687614: unblock: gdebi/0.8.6 (pre-approval)
On 2012-10-11 21:08, Luca Falavigna wrote: tags 687614 - moreinfo thanks 2012/10/6 Niels Thykier ni...@thykier.net: In the 0.8.5 code, there are a couple of places where GDebiCli.install returns False on error[1], which I believe python translates to 0 leading to exit 0 with errors (and I suspect that is not what you wanted). Good catch! I'm attaching a new debdiff implementing a fix for the return value. Looks better. :) Feel free to go ahead. Please ping us when it has been in unstable for a couple of days. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#359059: lintian: Allow vendor/user specific checks
On 2012-10-11 22:42, Jakub Wilk wrote: * Niels Thykier ni...@thykier.net, 2012-09-17, 13:49: I have devised a prototype implementation[1], which should demonstrate how this could be implemented with relatively few changes on top of the master branch. In the prototype, 1 the command line argument is --contrib-check X 2 if $CHECKS/contrib/X.desc is a file or symlink, then that is loaded 3 if $CHECKS/contrib/X is a dir (or symlink to a dir), all checks in that dir is loaded (but no recursion is done). (More or less a $CHECKS/contrib/X/*.desc) 4 $CHECKS is one of (in order): - ~/.lintian/checks - /etc/lintian/checks - LINTIAN_ROOT/checks (usually /usr/share/lintian/checks) (NB: Yes, this means you can shadow a built-in check) 2+3 together allows providers to split their check into multiple files (or merge multiple files into one) without users needing to know or care about it. Will there be a way to run _only_ contrib checks, i.e. skip the ones from lintian proper? Mmm, should be doable already by creating/using a null profile. Not sure if it should have better built-in support than that... Will there be a visual indication that an emitted tag comes from a contrib check? [lintian4python uses e:/w:/i:/p:/x: instead of E:/W:/I:/P:/X:, so that its output can't be easily confused with official lintian output.] I hadn't considered adding it and I am not sure we should. Though for the no built-in checks case it should be trivial to do a L::Output plugin for this purpose. (By trivial I mean L::Output::FullEWI trivial) How will overrides play with contrib checks? [I had a user who wanted to add an override for lintian4python, though there's currently no way to do that.] I think adding them to the standard overrides file will just work. Do you have a sample lintian4python case where the override fails to work? Or were you thinking we should have a separate overrides file for contrib checks? FTR, the prototype only loads collections from LINTIAN_ROOT/collections. Do we want to add a contrib dir in collections/ as well? Personally I think it would be a good idea as then we (i.e. Lintian maintainers) don't have to worry about name conflicts with contrib modules. I haven't thought thoroughly about it, but my gut feeling is that allowing 3rd-party collections would open a can of worms... [...] There is that - also we can always add it later if it is... ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#359059: lintian: Allow vendor/user specific checks
On 2012-10-12 11:45, Jakub Wilk wrote: * Niels Thykier ni...@thykier.net, 2012-10-11, 23:22: How will overrides play with contrib checks? [I had a user who wanted to add an override for lintian4python, though there's currently no way to do that.] I think adding them to the standard overrides file will just work. Do you have a sample lintian4python case where the override fails to work? Hmm. I was convinced that lintian would emit unused-override if it sees an override for a non-existent tag[0], but apparently this is not the case. (Bug or feature?) It is intentional (i.e. a feature). I see this part is not covered by our Manual, but it was in the Vendor Profile proposal(s)[0]. [0] I have a distinct memory of seeing spurious unused-override tags in early stage of lintian4python development. But maybe my memory is playing tricks on me. Depending on when you did this testing last, your memory may be true. At the very least, Vendor Profiles were not implemented until 2.5.2 (from Aug 2011). Plus, it may not have worked properly until 2.5.5[1]. Up to version 2.5.2, Lintian would indeed emit unused-override for unknown tags[1]. But with the introduction of Vendor profiles, Lintian will only emit unused-overrides for active tags (i.e. tags from the select profile that has not been suppressed). ~Niels [0] http://wiki.debian.org/Lintian/Spec/VendorCustomization https://lists.debian.org/debian-lint-maint/2011/04/msg00277.html * A tag not included in the current profile shall not be emitted. * An override for such a tag is not considered unneeded and must be ignored. [1] I haven't tested, but the following change sounds like it would affect it (as L::Tags determines if an override is unused or not). * lib/Lintian/Tags.pm: [...] + [NT] Use a Profile to determine if a tag is suppressed or not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#359059: lintian: Allow vendor/user specific checks
On 2012-09-17 13:49, Niels Thykier wrote: * Where do contrib checks install their data files? A suggestion could be: root/vendors/contrib/X/... and have Lintian special case it. Looking at the code needed to do this special casing, we might as well just restore the root/data dir and include that in the end directly. Contrib checks would then just put their data files in: root/data/contrib/X/... As an added bonus, the special casing does not need any additional testing because all the standard data files would be loaded from there as well. Yay! ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688512: unblock or tpu: glib2.0/2.33.12+really2.32.4-1
Control: tag -1 pending d-i On 2012-10-06 02:44, Josselin Mouette wrote: I have just uploaded version 2.33.12+really2.32.4-2 because of a security vulnerability: glib2.0 (2.33.12+really2.32.4-2) unstable; urgency=medium * Revert link adding for gdbus-object-manager-example. While it is useful to have in /usr/share/doc as an example, it must not be shipped with the system documentation. * 20_glib-compile-resources_leak.patch: new patch. Fix a leak introduced in version 2.32.4. Thanks Niels Thykier! * SECURITY: add 11_CVE-2012-3524_setuid.patch from upstream. Prevents using DBus in a setuid binary. Fixes CVE-2012-3524. Attached is the diff between -1 and -2. Cheers, Unblock added, unblock-udeb pending d-i approval. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689351: unblock: klibc/2.0.1-2
Control: tags -1 pending d-i On 2012-10-01 21:54, maximilian attems wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package klibc Has 3 fixes for armhf RC bug, plus security fix for dash and a fix for x86 cross building. See the diff: [...] Unblocked klibc/2.0.1-3, though unblock-udeb pending d-i approval. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690499: RM: rdeps of gtk-sharp2 [armhf] -- ANAIS; dependency already removed
Package: ftp.debian.org
Severity: normal
Hi,
In #689110, gtk2-sharp [armhf] was removed. Unfortunately, a lot of
its rdeps are still present on armhf. According to Britney, the
following _binary packages_ are holding up the migration of
gtk2-sharp (by becoming uninstallable).
I have checked a large sample of the packages (excl. ones named
-cli{,-dev}) and all of checked ones appear to depend on one or more
packages built by gtk-sharp2.
banshee, banshee-dbg, banshee-extension-lastfmfingerprint,
banshee-extension-lirc, banshee-extension-mirage, banshee-meego,
bareftp, cowbell, f-spot, gnome-do, gnome-subtitles,
libgnome-keyring1.0-cil, libgnome-keyring1.0-cil-dev,
libgnome2.0-cil-dev, libgnome2.24-cil, libgstreamer0.9-cil,
libgtkhtml3.14-cil-dev, libgtkhtml3.16-cil, libgtksourceview2-2.0-cil,
libgtksourceview2-cil-dev, libmono-uia-atkbridge1.0-cil,
libvte0.16-cil, libvte0.16-cil-dev, libwnck1.0-cil-dev,
libwnck2.20-cil, longomatch, mistelix, tangerine, tangerine-dbg,
tomboy
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678896: lintian: please add check for multi-arch: foreign -dbg packages
On 2012-10-17 23:57, Jakub Wilk wrote:
I'd tend to agree that M-A:foreign for -dbg packages is always wrong.
* Niels Thykier ni...@thykier.net, 2012-09-03, 13:49:
For a library, I see the problem the -dbg has symbols for a M-A:
same package (e.g. a library). But for some package that is M-A:
foreign, I don't see why the related -dbg package couldn't be M-A:
foreign.
Sure it might be weird, but I don't immediately see how it would
break anything.
If there's a -dbg package for a MA:foreign package, then something is
already broken. Imagine a situation like this:
Package: foo
Multi-Arch: foreign
Package: foo-dbg
Depends: foo (= ${binary:Version})
Now I can co-install foo-dbg:amd64 and foo:i386, despite the fact that
foo-dbg is useless in such setup.
(I'm afraid it's a corner-case of multi-arch that hasn't been
well-thought yet...)
Hah, in that case, foo should be Multi-Arch: allowed. In this case
rdeps can use foo:any to use the foreign dependency and the debug
package could use foo (implying the Multi-Arch: same relation)...
I know, it is a poor solution as it kills a major advantage of M-A
foreign as now a bunch of rdeps needs to append :any due to a debug
package. But the situation did remind me of Steve's favourite M-A:
allowed example python (and I think this was how he used M-A:allowed).
Anyhow, it is unfortunate that this mistake is possible, at least the
right foo-dbg is installable for all variants of foo.
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690828: csound: FTBFS on all architectures
Source: csound Version: 1:5.17.11~dfsg-2 Severity: serious Hi, csound currently FTBFS on all architectures. The snippet below is from the i386 log: /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/obj-i486-linux-gnu/csound_orcparse.h:153:22: error: unknown type name 'PARSE_PARM' In file included from /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/Top/main.c:31:0: /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/./H/csound_orc.h:24:0: warning: YYDEBUG redefined [enabled by default] In file included from /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/./H/csound_orc.h:16:0, from /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/Top/main.c:31: /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/obj-i486-linux-gnu/csound_orcparse.h:37:0: note: this is the location of the previous definition /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/Top/main.c: In function 'csoundCompile': /build/buildd-csound_5.17.11~dfsg-2-i386-QJTESH/csound-5.17.11~dfsg/Top/main.c:86:14: warning: variable 'sortedscore' set but not used [-Wunused-but-set-variable] make[3]: *** [CMakeFiles/csound64.dir/Top/main.c.o] Error 1 ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690920: unblock: dpkg/1.16.9
Hi, The copy of bug report from the BTS does not appear to have reached d-release@l.d.o, so this is just a minimal ping that will appear on the list. debdiffs at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690920 ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691005: unblock: kdegames/4:4.8.4-2
Control: reopen -1 On 2012-10-20 11:38, Beojan Stanislaus wrote: On Friday 19 October 2012 20:45:56 Lisandro Damián Nicanor Pérez Meyer wrote: [...] The version of python-qt4-sql this package depends on is unavailable in debian sid, making the update uninstallable. Indeed, thanks for catching that. Lisandro, can you please upload a new version fixing that and ping me via this bug when it has been in unstable for a couple of days? ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690895: unblock: giflib/4.1.6-10
Control: tags -1 + confirmed On 2012-10-20 13:48, Thibaut Gridel wrote: reopen 690895 thanks Hello again, On Thursday 18 October 2012, you wrote: On 2012-10-18 23:23, Thibaut Gridel wrote: Hi! Please unblock giflib Thank you for your interest. We can allow a minimal patch for the hardning fixes (/without/ a debhelper compat bump) if it goes via unstable, if needed. Please find enclosed proposed new debdiff, only for enabling hardening and fixes. Best Regards, Thibaut Hi, Looks okay; feel free to upload it to unstable. Please ping us once it has been in unstable for a couple of days. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688574: libdvdread4: lack of __USE_GNU causes crashes in dvd_reader.c ,, patch included
Hi, JFTR, man get_current_dir_name suggests that the macro _GNU_SOURCE should be used (rather than __USE_GNU). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691059: pre-approval: gigolo/0.4.1+dfsg-1
On 2012-10-20 21:56, Lionel Le Folgoc wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, I've prepared a new revision of gigolo to fix rc bug #654468 (the tarball contains waf… but still provides an autotools-based build system, so I repacked it to get rid of waf). Would such a change (see attached debdiff between 0.4.1-3 and 0.4.1+dfsg-1) be acceptable for wheezy? Thanks. Lionel [...] Hi, Please go ahead and ping us after it has been in unstable for a couple of days. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685149: Candidates for removal from testing
On 2012-10-22 09:20, Andreas Tille wrote: Hi, On Thu, Oct 18, 2012 at 10:32:39AM +0200, Niels Thykier wrote: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org gentle A package fixing the issue is in http://ftp-master.debian.org/new.html since some time and this had something to do with some problems in DAK (according to http://lists.alioth.debian.org/pipermail/debian-med-packaging/2012-October/017521.html ) Ansgar, it would be really welcome if you could try again your manual procedure to circumvent the problem to get the fixed package in. We (as in the Debian Med team) would be really happy if you would delay the removal of the package because we actually worked on this problem and it should be fine once it has passed new (due to a move from contrib to main). Kind regards Andreas. Hi, Noted, I have taken it off the list for now. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668437: lintian: Identify -dbg packages that have binaries with no debugging symbols
On 2012-04-11 22:37, Nelson A. de Oliveira wrote: Package: lintian Version: 2.5.6 Severity: wishlist Hi! Using #652099 as an example, we have a source package that has a -dbg binary package, with files located under /usr/lib/debug/ as they should be but with one problem: there are no debugging symbols. Could lintian do a new check against the binaries in a -dbg package to see if they indeed have the proper debugging symbols? Hi, It might be possible to do... Something like doing a nm -a $file | cut -b 18 and grepping for N If no N is found then we have a file with missing symbols and a warning about this. Did you by chance mean cut -b 8 or so. By the looks of it 18 cuts into the symbol/section/$something name. I assume the N you are talking about would be: | v N .debug_abbrev N .debug_aranges N .debug_frame N .debug_info N .debug_line N .debug_loc N .debug_pubnames N .debug_str ^ | (I don't know if nm + cut + grep is the best way to test for debugging symbols, but it seems to do the job) Thank you! Best regards, Nelson [...] If so, we should be able to simply check for the presence of any section starting with .debug_ (or maybe just .debug_line, which supposedly holds the line number mappings)[1]. ~Niels [1] Ref: http://www.dwarfstd.org/doc/Debugging%20using%20DWARF.pdf (see ELF sections on page 9) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683059: lintian: package-contains-broken-symlink should also check recommended packages
On 2012-07-28 10:16, Paul Gevers wrote: Package: lintian Version: 2.5.10 Severity: normal Dear Maintainer, In my package I want to create a symlinks to manpages in a recommended package (the binaries use update-alternatives to provide the proper variant). I would nearly consider this recommended package a dependency but doing so would cause a circular dependency and anyway policy [7.2] says: [...] I think the error would disappear if you were to put the symlink in the recommended package? I appreciate that this may not be as easy as I make it sound. (For reference, what packages are we talking about?) So I believe that symlinks to recommended packages should be fine, and as such the package-contains-broken-symlink check should also consider recommended packages next to depends packages. Strictly speaking it would still allow the package to ship a broken symlink, even if the situation is rare... Feel free to tell me I am wrong in this, but please provide arguments. But I suppose the real question is whether Recommends is strong enough for this purpose... Grtz Paul [7.2] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps [...] ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683060: lintian: *-command-not-in-package could check for alternatives in dependent packages
On 2012-07-28 10:31, Paul Gevers wrote: Package: lintian Version: 2.5.10 Severity: normal Dear Maintainer, In my package I want to provide a binary via update-alternatives to provide the multiple variants of the same program (a gtk2 and a qt variant). I want to ship one desktop file and one menu file in a package that depends on the either of the variants. Currently both desktop-command-not-in-package and menu-command-not-in-package raise a warning on this setup, but I believe they are false positives that could be checked on the use of update-alternatives in dependent packages. Grtz Paul [...] Truly, they are false-positives. Unforunately, update-alternatives (and dpkg-diverts for that matter) are created/updated/etc. in maintainer scripts. The problem is extracting this information (reliably) and have it available. Some ad-hoc parsing would probably do rather well, but things like declarative (dpkg-)diverts (and declarative alternatives) would be optimal on the Lintian side. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691203: Acknowledgement (Missing B-D to ant)
On 2012-10-22 22:56, Mathieu Malaterre wrote: Even after installing: maven-ant-helper I still get some error during building: [javadoc] /tmp/libswingx1-java-1.0/src/java/org/jdesktop/swingx/color/GradientPreviewPanel.java:26: package org.apache.batik.ext.awt does not exist [javadoc] import org.apache.batik.ext.awt.RadialGradientPaint; [javadoc]^ [javadoc] /tmp/libswingx1-java-1.0/src/java/org/jdesktop/swingx/color/GradientTrackRenderer.java:23: package org.apache.batik.ext.awt does not exist [javadoc] import org.apache.batik.ext.awt.MultipleGradientPaint; [javadoc]^ [javadoc] /tmp/libswingx1-java-1.0/src/beaninfo/org/jdesktop/swingx/editors/PainterUtil.java:50: package org.apache.batik.ext.awt does not exist [javadoc] import org.apache.batik.ext.awt.LinearGradientPaint; I guess I could merge 691203 and 691202 into one... let me know what you think. thanks [...] These particular errors (i.e. the [javadoc] ones) usually don't lead to a build error and at worst causes the Javadoc to be slightly less pleasent. Those javadoc errors should be fixed, but I would not consider it a priority to those in Wheezy nor Squeeze. The build-depends issues are of course) a different matter. But I think one bug is sufficient for tracking those, so I'd vote for merging. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691398: debhelper: dh_installdeb redundant is_udeb or unintended code flow
Package: debhelper
Version: 9.20120909
Severity: minor
Hi,
I noticed the following code in dh_installdeb:
foreach my $package (@{$dh{DOPACKAGES}}) {
[...]
if (is_udeb($package)) {
[...]
next;
}
[...]
if (! is_udeb($package)) {
[...]
}
}
If $package is a udeb, it will never reach past the first of the two
shown is_udeb if-statements. From the code and my understanding of
udebs, it looks the second if-statement is merely redundant (hench the
minor severity).
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642767: lintian: package-section-games-but-contains-no-game should be deprecated
On 2011-09-25 00:35, Michael Gilbert wrote: package: lintian version: 2.5.3 severity: normal According a recent games team meeting log and several freedesktop documents, games no longer belong in /usr/games. However, when a package is updated to put game executables in /usr/bin, the lintian error package-section-games-but-contains-no-game is asserted. For more info, see: http://meetbot.debian.net/debian-games/2011/debian-games.2011-06-26-09.57.html http://lists.freedesktop.org/archives/games/2011-May/000369.html Thanks, Mike Hi, Have you filed a bug against debian-policy? At least §11.11 says As described in the FHS, binaries of games should be installed in the directory /usr/games. Can I assume this implies that setgid-binaries for games will appear in /usr/bin as well (currently we only allow stuff in /usr/lib/games and /usr/games/)? On a related note, I suspect this will affect/break the tags package-section-games-but-has-usr-bin and games-package-should-be-section-games. package-section-games-but-has-usr-bin could survive as a consistency check (either everything goes into /usr/games or everything goes into /usr/bin). However that only makes sense if /usr/games is not (going to be) deprecated. The meeting logs were not completely clear to me on this part. I suppose we could salvage games-package-should-be-section-games by looking for setgid games binaries or/and installing stuff in (i.e.) /usr/lib/games and other discriminating directories. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645793: Orphaning lprfax
severity 645793 normal reassign 645793 wnpp retitle 645793 O: lprfax - Utility to allow printing to a fax modem thanks Hi, I am orphaning lprfax[1] on behalf of Camm Maguire (see #645793). Due to its RC bugs and its very low popcon I intend to request the removal of this package in about 14 days, if no one picks it up. ~Niels [1] Package: lprfax Version: 0.6-28 Installed-Size: 204 Maintainer: Camm Maguire c...@debian.org Architecture: i386 Depends: libc6 (= 2.0), netpbm, magicfilter, ghostscript, transfig, libjpeg-progs, texlive-latex-base, poppler-utils Pre-Depends: lprng (= 3.6.12), debianutils (= 1.6), mgetty-fax Suggests: samba, smbclient Description: Utility to allow printing to a fax modem lprfax provides a set of scripts and programs to control network fax spooling through the LPRng print system. The goal is to enable transparent faxing in any application able to print, via 'lpr -Pfax -Jnumber or name'. Features: * integration with mgetty/sendfax system and configuration files * load balancing among multiple fax modems * remote queue/log inspection and control * Customizable cover page generation via banner-page filters * Customizable name/fax number lookup from job specification * automated fax retries via lprng hold/release mechanism Tag: hardware::modem, qa::low-popcon, role::program, scope::utility, works-with::fax Section: net Priority: extra Filename: pool/main/l/lprfax/lprfax_0.6-28_i386.deb Size: 27176 MD5sum: e92eb21263ead68bbee351ddf89b5b8f SHA1: aebf1d979b0bb99c98a784f8fb2262f6b99717c9 SHA256: 89f70a1c124bdba1f850e78710c46c187004372031ef23c54591cc6c1d7a9f6e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647800: cal3d: Please add build-arch/build-indep targets and enable hardning flags
Package: cal3d Version: 0.11.0-4 Severity: wishlist Tags: patch User: hardening-disc...@lists.alioth.debian.org Usertags: goal-hardening Hi, Attached is a debdiff that enables build-arch/build-indep targets and enables hardning flags. The rules could be improved to only build the docs in build-indep; but given the short runtime for docs generation I figured it was not worth it. This would assist in hardning release goal[1] and the /proposed/ build-arch release goal[2]. Since the latter has not been accepted, this bug has been fixed as a wishlist. As I recall you are busy at the moment, so I intend to NMU this package. If I do not hear from you in a week, I will upload it to DELAYED/10 as per devref 5.11.1[3] Thanks for considering, ~Niels [1] http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags [2] https://wiki.debian.org/ReleaseGoals/BuildArchTarget [3] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu diff -u cal3d-0.11.0/debian/rules cal3d-0.11.0/debian/rules --- cal3d-0.11.0/debian/rules +++ cal3d-0.11.0/debian/rules @@ -5,22 +5,20 @@ DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) -CXXFLAGS = -Wall -g -fPIC LIBS = -lstdc++ ifneq (,$(findstring mips,$(DEB_BUILD_GNU_TYPE))) LIBS += -lm endif -ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) - CXXFLAGS += -O0 -else - CXXFLAGS += -O2 -endif + +DPKG_EXPORT_BUILDFLAGS = 1 +DEB_CXXFLAGS_MAINT_APPEND = -Wall -fPIC +include /usr/share/dpkg/buildflags.mk config.status: configure dh_testdir - CXXFLAGS=$(CXXFLAGS) LIBS=$(LIBS) \ + LIBS=$(LIBS) \ ./configure \ --host=$(DEB_HOST_GNU_TYPE) \ --build=$(DEB_BUILD_GNU_TYPE) \ @@ -34,7 +32,9 @@ sed -e 's/CC=gcc/CC=g++/g' libtool lt.tmp mv -f lt.tmp libtool -build: build-stamp +build: build-arch build-indep +build-arch: build-stamp +build-indep: build-stamp build-stamp: config.status dh_testdir diff -u cal3d-0.11.0/debian/control cal3d-0.11.0/debian/control --- cal3d-0.11.0/debian/control +++ cal3d-0.11.0/debian/control @@ -2,7 +2,7 @@ Section: libs Priority: optional Maintainer: Michael Koch konque...@gmx.de -Build-Depends: debhelper (= 5), doxygen +Build-Depends: debhelper (= 5), doxygen, dpkg-dev (= 1.16.1) Standards-Version: 3.8.2 Homepage: https://gna.org/projects/cal3d/ diff -u cal3d-0.11.0/debian/changelog cal3d-0.11.0/debian/changelog --- cal3d-0.11.0/debian/changelog +++ cal3d-0.11.0/debian/changelog @@ -1,3 +1,11 @@ +cal3d (0.11.0-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Added build-arch and build-indep targets. + * Enable harding flags by using dpkg-buildflags. + + -- Niels Thykier ni...@thykier.net Sun, 06 Nov 2011 13:55:19 +0100 + cal3d (0.11.0-4) unstable; urgency=low * Updated config.guess and config.sub (Closes: #528398).
Bug#647817: RM: libgnujmi-java -- RoQA; Orphaned library, no rdeps, low popcon
Package: ftp.debian.org Severity: normal Hi, libgnujmi-java is orphaned and has no reverse dependencies, so there is little reason to keep it in the archive. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647818: RM: png-sixlegs -- RoQA; orphaned, dead-upstream, no rdeps
Package: ftp.debian.org Severity: normal Orphaned library with no reverse dependencies. Last upstream release appears to be May 2008 (see [1]). ~Niels [1] http://code.google.com/p/javapng/downloads/list -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647821: nice: Should this package be orphaned/removed
Package: nice Severity: serious Hi, As far as I can tell, the maintainer of nice is also the (sole) upstream developer for nice. By the looks of it, upstream is dead and this implies that this package is silently unmaintained. If you are still around to maintain this package, please respond to this package within 14 days. Otherwise I shall I assume you have lost interest and orphan your package. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624534: Report new bug
Hi, I noticed your bug report against eclipse-pydev in Debian. You state you are using Windows and the report itself does not appear to be related to the eclipse-pydev package in Debian. So I suspect you may have wanted to file a bug against pydev itself[1] rather than against the Debian packages of pydev. ~Niels [1] http://pydev.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647826: RM: eclipse-pydev -- ROM; RC-buggy, no active maintainer
Package: ftp.debian.org Severity: normal Hi, eclipse-pydev has been RC-buggy for ages and to my knowledge there are no one actively working on fixing it. For good measure I have CC'ed d-java@l.d.o, just in case - but given it has not been in testing since 2007, I strongly suspect it is a dead package. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475377: Considering to RM afnix
Hi, I am considering to remove afnix, since it is unmaintained and has a very low popcon. However, there has been QA uploads to bump upstream releases twice this year (both uploaders CC'ed). If you have any interest in this package, please consider adopting it. Otherwise I will push for its removal. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647917: UDD: Update lintian tag regex
Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd
Hi,
The coming version of lintian is changing output format for tags on
lintian.d.o. The new format is
C: pkg type (version) [arch]: tag extra
(Where extra is the only optional value that may be left out).
I have attached the lintian code that examines this part of the log
file below[1]. The regex should be backwards compatible with the old
style log format, so UDD migration should be possible already now.
~Niels
[1]
# Matches something like: (1:2.0-3) [arch1 arch2]
# - captures the version and the architectures
my $verarchre = qr,(?: \s* \(( [^)]++ )\) \s* \[ ( [^]]++ ) \]),xo;
#
# ( version ) [architecture ]
# matches the full deal:
#1 222 444 666 777
# - T: pkg type (version) [arch]: tag [...]
# ^
# Where the marked part(s) are optional values. The numbers above the example
# are the capture groups.
my $fullre = qr/([EWIXOP]): (\S+)(?: (\S+)(?:$verarchre)?)?:
(\S+)(?:\s+(.*))?/o;
while () {
chomp;
next unless m/^$fullre/o;
my ($code, $package, $type, $pver, $parch, $tag, $extra) = ($1, $2, $3, $4,
$5, $6, $7);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647919: acl2: Please add support for build-arch and build-indep targets
Source: acl2 Severity: wishlist Tags: patch User: debian...@lists.debian.org Usertags: build-arch-target Hi, Please see attached patch for an example of how this could be done. In order to progress in a timely manner with /proposed/ release goal, it is my intention to NMU this package in 14 days (to DELAYED/10) if I have not heard from you. Thank you in advance for considering, ~Niels diff -Nru acl2-4.2/debian/changelog acl2-4.2/debian/changelog --- acl2-4.2/debian/changelog 2011-05-14 03:02:31.0 +0200 +++ acl2-4.2/debian/changelog 2011-11-07 15:58:09.0 +0100 @@ -1,3 +1,10 @@ +acl2 (4.2-1.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Added build-arch and build-indep targets to d/rules. + + -- Niels Thykier ni...@thykier.net Mon, 07 Nov 2011 15:52:34 +0100 + acl2 (4.2-1) unstable; urgency=low * New upstream release diff -Nru acl2-4.2/debian/rules acl2-4.2/debian/rules --- acl2-4.2/debian/rules 2011-05-13 20:07:24.0 +0200 +++ acl2-4.2/debian/rules 2011-11-07 15:55:36.0 +0100 @@ -108,7 +108,9 @@ # cd interface/infix make -f Makefile events touch $@ -build: build-stamp +build: build-arch build-indep +build-arch: build-stamp +build-indep: build-stamp build-stamp: debian/mini-proveall.out debian/test.log infix-stamp dh_testdir @@ -310,4 +312,4 @@ dh_builddeb binary: binary-indep binary-arch -.PHONY: build clean binary-indep binary-arch binary install +.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install
Bug#645271: axel: Doesn't honor noopt
Source: axel Tags: patch Followup-For: Bug #645271 User: hardening-disc...@lists.alioth.debian.org Usertags: goal-hardening Hi, Long time no see. ;) Attached is a patch that will use buildflags.mk to set the default buildflags (except -O2[1]). The upstream makefile had to be patched to insert the LDFLAGS correctly (LFLAGS is too late as I understand the linker). The patch also adds the build-arch and build-indep targets to debian/rules. This will fix axel for the harding release goal and the /proposed/ build-arch target release goal. ~Niels PS: The maintainer of dpatch has officially deprecated dpatch, so you may also want to migrate away from dpatch. [1] I presumed there was a reason the current build used -Os. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645271: axel: Doesn't honor noopt
tags 645271 + patch user debian...@lists.debian.org usertags 645271 build-arch-target thanks Gah, reportbug mess up - here is the patch. :) ~Niels acl2-4.2-1.1.diff Description: application/wine-extension-patch
Bug#647950: RM: quiteinsanegimpplugin -- RoQA; RC-buggy, orphaned, dead-upstream
Package: ftp.debian.org Severity: normal Hi, The WNPP bug #390836 has not seen any human activity since Feb 09, the package FTBFS #628333 and upstream appears to be dead. Finally it is listed on [1], so I suspect it is also blocking the qt3 removal in some (distant?) future. :) ~Niels [1] https://wiki.debian.org/qt3-x11-freeRemoval -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615595: O: sim -- Sim-IM Instant Messenger data files
Hi, I am considering to request a removal of sim because it is unmaintained and RC-buggy. But I saw a version of sim on mentors.d.n, despite this bug not being an ITA. So Alexander or Nikolay, are any of you interested in maintaining this in Debian? If not, I will file a removal request very soon (within 2 weeks). ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555034: Orphaning mlview
reassign 555034 wnpp retitle 555034 O: mlview - xml editor for GNOME environment thanks Hi, I am hereby orphaning mlview[1] on behalf of Sebastian Bacher. As it is RC buggy and has a very low popcon, I intend to RM within 14 days unless someone picks it up. ~Niels [1] Package: mlview Version: 0.9.0-2.2 Priority: optional Section: editors Maintainer: Sebastien Bacher seb...@debian.org Depends: [...] Description: An xml editor for GNOME environment Some features: * cut/copy/paste as child/paste as prev/paste as next/ of xml elements * xml element/attributes search * multi docs edition * Several editing views can be opened on the same document * drag and drop based copy/cut/past of xml elements * edition of xml elements and attributes can be made directly on the tree * namespace support * on-demand validation * graphical error reporting. Parse/validation time errors reported graphically. * when validation is switched on, MlView proposes an elements/attributes completion feature. When an element is added to the tree, MlView also add the children elements required by the DTD for the document to be valid. * Validation can be switched off. The xml document editon can then be done without any constraint. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648081: realtimebattle: Add build-{arch, indep} targets, enable hardning flags and migrate away from default-jdk-builddep
Source: realtimebattle Severity: wishlist Tags: patch Hi, Attached you will find a patch that: * Adds build-arch and build-indep targets. (/proposed/ release goal) - Cannot yet be used realibly on buildds, so the current is javac available code has been left for now. * Enables hardning flags (accepted release goal) - Required a minor patch to one of the upstream files. - Done in the .diff.gz, since there were other changes in the diff.gz already. * Migrates from default-jdk-builddep to default-jdk. - This saves an unused JDK on most common platforms (i.e. i386 and amd64) - Details about this can be found in java-common. ~Niels diff -u realtimebattle-1.0.8/debian/rules realtimebattle-1.0.8/debian/rules --- realtimebattle-1.0.8/debian/rules +++ realtimebattle-1.0.8/debian/rules @@ -1,13 +1,20 @@ #!/usr/bin/make -f +DPKG_EXPORT_BUILDFLAGS=1 + +include /usr/share/dpkg/buildflags.mk + d=debian/tmp ROOT=$(d)/usr LC_ALL=C PACKAGE=realtimebattle -export JAVAC=/usr/bin/ecj +JAVA_HOME=/usr/lib/jvm/default-java +export JAVAC=$(JAVA_HOME)/bin/javac export ROBOTS=empty rotate_and_fire seek_and_destroy xt-bot thomas2 joypad_robot perl-Skeleton perl raziel $(shell [ -x $(JAVAC) ] echo jBot ) -build: build-stamp +build: build-arch build-indep +build-arch: build-stamp +build-indep: build-stamp build-stamp: dh_testdir @@ -91,3 +98,3 @@ binary: binary-indep binary-arch -.PHONY: build clean binary-indep binary-arch binary install clean1 +.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install clean1 diff -u realtimebattle-1.0.8/debian/control realtimebattle-1.0.8/debian/control --- realtimebattle-1.0.8/debian/control +++ realtimebattle-1.0.8/debian/control @@ -3,8 +3,9 @@ Priority: optional Maintainer: Rémi Vanicat vani...@debian.org Standards-Version: 3.8.3 -Build-Depends: debhelper (= 5), libgtk2.0-dev, libglib2.0-dev -Build-Depends-Indep: default-jdk-builddep +Build-Depends: debhelper (= 5), libgtk2.0-dev, libglib2.0-dev, + dpkg-dev (= 1.16.1~) +Build-Depends-Indep: default-jdk Vcs-Browser: http://git.debian.org/?p=collab-maint/realtimebattle.git;a=summary Vcs-Git: git://git.debian.org/git/collab-maint/realtimebattle.git diff -u realtimebattle-1.0.8/debian/changelog realtimebattle-1.0.8/debian/changelog --- realtimebattle-1.0.8/debian/changelog +++ realtimebattle-1.0.8/debian/changelog @@ -1,3 +1,15 @@ +realtimebattle (1.0.8-10.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Added build-arch and build-indep to debian/rules. + * Reduce default-jdk-builddep to default-jdk and use default-java. + * Use buildflags.mk from dpkg-dev to set default build flags. +- This enables hardning build by default. + * Patched team-framework/log/sysloglogdriver.cpp, which was using +a non-constant as a format string to syslog. + + -- Niels Thykier ni...@thykier.net Tue, 08 Nov 2011 21:25:27 +0100 + realtimebattle (1.0.8-10) unstable; urgency=low * Use default-jdk-builddep and default-jre for jBot (Closes: #548811) only in patch2: unchanged: --- realtimebattle-1.0.8.orig/team-framework/log/sysloglogdriver.cpp +++ realtimebattle-1.0.8/team-framework/log/sysloglogdriver.cpp @@ -198,7 +198,7 @@ } } - syslog(_syslogPriority, message.c_str()); + syslog(_syslogPriority, %s, message.c_str()); } mapstring, string SyslogLogDriver::parseParameterString(const string parameters) throw
Bug#648084: kannel: git repository disagrees with the uploaded source package
Source: kannel Severity: normal Hi, I wanted to write a patch for the missing build-arch/build-indep targets in kannel. But on closer examination, it turns out that the git repository and the last uploaded packages seems to be disagreeing on contents/version. Below is the diff between the changelog of the source package and the git repository. It appears that the git version has the targets I wanted to add as a patch, so kudos if you keep at least that part. :D ~Niels diff -u kannel-1.4.3/debian/changelog kannel/debian/changelog --- kannel-1.4.3/debian/changelog 2010-03-19 03:19:45.0 +0100 +++ kannel/debian/changelog 2011-11-08 22:29:15.465140137 +0100 @@ -1,11 +1,14 @@ -kannel (1.4.3-2) unstable; urgency=low +kannel (1.4.3-2) UNRELEASED; urgency=low - * Drop superfluous /var/run/kannel ownership change in postinst -(already taken care of at SysV start time, and might fail if -/var/run is on temporary media). Closes: bug#574205, thanks to Lucas -Nussbaum. + * Drop README.Debian: Contained only outdated or superfluous info. + * Ease building with git-buildpackage: ++ Git-ignore quilt .pc dir. ++ Add source local-options. + * Drop old no longer used clutch from rules file. + * Rewrite rules file using CDBS. + * Build-depend on cdbs. - -- Jonas Smedegaard d...@jones.dk Fri, 19 Mar 2010 03:19:40 +0100 + -- Jonas Smedegaard d...@jones.dk Sun, 05 Dec 2010 17:23:54 +0100 kannel (1.4.3-1) unstable; urgency=low -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648152: maxima: Please enable build-arch and build-indep targets
Source: maxima Severity: wishlist Tags: patch User: debian...@lists.debian.org Usertags: build-arch-target Hi, Please see attached patch for an example of how this could be done. In order to progress in a timely manner with /proposed/ release goal, it is my intention to NMU this package in 14 days (to DELAYED/10) if I have not heard from you. Thank you in advance for considering, ~Niels diff -Nru maxima-5.24.0/debian/changelog maxima-5.24.0/debian/changelog --- maxima-5.24.0/debian/changelog 2011-05-16 18:56:23.0 +0200 +++ maxima-5.24.0/debian/changelog 2011-11-09 09:03:50.0 +0100 @@ -1,3 +1,10 @@ +maxima (5.24.0-1.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Added build-arch and build-indep targets in d/rules. + + -- Niels Thykier ni...@thykier.net Wed, 09 Nov 2011 09:01:51 +0100 + maxima (5.24.0-1) unstable; urgency=low * New upstream release diff -Nru maxima-5.24.0/debian/rules maxima-5.24.0/debian/rules --- maxima-5.24.0/debian/rules 2011-05-16 18:57:50.0 +0200 +++ maxima-5.24.0/debian/rules 2011-11-09 09:03:49.0 +0100 @@ -47,7 +47,9 @@ rm -rf debian/save MVERS:=$(shell head -n 1 debian/changelog | cut -f2 -d\ | tr -d '()' | cut -f1 -d-) -build: debian/save build-stamp +build: build-arch build-indep +build-arch: debian/save build-stamp +build-indep: debian/save build-stamp build-stamp: dh_testdir @@ -282,4 +284,4 @@ @echo 2 'source and diff are obsolete - use dpkg-source -b'; false binary: binary-indep binary-arch -.PHONY: build clean binary-indep binary-arch binary install +.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install
