Bug#732837: ITP: vcversioner -- Use version control tags to discover version numbers
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: vcversioner Version : 1.13.0.0 Upstream Author : Aaron Gallagher <_...@habnabit.org> * URL : https://github.com/habnabit/vcversioner * License : ISC Programming Lang: Python Description : Use version control tags to discover version numbers vcversioner autodiscovers a Python project's version number using version control system tags. This allows developers to avoid duplicating version information between their VCS and their setup.py metadata. . When the package is built, vcversioner generates a version.txt file that can be used for release tarballs. . Currently, vcversioner only supports the git VCS. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732837: ITP: vcversioner -- Use version control tags to discover version numbers
* Jeremy Stanley [2013-12-24 16:08:33 +]: > This sounds like a subset of python-pbr's features. What additional > benefits does it provide? > > http://packages.debian.org/sid/python-pbr It popped up as a dependency of the latest upstream release of txWS. pbr looks a bit "all-or-nothing" in its features, whereas vcversioner seems more conservative (i.e. only manage the version numbers and nothing else). Moreover, pbr requires distutils-style setup.cfg/setup.py, and txWS doesn't use that. Thanks for the hint though, -- Nicolas Dandrimont "Even more amazing was the realization that God has Internet access. I wonder if He has a full newsfeed?" (By Matt Welsh) signature.asc Description: Digital signature
Bug#604168: RFS: ramond
Hi Jonathan, * Jonathan Nieder [2010-11-22 17:43:38 -0600]: > FWIW, I am not a DD, so you have no hope of having this uploaded by me. :) > I also do not have an IPv6 network to test it on. Well, I'm glad to get feedback from a packaging point of view anyway. :) > Quick tips: > > . did you know about dh_installexamples? I did not, but it sounds useful. > . it might be nice to strip the outdated "Installation" section from > the README at build time, like this: > >sed '/Installation/, /textproc/ d' README >debian/README >dh_installdocs debian/README Seems like a good idea. > . is it important to say > > This manual page was written for the Debian > distribution because the original program does not > have a manual page. > > so early in the ramond.8 page? If it were me, I'd not mention it > at all; the COPYRIGHT section already says this was written for > Debian. Well now that I read it back it sounds weird indeed. I'll do another packaging pass tomorrow afternoon taking your remarks into account. > The packaging is very clean. Thanks for a pleasant read. Thank you for your review! Best, -- Nicolas Dandrimont "If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system." (By Linus Torvalds) signature.asc Description: Digital signature
Bug#604168: RFS: ramond (updated)
* Nicolas Dandrimont [2010-11-21 23:24:35 +0100]: > Dear mentors, > > I am looking for a sponsor for my package "ramond". > > * Package name: ramond > Version : 0.4-1 > Upstream Author : James Morse > * URL : http://ramond.sourceforge.net/ > * License : BSD > Section : net > > It builds these binary packages: > ramond - IPv6 Router Advertisement MONitoring Daemon > > The package appears to be lintian clean. > > The upload would fix these bugs: 604168 (ITP for ramond) > > We've been using this software on our network for a few months now and > it has proven very useful in killing off the rogue IPv6 routes and > notifying our users of their configuration problem. I think including > it into Debian would be worthwile. This is the first package I intend > for inclusion into the main Debian repositories, so there may be some > kinks to work out. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/r/ramond > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget http://mentors.debian.net/debian/pool/main/r/ramond/ramond_0.4-1.dsc > > I would be glad if someone took a look, gave me some feedback, and > eventually uploaded this package for me. Hi mentors, I updated the package to account for Jonathan Nieder's remarks[1], and improving a few things: - use of dh_installexamples - stripping the README off the installation instructions - rewording of the manpages - bump to dh compat level 8 - DEP-5 formatting for the debian/copyright file The package can be found in the same place as of the previous iteration (see links above). Cheers, -- Nicolas Dandrimont BOFH excuse #239: CPU needs bearings repacked [1] http://lists.debian.org/20101122234338.ga3...@burratino signature.asc Description: Digital signature
Bug#604168: RFS: ramond (updated, take 3)
* Kan-Ru Chen [2010-11-25 11:08:58 +0800]: > The package builds fine and appears to be lintian clean, though a little > too verbose. Please consider comment out the "export DH_VERBOSE=1" by > default in debian/rules. Done. > > - use of dh_installexamples > > - stripping the README off the installation instructions > > IMO, leave the README as is wouldn't harm at all. > > sed '/Installation/, /textproc/ d' README >debian/README > > Why sed? It could be done in a path, otherwise you leave a patched > debian/README that was not cleaned by dh_clean. I didn't consider that, thanks. I opted for the patch approach as I think that stripping the README off the installation instructions makes it more to the point. > And if you list the docs in debian/docs, dh_installdocs will take > care of them. Done. Take 3 on ramond's package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/ramond - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/ramond/ramond_0.4-1.dsc Thanks for your review, -- Nicolas Dandrimont "Linux: the operating system with a CLUE... Command Line User Environment". (seen in a posting in comp.software.testing) signature.asc Description: Digital signature
Bug#604168: RFS: ramond (updated, take 3)
* Kan-Ru Chen [2010-11-30 11:08:41 +0800]: > Nicolas Dandrimont writes: > > >> And if you list the docs in debian/docs, dh_installdocs will take > >> care of them. > > > > Done. > > Note that the file name is `package.docs' or `docs', not `installdocs'. > > > Take 3 on ramond's package can be found on mentors.debian.net: > > > > - URL: http://mentors.debian.net/debian/pool/main/r/ramond > > - Source repository: deb-src http://mentors.debian.net/debian unstable main > > contrib non-free > > - dget http://mentors.debian.net/debian/pool/main/r/ramond/ramond_0.4-1.dsc > > > > Thanks for your review, > > Thanks for your contribution to Debian. > > If no others want to sponsor this package, I will upload it with docs > fixed this evening. Hi, To save you this tiny bit of trouble, I reuploaded to mentors.d.n with the debian/docs path fixed. Thanks a lot, -- Nicolas Dandrimont BOFH excuse #342: HTTPD Error 4004 : very old Intel cpu - insufficient processing power signature.asc Description: Digital signature
Bug#431299: Patches to add different timescales for RC bugs status graph
Hi,
Since the patch from lucas has disappeared, please find attached another take
on this issue.
The first patch adds two new graphs: graph-month.png graphs the last month in
RC bugs, and graph-release graphs the RC bugs since the last release.
The second patch replaces the default graph with the -release one, and adds a
link to the two other graphs to the page.
Cheers,
--
Nicolas Dandrimont
From 2334c705c94b22a902f1729803bacdc541aea598 Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont
Date: Tue, 21 Jan 2014 01:34:21 +0100
Subject: [PATCH 1/2] Make RC bug graphs for the last month and since the last
release
Closes: #431299
---
dograph | 13 +
1 file changed, 13 insertions(+)
diff --git a/dograph b/dograph
index 0ce2fb9..ba6b822 100755
--- a/dograph
+++ b/dograph
@@ -21,6 +21,12 @@ find counts -type f -not -iname '*.bad'| sort | xargs egrep '^(.* ){7}' /dev/nul
# echo $date $count >> ${tmp}2
#done
+# This is the date of the wheezy release
+previous_release="201305040600"
+
+# And this is a month ago
+previous_month=`date +"%Y%m%d%H%M" --date="1 month ago"`
+
cat <From 1407c6e2653d4dc0f4839d95e868edfc11192ce6 Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont
Date: Tue, 21 Jan 2014 01:45:15 +0100
Subject: [PATCH 2/2] Link to new graphs in the generated html
---
dohtml | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dohtml b/dohtml
index d39128c..39b7889 100755
--- a/dohtml
+++ b/dohtml
@@ -95,7 +95,14 @@ EOF
cat <
-
+
+
+Other graphs:
+
+Graph for the last month
+Graph with all the history
+
+
The red line graphs all bugs with release-critical severities; the green
line graphs the number of bugs that are actually a concern for the next
--
1.8.5.3
signature.asc
Description: Digital signature
Bug#731376: ITP: libextutils-typemap-perl -- ExtUtils::Typemap - Read/Write/Modify Perl/XS typemap files
* Piotr Roszatycki [2013-12-04 20:31:41 +0100]: > Package: wnpp > Severity: wishlist > Owner: Piotr Roszatycki > > * Package name: libextutils-typemap-perl > Version : 1.00 > Upstream Author : Steffen Mueller > * URL : https://metacpan.org/release/ExtUtils-Typemap > * License : Artistic or GPL-1+ > Programming Lang: Perl > Description : ExtUtils::Typemap - Read/Write/Modify Perl/XS typemap > files > > ExtUtils::Typemap exists merely as a compatibility wrapper > around ExtUtils::Typemaps. In a nutshell, ExtUtils::Typemap was renamed to > ExtUtils::Typemaps because the Typemap directory in lib/ could collide with > the > typemap file on case-insensitive file systems. > > This package is required by Slic3r - G-code generator for 3D printers. Hi, Isn't all this already in libextutils-typemaps-default-perl? Slic3r works fine with that package. You can take a look at [1] for the current state of Slic3r packaging. [1] http://anonscm.debian.org/gitweb/?p=3dprinter/packages/slic3r.git Cheers, -- Nicolas Dandrimont "...[Linux's] capacity to talk via any medium except smoke signals." (By Dr. Greg Wettstein, Roger Maris Cancer Center) signature.asc Description: Digital signature
Bug#731376: ITP: libextutils-typemap-perl -- ExtUtils::Typemap - Read/Write/Modify Perl/XS typemap files
* Piotr Roszatycki [2013-12-05 00:46:40 +0100]: > 2013/12/4 Nicolas Dandrimont : > >> * Package name: libextutils-typemap-perl > >> This package is required by Slic3r - G-code generator for 3D printers. > > > > Hi, > > > > Isn't all this already in libextutils-typemaps-default-perl? Slic3r works > > fine with that package. > > Slic3r requires both of them: ExtUtils::Typemap and > ExtUtils::Typemaps::Default. At least the latest beta of Slic3er. > > git-blame [1] tells it requires ExtUtils::Typemap since 2013-06-23 > > [1] https://github.com/alexrj/Slic3r/blame/master/xs/Build.PL I'm not convinced that this dependency is right at all. EU::Typemap is never used in the codebase, and I'd expect any potential code generated by ParseXS to yield a dependency on EU::Typemap*s*, as it bundles that module. I think that just dropping the EU::Typemap dependency in Build.PL would be fine. Cheers, -- Nicolas Dandrimont "Linux poses a real challenge for those with a taste for late-night hacking (and/or conversations with God)." (By Matt Welsh) signature.asc Description: Digital signature
Bug#710487: My recent bpo-uploads not appearing in my qa page
Control: tags 710487 + patch
[Trimming down the Cc: list a bit]
* Mike Gabriel [2013-10-25 09:39:41 +]:
> I really wished someone with sufficient privileges could look at
> this rather sooner than later. I start loosing track of my uploads
> to wheezy-bpo (the scrap of paper gets scribbled more and more...).
> I guess, other package maintainer feel similar about this.
Please find attached a patch to the qa svn repository that makes
extract_incoming.pl look in the right place for !squeeze bpo sources.
Running the script on quantz and poking around the generated db file makes
me think that the "package versions" db file will contain all that is needed
for DDPO to find bpo uploads.
I have no qa/qa-core super cow powers, so I can't do much more.
Cheers,
--
Nicolas Dandrimont
I did this 'cause Linux gives me a woody. It doesn't generate revenue.
(Dave '-ddt->` Taylor, announcing DOOM for Linux)
Index: data/ddpo/extract_incoming.pl
===
--- data/ddpo/extract_incoming.pl (révision 3079)
+++ data/ddpo/extract_incoming.pl (copie de travail)
@@ -65,7 +65,6 @@
my $delayed_summary = "http://people.debian.org/~myon/delayed/delayed-summary";;
my $delayed_http = "http://people.debian.org/~djpig/delayed/";;
my $queue_summary = "http://ftp-master.debian.org/new.822";;
-my $bpo_url = "http://backports.debian.org/debian-backports";;
# global variables
my %db;
@@ -239,8 +238,16 @@
next if ($distkey =~ /^(unstable|testing)/);
my $dist = $active_dists{$distkey} . "-backports";
my $codename = $distkey eq "stable" ? "bpo" : "$distkey-bpo";
+
+my $archive = "ftp.debian.org";
+my $bpo_url = "http://ftp.debian.org/debian";;
+if ($dist eq "squeeze-backports") {
+$archive = "backports.org";
+$bpo_url = "http://backports.debian.org/debian-backports";;
+}
+
my $files_to_zcat = '';
-foreach my $file_to_zcat ( glob "/srv/qa.debian.org/data/ftp/backports.org/dists/$dist*/{main,contrib,non-free}/source/Sources.gz" )
+foreach my $file_to_zcat ( glob "/srv/qa.debian.org/data/ftp/$archive/dists/$dist*/{main,contrib,non-free}/source/Sources.gz" )
{
$files_to_zcat .= " $file_to_zcat" if( -e $file_to_zcat );
}
signature.asc
Description: Digital signature
Bug#710487: My recent bpo-uploads not appearing in my qa page
* Gerfried Fuchs [2013-10-25 14:24:41 +0200]:
> I wouldn't move the definition my "my $bpo_url" from the other URL
> definitions. Reason being, the special casing for squeeze-backports
> will eventually fade and can get removed, and the URL definitions should
> stick together. There's a reason why they are next to each other right
> now. :)
>
> Maybe also put my $archive next to it and put an additional comment
> that the special casing can get removed after squeeze gets archived.
That totally makes sense. Please find attached the v2 of this patch.
Thanks for the feedback,
--
Nicolas Dandrimont
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?"
(By Matt Welsh)
Index: data/ddpo/extract_incoming.pl
===
--- data/ddpo/extract_incoming.pl (révision 3079)
+++ data/ddpo/extract_incoming.pl (copie de travail)
@@ -65,7 +65,8 @@
my $delayed_summary = "http://people.debian.org/~myon/delayed/delayed-summary";;
my $delayed_http = "http://people.debian.org/~djpig/delayed/";;
my $queue_summary = "http://ftp-master.debian.org/new.822";;
-my $bpo_url = "http://backports.debian.org/debian-backports";;
+my $bpo_archive = "ftp.debian.org";
+my $bpo_url = "http://ftp.debian.org/debian";;
# global variables
my %db;
@@ -239,8 +240,15 @@
next if ($distkey =~ /^(unstable|testing)/);
my $dist = $active_dists{$distkey} . "-backports";
my $codename = $distkey eq "stable" ? "bpo" : "$distkey-bpo";
+
+# Special-casing for squeeze-bpo, to be removed when squeeze gets archived.
+if ($dist eq "squeeze-backports") {
+$bpo_archive = "backports.org";
+$bpo_url = "http://backports.debian.org/debian-backports";;
+}
+
my $files_to_zcat = '';
-foreach my $file_to_zcat ( glob "/srv/qa.debian.org/data/ftp/backports.org/dists/$dist*/{main,contrib,non-free}/source/Sources.gz" )
+foreach my $file_to_zcat ( glob "/srv/qa.debian.org/data/ftp/$bpo_archive/dists/$dist*/{main,contrib,non-free}/source/Sources.gz" )
{
$files_to_zcat .= " $file_to_zcat" if( -e $file_to_zcat );
}
signature.asc
Description: Digital signature
Bug#710487: My recent bpo-uploads not appearing in my qa page
* Nicolas Dandrimont [2013-10-25 14:48:27 +0200]:
> * Gerfried Fuchs [2013-10-25 14:24:41 +0200]:
>
> > I wouldn't move the definition my "my $bpo_url" from the other URL
> > definitions. Reason being, the special casing for squeeze-backports
> > will eventually fade and can get removed, and the URL definitions should
> > stick together. There's a reason why they are next to each other right
> > now. :)
> >
> > Maybe also put my $archive next to it and put an additional comment
> > that the special casing can get removed after squeeze gets archived.
>
> That totally makes sense. Please find attached the v2 of this patch.
And a v3 that actually works :-/ *whistles innocently*.
Cheers,
--
Nicolas Dandrimont
BOFH excuse #65:
system needs to be rebooted
Index: extract_incoming.pl
===
--- extract_incoming.pl (révision 3079)
+++ extract_incoming.pl (copie de travail)
@@ -65,7 +65,8 @@
my $delayed_summary = "http://people.debian.org/~myon/delayed/delayed-summary";;
my $delayed_http = "http://people.debian.org/~djpig/delayed/";;
my $queue_summary = "http://ftp-master.debian.org/new.822";;
-my $bpo_url = "http://backports.debian.org/debian-backports";;
+my $bpo_archive = "ftp.debian.org";
+my $bpo_url = "http://ftp.debian.org/debian";;
# global variables
my %db;
@@ -239,8 +240,17 @@
next if ($distkey =~ /^(unstable|testing)/);
my $dist = $active_dists{$distkey} . "-backports";
my $codename = $distkey eq "stable" ? "bpo" : "$distkey-bpo";
+
+# Special-casing for squeeze-bpo, to be removed when squeeze gets archived.
+my $cur_bpo_archive = $bpo_archive;
+my $cur_bpo_url = $bpo_url;
+if ($dist eq "squeeze-backports") {
+$cur_bpo_archive = "backports.org";
+$cur_bpo_url = "http://backports.debian.org/debian-backports";;
+}
+
my $files_to_zcat = '';
-foreach my $file_to_zcat ( glob "/srv/qa.debian.org/data/ftp/backports.org/dists/$dist*/{main,contrib,non-free}/source/Sources.gz" )
+foreach my $file_to_zcat ( glob "/srv/qa.debian.org/data/ftp/$cur_bpo_archive/dists/$dist*/{main,contrib,non-free}/source/Sources.gz" )
{
$files_to_zcat .= " $file_to_zcat" if( -e $file_to_zcat );
}
@@ -260,7 +270,7 @@
if( not defined $db{"$codename:$package"}
or redefined_version_compare( $db{"$codename:$package"}, $version ) < 0 );
$db{"$codename-title:$package"} = "$dist";
- $db{"$codename-url:$package"} = "$bpo_url/$directory/";
+ $db{"$codename-url:$package"} = "$cur_bpo_url/$directory/";
$backports{lc $maintainer}->{$package} = 1;
if ($uploaders) {
chomp $uploaders;
signature.asc
Description: Digital signature
Bug#727759: ITP: websocket-client -- WebSocket client library for python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: websocket-client Version : 0.12.0 Upstream Author : liris * URL : https://github.com/liris/websocket-client * License : LGPL-2.1+ Programming Lang: Python Description : WebSocket client library for python websocket-client provides a low-level, synchronous API providing WebSocket client functionality to Python programs. It conforms to the WebSocket specification as standardized by the IETF in RFC 6455. . WebSocket is a protocol providing full-duplex communication channels over TCP, mostly used in Web browsers. This module is a test dependency for moksha.hub. It will be packaged under the DPMT umbrella, and the binary package will be called python-websocket as per the Debian Python Policy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734758: Unable to start pristine containers
Package: docker.io Version: 0.6.7+dfsg1-2 Severity: grave Hello maintainer, Thanks a lot for the docker.io package. However, I can't seem to start a container. Steps to reproduce: 8< # docker.io pull debian [...] [successful] # docker.io run -i -t debian /bin/bash 2014/01/09 17:46:17 Error: create: Could not locate dockerinit: This usually means docker was built incorrectly. See http://docs.docker.io/en/latest/contributing/devenvironment for official build instructions. 8< I suppose that docker.io tries to look for dockerinit in the wrong place. Thanks a bunch! Nicolas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages docker.io depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.14 ii iptables 1.4.21-1 ii libc62.17-97 ii libsqlite3-0 3.8.2-1 ii lxc 0.9.0~alpha3-2+deb8u1 Versions of packages docker.io recommends: ii ca-certificates 20130906 docker.io suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734952: ITP: cloud-sptheme -- Cloud Sphinx theme and related extensions
Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont
* Package name: cloud-sptheme
Version : 1.6
Upstream Author : Eli Collins
* URL : http://pythonhosted.org/cloud_sptheme/
* License : BSD
Programming Lang: Python
Description : Cloud Sphinx theme and related extensions
cloud_sptheme contains a Sphinx theme named "Cloud", and some related
Sphinx extensions. Cloud and its extensions are primarily oriented
towards generating html documentation for Python libraries. It provides
numerous small enhancements to make the html documentation more
interactive, and improve the layout on mobile devices.
.
In addition to the Cloud theme, this package provides a few extra Sphinx
extensions which may be useful when documenting Python projects; and
should be theme-agnostic:
.
cloud_sptheme.ext.autodoc_sections
Patches the sphinx.ext.autodoc to handle RST section headers inside
docstrings.
cloud_sptheme.ext.issue_tracker
Adds a special :issue: role for quickly linking to your project's
issue tracker.
cloud_sptheme.ext.escaped_samp_literals
Patches Sphinx to permit escaped {} characters within a :samp: role.
cloud_sptheme.ext.table_styling
Enhances .. table directive to support per-column text alignment and
other layout features.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library
* Bas Wijnen [2013-11-02 14:22:02 -0400]: > Package: wnpp > Severity: wishlist > Owner: Bas Wijnen > > * Package name: libpolyclipping > Version : 6.0.0 > * URL : http://sourceforge.net/projects/polyclipping Hi Bas, Does this have anything to do with Slic3r packaging? While debugging an issue with Slic3r on 32-bit archs, I tried upgrading to clipper 6.0.0 and Slic3r's test suite was broken. However, upstream intends to move to clipper 6.0.0 just after its next release, so we might want to wait it out a bit. Cheers, -- Nicolas Dandrimont Avoid the Gates of Hell. Use Linux (Unknown source) signature.asc Description: Digital signature
Bug#728670: ITP: libwx-glcanvas-perl -- Perl interface to wxWidgets' OpenGL canvas
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: libwx-glcanvas-perl Version : 0.09 Upstream Author : Mattia Barbon * URL : https://metacpan.org/release/Wx-GLCanvas/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl interface to wxWidgets' OpenGL canvas Wx::GLCanvas is an extension module allowing the integration of an OpenGL Canvas in Perl programs using the wxWidgets toolkit. It does so by wrapping the wxWidgets wxGLCanvas class. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library
* Bas Wijnen [2013-11-04 18:47:52 +0100]: > Hi, > > On Sun, Nov 03, 2013 at 11:19:44PM +0100, Nicolas Dandrimont wrote: > > Does this have anything to do with Slic3r packaging? > > No, this is a prerequisite for the Cura engine. I thought Slic3r used a > different library, but appearantly I was wrong? In that case I will need to > have a look at the perl package, because I suppose they have the same source > (I was planning to ignore the perl part and only package the c++ source from > upstream; it contains implementations in many other languages as well). > > I can't see it in the repository though; is it already in there? There is no Perl library per se. Slic3r uses the C++ libpolyclipping via an XS++ wrapper (i.e. via a C++ Perl module). > > While debugging an issue with Slic3r on 32-bit archs, I tried upgrading to > > clipper 6.0.0 and Slic3r's test suite was broken. > > I have a 6.0.0 package just about ready to upload now; it might still take a > while before I do, though, because I added a pkgconfig file and upstream said > he wanted to include it, so I'll probably let that happen first. > > > However, upstream intends to move to clipper 6.0.0 just after its next > > release, so we might want to wait it out a bit. > > Good idea, I think. When we need it, we can just add a perl binary package > from my source package (some help with packaging would be welcome; I don't > know any perl). Slic3r should be able to dynamically link to the C library, so your package should be fine. I'll worry about the de-embedding side when libpolyclipping is available. Thanks, -- Nicolas Dandrimont BOFH excuse #443: Zombie processes detected, machine is haunted. signature.asc Description: Digital signature
Bug#689636: status?
* Bdale Garbee [2014-06-16 08:36:50 -0600]: > What is the status of this ITP? It looks like it has been more than a year > since the last "meaningful update" here, and still no slic3r in Debian? Hi Bdale, Chow Loong Jin has taken over the Slic3r packaging work under the umbrella of the 3D printing team. It just got REJECTed (nothing blocking, just some missing info in d/copyright). http://lists.alioth.debian.org/pipermail/3dprinter-general/Week-of-Mon-20140616/000139.html It's happening :) Cheers, -- Nicolas Dandrimont BOFH excuse #87: Password is too complex to decrypt signature.asc Description: Digital signature
Bug#752895: fedmsg init scripts are broken
Package: fedmsg Version: 0.8.0-1 Severity: serious The fedmsg init scripts do not launch the fedmsg utilities. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fedmsg depends on: ii python 2.7.6-2 ii python-fedmsg 0.8.0-1 pn python:any fedmsg recommends no packages. fedmsg suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742952: ITP: datanommer -- a storage consumer for the fedmsg bus
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: datanommer Version : 0.3.0 Upstream Author : Ralph Bean and others * URL : https://github.com/fedora-infra/datanommer * License : GPLv3+ Programming Lang: Python Description : a storage consumer for the fedmsg bus fedmsg (Fedora Messaging) is a Python package and API used within the Fedora infrastructure to send and receive messages to and from applications in order to allow for asynchronous processes. . datanommer is a fedmsg consumer that stores all the messages received on a fedmsg bus inside a database. It also contains some crude tools to query that database. Upstream has split the package in four independently released components: datanommer (namespace package), datanommer.commands (command line utilities), datanommer.consumer (the fedmsg consumer) and datanommer.models (SQLAlchemy models). They will be packaged separately. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743132: ITP: python-fedora -- Python modules for interacting with Fedora Services
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: python-fedora Version : 0.3.33 Upstream Author : Toshio Kuratomi and others * URL : https://fedorahosted.org/python-fedora/ * License : GPL-2+ and/or LGPL-2.1+ Programming Lang: Python Description : Python modules for interacting with Fedora Services The python-fedora module provides a Python API for connecting to web services provided by the fedora infrastructure. . Specifically, this package provides clients for the Fedora Account System, for the Fedora Package Database, for the Fedora Build System (bodhi), and for the Fedora wiki, as well as a more generic client for the other Fedora web services. This is a dependency of a test dependency (fedmsg-meta-fedora-infrastructure) for the datanommer package. Upstream provides, in the same tarball, modules to build clients and servers for the fedora infrastructure. The Debian package will only contain the client parts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744726: websocket-client should be repacked
Control: tags -1 + fixed-upstream pending * Leo Iannacone [2014-04-14 00:20:53 +0200]: > Dear Maintainer, > > your package seems to be packaged over pip. > > You should consider to repack it according with real > upstream source. Hi, It's a best practice to use whatever upstream provides as a release, and to avoid gratuitous repackagings. AFAICS, the new upstream release contains most of the stuff that was missing previously, I'll close that bug when I'll have uploaded the new version. > Moreover binary package python-websocket should be > renamed to python-websocket-client according with > source name. No. The Debian Python policy (section 2.2, "Module Package Names")[1] states that binary packages must be named after the importable module packaged within. The import statement is "import websocket", therefore the binary package name is right. I chose the source package name to match the upstream name. [1] https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names Thanks for your report, -- Nicolas Dandrimont BOFH excuse #13: we're waiting for [the phone company] to fix that line signature.asc Description: Digital signature
Bug#741606: [Python-modules-team] Bug#741606: Test suite missing and not run during the package build
Control: tags -1 + fixed-upstream pending * Robie Basak [2014-03-14 13:09:56 +]: > I'm doing some QA on this package in preparation for main inclusion in > Ubuntu. I found that upstream has a test suite, but does not ship it in > the PyPI tarball, and thus it is not being run as part of the package > build. It would be nice if we could do this. I've filed a bug upstream > to have it included, and I'd like this bug to track that the tests are > being not being run in Debian. > > In Ubuntu I may end up cherry-picking the entire test suite as a patch > and running it to fulfill our requirements, but I presume it would be > better for Debian to fix this when upstream can ship the test suite > directly. * Robie Basak [2014-03-17 17:18:40 +]: > Note that I also had an issue with some upstream tests requiring an > Internet connection. I filed > https://github.com/liris/websocket-client/pull/66 with a workaround I > applied to Ubuntu and to track this. Hi, First of all, thanks for your report, and sorry I spent so much time getting back to you. I see that upstream has fixed both issues and released a tarball containing the fixes. I'll update the package ASAP. Thanks for your work with upstream on those issues! Cheers, -- Nicolas Dandrimont BOFH excuse #387: Your computer's union contract is set to expire at midnight. signature.asc Description: Digital signature
Bug#747481: ITP: backports.ssl-match-hostname -- Backport of the Python 3.2 SSL hostname checking function
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: backports.ssl-match-hostname Version : 3.4.0.2 Upstream Author : Brandon Craig Rhodes * URL : https://bitbucket.org/brandon/backports.ssl_match_hostname * License : Python Programming Lang: Python Description : Backport of the Python 3.2 SSL hostname checking function The Secure Sockets layer is only actually secure if you check the hostname in the certificate returned by the server to which you are connecting, and verify that it matches to hostname that you are trying to reach. . But the matching logic, defined in RFC2818, can be a bit tricky to implement on your own. So the ssl package in the Standard Library of Python 3.2 and greater now includes a match_hostname() function for performing this check instead of requiring every application to implement the check separately. . This package contains a backport of the ssl.match_hostname function for Python 2.4 and above. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747481: ITP: backports.ssl-match-hostname -- Backport of the Python 3.2 SSL hostname checking function
* Nicolas Dandrimont [2014-05-09 10:34:09 +0200]: > Package: wnpp > Severity: wishlist > Owner: Nicolas Dandrimont > > * Package name: backports.ssl-match-hostname > Version : 3.4.0.2 > Upstream Author : Brandon Craig Rhodes > * URL : https://bitbucket.org/brandon/backports.ssl_match_hostname > * License : Python > Programming Lang: Python > Description : Backport of the Python 3.2 SSL hostname checking function > > The Secure Sockets layer is only actually secure if you check the > hostname in the certificate returned by the server to which you are > connecting, and verify that it matches to hostname that you are trying > to reach. > . > But the matching logic, defined in RFC2818, can be a bit tricky to > implement on your own. So the ssl package in the Standard Library of > Python 3.2 and greater now includes a match_hostname() function for > performing this check instead of requiring every application to > implement the check separately. > . > This package contains a backport of the ssl.match_hostname function for > Python 2.4 and above. On IRC, Jakub kindly pointed me at #626539 and its resolution. As a recent update of a package I maintain (websocket-client) actually needs this backport, and I'll need to use it on wheezy (and therefore have to backport the backport), I'll go ahead and package that anyway. Thanks, -- Nicolas Dandrimont Microsoft is not the answer. Microsoft is the question. NO (or Linux) is the answer. (Taken from a .signature from someone from the UK, source unknown) signature.asc Description: Digital signature
Bug#684418: node-semver: nodejs interpreter location fix
Control: tags -1 + patch Hello, You will find attached a "git am"-able patch for your git repository fixing #684418. I don't intend to NMU as nodejs will likely not be part of wheezy, so there is time. (I did the patch so I could install and use npm). Have a nice day, -- Nicolas Dandrimont From ff8a54b996123f39b98621691d04629e42668e2b Mon Sep 17 00:00:00 2001 From: Nicolas Dandrimont Date: Sun, 19 Aug 2012 19:38:28 +0200 Subject: [PATCH] Add a patch to change the nodejs interpreter path --- debian/changelog |4 debian/patches/1002_change_nodejs_interpreter_path.patch | 14 ++ debian/patches/series|1 + 3 files changed, 19 insertions(+) create mode 100644 debian/patches/1002_change_nodejs_interpreter_path.patch diff --git a/debian/changelog b/debian/changelog index 99cdcce..6d87750 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,7 +1,11 @@ node-semver (1.0.13-2) UNRELEASED; urgency=low + [ Jérémy Lal ] * Fix watch file. + [ Nicolas Dandrimont ] + * Change path to nodejs interpreter (Closes: #684418) + -- Jérémy Lal Tue, 20 Mar 2012 00:57:22 +0100 node-semver (1.0.13-1) unstable; urgency=low diff --git a/debian/patches/1002_change_nodejs_interpreter_path.patch b/debian/patches/1002_change_nodejs_interpreter_path.patch new file mode 100644 index 000..ebc4e3a --- /dev/null +++ b/debian/patches/1002_change_nodejs_interpreter_path.patch @@ -0,0 +1,14 @@ +Description: Change the path of the node interpreter +Author: Nicolas Dandrimont +Bug-Debian: http://bugs.debian.org/684418 + +--- + +--- node-semver-1.0.13.orig/bin/semver node-semver-1.0.13/bin/semver +@@ -1,4 +1,4 @@ +-#!/usr/bin/env node ++#!/usr/bin/env nodejs + // Standalone semver comparison program. + // Exits successfully and prints matching version(s) if + // any supplied version is valid and passes all tests. diff --git a/debian/patches/series b/debian/patches/series index cbe9e7c..19c241e 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1 +1,2 @@ 1001_require_semver.patch +1002_change_nodejs_interpreter_path.patch -- 1.7.10.4 pgpmFpX2C9eow.pgp Description: PGP signature
Bug#613210: Status of ITP: replicatorg ?
Le 16/01/2012 à 05:22, Jeremy Bicha écrivit : > Hi, I was curious how the work was coming on getting replicatorg into > Debian. I'm a bit curious as to why bug 613297 is a blocker; I didn't > think replicatorg used twitter at all. Hello Jeremy, and thanks for your interest in replicatorg packaging, In replicatorg, at least until version 24, there was a "twitter bot" plugin which could be used for the machine to tweet what it has printed... I'm not sure if it's still available as I haven't followed ReplicatorG development lately. My latest gut feeling was to patch it out, seeing the problems with the twitter module. > If you do decide not to continue working on this, could you at least > post what you've done so far? The only problem I see for packaging replicatorg and see it accepted in Debian is the number of "embedded" copies of skeinforge (I already expunged avrdude without a hiccup, and the java libraries are available). I intended for the replicatorg source package to build a binary package for each version of skeinforge embedded, each of them providing a common "skeinforge" virtual package on which the "replicatorg" binary package would depend. I've been swamped by work lately, and didn't have time to use a MakerBot since september (yay PhD). Fortunately, my workload is tapering off and I'd be glad to have someone co-maintain the package! I'll clean up what I have right now to push it to collab-maint so you can take a look. (Oh, yeah, that'll have to wait for alioth to come back up too :) I'll ping you when it's ready) Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613210: Status of ITP: replicatorg ?
Le 17/01/2012 à 13:28, Nicolas Dandrimont
écrivit :
> Le 16/01/2012 à 05:22, Jeremy Bicha écrivit :
> > Hi, I was curious how the work was coming on getting replicatorg into
> > Debian. I'm a bit curious as to why bug 613297 is a blocker; I didn't
> > think replicatorg used twitter at all.
Hello,
So here is the current status of things:
git+ssh://git.debian.org/git/collab-maint/replicatorg.git
http://anonscm.debian.org/gitweb/?p=collab-maint/replicatorg.git;a=summary
I had some more free time than I expected, so I spent some time updating
the packaging for the 0029r2 upstream release. The packages work, at
least as far as I can test without a bot at hand.
I split the binary packages for replicatorg and
skeinforge-{35,40,44}. The last thing that needs to be done is updating
the debian/copyright information (actually, to put some information in
there), which I should be able to do this evening.
Some of the patches could use some DEP-3 tagging and forwarding upstream
(only 0006-Make-the-crash-check-more-robust.patch seems useful upstream,
the other ones are for DFSG-freeness).
Then I intend to put the package up for review at mentors.debian.net and
hopefully get it sponsored into the archive.
If you'd like to help, just let me know, we can work things out on IRC
(I'm available as olasd on OFTC and Freenode) or by email.
Cheers,
--
Nicolas Dandrimont
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613297: Twitter4J is not DFSG-free: unblock replicatorg, drop the ITP
package wnpp unblock 613210 by 613297 retitle 613297 RFP: twitter4j -- A Java library for the Twitter API noowner 613297 kthxbye Hi, As Twitter4J seems to be non-dfsg-free, and ReplicatorG doesn't really need it, I'm dropping the ITP. Thanks to Martin Quinson for his work on the packaging, which is still available in the pkg-java git. Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#657047: Is this FTBFS reproducible on hplip/3.12.2-1?
Hi, I came across this bug during the Paris BSP, and I could reproduce it in hplip/3.11.12-2. In the meantime, the maintainer made an upload of a new upstream release (hplip/3.12.2-1), and I can't reproduce the failure anymore. Would you care to check if you can reproduce the build failure? Thanks, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#657047: Is this FTBFS reproducible on hplip/3.12.2-1?
tags 657047 + patch thanks Le 18/02/2012 à 19:06, Ronny Standtke écrivit : > > I came across this bug during the Paris BSP, and I could reproduce it in > > hplip/3.11.12-2. In the meantime, the maintainer made an upload of a new > > upstream release (hplip/3.12.2-1), and I can't reproduce the failure > > anymore. > > > > Would you care to check if you can reproduce the build failure? > > I just tried backporting hplip-3.12.2-1 to squeeze and the bug is > still there when trying to build the package within a clean pbuilder > chroot. The attached patch should fix the build issue. The logic is : if readlink -f fails, then the link is absolute and the file is to be found in debian/tmp. This logic fixed the issue in the previous version of the package. Please test the patch and report back. Thanks, -- Nicolas Dandrimont diff -u hplip-3.12.2/debian/rules hplip-3.12.2/debian/rules --- hplip-3.12.2/debian/rules +++ hplip-3.12.2/debian/rules @@ -268,8 +268,12 @@ ln -s /usr/share/hplip/hpssd.py ./debian/tmp/usr/sbin/hpssd # Correct Python interpreter path in all executables - for file in ./debian/tmp/usr/bin/* ./debian/tmp/usr/sbin/* ./debian/tmp/usr/lib/cups/*/*; do \ - perl -p -i -e 's:^\s*\#\!/usr/bin/env\s+python.*:#!/usr/bin/python:' `readlink -f $$file`; \ + set -e; for file in ./debian/tmp/usr/bin/* ./debian/tmp/usr/sbin/* ./debian/tmp/usr/lib/cups/*/*; do \ + linkedfile=`readlink -f $$file || true`; \ + if test -z $$linkedfile; then \ + linkedfile=$(CURDIR)/debian/tmp/`readlink $$file`; \ + fi; \ + perl -p -i -e 's:^\s*\#\!/usr/bin/env\s+python.*:#!/usr/bin/python:' $$linkedfile; \ done # Remove all *.pyc files, they do not need to be shipped with the diff -u hplip-3.12.2/debian/changelog hplip-3.12.2/debian/changelog --- hplip-3.12.2/debian/changelog +++ hplip-3.12.2/debian/changelog @@ -1,3 +1,10 @@ +hplip (3.12.2-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix FTBFS in pbuilder (Closes: #657047) + + -- Nicolas Dandrimont Sat, 18 Feb 2012 19:40:06 +0100 + hplip (3.12.2-1) unstable; urgency=low * New Upstream Release
Bug#655970: Bug #655970: wrong dependencies wrt the initscript?
retitle 655970 clvm dependency on cman is not tight enough for the initscript thanks Hi, I came across this bug during the Paris BSP, and I can't provide a patch without having your opinion first. It seems that the clvm init script depends unconditionnally on the cman service and on cman-provided binaries. Unfortunately clvm depends on "corosync | cman", and corosync doesn't provide either the service nor the binary. I see a few possible ways out: either tightening the dependency of the package on cman, loosening the init script dependency, or making the init script installation conditional on having cman. What do you think? Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631212: Patch not complete, python-cloudservers is broken in squeeze in a different way
clone 631212 -1 retitle -1 python-cloudservers: breaks with the python2.7-provided argparse # The patch provided by Carl only fixes the issue in wheezy/sid tags -1 wheezy sid patch tags 631212 squeeze thanks Hello Carl, dear maintainer, Unfortunately python-cloudservers is broken in squeeze and in wheezy/sid in two different ways: - In squeeze, an unconditional dependency on python-simplejson is needed for the python2.5 module to work. - In wheezy/sid, the simplejson dependency is useless (as it is provided by python2.6 and 2.7). But cloudservers now breaks with the python2.7-provided argparse module, which doesn't register itself in the pkg-resources repository. I think your patch fixes the second issue, but of course it doesn't fix the package in squeeze which should be fixed separately, hence the bug cloning. Furthermore, I think there could be a cleaner option to remove the "argparse" requirement in pkg-resources, and I think this was done in the past for simplejson, when it became provided by python2.6. Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#680505: desktop-base: Text has too low contrast with new Grub background
Hi, Le 06/07/2012 à 16:48, Paul Tagliamonte écrivit : > > > > > Also image brightness varies in different part of the image. > > > > > Consider making image use more homogenous brightness when text is > > > > > printed > > > > > over it and if using light colour background make text colour darker. > > > > > > > > This is the style the author of the theme has gone with. I'm sure we can > > > > find a color that works without destorying his vision for the work. > > > > > > I'm concerned about this because I wouldn't want to see the theme > > > changed. I hope higher contrast can be achieved for those who wish it by > > > simply changing the text color. > > > > I'll see what color can be used. If no one is suitable, I may render a > > darker > > background for grub. > > Let's get s'more opinions. I didn't really have a problem with it, and I > didn't notice until the reporter pointed it out, so let's get s'more > opionons before we go and do that :) I agree the text to background contrast is too low, and I have a hard time seeing the grub countdown. > > > > > > It's interesting that you notice it, too. I wonder if the type of > > > display (CRT vs LCD or even type of LCD) has something to do with it. > > > Looks gorgeous on all the LCDs here. I have found the contrast to be too low on both the screens I saw it on: my Thinkpad x61s (laptop, 1024x768), and my desktop (it's a 24 inch iiyama LCD screen, and I'm not quite certain what is the resolution in early boot. It's certainly not the native 1920x1080 though). Thanks for looking into this issue! Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658584: ITP: zed -- abstract engine for text edition in OCaml
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: zed Version : 1.1 Upstream Author : Jérémie Dimino * URL : http://forge.ocamlcore.org/projects/zed/ * License : MIT Programming Lang: OCaml Description : abstract engine for text edition in OCaml Zed is an abstract engine for text edition. It can be used to write text editors, edition widgets, readlines, ... . Zed uses Camomile to fully support the Unicode specification, and implements an UTF-8 encoded string type with validation, and a rope datastructure to achieve efficient operations on large Unicode buffers. Zed also features a regular expression search on ropes. . To support efficient text edition capabilities, Zed provides macro recording and cursor management facilities. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658596: ITP: lambda-term -- terminal manipulation library for OCaml
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: lambda-term Version : 1.1 Upstream Author : Jérémie Dimino * URL : http://forge.ocamlcore.org/projects/lambda-term/ * License : MIT Programming Lang: OCaml Description : terminal manipulation library for OCaml Lambda-term is a cross-platform library for manipulating the terminal. It provides an abstraction for keys, mouse events, colors, as well as a set of widgets to write curses-like applications. . The main objective of lambda-term is to provide a higher level functional interface to terminal manipulation than, for example, ncurses, by providing a native OCaml interface instead of bindings to a C library. . Lambda-term integrates with zed to provide text edition facilities in console applications, and helps with encoding management, by providing a high-level interface to iconv. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673946: ITA: hellanzb -- Newzbin (nzb) & BinNews (bns) files downloader and post-processor
Le 22/07/2012 à 16:13, Bart Martens écrivit : > Hi Nicolas, > > How is progress on this ITA ? Hello Bart, The package has been imported into the PAPT SVN[1], and updated to latest packaging standards. [1] http://anonscm.debian.org/viewvc/python-apps/packages/hellanzb/ I have been waiting for feedback on one of the outstanding RC bugs[2], to no avail. As the bug is quite old, does not really make sense to me, and contains virtually no information, I'm tempted to just close it. [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616569 When this issue is cleared, the package should be ready for upload. I might subsequently upgrade to a current git snapshot. The upstream website[3] is (more or less) dead, and the original author has collected patches to fix bugs on github[4], in "maintainance mode". [3] http://www.hellanzb.com [4] https://github.com/pjenvey/hellanzb All in all, seeing the very low upstream activity (no commits in years) and considering the available alternatives (e.g. sabnzbd) it might even be better to consider removing the package altogether. The package won't be part of wheezy, so we have some time to weigh the different options anyway. Thanks for your interest, -- Nicolas Dandrimont pgpKYSHZ5NtAC.pgp Description: PGP signature
Bug#702298: ITP: fabtools -- tools for writing awesome Fabric files
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont Package name: fabtools Version : 0.12.0 Upstream Author : Ronan Amicel URL : https://github.com/ronnix/fabtools http://fabtools.readthedocs.org/ License : BSD 2-clause Programming Lang: Python Description : common utilities for writing Fabric files fabtools includes useful functions to help people write Fabric files. For instance, through its API, it allows to manage system users, packages, databases, ... fabtools provides a number of low-level actions, as well as a higher level interface named fabtools.require. This higher-level interface, inspired by configuration management tools such as Chef or Puppet, is declarative and idempotent. (comments welcome on the long description, which looks like it needs some expanding) According to the Python policy, the binary package will be called python-fabtools. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613210: Assistance
* 4 mars 2013 23:56 CET, Matt Joyce : > Willing to help package this. > > Does anyone have any updated work on this I can start pushing on this? > > I was going to just do a PPA, but if you guys have some existing work > I'd love to help push you over the finish line. Hi, Everything I have done so far is available in collab-maint git. The packages were in working shape and have been used in my former robotics club to drive a makerbot cupcake. However, I think the licensing needs to be clarified (a lot) before replicatorg can enter the archive. At least it did at the time of 0029r2: there are bits from processing, arduino, and the oh-so-nice pile of python for the N bundled skeinforge versions, most of those not having individual licensing info. It's a bit scary. I don't have easy access to the makerbot hardware anymore, so my motivation to chase down those licensing issues quite low. Furthermore, for my reprap at home, I'm using printrun and Slic3r and didn't feel the need to use ReplicatorG. I'd be glad to guide you through getting the packaging up to par for the latest version, and track down those pesky licenses to try and release the package to Debian. Hope this helps, -- Nicolas Dandrimont pgp83PK_pIRi8.pgp Description: PGP signature
Bug#692410: license information for Math::Libm
* Florian Schlichting [2012-11-05 23:09:48 +0100]: > Hi, > > While packaging your module Math::Libm for Debian, I noticed that it > doesn't seem to mention any licensing information, not even "same as > Perl" or anything like that. License information is needed in order for > us (and others) to be able to legally distribute the software. Could you > please give us (replying to this email is fine) the license that > Math::Libm is distributed under? > > This is more than just a Debian issue. I'm not a lawyer, but it's my > understanding that both copyright and licensing information is vital for > the continued success of open source software. Copyright is what allows > you to assert a license, and a license is what gives others the rights > to use and re-distribute your software. A great article discussing some > of this is "What is Copyleft?" by Richard Stallman: > http://www.gnu.org/copyleft/ > > Thanks for releasing your work to the CPAN. I apologize in advance for > the noise, as I understand that the last thing most authors want to deal > with is legal administrivia like this. I do hope, however, that you > could (in your continued generosity) help us with this request. Please > also consider adding these statements to your code/package README, since > we must distribute some evidence of copyright information if it is not > in the source package itself. Hello Florian, While investigating the status of Slic3r's dependencies (thanks a lot for your work so far, BTW), I noticed the Math::Libm issue. Thankfully, Fedora has had the same issue, and has gotten clarification from Daniel Lewart before going ahead with the packaging: https://raw.github.com/hroncok/RPMAdditionalSources/master/Math-Libm-license.txt I'm not sure how to proceed to integrate that info in the Debian package though. I don't see a new release coming up with a LICENSE file, ever (it was uploaded to CPAN only once, in 2000). What do you think? Cheers, -- Nicolas Dandrimont signature.asc Description: Digital signature
Bug#709907: ITP: libmath-convexhull-monotonechain-perl -- Perl module to calculate a convex hull using Andrew's monotone chain algorithm
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: libmath-convexhull-monotonechain-perl Version : 0.01 Upstream Author : Steffen Mueller, * URL : https://metacpan.org/release/Math-ConvexHull-MonotoneChain * License : GPL-1+ or Artistic (same as Perl) Programming Lang: Perl/C Description : Perl module to calculate a convex hull using Andrew's monotone chain algorithm This (XS) module optionally exports a single function convex_hull which calculates the convex hull of the input points and returns it. Andrew's monotone chain convex hull algorithm constructs the convex hull of a set of 2-dimensional points in O(n*log(n)) time. It does so by first sorting the points lexicographically (first by x-coordinate, and in case of a tie, by y-coordinate), and then constructing upper and lower hulls of the points in O(n) time. It should be somewhat faster than a plain Graham's scan (also O(n*log(n))) in practice since it avoids polar coordinates. This package is a dependency for Slic3r (ITP #689636) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572874: bcfg2: new upstream
* Sami Haahtinen [2010-03-08 13:03:54 +0200]:
> Hi,
>
> On Sun, 2010-03-07 at 12:09 +0100, Toni Mueller wrote:
> > bcfg2 has reached version 1.0.1 about six weeks ago. It would be nice if
> > the package could be updated.
>
> Thanks for the reminder, i'll try and work out an upload later this
> week.
Hi,
This reminded me of a bug I've been bitten by a little while back,
using a custom 1.0.1 package on a Squeeze box. It is caused by the
output of debsums, which has changed as of version 2.0.47. I just
reported it upstream.
[http://trac.mcs.anl.gov/projects/bcfg2/ticket/857]
You should consider backporting the fix (patch attached) if you
package 1.0.1, as debsums' output detection doesn't work right now.
Thanks,
--
Nicolas Dandrimont
BOFH excuse #154:
You can tune a file system, but you can't tune a fish (from most tunefs man
pages)
diff --git a/src/lib/Client/Tools/APT.py b/src/lib/Client/Tools/APT.py
index 9b7b6d7..ed686e4 100644
--- a/src/lib/Client/Tools/APT.py
+++ b/src/lib/Client/Tools/APT.py
@@ -64,9 +64,11 @@ class APT(Bcfg2.Client.Tools.Tool):
for item in output:
if "checksum mismatch" in item:
files.append(item.split()[-1])
+elif "changed file" in item:
+files.append(item.split()[3])
elif "can't open" in item:
files.append(item.split()[5])
-elif "is not installed" in item:
+elif "is not installed" in item or "missing file" in item:
self.logger.error("Package %s is not fully installed" \
% entry.get('name'))
else:
signature.asc
Description: Digital signature
Bug#630320: obus: FTBFS on several architectures: can't find Dynlink
clone 630320 -1
reassign -1 libfindlib-ocaml 1.2.6+debian-1
retitle -1 camlp4 depends on Dynlink on all architectures
severity -1 important
tag -1 patch
retitle 630320 FTBFS on ocaml native arches without native dynlink
tag 630320 pending
thanks
Hi,
Thanks for your report. There are indeed two separate issues, one for
armel, and one for the other architectures.
The armel issue is an obus issue: configure detects that armel is a native
architecture and therefore builds native files. However, as camlp4
depends on dynlink, and armel doesn't have native dynlink, it fails to
build. Forcing a non-native build on architectures without natdynlink
fixes the issue.
For the other arches, the problem is that camlp4 now unconditionnally
depends on Dynlink, whether the architecture have natdynlink or
not. This change (which I couldn't trace, but surely is an ocaml
upstream change) wasn't reflected in the METAS/META.camlp4 file, and
now camlp4.lib fails to link on non-natdynlink architectures.
To see the bug, e.g. on a mipsel qemu:
--8<--
nicolasd@debian:~$ ocaml
Objective Caml version 3.12.0
# #use "topfind";;
- : unit = ()
Findlib has been successfully loaded. Additional directives:
#require "package";; to load a package
#list;; to list the available packages
#camlp4o;;to load camlp4 (standard syntax)
#camlp4r;;to load camlp4 (revised syntax)
#predicates "p,q,...";; to set these predicates
Topfind.reset();; to force that packages will be reloaded
#thread;; to enable threads
- : unit = ()
# #camlp4o;;
/usr/lib/ocaml/camlp4: added to search path
/usr/lib/ocaml/camlp4/camlp4o.cma: loaded
Error: Reference to undefined global `Dynlink'
--8<--
Attached is a patch for findlib, I didn't commit this as I'm not certain
this is the way to go. But anyway after changing the META.camlp4 file
the obus FTBFS goes away.
Thanks,
--
Nicolas Dandrimont
From: Nicolas Dandrimont
Date: Tue, 14 Jun 2011 15:21:31 +0200
Subject: Camlp4 depends on Dynlink on every architecture
---
site-lib-src/camlp4.310/META.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/site-lib-src/camlp4.310/META.in b/site-lib-src/camlp4.310/META.in
index 637d848..a490ab1 100644
--- a/site-lib-src/camlp4.310/META.in
+++ b/site-lib-src/camlp4.310/META.in
@@ -6,7 +6,7 @@ dnl This file is input of the m4 macro processor.
`directory = "'camlp4_dir`"'
`# For the toploop:'
-`requires(byte,toploop) = "'camlp4_dynlink`"'
+`requires(byte,toploop) = "dynlink"'
`archive(byte,toploop,camlp4o) = "camlp4o.cma"'
`archive(byte,toploop,camlp4r) = "camlp4r.cma"'
@@ -16,7 +16,7 @@ dnl This file is input of the m4 macro processor.
`preprocessor = "'camlp4_cmd`"'
`package "lib" ('
-` requires = "camlp4 'camlp4_dynlink`"'
+` requires = "camlp4 dynlink"'
` version = "[distributed with Ocaml]"'
` description = "Camlp4 library"'
` archive(byte) = "camlp4lib.cma"'
--
pgpfDKJoAlTXA.pgp
Description: PGP signature
Bug#640032: Ships META.graphics without depending on its module files
tag 640032 + moreinfo thanks Le 01/09/2011 à 19:02, Romain Beauxis écrivit : > Package: libfindlib-ocaml > Version: 1.2.7+debian-1 > Severity: normal > > Hi! > > This package provides a META file for the graphics module. However, > graphics module files are shipped by the ocaml package, which is not a > dependency of libfindlib-ocaml. > > This leads to ocamlfind reporting graphics as installed while in fact > it is not and, thus, fuild failures.. Hi, This was bug #605695, closed in version 1.2.7+debian-1, and well, right now I can't seem to reproduce it. If I uninstall ocaml-base (which contains graphics.cma), `ocamlfind query graphics` reports "ocamlfind: Package `graphics' not found" What do you run to find out whether graphics is available? Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#463044: Intent to adopt and update the python-simpy debian package
Hi Antal, I'm contacting you as you're the current maintainer of the python-simpy package in Debian (listed with your address @puj.edu.co). The package is currently quite outdated, and there is a Debian bug report (http://bugs.debian.org/463044) open about that since 2008. As I'm a user of simpy, and a Debian enthusiast, I would be glad to take over and update this package. Would that be okay with you? Thanks a lot, -- Nicolas Dandrimont pgpzJMdWLhx1b.pgp Description: PGP signature
Bug#463044: [Antal A. Buss] Re: Intent to adopt and update the python-simpy debian package
--- Begin Message --- Hi Nicolas, I'm not a simpy user anymore, so please go ahead and thanks for helping Antal On Wed, Aug 24, 2011 at 5:13 PM, Nicolas Dandrimont wrote: > > Hi Antal, > > I'm contacting you as you're the current maintainer of the python-simpy > package in Debian (listed with your address @puj.edu.co). > > The package is currently quite outdated, and there is a Debian bug > report (http://bugs.debian.org/463044) open about that since 2008. As > I'm a user of simpy, and a Debian enthusiast, I would be glad to take > over and update this package. Would that be okay with you? > > Thanks a lot, > -- > Nicolas Dandrimont > --- End Message --- -- Nicolas Dandrimont
Bug#640032: More informations
Le 27/09/2011 à 15:58, Romain Beauxis écrivit : > Hi, > > If you look at the files installed by your libfindlib-ocaml package, > you have this one: > /usr/lib/ocaml/METAS/META.graphics Yes, I know libfindlib-ocaml installs META.graphics unconditionnally. > This files indicates to ocamlfind that graphics is available: > ocamlfind query graphics > > /usr/lib/ocaml > > Also, ocaml-base is not installed on my system. > > We have had this bug on many different systems and it was also > reported by many users. I'd, thus, return you the question: how can I > repeat your failure to reproduce?? Quoting the aforementioned META.graphics file, it contains the line """ exists_if = "graphics.cma" """ My understanding is that ocamlfind only reports graphics as installed if the file exists, which should only be the case when ocaml-base is installed. This is the behaviour I can notice on my system. Looking further, I tried installing the other packages containing a graphics.cma file (mingw32-ocaml and liquidsoap-plugin-graphics), but still failed to reproduce. Do you have some graphics.cma installed anywhere that could confuse ocamlfind? Thanks, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643440: Patches for -Werror=format-security issues in mailutils
tag 643440 + patch
kthxbye
Hi,
You'll find attached two patches that fix the mailutils FTBFS with the
hardening build flags:
The first patch, fix_FTBFS_with_format-security.diff fixes the actual
-Werror=format-security issues. A lot of those are GCC pedantry, but I
think some may be real issues (the writeline hunks, for instance).
The second patch, refresh_mh_fmtgram.diff refreshes mh/mh_fmtgram.c from
the updated mh/mh_fmtgram.y (changed in the previous patch).
The diff is quite noisy as the file was generated by upstream with an
older version of bison than that currently in sid.
Cheers,
--
Nicolas Dandrimont
Description: Fix FTBFS with -Werror=format-security
Author: Nicolas Dandrimont http://bugs.debian.org/643440
Last-Update: 2011-09-28
Index: mailutils-2.2+dfsg1/libproto/pop/pop3_sendline.c
===
--- mailutils-2.2+dfsg1.orig/libproto/pop/pop3_sendline.c 2011-09-28 12:03:00.0 +0200
+++ mailutils-2.2+dfsg1/libproto/pop/pop3_sendline.c 2011-09-28 12:04:41.0 +0200
@@ -112,7 +112,7 @@
{
if (line)
{
- int status = mu_pop3_writeline (pop3, line);
+ int status = mu_pop3_writeline (pop3, "%s", line);
if (status)
return status;
}
Index: mailutils-2.2+dfsg1/libproto/nntp/nntp_sendline.c
===
--- mailutils-2.2+dfsg1.orig/libproto/nntp/nntp_sendline.c 2011-09-28 12:03:00.0 +0200
+++ mailutils-2.2+dfsg1/libproto/nntp/nntp_sendline.c 2011-09-28 12:04:41.0 +0200
@@ -112,7 +112,7 @@
{
if (line)
{
- int status = mu_nntp_writeline (nntp, line);
+ int status = mu_nntp_writeline (nntp, "%s", line);
if (status)
return status;
}
Index: mailutils-2.2+dfsg1/mail/retain.c
===
--- mailutils-2.2+dfsg1.orig/mail/retain.c 2011-09-28 12:04:24.0 +0200
+++ mailutils-2.2+dfsg1/mail/retain.c 2011-09-28 12:04:41.0 +0200
@@ -33,7 +33,7 @@
if (argc == 1)
{
if (mu_list_is_empty (*list))
- fprintf (ofile, _(msg));
+ fprintf (ofile, "%s", _(msg));
else
util_slist_print (*list, 1);
return 0;
Index: mailutils-2.2+dfsg1/mail/unset.c
===
--- mailutils-2.2+dfsg1.orig/mail/unset.c 2011-09-28 12:04:24.0 +0200
+++ mailutils-2.2+dfsg1/mail/unset.c 2011-09-28 12:04:41.0 +0200
@@ -38,7 +38,7 @@
char *buf = xmalloc ((7+strlen (argv[i])) * sizeof (char));
strcpy (buf, "set no");
strcat (buf, argv[i]);
- if (!util_do_command (buf))
+ if (!util_do_command ("%s", buf))
status = 1;
free (buf);
}
Index: mailutils-2.2+dfsg1/mh/mh_fmtgram.y
===
--- mailutils-2.2+dfsg1.orig/mh/mh_fmtgram.y 2011-09-28 12:04:24.0 +0200
+++ mailutils-2.2+dfsg1/mh/mh_fmtgram.y 2011-09-28 12:04:41.0 +0200
@@ -207,7 +207,7 @@
else
{
yyerror (_("undefined function"));
- mu_error ($1);
+ mu_error ("%s", $1);
YYERROR;
}
}
Index: mailutils-2.2+dfsg1/mh/mhn.c
===
--- mailutils-2.2+dfsg1.orig/mh/mhn.c 2011-09-28 12:04:24.0 +0200
+++ mailutils-2.2+dfsg1/mh/mhn.c 2011-09-28 12:04:41.0 +0200
@@ -1644,7 +1644,7 @@
int rc;
asprintf (&p, _("File %s already exists. Rewrite"), name);
- rc = mh_getyn (p);
+ rc = mh_getyn ("%s", p);
free (p);
if (!rc)
{
Index: mailutils-2.2+dfsg1/imap4d/append.c
===
--- mailutils-2.2+dfsg1.orig/imap4d/append.c 2011-09-28 12:04:24.0 +0200
+++ mailutils-2.2+dfsg1/imap4d/append.c 2011-09-28 12:04:41.0 +0200
@@ -204,7 +204,7 @@
if (status == 0)
return util_finish (command, RESP_OK, "Completed");
- return util_finish (command, RESP_NO, err_text);
+ return util_finish (command, RESP_NO, "%s", err_text);
}
Index: mailutils-2.2+dfsg1/imap4d/status.c
===
--- mailutils-2.2+dfsg1.orig/imap4d/status.c 2011-09-28 12:04:24.0 +0200
+++ mailutils-2.2+dfsg1/imap4d/status.c 2011-09-28 12:04:41.0 +0200
@@ -148,7 +148,7 @@
if (count == 0)
return util_finish (command, RESP_BAD, "Too few args (empty list)");
else if (err_msg)
- return util_finish (command, RESP_BAD, err_msg);
+ return util_finish (command, RESP_BAD, "%s", err_msg);
return util_finish (command, RESP_OK, "Completed");
}
Index: mailutils-2.2+dfsg1/imap4d/delete.c
===
--- mailutils-2.2+dfsg1.orig/imap4d/delete.c 2011-09-28 12:04:24.00
Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers
* Bas Wijnen [2013-07-04 18:04:15 +0200]: On Thu, Jul 04, 2013 at 09:34:24AM +0200, Andrea Colangelo wrote: > > Hi Bas Wijnen, > > > > I'm interested in seeing this package uploaded into archive. A few months > > passed since this bug has been opened. How are things going? > > There were several perl modules required for making a Debian package. > I'm not confident that I can properly maintain those, so I asked the > Perl team. They have slowly added them. I'm not sure if all of them > are packaged now; I should check again. Hi, The dependencies for version 0.9.10b should be good to go in sid, thanks to the debian-perl team. I updated and/or packaged the last few modules that needed updating, and I had Slic3r run on my machine without using CPAN. Slic3r's git repo grew a few extra dependencies today (with a few branches getting merged into master), I'll take a look (it'll be easier if there's a preliminary package). I'd be glad to comaintain Slic3r if you need help. On a related note, I was thinking of putting a team together to join forces on the 3d-printing related packaging effort (probably by creating an alioth project, which would give us a central place to put our code repositories, and mailing lists). Would you be interested in creating such a structure? Cheers, -- Nicolas Dandrimont BOFH excuse #146: Communications satellite used by the military for star wars. signature.asc Description: Digital signature
Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers
* Bas Wijnen [2013-07-07 01:07:58 +0200]: > On Sat, Jul 06, 2013 at 11:48:08PM +0200, Nicolas Dandrimont wrote: [snip] > > On a related note, I was thinking of putting a team together to join > > forces on the 3d-printing related packaging effort (probably by > > creating an alioth project, which would give us a central place to put > > our code repositories, and mailing lists). Would you be interested in > > creating such a structure? > > Yes, that sounds very useful. I currenly have two packages which would > belong there: arduino-mighty-1284p, for supporting the melzi board, and > the new Cura (which will actually be two packages, -engine and -gui). > > I previously looked at Repsnapper, but someone else eventually packaged > it; it should be part of this as well, I think. Yeah. sfact is also packaged by someone else. I intend to take a look at printrun/pronterface soon too. > I've also written a print server and am in the process of writing new > firmware. Once done, they should be packaged as well, of course. Sounds great! > As for the structure, I'd prefer to use git for our repositories. Is > that ok with you? Git is perfectly fine with me. I'll take a look at the procedure to create a packaging project on Alioth. Don't block on me though, git makes for an easy relocation anyway ;) Cheers, -- Nicolas Dandrimont I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-) (Linus Torvalds) signature.asc Description: Digital signature
Bug#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers
* Bas Wijnen [2013-07-07 04:15:50 +0200]: > On Sat, Jul 06, 2013 at 11:48:08PM +0200, Nicolas Dandrimont wrote: > > On a related note, I was thinking of putting a team together to join forces > > on > > the 3d-printing related packaging effort (probably by creating an alioth > > project, which would give us a central place to put our code repositories, > > and > > mailing lists). Would you be interested in creating such a structure? > > I've just created an alioth project; if you give me your alioth login, > I'll add you as an administrator. Ah, well, signals crossed. My login is `dandrimont-guest'. Thanks, -- Nicolas Dandrimont BOFH excuse #58: high pressure system failure signature.asc Description: Digital signature
Bug#715404: ITP: snapper -- Linux filesystem snapshot management tool
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: snapper Version : 0.1.4 Upstream Author : Arvin Schnell * URL : http://snapper.io/ * License : GPL-2 Programming Lang: C++ Description : Linux filesystem snapshot management tool Snapper is a tool for Linux filesystem snapshot management. Apart from the obvious creation and deletion of snapshots, it can compare snapshots and revert differences between snapshots. In simple terms, this allows root and non-root users to view older versions of files and revert changes. . The features include: * Manually create snapshots * Automatically create snapshots, e.g. when using a package manager * Automatically create timeline of snapshots * Show and revert changes between snapshots * Works with btrfs, ext4 and thin-provisioned LVM volumes * Supports Access Control Lists and Extended Attributes * Automatic cleanup of old snapshots * Command line interface * D-Bus interface * PAM module to create snapshots during login and logout (libpam-snapper) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#712093: marionnet: bus address error on start and 3 popups
* Pierre M. [2013-06-14 16:53:14 +0200]: > Package: marionnet > Version: 0.90.6+bzr407-1 > Followup-For: Bug #712093 > > Hello, > > thank you for appreciating my feedback. > I did dpkg-query --listfiles marionnet > to locate /usr/sbin/marionnet-daemon > > then in a terminal I keyed /usr/sbin/marionnet-daemon > The result : > === > Welcome to marionnet > (snip) > === > Fatal error: exception Pervasives.Exit > > It seems I have an issue with marionnet-daemon too. > Hope this helps, happy Debianing Hi, Did you run the daemon as root? The daemon needs to run privileged, and allows users to create VMs and virtual switches. If it didn't start as root, could you please paste the full output? Thanks, -- Nicolas Dandrimont BOFH excuse #48: bad ether in the cables signature.asc Description: Digital signature
Bug#721423: NMU diff for version 0.68-1.2
tag 721423 + patch pending thanks Dear maintainer, Please find attached the diff for the NMU I will upload shortly to unstable. It simply disables the online tests. I'm 0-day uploading as it's a pretty simple patch, the maintainer has been inactive for months and we don't want to delay the Perl 5.18 transition too much. Thanks, -- Nicolas Dandrimont diff -Nru libnet-dns-perl-0.68/debian/changelog libnet-dns-perl-0.68/debian/changelog --- libnet-dns-perl-0.68/debian/changelog 2012-08-22 20:36:19.0 +0200 +++ libnet-dns-perl-0.68/debian/changelog 2013-09-04 20:09:41.0 +0200 @@ -1,3 +1,10 @@ +libnet-dns-perl (0.68-1.2) unstable; urgency=high + + * Non-maintainer upload. + * Disable online tests as buildds can be firewalled (Closes: #721423) + + -- Nicolas Dandrimont Wed, 04 Sep 2013 20:09:39 +0200 + libnet-dns-perl (0.68-1.1) unstable; urgency=low * Non-maintainer upload. diff -Nru libnet-dns-perl-0.68/debian/rules libnet-dns-perl-0.68/debian/rules --- libnet-dns-perl-0.68/debian/rules 2012-08-22 20:36:19.0 +0200 +++ libnet-dns-perl-0.68/debian/rules 2013-09-04 20:01:52.0 +0200 @@ -38,7 +38,7 @@ #$(MAKE) #/usr/bin/docbook-to-man debian/Net-DNS.sgml > Net-DNS.1 - $(PERL) Makefile.PL INSTALLDIRS=vendor + $(PERL) Makefile.PL INSTALLDIRS=vendor --noonline-tests # --online-tests --IPv6-tests # COMPRESS='gzip -9' signature.asc Description: Digital signature
Bug#718956: ITP: printrun -- 3D-printing host software
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: printrun Version : 20130711 Upstream Author : Kliment Yanev * URL : https://github.com/kliment/Printrun * License : GPLv3+ Programming Lang: Python Description : 3D-printing host software Printrun is a set of G-Code sending applications for 3D-printers. . It consists of printcore (a dumb G-Code sender), pronsole (a full-fledged command-line G-Code sender), pronterface (a G-Code sender with a graphical interface), and a collection of related scripts. . Combined with a slicing program, it allows the user to operate a 3D printer such as a RepRap from scratch. I'd be glad to hear feedback on the long description, as I'm a bit in a "bubble" (and I'm sure there's room for improvement). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695336: Bug#718956: ITP: printrun -- 3D-printing host software
forcemerge 695336 718956 owner 695336 ! thanks * Eugeniy Meshcheryakov [2013-08-07 10:58:34 +0200]: > 7 серп. 2013 09:45, "Nicolas Dandrimont" напис. > > > > [ duplicate printrun ITP ] > > Hi, > > There is already a wnpp bug here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695336 > Hi, Of course there is... merging. As the former owner of the ITP has "forfeited" it, I'll take it over, if you don't mind. I'm more than happy to take on comaintainers. We're in the process of boostrapping a 3d-printing related software team, and the package will be maintained there once the dust settles. Since the ITP, upstream has made a tarball release (more like a tag really). Printrun has also become a python module ready for use by other software if necessary. I'm in close contact with Guillaume Seguin, and there will be real tarball releases once The packaging will therefore be really different. I'll take a look at what can be reused from the previous attempt (at a glance, at least the manpages are salvagable). Cheers, -- Nicolas Dandrimont BOFH excuse #40: not enough memory, go get system upgrade signature.asc Description: Digital signature
Bug#719127: linux-image-3.10-2-amd64: kernel panic (fatal exception in interrupt) in Workqueue: events mei_timer [mei]
Package: src:linux Version: 3.10.5-1 Followup-For: Bug #719127 Hi, While at DebConf, I had a kernel panic in quite the same place three times, on a Thinkpad x230 laptop. I'm sure I had the panic while on battery power (the most recent one), not sure about AC. I rmmod'd the module so it shouldn't show up down there. Thanks in advance, Nicolas Dandrimont -- Package-specific info: ** Version: Linux version 3.10-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.5-1 (2013-08-07) ** Command line: BOOT_IMAGE=/vmlinuz-3.10-2-amd64 root=/dev/mapper/lvm-root ro quiet init=/bin/systemd ** Not tainted ** Kernel log: [ 20.019802] thinkpad_acpi: detected a 8-level brightness capable ThinkPad [ 20.019905] thinkpad_acpi: radio switch found; radios are enabled [ 20.020010] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver [ 20.020012] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [ 20.021484] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 20.021934] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 20.021992] thinkpad_acpi: Console audio control enabled, mode: monitor (read only) [ 20.023057] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14 [ 20.116745] platform microcode: firmware: agent aborted loading intel-ucode/06-3a-09 (not found?) [ 20.116792] microcode: CPU1 sig=0x306a9, pf=0x10, revision=0x13 [ 20.260625] [drm] Initialized drm 1.1.0 20060810 [ 20.383927] i915 :00:02.0: enabling device (0006 -> 0007) [ 20.384580] [drm] Memory usable by graphics device = 2048M [ 20.384583] checking generic (e000 41) vs hw (e000 1000) [ 20.384585] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver [ 20.384607] Console: switching to colour dummy device 80x25 [ 20.384688] i915 :00:02.0: setting latency timer to 64 [ 20.402869] i915 :00:02.0: irq 48 for MSI/MSI-X [ 20.402878] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 20.402880] [drm] Driver supports precise vblank timestamp query. [ 20.402931] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=mem [ 20.490320] iTCO_vendor_support: vendor-support=0 [ 20.490679] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.10 [ 20.490703] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) [ 20.490758] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 20.500915] platform microcode: firmware: agent aborted loading intel-ucode/06-3a-09 (not found?) [ 20.500958] microcode: CPU2 sig=0x306a9, pf=0x10, revision=0x13 [ 20.502560] platform microcode: firmware: agent aborted loading intel-ucode/06-3a-09 (not found?) [ 20.502593] microcode: CPU3 sig=0x306a9, pf=0x10, revision=0x13 [ 20.502936] platform microcode: firmware: agent aborted loading intel-ucode/06-3a-09 (not found?) [ 20.503000] microcode: Microcode Update Driver: v2.00 , Peter Oruba [ 20.519880] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [ 20.536700] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd002a3/0x940300/0x123800, board id: 1611, fw id: 1099905 [ 20.536708] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 [ 20.537119] fbcon: inteldrmfb (fb0) is primary device [ 20.574827] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input15 [ 21.438800] Console: switching to colour frame buffer device 170x48 [ 21.443638] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 21.443641] i915 :00:02.0: registered panic notifier [ 21.535112] acpi device:01: registered as cooling_device4 [ 21.535200] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 21.535263] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input16 [ 21.535553] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 21.830492] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [ 21.947305] cfg80211: World regulatory domain updated: [ 21.947310] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 21.947312] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 21.947314] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 21.947316] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [ 21.947318] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 21.947320] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [ 22.079474] device fsid eee6684b-e98e-4cda-b3f0-35f23dc16be5 devid 1 transid 151743 /dev/dm-2 [ 22.266610] device fsid eee6684b-e98e-4cda-b3f0-35
Bug#651849: ramond doesn't care about value of RAMONDCONFIG in /etc/default/ramond
# this bug doesn't impede the ipv6 release goal
tags = pending
kthxbye
Le 12/12/2011 à 16:49, Anders Jackson
écrivit :
> Package: ramond
> Version: 0.5-1
> Severity: normal
> Tags: ipv6
>
> Dear Maintainer, when I tried to configure ramond, I created a
> directory for config files and scripts (/etc/ramond/).
> To use the config file /etc/ramond/ramonf.config, I changed the value
> of RAMONDCONFIG in /etc/default/ramond according to the documentation
> there.
>
> But when I tried to start ramond, I didn't got any errors on the
> command line (used services and invoke-rc.d), except that status told
> me that ramond wasn't running:
>
> $ sudo service ramond status
> ramond is not running ... failed!
> $
>
> and this message in /var/log/syslog:
>
> Dec 12 14:55:33 my-computer ramond: Syntax error in configuration file
>
> When making a symbolic link from /etc/ramond/ramond.conf to
> /etc/ramond.conf, ramond started to work.
>
> When I look into /etc/init.d/ramond, I can't see that the script set
> DAEMON_ARGS to "-c $RAMONDCONF", which would have solved this problem.
>
> Hope this information is enough to fix this error when configure ramond.
Hi,
Thanks for your thorough report, and for your interest in ramond! It
seems that I indeed forgot to set DAEMON_ARGS to something meaningful
when I wrote the init script.
You'll find attached an updated init script. I'll try to get an updated
package uploaded soon.
Cheers,
--
Nicolas Dandrimont
#!/bin/sh
### BEGIN INIT INFO
# Provides: ramond
# Required-Start:$network $local_fs $remote_fs
# Required-Stop: $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Router Advertisement MONitoring Daemon
# Description: ramond is a daemon program monitoring IPv6
#router advertisement packets.
### END INIT INFO
# Author: Nicolas Dandrimont
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="IPv6 RA monitoring Daemon" # Introduce a short description here
NAME=ramond # Introduce the short server's name here
DAEMON=/usr/sbin/ramond # Introduce the server's location here
DAEMON_ARGS="" # Arguments to run the daemon with
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
[ "x$RAMONDCONFIG" = "x" ] && RAMONDCONFIG=/etc/ramond.conf
[ "x$DAEMON_ARGS" = "x" ] && DAEMON_ARGS="-c $RAMONDCONFIG"
#
# Function that starts the daemon/service
#
do_start()
{
if [ ! -r $RAMONDCONFIG ]; then
log_failure_msg "ramond config file $RAMONDCONFIG doesn't exist; set the right path to it in /etc/default/$NAME"
return 2
fi
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP)
Bug#675209: src:munin: Please lower debhelper compatibility level to 8 for easier backporting
Package: src:munin Version: 2.0~rc6-3 Severity: wishlist Dear munin maintainers, First of all, thanks a lot for your hard work on bringing munin 2.0 to wheezy, it's really appreciated! Could you please lower the debhelper compatibility level to 8 (as well as the debhelper dependency) as it would make it easier to backport the munin2 packages to squeeze (basically, all the build-deps are in squeeze except debhelper (>= 9)). As far as I can tell, as munin only builds arch:all packages, the debhelper multi-arch changes are not needed. Executable debhelper files are not used either. Only thing I'm not really sure of is the build-arch/build-indep targets presence in debhelper compat 8 but, again, as all the built packages are all arch:all, I'm not really sure it's relevant either. Thanks in advance, Nicolas Dandrimont -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673946: ITA hellanzb
retitle 673946 ITA: hellanzb -- Newzbin (nzb) & BinNews (bns) files downloader and post-processor owner 673946 ! kthxbye Hi, I intend to adopt the hellanzb package. I will certainly put it under the PAPT umbrella. Have a nice day, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#616569: "hellanzb crashes server": is this still relevant?
tags 616569 + unreproducible moreinfo thanks Hi, I'm taking over the hellanzb package, and I'm currently going through the outstanding bug reports. I have been using hellanzb for a few years on several up-to-date debian systems, feeding it quite a lot of nzb files, and I'm afraid I didn't notice any such crash. I also don't really understand how a segfault could provoke the symptoms you're talking about. Moreover, the information on the bug report is a bit sparse to reproduce the bug. Could you please least send the nzb file that made hellanzb crash, or at least test on squeeze or sid if the crash still happens with the current hellanzb and python versions? Thanks in advance, -- Nicolas Dandrimont pgpgQRBqWsrgB.pgp Description: PGP signature
Bug#794637: ITP: celerymon -- real-time monitoring of Celery workers
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: celerymon Version : 1.0.3 Upstream Author : Ask Solem * URL : https://github.com/celery/celerymon * License : BSD 2-clause Programming Lang: Python Description : real-time monitoring of Celery workers Celery is an open source asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well. . Celerymon provides an HTTP API and a web-interface to do real-time monitoring of the workers in a Celery cluster. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]
Tiago, when replying to a RFS, please use the bug report rather than the
mailing list.
* Tiago Ilieve [2016-04-12 03:23:50 -0300]:
> > When I tried to dput I've been refused it because 1.4.0-1 was already on the
> > server. That's the only way I found. Maybe I did something wrong.
>
> Maybe you uploaded again before mentors.d.n processed the first
> upload? There's an waiting time ("How long will it take until my
> upload is available to sponsors?" from its Q&A[5]) between the upload
> and the package actually being available in there. I'm suggesting this
> because mentors.d.n even store different versions of the package, even
> when you did not bump its version. You can always use the delete
> button from its web interface as well.
Please don't.
Pierre-Elliott, please post full error messages when you have an issue, not
your interpretation of the message. You probably got tripped by the fact that
dput leaves a .upload file along your .changes to avoid double uploads. You can
either remove the .upload file or use dput -f to bypass that check.
No need to bump the revision number (which might end you up forgetting to
upload the original tarball) or removing the package from mentors.d.n (which
will remove history).
Bye,
--
Nicolas Dandrimont
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."
(By dmegg...@aix1.uottawa.ca)
signature.asc
Description: Digital signature
Bug#770612: unblock: btrfs-tools/3.17-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package btrfs-tools
The upload backports two patches from the upstream 3.17.1 branch, fixing
RC bug #768746 (merged with #769684).
That upload allows packages depending on libbtrfs0 (such as snapper) to build
again.
X-D-CC'ing -boot@ as btrfs-tools produces a udeb, and is currently block-udeb'd.
Guessing the right hint would be:
unblock-udeb btrfs-tools/3.17-1.1
Thanks!
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru btrfs-tools-3.17/debian/changelog btrfs-tools-3.17/debian/changelog
--- btrfs-tools-3.17/debian/changelog 2014-10-23 23:04:25.0 +0200
+++ btrfs-tools-3.17/debian/changelog 2014-11-22 14:52:06.0 +0100
@@ -1,3 +1,13 @@
+btrfs-tools (3.17-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add 0002-Fix-linking-with-libbtrfs.patch from upstream, to properly
+export all the previously exported API (Closes: #768746)
+ * Add 0003-Make-headers-C++-compatible.patch from upstream, making the
+new headers C++-compatible.
+
+ -- Nicolas Dandrimont Sat, 22 Nov 2014 14:52:06 +0100
+
btrfs-tools (3.17-1) unstable; urgency=medium
* New upstream release.
diff -Nru btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch
--- btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch 1970-01-01 01:00:00.0 +0100
+++ btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch 2014-11-15 16:23:00.0 +0100
@@ -0,0 +1,36 @@
+From dcf11c371cbcdca78f297fe042095912634a8323 Mon Sep 17 00:00:00 2001
+From: David Sterba
+Date: Thu, 30 Oct 2014 18:33:41 +0100
+Subject: [PATCH] btrfs-progs: fix linking with libbtrfs
+
+Reported at https://github.com/openSUSE/snapper/issues/128
+
+Commit cdb9e22e292275237c added another rbtree file that defines
+functions that libbtrfs uses.
+
+Signed-off-by: David Sterba
+---
+ Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 9c69ada..203597c 100644
+--- a/Makefile
b/Makefile
+@@ -10,14 +10,14 @@ objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
+ root-tree.o dir-item.o file-item.o inode-item.o inode-map.o \
+ extent-cache.o extent_io.o volumes.o utils.o repair.o \
+ qgroup.o raid6.o free-space-cache.o list_sort.o props.o \
+- ulist.o qgroup-verify.o backref.o rbtree-utils.o
++ ulist.o qgroup-verify.o backref.o
+ cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
+ cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
+ cmds-quota.o cmds-qgroup.o cmds-replace.o cmds-check.o \
+ cmds-restore.o cmds-rescue.o chunk-recover.o super-recover.o \
+ cmds-property.o
+ libbtrfs_objects = send-stream.o send-utils.o rbtree.o btrfs-list.o crc32c.o \
+- uuid-tree.o utils-lib.o
++ uuid-tree.o utils-lib.o rbtree-utils.o
+ libbtrfs_headers = send-stream.h send-utils.h send.h rbtree.h btrfs-list.h \
+ crc32c.h list.h kerncompat.h radix-tree.h extent-cache.h \
+ extent_io.h ioctl.h ctree.h btrfsck.h version.h
diff -Nru btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch
--- btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch 1970-01-01 01:00:00.0 +0100
+++ btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch 2014-11-15 16:57:02.0 +0100
@@ -0,0 +1,96 @@
+From cafacda441120976105d01c07286e843cb7cbb94 Mon Sep 17 00:00:00 2001
+From: David Sterba
+Date: Mon, 3 Nov 2014 23:50:50 +0100
+Subject: [PATCH] btrfs-progs: libbtrfs, make exported headers compatible with
+ C++
+
+Add externs and don't use a reserved keyword.
+
+Signed-off-by: David Sterba
+---
+ rbtree-utils.h | 8
+ rbtree.h | 10 +-
+ rbtree_augmented.h | 8
+ 3 files changed, 25 insertions(+), 1 deletion(-)
+
+diff --git a/rbtree-utils.h b/rbtree-utils.h
+index 7298c72..718581f 100644
+--- a/rbtree-utils.h
b/rbtree-utils.h
+@@ -21,6 +21,10 @@
+
+ #include "rbtree.h"
+
++#ifdef __cplusplus
++extern "C" {
++#endif
++
+ /* The common insert/search/free functions */
+ typedef int (*rb_compare_nodes)(struct rb_node *node1, struct rb_node *node2);
+ typedef int (*rb_compare_keys)(struct rb_node *node, void *key);
+@@ -42,4 +46,8 @@ static void free_##name##_tree(struct rb_root *root) \
+ rb_free_nodes
Bug#672845: RFH Packaging DNSSEC/TLSA Validator
Hey Ondřej, * Ondřej Surý [2014-07-22 02:42:03 +0200]: > I just found the upstream misses OpenSSL exception[1], so I will > have to sort it out together with next stable upstream release. > > 1. Do we already have some nice *SSL boilerplate exception that > would allow OpenSSL derivative libraries as well? Joey Hess quoted the FSF boilerplate in [1]. In can be found in at least wget and GnuPG. In full: | In addition, as a special exception, gives permission to | link the code of with the OpenSSL project's "OpenSSL" library (or | with modified versions of it that use the same license as the "OpenSSL" | library), and distribute the linked executables. You must obey the GNU General | Public License in all respects for all of the code used other than "OpenSSL". | If you modify this file, you may extend this exception to your version of the | file, but you are not obligated to do so. If you do not wish to do so, delete | this exception statement from your version. [1] https://lists.debian.org/debian-devel/2014/07/msg00564.html HTH, -- Nicolas Dandrimont BOFH excuse #390: Increased sunspot activity. signature.asc Description: Digital signature
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Control: owner -1 ! Hey bofh80, * bofh80 [2014-07-14 16:27:40 +0100]: > Thanks for the feedback, I've uploaded 0.6.1 with an extra depends. > I've checked in a vm without e17 installed this time to make sure it works > first. > If you'd be so kind as to check the new version and let me know? > > http://mentors.debian.net/package/terminology > > The respective dsc file can be found at: > http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.1-1.dsc > > Sorry for the delay in getting back to you, I missed it, came before i > subscribed to the mailing list. Terminology has piqued my interest for a while now, and I want to see it in Debian so I'll sponsor you. Here's my review: - debian/README.source is useless. - debian/copyright: - you're not Sebastian Reichel, are you? :) - ltmain.sh is GPL-2 - the copyright for src/bin/lz4 is missing - the copyright years need updating, and I think the authors list is outdated. - the *_eet.* seem to be autogenerated. ftpmasters will probably want them to be built from source, although not having source is fine wrt the license (BSD2). I don't see the source anywhere. - debian/control: - The descriptions need more work: the list of features needs trimming, and/or reformatting. - You might want to Suggest: libelementary-bin and let people know how to switch to OpenGL rendering in a README.Debian. Soft rendering is toasty. - debian/rules: - you should trim the comments/debmake foo and keep it simple. - DPKG_EXPORT_BUILDFLAGS = 1 is the default in debhelper compat level 9 - please have debhelper pass --disable-silent-rules to configure. - I think the exports (from the upstream README) are useful at runtime. - debian/terminology.lintian-overrides: I'm not a big fan of overriding the binary-without-manpage lintian warning, but I won't make you write the manpages either (I like writing manpages, but I understand not everyone does). I'd leave the warning as a reminder that those extra executables need some documentation. - debian/changelog: I'd merge the two entries in a single one, as the first one never entered Debian. - debian/watch: it seems that upstream switched to bz2 tarballs. See https://wiki.debian.org/debian/watch#Common_mistakes for a hint. Furthermore the 0.6.1 version doesn't exist there. You should either update it or provide a get-orig-source target in d/rules to rebuild the tarball you used. Build is ok, lintian seems happy. Things seem to run fine too. Setting aside the sourceless files bit, those issues shouldn't be very hard to fix. Please talk to upstream about the autogenerated files, we really want to ship the source, and ideally, we need the machinery to regenerate them at build time. Cheers, -- Nicolas Dandrimont BOFH excuse #191: Just type 'mv * /dev/null'. signature.asc Description: Digital signature
Bug#754260: RFS: terminology/0.6.0-1 [ITP]
Heya, * Anthony F McInerney [2014-07-30 23:46:03 +0100]: > Hi Nicolas > > The eet file source issues, i ran a 'find' and couldn't see the files your > talking about, could you name one or two explicitly for me? The two files I was talking about are: ./src/bin/app_server_eet.c ./src/bin/app_server_eet.h > When i mentioned them, the terminology devs seemed to think they were > config files. (enlightenment has a thing about putting text into 'machine > code' for faster parsing) there are tools like edje_cc edje_decc edje_recc > etc > > Everything else has been taken care of and i have uploaded 0.6.1-2 for you > to peruse. > > The respective dsc file can be found at: > http://mentors.debian.net/debian/pool/main/t/terminology/terminology_0.6.1-2.dsc Please keep the revision at -1 until the package is uploaded to Debian. mentors.d.n will be fine with you reuploading the same version over and over again. I'll take another look later today. Cheers, -- Nicolas Dandrimont BOFH excuse #382: Someone was smoking in the computer room and set off the halon systems. signature.asc Description: Digital signature
Bug#779662: package fails to build without network connection
Control: tags -1 + unreproducible * Matthias Klose [2015-03-03 20:26:38 +0100]: > Package: src:fedmsg-meta-fedora-infrastructure > Version: 0.2.18-1 > Severity: serious > Tags: sid jessie > > The package fails to build in an unstable environment on amd64 without having > network access. the build log shows errors like these, which go away if you > have > network connection. Hi, I couldn't reproduce this on my laptop disconnected from the internet. Please be more specific as to what you mean by "no network access". I'm pretty sure those tests need access to localhost, and I'm not sure "no localhost" is a supported configuration for our build environment. Thanks, -- Nicolas Dandrimont BOFH excuse #433: error: one bad user found in front of screen signature.asc Description: Digital signature
Bug#798199: New list: debian-outre...@lists.debian.org
Package: lists.debian.org Severity: wishlist Hi all, I would like to request the creation of a new list, debian-outre...@lists.debian.org. Name: debian-outreach Short description: Public discussion of the Outreach Team's activities Long description: Discussion of Debian's participation in internship-like programs, such as Outreachy, Google Summer of Code, ... Program administrators and members of the Outreach Team will send announcements regarding Debian's participation to this mailing-list. Debian interns will send periodic reports of their work to this mailing-list. Rationale: The current mailing-list, soc-coordination on alioth, has become a burden as its name is GSoC-specific and, sadly, it is riddled with spam, which often makes gmail users get unsubscribed automatically after bounces. Now that the Outreach Team has been permanently delegated as such, and as we are between programs, now would be a good time to migrate to a proper, non-program-specific mailing-list on official Debian infrastructure. Category: I'm torn between Developers and Misc Debian, with a slight preference for the latter. Subscription policy: open Post policy: open Web archive: yes I'd like to bootstrap the list with the subscribers and archives from soc-coordination (although after a quick glance it doesn't seem possible to get those archives without admin intervention), please let me know how to provide them to you once the list is created! Thanks in advance, Nicolas for the Outreach Team. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#798199: [Soc-coordination] Bug#798199: New list: debian-outre...@lists.debian.org
* Daniel Pocock [2015-09-06 19:49:10 +0200]: > > > Program administrators and members of the Outreach Team will send > > announcements regarding Debian's participation to this > > mailing-list. Debian interns will send periodic reports of their > > work to this mailing-list. > > > > Have you thought about creating a separate list for the weekly reports? Not directly. While writing this description, I thought of a separate list for announcements (program deadlines, welcome emails and such) that would be easier to follow for people who don't want to get all the traffic from the reports. I think it's a good idea to migrate the current list "as-is" and to think about splitting off in a potential second step, if there's consensus that the traffic is too high. Does that make sense? -- Nicolas Dandrimont BOFH excuse #72: Satan did it signature.asc Description: Digital signature
Bug#760925: lists.debian.org: New List: debconf-bid-paris
Package: lists.debian.org Severity: wishlist Dear Listmasters, We would like to request the creation of a mailing-list according to the details below: Name: debconf-bid-paris Rationale: This list would serve as a coordination list for the future DebConf16 Bid in or around Paris. While most of the coordination so far has happened IRL or on IRC, a mailing-list is critical for long-term collaboration. We are aiming for a DebConf16 bid, but would be ready to let it slip if negotiations with venues aren't fruitful, hence the year-agnostic list name. We have a core team of a few DDs, and the discussion so far has shown interest from a team of local helping hands. Short description: DebConf bid team for Paris Long description: Discussion amongst the team bidding to host a DebConf in or around Paris, France. Category: DebConf Subscription Policy: open Post Policy: open Web Archive: yes Thanks in advance, and let me know if you need anything else from us (seconds will follow)! Cheers, -- Nicolas Dandrimont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757320: Wrong dnssec-trigger-script path in /etc/NetworkManager/dispatcher.d/01-dnssec-trigger
Package: dnssec-trigger Version: 0.13~svn685-1 Severity: important Control: tags -1 patch Dear maintainer, The path to dnssec-trigger-script in the NetworkManager dispatcher hook is wrong. It seems that with NetworkManager 0.9.10.0-1, the shell script fallback fails, which means that DHCP-supplied DNS server notification does not work. Please find attached a patch that fixes the issue. Cheers, Nicolas Dandrimont -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dnssec-trigger depends on: ii init-system-helpers 1.20 ii libc62.19-7 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.24-1 ii libldns1 1.6.17-5 ii libssl1.0.0 1.0.1h-3 ii python 2.7.8-1 ii unbound 1.4.22-1 dnssec-trigger recommends no packages. dnssec-trigger suggests no packages. -- no debconf information >From d834d37f068a31c6ea93f71e7ee7e03a4ddb56a1 Mon Sep 17 00:00:00 2001 From: Nicolas Dandrimont Date: Thu, 7 Aug 2014 08:39:00 +0200 Subject: [PATCH] Fix path to dnssec-trigger-script in the NetworkManager hook --- debian/patches/debian-quirks.patch | 11 +++ 1 file changed, 11 insertions(+) diff --git a/debian/patches/debian-quirks.patch b/debian/patches/debian-quirks.patch index c81b084..9d890e0 100644 --- a/debian/patches/debian-quirks.patch +++ b/debian/patches/debian-quirks.patch @@ -1,5 +1,16 @@ --- dnssec-trigger.orig/01-dnssec-trigger.in +++ dnssec-trigger/01-dnssec-trigger.in +@@ -11,8 +11,8 @@ fi + + # Exec the dnssec-trigger update script that uses NetworkManager API to gather + # all the necessary information. +-if [ -x @libexecdir@/dnssec-trigger-script ]; then +-exec @libexecdir@/dnssec-trigger-script --update ++if [ -x /usr/lib/dnssec-trigger/dnssec-trigger-script ]; then ++exec /usr/lib/dnssec-trigger/dnssec-trigger-script --update + fi + + # When dnssec-trigger-script is absent or not executable, the original @@ -23,7 +23,7 @@ fi # set PATH correctly instead of absolute paths to binaries PATH="@sbindir@:@bindir@:/sbin:/usr/sbin:/bin:/usr/bin" -- 2.1.0.rc1
Bug#738195: [pkg-cli-apps-team] Processed: reopening 738195
clone 738195 -1
reassign -1 gnome-do-plugins 0.8.5-2
retitle -1 gnome-do-plugins: About pages for plugins link to a parked domain
fixed 738195 0.95.2-1
close 738195
thanks
* Sam Morris [2014-11-12 11:25:41 +]:
> On Wed, Nov 12, 2014 at 12:38:32AM +0800, Chow Loong Jin wrote:
> >
> > On Tue, Nov 11, 2014 at 04:06:06PM +, Debian Bug Tracking System wrote:
> > > Processing commands for cont...@bugs.debian.org:
> > >
> > > > reopen 738195
> > > Bug #738195 {Done: Chow Loong Jin } [gnome-do]
> > > gnome-do: Changed location of homepage
> > > Bug #757056 {Done: Chow Loong Jin } [gnome-do]
> > > gnome-do: URL needs updating
> > > Bug reopened
> > > Ignoring request to alter fixed versions of bug #738195 to the same
> > > values previously set
> > > Ignoring request to alter fixed versions of bug #757056 to the same
> > > values previously set
> > > > thanks
> > > Stopping processing here.
> >
> > Why are you reopening this bug? Are there any outdated references left?x
> > https://packages.debian.org/sid/gnome-do seems to show an updated URL to me.
> > Grepping the source for davebsd.com shows nothing.
>
> As I explained, the bug is not fixed. The About button for each plug-in
> in the Preferences window still sends me off to oneclickads.net.
>
> I did take a brief look at the source package and I also don't see where
> the old URL is coming from, but it's still there.
The plugins are in gnome-do-plugins, and yes, the URLs are wrong there.
Cloning the bug to the right package, and closing the gnome-do package.
Cheers,
--
Nicolas Dandrimont
signature.asc
Description: Digital signature
Bug#738195: [pkg-cli-apps-team] Processed: reopening 738195
* Nicolas Dandrimont [2014-11-15 14:37:10 +0100]: > * Sam Morris [2014-11-12 11:25:41 +]: > > As I explained, the bug is not fixed. The About button for each plug-in > > in the Preferences window still sends me off to oneclickads.net. > > > > I did take a brief look at the source package and I also don't see where > > the old URL is coming from, but it's still there. > > The plugins are in gnome-do-plugins, and yes, the URLs are wrong there. > > Cloning the bug to the right package, and closing the gnome-do package. So, I investigated that bug a bit further, and it seems that the davebsd URLs currently in the plugins don't have a replacement: the wiki is dead and hasn't been transferred to the new host. As it seems that the plugin urls always point to that wiki, I think the best resolution might be to disable the url display altogether. Hope this helps, -- Nicolas Dandrimont How do I type "for i in *.dvi do xdvi i done" in a GUI? (Discussion in comp.os.linux.misc on the intuitiveness of interfaces.) signature.asc Description: Digital signature
Bug#768746: snapper: FTBFS in jessie: BtrfsUtils.cc:127:27: error: 'btrfs_qgroup_inherit' was not declared in this scope
Control: retitle -1 libbtrfs missing headers Control: found -1 3.17-1 Control: tags -1 + upstream fixed-upstream patch * Andrey Rahmatullin [2014-11-15 20:49:10 +0500]: > Control: reassign -1 btrfs-tools > Control: forcemerge 768694 -1 > > On Sun, Nov 09, 2014 at 08:15:16AM +0100, Lucas Nussbaum wrote: > > > /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > > > -I.. -I/usr/include/libxml2 -D_FORTIFY_SOURCE=2 > > > -DCONFDIR='"/etc/default"' -D_FILE_OFFSET_BITS=64 -g -O2 > > > -fstack-protector-strong -Wformat -Werror=format-security -std=c++0x > > > -Wall -Wextra -Wformat=2 -Wnon-virtual-dtor -Wno-unused-parameter -c -o > > > BtrfsUtils.lo BtrfsUtils.cc > > > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/libxml2 > > > -D_FORTIFY_SOURCE=2 -DCONFDIR=\"/etc/default\" -D_FILE_OFFSET_BITS=64 -g > > > -O2 -fstack-protector-strong -Wformat -Werror=format-security -std=c++0x > > > -Wall -Wextra -Wformat=2 -Wnon-virtual-dtor -Wno-unused-parameter -c > > > BtrfsUtils.cc -fPIC -DPIC -o .libs/BtrfsUtils.o > > > BtrfsUtils.cc: In function 'void snapper::create_snapshot(int, int, const > > > string&, bool, snapper::qgroup_t)': > > > BtrfsUtils.cc:127:27: error: 'btrfs_qgroup_inherit' was not declared in > > > this scope > The relevant header is included only with HAVE_LIBBTRFS (which is > apparently wrong because the source can't be compiled without the header) > which is false because libbtrfs.so can't be linked against. Well, yes, that's a bug in btrfs-tools: libbtrfs stopped exporting some headers after an upstream refactoring, and can't be linked against anymore. Cherry-picking the two following patches from the 3.17 branch of btrfsprogs restores the headers and lets snapper compile properly. - https://github.com/kdave/btrfs-progs/commit/dcf11c371cbcdca78f297fe042095912634a8323.patch - https://github.com/kdave/btrfs-progs/commit/cafacda441120976105d01c07286e843cb7cbb94.patch Unless the maintainer disagrees, I will upload a NMU (to DELAYED/5) adding those two patches. Cheers, -- Nicolas Dandrimont BOFH excuse #129: The ring needs another token signature.asc Description: Digital signature
Bug#768746: snapper: FTBFS in jessie: BtrfsUtils.cc:127:27: error: 'btrfs_qgroup_inherit' was not declared in this scope
* Nicolas Dandrimont [2014-11-15 17:50:02 +0100]:
> Unless the maintainer disagrees, I will upload a NMU (to DELAYED/5) adding
> those two patches.
Debdiff attached.
--
Nicolas Dandrimont
"...[Linux's] capacity to talk via any medium except smoke signals."
(By Dr. Greg Wettstein, Roger Maris Cancer Center)
diff -Nru btrfs-tools-3.17/debian/changelog btrfs-tools-3.17/debian/changelog
--- btrfs-tools-3.17/debian/changelog 2014-10-23 23:04:25.0 +0200
+++ btrfs-tools-3.17/debian/changelog 2014-11-15 16:58:09.0 +0100
@@ -1,3 +1,13 @@
+btrfs-tools (3.17-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add 0002-Fix-linking-with-libbtrfs.patch from upstream, to properly
+export all the previously exported API (Closes: #768746)
+ * Add 0003-Make-headers-C++-compatible.patch from upstream, making the
+new headers C++-compatible.
+
+ -- Nicolas Dandrimont Sat, 15 Nov 2014 16:23:26 +0100
+
btrfs-tools (3.17-1) unstable; urgency=medium
* New upstream release.
diff -Nru btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch
--- btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch 1970-01-01 01:00:00.0 +0100
+++ btrfs-tools-3.17/debian/patches/0002-Fix-linking-with-libbtrfs.patch 2014-11-15 16:23:00.0 +0100
@@ -0,0 +1,36 @@
+From dcf11c371cbcdca78f297fe042095912634a8323 Mon Sep 17 00:00:00 2001
+From: David Sterba
+Date: Thu, 30 Oct 2014 18:33:41 +0100
+Subject: [PATCH] btrfs-progs: fix linking with libbtrfs
+
+Reported at https://github.com/openSUSE/snapper/issues/128
+
+Commit cdb9e22e292275237c added another rbtree file that defines
+functions that libbtrfs uses.
+
+Signed-off-by: David Sterba
+---
+ Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 9c69ada..203597c 100644
+--- a/Makefile
b/Makefile
+@@ -10,14 +10,14 @@ objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
+ root-tree.o dir-item.o file-item.o inode-item.o inode-map.o \
+ extent-cache.o extent_io.o volumes.o utils.o repair.o \
+ qgroup.o raid6.o free-space-cache.o list_sort.o props.o \
+- ulist.o qgroup-verify.o backref.o rbtree-utils.o
++ ulist.o qgroup-verify.o backref.o
+ cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
+ cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
+ cmds-quota.o cmds-qgroup.o cmds-replace.o cmds-check.o \
+ cmds-restore.o cmds-rescue.o chunk-recover.o super-recover.o \
+ cmds-property.o
+ libbtrfs_objects = send-stream.o send-utils.o rbtree.o btrfs-list.o crc32c.o \
+- uuid-tree.o utils-lib.o
++ uuid-tree.o utils-lib.o rbtree-utils.o
+ libbtrfs_headers = send-stream.h send-utils.h send.h rbtree.h btrfs-list.h \
+ crc32c.h list.h kerncompat.h radix-tree.h extent-cache.h \
+ extent_io.h ioctl.h ctree.h btrfsck.h version.h
diff -Nru btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch
--- btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch 1970-01-01 01:00:00.0 +0100
+++ btrfs-tools-3.17/debian/patches/0003-Make-headers-C++-compatible.patch 2014-11-15 16:57:02.0 +0100
@@ -0,0 +1,96 @@
+From cafacda441120976105d01c07286e843cb7cbb94 Mon Sep 17 00:00:00 2001
+From: David Sterba
+Date: Mon, 3 Nov 2014 23:50:50 +0100
+Subject: [PATCH] btrfs-progs: libbtrfs, make exported headers compatible with
+ C++
+
+Add externs and don't use a reserved keyword.
+
+Signed-off-by: David Sterba
+---
+ rbtree-utils.h | 8
+ rbtree.h | 10 +-
+ rbtree_augmented.h | 8
+ 3 files changed, 25 insertions(+), 1 deletion(-)
+
+diff --git a/rbtree-utils.h b/rbtree-utils.h
+index 7298c72..718581f 100644
+--- a/rbtree-utils.h
b/rbtree-utils.h
+@@ -21,6 +21,10 @@
+
+ #include "rbtree.h"
+
++#ifdef __cplusplus
++extern "C" {
++#endif
++
+ /* The common insert/search/free functions */
+ typedef int (*rb_compare_nodes)(struct rb_node *node1, struct rb_node *node2);
+ typedef int (*rb_compare_keys)(struct rb_node *node, void *key);
+@@ -42,4 +46,8 @@ static void free_##name##_tree(struct rb_root *root) \
+ rb_free_nodes(root, free_func); \
+ }
+
++#ifdef __cplusplus
++}
++#endif
++
+ #endif
+diff --git a/rbtree.h b/rbtree.h
+index 03c06d8..0d4f2bf 100644
+--- a/rbtree.h
b/rbtree.h
+@@ -34,6 +34,10 @@
+ #include
+ #endif /* BTRFS_FLAT_INCLUDES */
+
++#ifdef __cplusplus
++extern "C" {
++#endif
++
+ struct rb_node {
+ unsigned long __rb_parent_color;
+ struct rb_node *rb_right;
+@@ -75,7 +79,7 @@ extern struct rb_node *rb_first_postorder(const struct rb_root *);
+ extern struct rb_node *rb_next_postorder(const struct rb_node *);
+
+ /* Fast replacement of a single node
Bug#798199: [Soc-coordination] Bug#798199: New list: debian-outre...@lists.debian.org
* Daniel Pocock [2015-09-06 21:12:03 +0200]: > Maybe - a debian-outreach-announce list? > > Personally, I feel that with 20 students or more at a time there are a > lot of reports and most mentors and other students on the list would > not be reading through all of them every week. > > People get more and more email these days and the more that we can do > as a project to help people (both mentors and students) to get more > focused communication, the less likely they are to become frustrated > or even burnt out. > > So there could be three lists: > > debian-outreach-announce > - announce program start and finish details > > debian-outreach > - discussions that potentially involve multiple students or mentors, > students looking for a mentor, etc > > debian-outreach-report > - students submit weekly reports (with CC to their mentors) Hi, Thanks to this discussion the mailing list creation has stalled. The status-quo, an alioth mailing-list, is unbearable, and way more frustrating than migrating to a single Debian mailing-list: the noise from spam is very, very high, which is a burden to all. Dear listmasters, please consider creating one single mailing-list, debian-outreach@l.d.o, as asked in the original bug-report. This would be one great step forward from the status-quo. It is easy enough to add more mailing-lists afterwards if we feel that the noise is too high. Unfortunately, this is becoming time-sensitive, as Outreachy and Google Summer of Code are going to start in a few weeks, and we need to communicate proper contact details. Thanks for your consideration, -- Nicolas Dandrimont signature.asc Description: Digital signature
Bug#810816: pgbouncer: New upstream version 1.7
Package: pgbouncer Severity: wishlist Dear Maintainers, pgbouncer 1.7 has been released. It adds several interesting features, most notably TLS and HBA file support. It'd be great if you could update the package. Thanks a lot! :) Nicolas. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#704706: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)
* Pierre-Elliott Bécue [2016-03-23 22:44:18 +0100]: > Control: owner -1 ! > Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID > Protocol (Mozilla Persona) > > Hey, > > I intend to package. VCS is up, the package builds correctly. > > VCS: https://github.com/P-EB/python-browserid > Build results: https://peb.pimeys.fr/packages/python-browserid/ > > Comments welcome, and if everything seems okay, please, I'd like to request > for sponsorship on this package. Hi Pierre-Elliott, To get more luck, you should really use the proper channels for sponsorship: either the debian-python mailing-list specific to python packages, or the general sponsorship-requests process on the debian-mentors mailing-list (more info is available on http://mentors.debian.net/sponsors). Cheers (and good luck with your packages!), -- Nicolas Dandrimont BOFH excuse #287: Telecommunications is downshifting. signature.asc Description: Digital signature
Bug#809811: postgresql-common: server maintscripts operate on all the versions when using systemd
Package: postgresql-common Version: 171 Severity: important Dear Maintainer, When using systemd, and having several versions of postgresql installed, an upgrade of e.g. postgresql-9.5 will stop then start all versions. It seems that the maintainer scripts use "invoke-rc.d postgresql $action $version", and systemd happily ignores the spare $version argument. AFAICT some kind of switch on the presence (and usage) of systemd is needed, to be able to operate on the specific postgresql@$version-$cluster autogenerated units. Thanks! Nicolas -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql-common depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.58 ii init-system-helpers 1.24 ii lsb-base 9.20150917 ii postgresql-client-common 171 ii procps2:3.3.11-3 ii ssl-cert 1.0.37 ii ucf 3.0031 Versions of packages postgresql-common recommends: ii logrotate 3.8.7-2 postgresql-common suggests no packages. -- debconf information excluded
Bug#866595: src:python-async-timeout: Does not run tests on build
Package: src:python-async-timeout Version: 1.2.1-1 Severity: normal Dear maintainer, python-async-timeout's tests depend on the pytest_aiohttp module, which is not currently packaged. Some behavior of pybuild makes the tests not be run at the moment. Adding python3-pytest explicitly to Build-Dependencies make it try to run the tests and fail. Please consider packaging the missing test fixtures and having async-timeout run its tests on build. Thanks! -- System Information: Debian Release: 9.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#868818: RM: fedmsg -- RoQA; unmaintained, RC-buggy
* Chris Lamb [2017-08-02 13:39:09 -0400]: > [Adding olasd to CC] > > > > > RM: fedmsg -- RoQA; unmaintained, RC-buggy > > > > > > Hm, that would break these build-depends: > > > > > > datanommer.commands > > > datanommer.consumer > > > datanommer.models > > > fedmsg-meta-debian > > > fedmsg-meta-fedora-infrastructure > > > > They can all be removed along, same rationale essentially (unmaintained, > > out of testing for a long time, not in stretch) > > Olasd, you are in the Maintainer field of these. Any objection? Please go ahead. Thanks! -- Nicolas Dandrimont BOFH excuse #158: Defunct processes signature.asc Description: PGP signature
Bug#851153: ITP: hiro -- time manipulation utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: hiro Version : 0.2 Upstream Author : Ali-Akber Saifee * URL : http://hiro.readthedocs.org/ / https://github.com/alisaifee/hiro * License : MIT Programming Lang: Python Description : time manipulation utilities for Python The hiro module provides a context-manager which hijacks a few commonly used time function to manipulate time in its context. It allows you to rewind, forward, freeze, unfreeze, and scale time according to given settings. . Most notably, the builtin functions time.sleep, time.time, time.gmtime, datetime.now, datetime.utcnow and datetime.today behave according the configuration of the context. hiro is a test dependency for python-limits, which itself is a dependency for flask-limiter which I intend to package. I will maintain those packages under the Debian Python Modules Team umbrella.
Bug#851255: ITP: python-rediscluster -- Python interface to a cluster of Redis key-value stores
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: python-rediscluster Version : 0.5.3 Upstream Author : Salimane Adjao Moustapha * URL : https://github.com/salimane/rediscluster-py * License : MIT Programming Lang: Python Description : Python interface to a cluster of Redis key-value stores Redis is a key-value database in a similar vein to memcache but the dataset is non-volatile. Redis additionally provides native support for atomically manipulating and querying data structures such as lists and sets. . rediscluster is a Python library adapting the upstream Redis bindings to enable sharding among different Redis instances in a transparent, fast, and fault tolerant way. This package will be maintained under the umbrella of the Debian Python Modules Team. It is a dependency of python-limits, which in turn is a dependency of Flask-Limiter which I intend to package.
Bug#851255: ITP: python-rediscluster -- Python interface to a cluster of Redis key-value stores
Control: retitle -1 ITP: redis-py-cluster -- Python client to the Redis cluster interface Hrm. Of course that's the wrong upstream project. Here's the info for the proper project * Nicolas Dandrimont [2017-01-13 13:23:37 +0100]: > Package: wnpp > Severity: wishlist > Owner: Nicolas Dandrimont > > * Package name: redis-py-cluster Version : 1.3.3 Upstream Author : Johan Andersson URL : https://github.com/Grokzen/redis-py-cluster / http://redis-py-cluster.readthedocs.io/ > * License : MIT > Programming Lang: Python > Description : Python interface to a cluster of Redis key-value stores > > Redis is a key-value database in a similar vein to memcache but the dataset > is non-volatile. Redis additionally provides native support for atomically > manipulating and querying data structures such as lists and sets. > . redis-py-cluster provides Python bindings to Redis Cluster, the distributed implementation of the Redis key-value store, available upstream since Redis 3.0. > > This package will be maintained under the umbrella of the Debian Python > Modules > Team. It is a dependency of python-limits, which in turn is a dependency of > Flask-Limiter which I intend to package. Enjoy, -- Nicolas Dandrimont BOFH excuse #221: The mainframe needs to rest. It's getting old, you know. signature.asc Description: Digital signature
Bug#851272: ITP: python-limits -- Rate limiting utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: python-limits Version : 1.2.1 Upstream Author : Ali-Akber Saifee * URL : https://limits.readthedocs.org * License : MIT Programming Lang: Python Description : Rate limiting utilities for Python limits is a Python module providing utilities to implement rate limiting using various strategies, such as fixed or moving windows, and various storage backends, such as in in-memory storage, Redis or memcached. limits is the back-end and base implementation of the rate-limiting algorithms provided by Flask-Limiter. The module will be maintained inside the Debian Python Modules Team
Bug#851290: ITP: flask-limiter -- Rate-limiting for Flask routes
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: flask-limiter Version : 0.9.3 Upstream Author : Ali-Akber Saifee * URL : http://flask-limiter.readthedocs.org/ | https://github.com/alisaifee/flask-limiter * License : MIT Programming Lang: Python Description : Rate-limiting for Flask routes Flask is a micro web framework for Python based on Werkzeug, Jinja 2 and good intentions. . Flask-Limiter provides rate limiting features to flask routes. It has support for a configurable backend for storage with current implementations for in-memory, redis and memcache. This package will be maintained under the umbrella of the Debian Python Modules Team
Bug#834033: src:python-kafka: Please package newer upstream version (1.2.5 available)
Package: src:python-kafka Version: 0.9.5-2 Severity: wishlist Dear Maintainer, I would like to use python-kafka using features released in 1.0, 1.1 and 1.2 (support for coordinated consumer groups, SSL, kafka 0.10 features). Please consider updating the python-kafka package to something more recent than the currently packaged 0.9.5 upstream release. I tried to look at the git repository to do the update, but I have to say that the pkg-openstack paraphernalia confused me, so I'm sorry for not providing patches. Upstream has deprecated lots of legacy APIs, but as far as I can tell they have not been removed yet, so the transition for reverse-dependencies should be smooth. Thank you for considering, Nicolas Dandrimont -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#1070161: ITS: ramond
On Wed, May 1, 2024, at 04:50, Boyuan Yang wrote: > Source: ramond > Version: 0.5-4.2 > Severity: important > Tags: sid trixie > X-Debbugs-CC: nicolas.dandrim...@crans.org > > Dear package ramond maintainer in Debian, > > After looking into the package you maintain (ramond, > https://tracker.debian.org/pkg/ramond), I found that this package > received no maintainer updates in the past 12 years and is not in good > shape. As a result, I am filing an ITS (Intent to Salvage) request > against your package to take over package maintenance according to > section 5.12 in Debian's Developers' Reference [1]. > > [...] Hi, Thank you for picking up this package. You should feel free to go ahead with immediate adoption[1]. [1] https://wiki.debian.org/LowThresholdAdoption In this day and age, most managed switches are able to block unwanted IPv6 router advertisements, so before spending much effort on a project that, last I checked, was dormant upstream, you should assess whether ramond is still relevant. Thanks again, -- Nicolas Dandrimont
Bug#1054898: piuparts.d.o: overhaul merged-/usr configuration to match the majority of installed systems (was: piuparts: drop unmerged-usr sid configuration for debci)
Bcc: Reply-To: Control: retitle -1 piuparts.d.o: overhaul merged-/usr configuration to match the majority of installed systems Control: tags -1 - patch Cc'ing Helmut & the release team as a heads-up. Hi Luca, Thanks for submitting this bug and proposing a patch. To recap, piuparts tests in sid are currently broken because the usr-is-merged package fails to upgrade since it's removed support for the exemption flag (as piuparts uses unmerged-/usr chroots with the flag file, which is not supported anymore). Before rushing to fix this with one more hack, I'd like to have a look at what we want piuparts to be testing from first principles again. In short, I think we've made a mistake by having piuparts use unmerged-/usr chroots during the bookworm development cycle, and I'd like to fix that now. As far as I understand, this is our "support matrix" | distro | build chroots | installed system support | layout for new installs | | -- | - | - | --- | | sid (&exp) | merged-/usr | merged-/usr only | merged | | trixie | merged-/usr | merged-/usr only | merged | | bookworm | unmerged-/usr | merged-/usr only | merged | | bullseye | unmerged-/usr | merged or unmerged| merged | | buster | unmerged-/usr | merged or unmerged| merged | | stretch| unmerged-/usr | unmerged or merged (experimental) | unmerged | | jessie | unmerged-/usr | unmerged-/usr only| unmerged | In practice, as piuparts has been running almost exclusively on unmerged-/usr chroots, and only running a narrow set of sid tests on merged-/usr chroots, it has been running its (package install and upgrade) tests mostly against a non-default setup, catching issues that would have been most relevant for build chroots. I believe that we should be doing the following now: - Update the piuparts config to default to generating and using merged-/usr chroots for all suites. Upload piuparts to sid. - Replace all base chroots from buster and up on piuparts.debian.org with merged-/usr chroots - (maybe) add unmerged variants of the bullseye-pu and bookworm-pu tests to make sure we can still use these packages in buildd chroots There is the question of what to do for piuparts.d.o tests that involve upgrading the base chroot across the unmerged-/usr support boundary, but switching over to only using merged-/usr base chroots for buster and up will alleviate that (I don't think we have any archaeological tests starting from stretch running anymore). Alternatively, I've poked a little bit at running the usrmerge script in a pre_distupgrade piuparts hook, which is a bit awkward as these hooks are run after the sources.list is updated for the target suite. It's just a matter of adding a new class of hooks (pre_sourceslistupdate or something) and implementing usrmerge in that. I'm not sure it's worth the hassle compared to the efforts already put into dumat. As far as I can tell, to guard testing migration, the release team is comparing the results of piuparts running on the package in trixie, with the results of piuparts running on the package in sid. I'm not sure that upgrades (that is, testing2sid) are involved, so, as long as the chroots are consistent between the trixie tests and the sid tests, these exports should keep making sense for the release team. Does my reasoning make sense? Thanks, -- Nicolas Dandrimont Date: Sat, 28 Oct 2023 17:10:24 +0200 Message-ID: <87v8aqzstb@dandrimont.eu> signature.asc Description: PGP signature
Bug#1035654: non-essential adduser poses problems to purging packages
On Thu, May 18, 2023, at 10:03, Marc Haber wrote: > On Thu, May 18, 2023 at 12:24:39AM +0200, Johannes Schauer Marin > Rodrigues wrote: >> Marc, the same offer to you for your recent adduser upload to unstable. > > Yes, please. Thanks for your work. > > adduser probably needs an additional hint because the new upload makes > piuparts fail now, as discussed yesterday. Hi, To work around this issue on the piuparts side, it sounds like we should make piuparts treat adduser as fake-essential for tests ending at bookworm or sid, so that we don't try to uninstall it; Andreas, what do you think? Thanks, -- Nicolas Dandrimont
Bug#1080294: RM: flask-testing -- ROM; unmaintained; RC-buggy; not in last stable release; no revdeps
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: flask-test...@packages.debian.org Control: affects -1 + src:flask-testing User: ftp.debian@packages.debian.org Usertags: remove Hi, Please remove flask-testing from unstable; I've not used it for years, it's been kept alive by the python team for a time but it's been RC buggy for a while, has missed the last stable release, and has no revdeps. Thanks, Nicolas
Bug#537512: shutter: Should Depend on libgtk2-imageview-perl, not Recommend it.
Package: shutter Version: 0.80-1 Severity: grave Justification: renders package unusable Hi, When installing shutter without Recommends:, it fails to start giving the following message: Can't locate Gtk2/ImageView.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/shutter line 51. BEGIN failed--compilation aborted at /usr/bin/shutter line 51. Installing the recommended package libgtk2-imageview-perl obviously solves the issue. Thank you, -- Nicolas Dandrimont -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (499, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages shutter depends on: ii imagemagick7:6.5.1.0-1.1 image manipulation programs ii libfile-basedir-perl 0.03-0.1 Perl module to use the freedesktop ii libfile-copy-recursive-per 0.38-1Perl extension for recursively cop ii libfile-desktopentry-perl 0.04-2Perl module to handle freedesktop ii libfile-homedir-perl 0.86-1Get the home directory for yoursel ii libfile-mimeinfo-perl 0.15-1Perl module to determine file type ii libfile-which-perl 0.05-7Perl module for searching paths fo ii libglib-perl 1:1.222-1 Perl interface to the GLib and GOb ii libgnome2-gconf-perl 1.044-3 Perl interface to the GNOME GConf ii libgnome2-perl 1.042-2 Perl interface to the GNOME librar ii libgnome2-vfs-perl 1.081-1 Perl interface to the 2.x series o ii libgnome2-wnck-perl0.16-2Perl interface to the Window Navig ii libgtk2-perl 1:1.221-1 Perl interface to the 2.x series o ii liblocale-gettext-perl 1.05-4Using libc functions for internati ii libproc-simple-perl1.26-1Perl interface to launch and contr ii librsvg2-common2.26.0-1 SAX-based renderer library for SVG ii libsort-naturally-perl 1.02-1Sort naturally - sort lexically ex ii libwww-mechanize-perl 1.58-1module to automate interaction wit ii libwww-perl5.829-1 WWW client/server library for Perl ii libx11-protocol-perl 0.56-2Perl module for the X Window Syste ii libxml-simple-perl 2.18-2Perl module for reading and writin ii perlmagick 7:6.5.1.0-1.1 Perl interface to the ImageMagick Versions of packages shutter recommends: pn libgoo-canvas-perl (no description available) pn libgtk2-imageview-perl (no description available) Versions of packages shutter suggests: pn gnome-web-photo(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535540: [offlineimap] folder sync is now random - patch attached
Package: offlineimap
Version: 6.1.1
--- Please enter the report below this line. ---
I can confirm this behavior in version 6.1.1.
The problem comes from the data structure used to save the queue of
folders to be synced. Replacing the dict by a list of lists fixes the
problem, by obviously keeping the order of the folder list (patch is
attached).
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.30
Debian Release: squeeze/sid
500 unstable-i386 emacs.orebokech.com
500 unstable-i386 debian.lcs.mit.edu
500 unstableemacs.orebokech.com
500 unstabledebian.lcs.mit.edu
500 testing-i386security.debian.org
500 testing-i386debian.lcs.mit.edu
500 testing security.debian.org
500 testing debian.lcs.mit.edu
500 squeeze-i386debathena.mit.edu
500 squeeze debathena.mit.edu
1 experimental-i386 debian.lcs.mit.edu
1 experimentaldebian.lcs.mit.edu
--- Package information. ---
Depends (Version) | Installed
==-+-
python(>= 2.5) | 2.5.4-2
python-support (>= 0.90.0) | 1.0.3
Package's Recommends field is empty.
Suggests (Version) | Installed
==-+-===
python-kerberos|
--- offlineimap.orig/accounts.py 2009-03-19 15:11:28.0 -0400
+++ offlineimap/accounts.py 2009-07-04 05:56:01.0 -0400
@@ -37,9 +37,9 @@
# folders haven't yet been added, or this account is once-only; drop signal
return
elif self.folders:
-for folder in self.folders:
+for foldernr in range(len(self.folders)):
# requeue folder
-self.folders[folder] = True
+self.folders[foldernr][1] = True
self.quick = False
return
# else folders have already been cleared, put signal...
@@ -49,22 +49,22 @@
def addfolders(self, remotefolders, autorefreshes, quick):
self.folderlock.acquire()
try:
-self.folders = {}
+self.folders = []
self.quick = quick
self.autorefreshes = autorefreshes
for folder in remotefolders:
# new folders are queued
-self.folders[folder] = True
+self.folders.append([folder, True])
finally:
self.folderlock.release()
def clearfolders(self):
self.folderlock.acquire()
try:
-for folder in self.folders:
-if self.folders[folder]:
+for folder, queued in self.folders:
+if queued:
# some folders still in queue
return False
-self.folders.clear()
+self.folders[:] = []
return True
finally:
self.folderlock.release()
@@ -74,10 +74,10 @@
dirty = True
while dirty:
dirty = False
-for folder in self.folders:
-if self.folders[folder]:
+for foldernr, (folder, queued) in enumerate(self.folders):
+if queued:
# mark folder as no longer queued
-self.folders[folder] = False
+self.folders[foldernr][1] = False
dirty = True
quick = self.quick
self.folderlock.release()
Bug#535540: folder sync order is now random
* Stefano Zacchiroli [2009-07-05 17:18:33 +0200]: > FWIW, also the mutt mailbox file generated via [mbnames] has random > ordering which, bizarrely, does not match the syncing order (nor the > one which would be prescribed by my syncing function). Hi Zack, As a matter of fact, that's how I noticed the bug, and the patch I posted fixes this too (as a side effect, it seems). Cheers, -- Nicolas Dandrimont BOFH excuse #374: It's the InterNIC's fault. signature.asc Description: Digital signature
Bug#535540: folder sync order is now random
* John Goerzen [2009-07-06 08:10:45 -0500]: > Hey guys, > > Can you try reverting patch 2e22b4123190c8ae434efb2bfb3d507694482644 and > let me know if that fixes it? I'd like to isolate which commit caused > the problem, and revert it, rather than try to patch on top of it. > > Other patches that might be culprits could be: > > d69176090c4afb220df566ef5ed5e653933be45e > 817c09a4607f45635a6f327cebc593e396723514 > 3847d0ba9d17f42cbb4ae15ea9cfb97aca2029ca > e1fb9492f84538df698d6a2f1cfa2738929ed040 > Reverting each one of the above patches (one by one) didn't solve the issue. After bisecting, the patch introducing the misbehavior is one of: 61567d0d3641bddab88911fc9e216c8f213525cf e1fb9492f84538df698d6a2f1cfa2738929ed040 147265ac391c9feeae88ddcac5b6685c87d4a39b Unfortunately I couldn't test the first two patches alone, because 61567d0d introduces the use of SigListener, which is defined in 147265ac. My patch modifies the SigListener introduced in the last commit referenced above. How would you like to proceed? Thanks for your work! -- Nicolas Dandrimont BOFH excuse #128: Power Company having EMP problems with their reactor signature.asc Description: Digital signature
Bug#535540: folder sync order is now random
* martin f krafft [2009-07-06 15:30:38 +0200]: > > e1fb9492f84538df698d6a2f1cfa2738929ed040 > > Reverting that one restores the order. Hm. I have messed something up somehow the first time, but yes, reverting this patch removes the misbehavior. Thanks, -- Nicolas Dandrimont signature.asc Description: Digital signature
Bug#613293: RFS: svgsalamander (updated, take 3)
Hi, I have contacted upstream with my questions about svgsalamander. He answered quickly but I took some time to get back to work. My latest work is available in pkg-java's git repo : git://git.debian.org/pkg-java/svgsalamander.git I updated the package for latest upstream (svn rev. 0095). Upstream doesn't intend to do and keep track of a formal release, so I'm keeping the debian version simple (well, modulo the 00, but anyways...). I removed use of the embedded batik code copy as upstream intends it for compatibility with Java5 and older. It is still in the source so the copyright info is still there. I think svgsalamander should be quite ready for upload now. Latest source is available from mentors.d.n at - URL: http://mentors.debian.net/debian/pool/main/s/svgsalamander - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/svgsalamander/svgsalamander_0095-1.dsc Thanks in advance, Nicolas Dandrimont (Keeping full message below for ITP documentation, forgot to Cc: it) Le 06/03/2011 à 16:11, Nicolas Dandrimont écrivit : > > Hi, > > I had some exams last week so I haven't had time to look into > svgsalamander again until today. I addressed most of the comments from > Niels in the new version I uploaded to mentors (and git). > > Le 26/02/2011 à 16:17, Niels Thykier écrivit : > > On 2011-02-19 18:49, Nicolas Dandrimont wrote: > > > The package can be found on mentors.debian.net: > > > - URL: http://mentors.debian.net/debian/pool/main/s/svgsalamander > > > - Source repository: deb-src http://mentors.debian.net/debian unstable > > > main > > > contrib non-free > > > - dget > > > http://mentors.debian.net/debian/pool/main/s/svgsalamander/svgsalamander_0089-1.dsc > > > > > > It is also available under git at > > > git://git.debian.org/pkg-java/svgsalamander.git > > > (Browser: http://git.debian.org/?p=pkg-java/svgsalamander.git;a=summary) > > > > > > This is my first Java package, so I'm sure I didn't get everything > > > right. Off the top of my head, here are some of my thoughts: > > > > > > - The jar is being signed at build-time. Should I disable this? > > > > > > > I have not tried to build it; else I would have been able to answer this > > myself. :P If signs automatically without requiring any interaction, > > then it is not a problem (build-wise, but the signature is probably not > > worth a lot then). If the build stops waiting for the user to (e.g.) > > supply a password, then it is definitely not okay (since then it will > > not be rebuildable on our auto-build machines). > > The jar files are automatically signed by a build-time-generated > temporary key. As this seems to be pointless, I just removed it > altogether. > > > > - I decided to install the javadoc at the same time as the > > > package. Should I split it in another package? > > > > > > > Yes please; javadoc tends to take up a lot more space than the jar files > > themselves. You should also make the javadoc link against the system > > javadoc (this requires a Build-Depends on default-jdk-doc plus the -doc > > packages of any package it depends plus [for ant] a couple of > href="/path/to/javadoc/" /> in the javadoc tag). > > Done. > > > > - I'll put the package under team-maintainance. If I understand the > > > Policy correctly, I should set: > > > ---8<--- > > > Maintainer: Debian Java Maintainers > > > > > > Uploaders: Nicolas Dandrimont > > > ---8<--- > > > even though I'm neither a DD nor a DM. Is that correct? > > > > > > > Yes. > > Done. > > > So; debian/docs is empty - if the file is not needed you should remove it. > > Done. > > > The copyright file does not list that > > svg-core/src/main/java/com/kitfox/svg/batik/RadialGradientPaintContext.java > > (and quite possibly other files) are Copyright Apache Software > > Foundation and under Apache-1.1 > > You should probably ping upstream about that. > > I updated the copyright file with the info for > svg-core/src/main/java/com/kitfox/svg/batik/*. Those seem to have been > taken verbatim from batik, but I don't know which version. I'm pinging > upstream about this to know : > - From which batik version those files were taken > - If the files were modified > - If it is at all possible to use the system batik library instead of > embedding a few source files... Which should be okay as long as the > Apache
Bug#613210: ITP: replicatorg -- Simple 3D printing program
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont * Package name: replicatorg Version : 0023 Upstream Author : Zach Hoeken, Marius Kintel, Adam Mayer et al. * URL : http://replicat.org/ * License : GPLv2 Programming Lang: Java (UI), Python (CAD file conversion backends) Description : Simple 3D printing program ReplicatorG is a simple, open-source 3D printing program. . It is designed to drive a Makerbot CupCake CNC, a RepRap machine, or any generic CNC machine that is able to understand G-code. . This software is able to directly drive the machine with a G-code file, or can process an STL file to generate the G-Code. An integrated interface allows the user to do simple transformations on the STL object before processing it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
