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 () | 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#1042734: binutils-mingw-w64 FTBFS: Patch debian/patches/specify-timestamp.patch does not apply
Control: tags -1 + patch pending
On Mon, Jul 31, 2023 at 11:37:39AM +0300, Adrian Bunk wrote:
> Source: binutils-mingw-w64
> Version: 11
> Severity: serious
> Tags: ftbfs
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/binutils-mingw-w64.html
> https://buildd.debian.org/status/fetch.php?pkg=binutils-mingw-w64=riscv64=11=1690696627=0
>
> ...
> pplying patch debian/patches/specify-timestamp.patch
> patching file upstream/bfd/peXXigen.c
> Hunk #2 FAILED at 840.
> 1 out of 2 hunks FAILED -- rejects in file upstream/bfd/peXXigen.c
> patching file upstream/ld/pe-dll.c
> Hunk #2 FAILED at 1232.
> 1 out of 2 hunks FAILED -- rejects in file upstream/ld/pe-dll.c
> patching file upstream/ld/emultempl/pe.em
> patching file upstream/ld/emultempl/pep.em
> Patch debian/patches/specify-timestamp.patch does not apply (enforce with -f)
> make[1]: *** [debian/rules:71: unpack] Error 1
>
A patch implementing SOURCE_DATE_EPOCH support for --insert-timestamp was merged
upstream, so this debian-specific implementation can be dropped.
http://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6badd1020f5bebd3f60a780b8e41a1b581046087
Attached is a git-format-patch for a NMU of binutils-mingw-w64 dropping the
patch. I've uploaded it to DELAYED/2.
Cheers,
Nicolas
From 1c70e29cafe59e1f099a546ae157eef62bbab0e6 Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont
Date: Tue, 8 Aug 2023 18:13:53 +0200
Subject: [PATCH] Drop specify-timestamp.patch, applied upstream in binutils
2.41 (Closes: #1042734)
---
debian/changelog | 8 ++
debian/patches/series | 1 -
debian/patches/specify-timestamp.patch | 128 -
3 files changed, 8 insertions(+), 129 deletions(-)
delete mode 100644 debian/patches/specify-timestamp.patch
diff --git a/debian/changelog b/debian/changelog
index 4ce45da..f254c82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+binutils-mingw-w64 (11+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop specify-timestamp.patch, applied upstream in binutils 2.41
+(Closes: #1042734)
+
+ -- Nicolas Dandrimont Tue, 08 Aug 2023 18:18:48 +0200
+
binutils-mingw-w64 (11) unstable; urgency=medium
* In preparation for binutils 2.41, drop pr30079.patch, merged
diff --git a/debian/patches/series b/debian/patches/series
index df17d1d..1d58fe7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,5 +1,4 @@
testsuite-timeout.patch
-specify-timestamp.patch
dont-run-objcopy.patch
disable-flags.patch
reproducible-import-libraries.patch
diff --git a/debian/patches/specify-timestamp.patch b/debian/patches/specify-timestamp.patch
deleted file mode 100644
index f268ea4..000
--- a/debian/patches/specify-timestamp.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-Description: Allow the PE timestamp to be specified
-Author: Stephen Kitt
-
a/upstream/bfd/peXXigen.c
-+++ b/upstream/bfd/peXXigen.c
-@@ -74,6 +74,9 @@
- #include
- #include
-
-+#include
-+#include
-+
- /* NOTE: it's strange to be including an architecture specific header
-in what's supposed to be general (to PE/PEI) code. However, that's
-where the definitions are, and they don't vary per architecture
-@@ -837,9 +840,36 @@
-
- /* Use a real timestamp by default, unless the no-insert-timestamp
- option was chosen. */
-- if ((pe_data (abfd)->timestamp) == -1)
--H_PUT_32 (abfd, time (0), filehdr_out->f_timdat);
-- else
-+ if ((pe_data (abfd)->timestamp) == -1) {
-+time_t now;
-+char *source_date_epoch;
-+unsigned long long epoch;
-+char *endptr;
-+
-+now = time (NULL);
-+source_date_epoch = getenv("SOURCE_DATE_EPOCH");
-+if (source_date_epoch) {
-+ errno = 0;
-+ epoch = strtoull(source_date_epoch, , 10);
-+ if ((errno == ERANGE && (epoch == ULLONG_MAX || epoch == 0))
-+ || (errno != 0 && epoch == 0)) {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: strtoull: %s\n",
-+ strerror(errno));
-+ } else if (endptr == source_date_epoch) {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: No digits were found: %s\n",
-+ endptr);
-+ } else if (*endptr != '\0') {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: Trailing garbage: %s\n",
-+ endptr);
-+ } else if (epoch > ULONG_MAX) {
-+_bfd_error_handler("Environment variable $SOURCE_DATE_EPOCH: value must be smaller than or equal to: %lu but was found to be: %llu\n",
-+ ULONG_MAX, epoch);
-+ } else {
-+now = epoch;
-+ }
-+}
-+H_PUT_32 (abfd, now, filehdr_out->f_timdat);
-+ } else
- H_PUT_32 (abfd, pe_data (abfd)->timestamp, filehdr_out->f_timda
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#992226: piuparts: bullseye is now stable
Control: tags -1 + pending Hi Sebastian, On Mon, Aug 16, 2021, at 08:37, Sebastian Ramacher wrote: > Since bullseye was release on Saturday, please change all jobs that > start from stable (e.g., stable2sid) to use bullseye instead of buster. I've just deployed piuparts 1.1.4 on piuparts.d.o, which updates the (old)*stable and testing aliases for the bullseye release. This should make the stable2* and testing2sid environments DTRT. I've also deployed a followup change to make sure the test environments for bullseye-pu, bullseye-security and bullseye2next, used by SRMs, are being created and handled. (currently deployed branch: https://salsa.debian.org/debian/piuparts/-/tree/tmp-1.1.4, until Andreas pushes his actual 1.1.4 branch on which I'll rebase the pejacevic changes). I'll leave this bug open until we've confirmed that all results are as expected (which should show up in the next piuparts-report run). Thanks for your work on bullseye! Cheers, -- Nicolas Dandrimont
Bug#982358: SIGABRT when rendering a geometry in GUI mode
Control: retitle -1 openscad: needs explicit dependency on the non-gles variant of libqt5gui On Tue, Feb 9, 2021, at 12:31, Torsten Paul wrote: > On 09.02.21 12:24, Nicolas Dandrimont wrote: > > OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.4 > > OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 > > OpenSCAD is not compatible with GLES. > > Looks like there needs a conflict setting for: > > ii libqt5gui5-gles 5.15.2+dfsg-3 Good catch! Replacing this package with libqt5gui5 (no gles) solved the issue. Looks like I ended up with libqt5gui5-gles last October during a partial upgrade, probably due to a temporary multiarch version desync? Haven't noticed this until now, as I don't really use many Qt apps. I'm not sure what the best way of solving this issue in the package metadata is. The cleanest would probably be having libqt5gui5-gles Breaks: openscad, but that needs coordination with the Qt maintainers. Supposedly, just making the dependency of openscad on libqt5gui5 explicit would work, but I don't know if the package name is the same on all arches. Thanks for the quick diagnosis, -- Nicolas Dandrimont
Bug#982358: SIGABRT when rendering a geometry in GUI mode -- missing attached file
Package: openscad
Version: 2021.01-1
Followup-For: Bug #982358
And here is the missing attached scad file...
--
Nicolas Dandrimont
//outer diameter (mm)
da=65;
//inner diameter (mm)
di=53;
//wall thikness (0.8 works great!)
w=0.8;
//funnel´s entrence / funnel´s biggest diameter (120 seems perfect for all
sizes)
bd=120;
dd=bd/2;
d1=di;
d2=da+1;
$fn=80/1;
///
Funnel/
///
rotate(a=180,v=[0,1,0])
translate([0,0,-40])
difference(){
union(){
cylinder (40,d1/2,dd+2*w);
//translate([0,0,-5])
//difference(){
//cylinder(5,d1/2,d1/2);
//cylinder(5,(d1-w*2)/2,(d1-w*2)/2);
//}
translate([0,0,-5])
difference(){
cylinder (40,(d2+2*w)/2,(d2+2*w)/2);
cylinder (40,d2/2,d2/2);
}
}
cylinder (40.01,d1/2-2*w,dd);
cylinder(5,(d1-w*2)/2,(d1-w*2)/2);
}
/
///Tamper
/
translate([dd+di/2+3,0,0]){
difference(){
union(){
cylinder(10,(d1/2)-2,(d1/2)-2);
translate([0,0,10])
cylinder(10,(d1/2)-2,7);
translate([0,0,10])
cylinder(25,9.5,7);
translate([0,0,35])
cylinder(10,7,9.5);
translate([0,0,45])
sphere(9.5);
}
translate([0,0,45])
rotate(a=90,v=[1,0,0])
cylinder(200,3,3,center=true);
}
}
Bug#982358: SIGABRT when rendering a geometry in GUI mode
context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #38 0x75bd345f in QEventDispatcherGlib::processEvents(QFlags) () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #39 0x75b7a8cb in QEventLoop::exec(QFlags) () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #40 0x75b82b40 in QCoreApplication::exec() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #41 0x5584123a in gui(std::vector, std::allocator >, std::allocator, std::allocator > > >&, boost::filesystem::path const&, int, char**) (inputFiles=, original_path=, argc=, argv=) at src/openscad.cc:847 #42 0x555f6557 in main(int, char**) (argc=, argv=0x7fffdea8) at src/openscad.cc:1188 (gdb) core-file No core file now. (gdb) generate-core-file openscad.sigabrt warning: target file /proc/720692/cmdline contained unexpected null characters Saved corefile openscad.sigabrt (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) n Program not restarted. (gdb) continue Continuing. [Thread 0x7fff77fff700 (LWP 720796) exited] [Thread 0x7fffacd61700 (LWP 720795) exited] [Thread 0x7fffad562700 (LWP 720794) exited] [Thread 0x7fffc8a20700 (LWP 720715) exited] [Thread 0x7fffc9221700 (LWP 720714) exited] [Thread 0x7fffc9a22700 (LWP 720713) exited] [Thread 0x7fffca223700 (LWP 720712) exited] [Thread 0x7fffd27fc700 (LWP 720708) exited] [Thread 0x7fffd2ffd700 (LWP 720707) exited] [Thread 0x7fffd37fe700 (LWP 720706) exited] [Thread 0x7fffd3fff700 (LWP 720705) exited] [Thread 0x7fffcbfff700 (LWP 720704) exited] [Thread 0x7fffe8b96700 (LWP 720703) exited] [Thread 0x7fffe9397700 (LWP 720702) exited] [Thread 0x7fffe9b98700 (LWP 720701) exited] [Thread 0x7fffea883700 (LWP 720699) exited] [Thread 0x7fffeb152700 (LWP 720698) exited] [Thread 0x7fffeb953700 (LWP 720697) exited] [Thread 0x71411700 (LWP 720696) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (quit) I can share a coredump if you think that would be helpful/appropriate, but it's around 2 GiB so it's going to take a while to upload... Cheers, Nicolas Dandrimont -- Package-specific info: Output of /usr/share/bug/openscad: $ glxinfo |grep 'OpenGL .* string:' OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.4 OpenGL core profile shading language version string: 4.60 OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.4 OpenGL shading language version string: 4.60 OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openscad depends on: ii lib3mf11.8.1+ds-3.1 ii libboost-filesystem1.74.0 1.74.0-8 ii libboost-program-options1.74.0 1.74.0-8 ii libboost-regex1.74.0 [libboost-regex1.74.0-icu67] 1.74.0-8 ii libc6 2.31-9 ii libcairo2 1.16.0-5 ii libdouble-conversion3 3.1.5-6.1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libglib2.0-0 2.66.6-2 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgmp10 2:6.2.1+dfsg-1 ii libharfbuzz0b 2.7.4-1 ii libmpfr6 4.1.0-3 ii libopencsg11.4.2-3 ii libqscintilla2-qt5-15 2.11.6+dfsg-2 ii libqt5core5a 5.15.2+dfsg-4 ii libqt5dbus55.15.2+dfsg-4 ii libqt5gamepad5 5.15.2-2 ii libqt5gui5-gles5.15.2+dfsg-3 ii libqt5multimedia5 5.15.2-2 ii libqt5network5 5.15.2+dfsg-4 ii libqt5widgets5
Bug#970870: postgresql-autodoc: incompatible with PostgreSQL >= 12
Package: postgresql-autodoc Version: 1.40-3 Severity: grave Tags: upstream sid bullseye Dear maintainer, postgresql-autodoc, as currently packaged in Debian, doesn't work with PostgreSQL 12, which is the current default version of PostgreSQL in testing and sid (it works fine with PostgreSQL 11 which is shipped with buster). The failure mode is the following (excuse my French): $ postgresql_autodoc -d softwareheritage-dev -f autodoc/db-schema DBD::Pg::st execute failed: ERREUR: la colonne � adsrc � n'existe pas LIGNE 40 : adsrc ^ at /usr/bin/postgresql_autodoc line 687. DBD::Pg::st fetchrow_hashref failed: no statement executing at /usr/bin/postgresql_autodoc line 689. [...] Use of uninitialized value in numeric comparison (<=>) at /usr/bin/postgresql_autodoc line 991. [...] Use of uninitialized value in numeric comparison (<=>) at /usr/bin/postgresql_autodoc line 1466. [...] This generates dot files with a lot of column missings. Upstream seems to have picked up development on GitHub at https://github.com/cbbrowne/autodoc. This repository shows a bunch of commits on top of the current Debian version which should fix at least this bug. Thank you, Nicolas -- System Information: Debian Release: bullseye/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 5.8.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgresql-autodoc depends on: ii libdbd-pg-perl 3.14.2-1 ii libhtml-template-perl 2.97-1 ii libterm-readkey-perl 2.38-1+b1 ii perl 5.30.3-4 Versions of packages postgresql-autodoc recommends: ii dia 0.97.3+git20160930-9 ii docbook-defguide [docbook-book] 2.0.17+svn9912-2 ii firefox [www-browser] 80.0.1-1 ii firefox-esr [www-browser] 78.2.0esr-1 ii google-chrome-stable [www-browser] 85.0.4183.102-1 ii graphviz2.42.2-4 postgresql-autodoc suggests no packages. -- no debconf information
Bug#970379: Follow up: Full build log
On Tue, Sep 15, 2020, at 12:30, Sven Mueller wrote: > I also noticed that I couldn't find any reverse dependencies, so one course > of action might be removal of the package from Debian. Hey Sven, facter definitely build-depends on libcpp-hocon-dev. In turn, puppet depends on facter. facter needs an update to a newer upstream release. I think facter 4.x completely drops the native code in favor of full ruby. Then we can probably remove cpp-hocon. Thanks for the full build log! > Full build log (ignore the weird internal mirror, packages are exactly as > currently in Debian unstable) attached. > > *Attachments:* > * cpp-hocon_0.1.7-1_amd64-2020-09-15T10:19:53Z.build Cheers, -- Nicolas Dandrimont
Bug#956708: New upstream release 1.4.0 available (with security fixes for SASL/SCRAM auth)
Package: src:librdkafka Version: 1.3.0-1 Severity: important Tags: patch security upstream Dear maintainers, Upstream for librdkafka has recently released version 1.4.0 of the library[1]. [1] https://github.com/edenhill/librdkafka/releases/tag/v1.4.0 The release notes mention that two security issues[2,3] in the way SASL/SCRAM authentication was implemented. SASL/SCRAM was introduced in v0.11.0, and the offending code was introduced at that point[4], so the security bug affects the version in stable as well. [2] https://github.com/edenhill/librdkafka/commit/9b468d2fafbdc23f2326e174a6bd92e70457ce6d [3] https://github.com/edenhill/librdkafka/commit/8f7a4c858afc8ff24672426473448c3e0c56cfc3 [4] https://github.com/edenhill/librdkafka/blob/v0.11.0/src/rdkafka_sasl_scram.c lines 91 (nonce bug) and 340-341 (buffer overflow) I guess these patches could be uploaded as a stable update (but I haven't looked at older security fixes if some more would be relevant). I've prepared the update for sid[5] and I can upload it if you'd like (I'm currently using a package of a git checkout of a pre-1.4.0 commit in production, and will update to 1.4.0 there anyway). [5] https://salsa.debian.org/olasd/librdkafka branches debian/sid and pristine-tar Thanks for your work! Nicolas -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 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) LSM: AppArmor: enabled
Bug#953756: [Piuparts-devel] Bug#953756: piuparts: Please add exception for dselect cmethopt file
Control: tags -1 pending On Fri, Mar 13, 2020, at 00:02, Guillem Jover wrote: > The piuparts run for dselect is failing: > > <https://piuparts.debian.org/experimental/fail/dselect_1.20.0.log> > > because that version started removing a file it owns during package > purge. > > The involved file («/var/lib/dpkg/cmethopt») is managed by dselect to > track the current download method, but is also created by debootstrap > while it is doing the apt/dselect setup. > > So I guess it would need an exception for this. Hi Guillem, Thanks for the report! I've added the exception to the develop branch[1], updated the piuparts.d.o runner, and triggered another run of piuparts on dselect/1.2.0, which passed successfully. [1] https://salsa.debian.org/debian/piuparts/-/commit/b61234940b3b650d91870fd58503853cf025758b I'll close this bug when uploading a new version of piuparts (probably at some point this weekend). Cheers! -- Nicolas Dandrimont
Bug#949763: python-azure: please consider uploading a new version
* Luca Boccassi [2020-01-30 23:04:29 +]: > control: tags -1 patch > > On Fri, 24 Jan 2020 17:04:36 + Luca Boccassi > wrote: > > Source: python-azure > > Version: 20181112+git-3 > > Severity: wishlist > > Blocks: 930413 > > > > Dear Maintainer(s), > > > > Please consider uploading the latest version of python-azure. It is > > needed for the upload of azure-cli. > > > > If time is lacking, I'm happy to do an NMU. > > > > Thank you! > > Dear Maintainer(s), > > I have opened MRs on Salsa to update the package: > > https://salsa.debian.org/python-team/modules/python-azure/merge_requests/1 > https://salsa.debian.org/python-team/modules/python-azure/merge_requests/2 > https://salsa.debian.org/python-team/modules/python-azure/merge_requests/3 > > At the same time the MR also fixes build reproducibility. > > dh_python indicates some missing dependencies, I'll check if they are > mandatory or optional. > > Unless there are any objections and/or plans to update the package by > the maintainers, I plan to do a delayed NMU with these changes later > next week once the deps are sorted. I'll send another notice with a > debdiff if/when I do so. Hi, Sorry for the delay responding! Please feel free to upload without (more) delay! I also suggest that you join the team so you can commit directly to the VCS (and add yourself as Uploader? *cough*). If you really don't feel like it then I'll look at merging your stuff in. Thanks for your work! -- Nicolas Dandrimont signature.asc Description: PGP signature
Bug#949685: Please drop dependencies on python3-pip / python3-wheel
Package: python3-pypandoc
Version: 1.4+ds0-1.1
Severity: normal
Dear maintainer,
Upstream pypandoc records pip and wheel in its setup.py as install_requires.
These requirements get carried over to the python3-pypandoc dependencies via
${python3:Depends}. However, AFAICT, nothing in pypandoc depends on pip or wheel
at runtime.
Please consider dropping these requirements, which would trim down the
dependency tree of pypandoc considerably (as python3-pip itself recommends
build-essential).
Thanks!
-- System Information:
Debian Release: bullseye/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-2-amd64 (SMP w/8 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)
LSM: AppArmor: enabled
Versions of packages python3-pypandoc depends on:
ii pandoc 2.5-3
ii python33.7.5-3
ii python3-pip18.1-6
ii python3-pkg-resources 44.0.0-1
ii python3-wheel 0.33.6-2
python3-pypandoc recommends no packages.
python3-pypandoc suggests no packages.
-- no debconf information
Bug#896095: Current status
Bug#946457: Please package new upstream version 1.4.7 (performance regressions in 1.4.6)
Package: src:python-kafka Version: 1.4.6-1 Severity: important Tags: upstream Dear maintainer, python-kafka versions 1.4.5 and 1.4.6 suffer from large performance regressions in the consumer implementation (some people have reported a 4-8x throughput reduction upstream at https://github.com/dpkp/kafka-python/issues/1888). Version 1.4.7 has been released a while ago which fixes these performance regressions. Please consider uploading this new version. Thank you! -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN 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) LSM: AppArmor: enabled
Bug#925166: pg_createcluster: datadir gets created in / when using relative paths
Package: postgresql-common Version: 200 Severity: normal Dear maintainer, When doing the upgrade of a set of postgresql clusters from 10 to 11, while in directory /srv/softwareheritage/postgres/11, I ended up typing: LC_ALL=C.UTF-8 pg_createcluster -d ./testdedup 11 testdedup Instead of the expected /srv/softwareheritage/postgres/11/testdedup data directory, this created a data directory /testdedup at the root of the filesystem. I'm guessing directory argument parsing/resolution should happen before the chdir '/', but my Perl is too rusty to prepare a cogent patch, sorry! Cheers, Nicolas -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgresql-common depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.71 ii lsb-base 10.2019031300 ii postgresql-client-common 200 ii procps2:3.3.15-2 ii ssl-cert 1.0.39 ii ucf 3.0038+nmu1 Versions of packages postgresql-common recommends: ii e2fsprogs 1.45.0-1 ii logrotate 3.14.0-4 Versions of packages postgresql-common suggests: ii libjson-perl 4.02000-1 -- debconf information excluded
Bug#921034: Depends on MaxMind GeoIP Legacy databases - superseded by GeoIP2
Package: libnginx-mod-http-geoip Version: 1.14.2-2 Severity: important Dear maintainer, In its current form, the geoip module for nginx depends on the MaxMind GeoIP database in the Legacy format, the free version of which (GeoLite Legacy) has been deprecated since January 2018 and discontinued at the beginning of 2019. https://support.maxmind.com/geolite-legacy-discontinuation-notice/ Paying customers of MaxMind still get access to the GeoIP Legacy database as far as I can tell, however people who used the royalty-free option such as the DebConf Video Team can't do that any longer. To make sure IP Geolocation functionality stays functional long-term in nginx, please consider providing a GeoIP2 module such as https://github.com/leev/ngx_http_geoip2_module. Thanks for your work on nginx! -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnginx-mod-http-geoip depends on: ii libc6 2.28-5 ii libgeoip1 1.6.12-1 ii nginx-common 1.14.2-2 libnginx-mod-http-geoip recommends no packages. libnginx-mod-http-geoip suggests no packages. -- no debconf information
Bug#921030: Fails to import the ansible module since its migration to Python 3
Package: ansible-lint Version: 3.4.20+git.20180203-1 Severity: grave Tags: sid Dear maintainer, Running ansible-lint with the current ansible version in sid results in an ImportError for the ansible Python 2 module. The ansible maintainers have migrated the ansible module to Python 3 so I expect this migration also needs to happen with ansible-lint. This will also affect testing as soon as ansible migrates, which AFAICT should happen tomorrow. Thanks for your work! -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ansible-lint depends on: ii ansible 2.7.6+dfsg-1 ii python 2.7.15-4 ii python-six 1.12.0-1 ii python-yaml 3.13-2 ansible-lint recommends no packages. ansible-lint suggests no packages. -- no debconf information
Bug#918779: r10k: uninitialized constant Cri::Error
Package: r10k Version: 2.6.3-1 Followup-For: Bug #918779 Control: severity -1 grave Control: tags -1 + buster sid Dear maintainer, I'm bumping the severity of this bug as this makes the current combination of r10k and ruby-cri versions in buster and sid unusable. Thanks for maintaining r10k! Nicolas -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages r10k depends on: ii ruby1:2.5.1 ii ruby-colored1.2-2 ii ruby-cri2.15.2-1 ii ruby-gettext-setup 0.30-2 ii ruby-log4r 1.1.10-4 ii ruby-minitar0.6.1-1 ii ruby-multi-json 1.12.1-1 ii ruby-puppet-forge 2.2.9-2 ii ruby-rugged 0.27.4+ds-1 Versions of packages r10k recommends: ii git 1:2.20.1-1 r10k suggests no packages. -- no debconf information
Bug#913530: [Python-modules-team] Bug#913530: crashes because of html5lib incompatibility
Control: tags -1 + unreproducible moreinfo
Hi!
* Antoine Beaupre [2018-11-11 17:14:52 -0500]:
> Package: python3-bleach
> Version: 2.1.3-1
> Severity: critical
>
> In current Debian buster, with the Python 3.6 interpreter, bleach
> completely fails to load as a module:
>
> $ python3
> Python 3.6.7 (default, Oct 21 2018, 08:08:16)
> [GCC 8.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import bleach
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python3/dist-packages/bleach/__init__.py", line 8, in
>
> from bleach.linkifier import (
> File "/usr/lib/python3/dist-packages/bleach/linkifier.py", line 7, in
>
> from html5lib.filters.sanitizer import allowed_protocols
> ImportError: cannot import name 'allowed_protocols'
On an up-to-date sid system, at least with the same package versions as your
system:
$ python3.6
Python 3.6.7 (default, Oct 21 2018, 08:08:16)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bleach
>>> bleach.__file__
'/usr/lib/python3/dist-packages/bleach/__init__.py'
>>> import html5lib
>>> html5lib.__file__
'/usr/lib/python3/dist-packages/html5lib/__init__.py'
>>> from html5lib.filters.sanitizer import allowed_protocols
>>> allowed_protocols
frozenset({'news', 'callto', 'telnet', 'xmpp', 'rsync', 'data', 'nntp', 'irc',
'gopher', 'feed', 'ed2k', 'https', 'webcal', 'urn', 'ftp', 'rtsp', 'afs',
'http', 'tag', 'mailto', 'ssh', 'aim', 'sftp'})
The debci tests for python-readme-renderer, which itself imports bleach, are
also happy (and have always been since the upload of readme-renderer in April).
Please show what html5lib.__file__ returns on your system?
> [...]
>
> The simplest fix for this would probably be to upgrade bleach to the
> latest release. Indeed, this command works around the problem
> completely:
>
> sudo pip install bleach
I have the feeling this may be your problem; Don't ever ever install packages
system-wide with pip, as they will shadow the modules that are installed by
Debian, and will never be upgraded, which will lead to all kinds of
weirdnesses.
If my intuition is correct, and an old html5lib has been installed by pip,
you'll want to purge the contents of /usr/local/lib/python3*/dist-packages/ (or
~/.local/lib/python3.6/dist-packages) to fix your system.
Hope this helps,
--
Nicolas Dandrimont
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first.
(Arno Schaefer's .sig)
signature.asc
Description: PGP signature
Bug#913338: dh-python: Support PEP440 "Compatible release" dependency version specifiers
Package: dh-python
Version: 3.20180927
Severity: wishlist
Tags: patch
Dear maintainer,
While packaging python-azure, I noticed a bunch of "Cannot find package that
provides _ [...]" messages.
It turns out that the azure stuff makes extensive use of the PEP440 "Compatible
release" ``module ~= version`` syntax in its install_requires.
Attached is a patch adding support for these version restrictions for packages
that are marked as compliant with PEP396. Even for modules that aren't marked as
such, having ~= recognized as a valid version specifier operator, avoids pydist
looking for bogus `_` modules: the tilde stops being mapped to an
underscore.
Thanks for considering!
Nicolas
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500,
'stable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-rc7-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)
LSM: AppArmor: enabled
Versions of packages dh-python depends on:
ii python33.6.7-1
ii python3-distutils 3.7.1-1
dh-python recommends no packages.
Versions of packages dh-python suggests:
ii dpkg-dev 1.19.2
ii libdpkg-perl 1.19.2
-- no debconf information
>From efa82c3385904a03d7fb5d1949d653e3de77ecfc Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont
Date: Fri, 9 Nov 2018 17:29:18 +0100
Subject: [PATCH] Support "Compatible release" version specifiers in the
requires parser
This adds support for ~= version specifiers as proposed in
https://www.python.org/dev/peps/pep-0440/#compatible-release
---
dhpython/pydist.py| 38 --
tests/test_depends.py | 22 ++
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/dhpython/pydist.py b/dhpython/pydist.py
index 7372a50..42b1ec1 100644
--- a/dhpython/pydist.py
+++ b/dhpython/pydist.py
@@ -52,7 +52,7 @@ REQUIRES_RE = re.compile(r'''
\s*
\(? # optional parenthesis
(?: # optional minimum/maximum version
-(?P<=?|>=?|==|!=)
+(?P<=?|>=?|==|!=|~=)
\s*
(?P(\w|[-.])+)
(?: # optional interval minimum/maximum version
@@ -70,6 +70,7 @@ DEB_VERS_OPS = {
'==': '=',
'<': '<<',
'>': '>>',
+'~=': '>=',
}
@@ -139,7 +140,7 @@ def guess_dependency(impl, req, version=None, bdep=None,
version = Version(version)
# some upstreams have weird ideas for distribution name...
-name, rest = re.compile('([^!><= \(\)\[]+)(.*)').match(req).groups()
+name, rest = re.compile('([^!><=~ \(\)\[]+)(.*)').match(req).groups()
# TODO: check stdlib and dist-packaged for name.py and name.so files
req = safe_name(name) + rest
@@ -173,6 +174,10 @@ def guess_dependency(impl, req, version=None, bdep=None,
o2 = _translate_op(req_d['operator2'])
v2 = _translate(req_d['version2'], item['rules'],
item['standard'])
d += ", %s (%s %s)" % (item['dependency'], o2, v2)
+elif req_d['operator'] == '~=':
+o2 = '<<'
+v2 = _translate(_max_compatible(req_d['version']),
item['rules'], item['standard'])
+d += ", %s (%s %s)" % (item['dependency'], o2, v2)
return d
elif accept_upstream_versions and req_d['version'] and \
req_d['operator'] not in (None,'!='):
@@ -181,6 +186,9 @@ def guess_dependency(impl, req, version=None, bdep=None,
if req_d['version2'] and req_d['operator2'] not in (None,'!='):
o2 = _translate_op(req_d['operator2'])
d += ", %s (%s %s)" % (item['dependency'], o2,
req_d['version2'])
+elif req_d['operator'] == '~=':
+o2 = '<<'
+d += ", %s (%s %s)" % (item['dependency'], o2,
_max_compatible(req_d['version']))
return d
else:
if item['dependency'] in bdep:
@@ -305,6 +313,32 @@ def _pl2py(pattern):
return GROUP_RE.sub(r'\\g<\1>', pattern)
+def _max_compatible(version):
+"""Return the maximum version compatible with `version` in PEP440 terms,
+used by ~= requires version specifiers.
+
+https://www.python.org/dev/peps/pep-0440/#compatible-release
+
+>>> _max_compatible('2.2')
+'3'
+>>> _max_compatible('1.4.5')
+'1.5'
+>>> _max_compatible('1.3.alpha4')
+'2'
+>>> _max_compatible('2.1.3.post5')
+
Bug#902631: devscripts: CI fails in unstable due to Python 3.7
Control: tags -1 + patch * Thomas Goirand [2018-08-25 22:02:51 +0200]: > Hi Sando, > > I do support uploading 2 source packages, one for py2, and one for py3. > This is the most reasonable solution. Worst case, if that cannot be > done, then we got to move forward and restore Py3 support (and > eventually drop Py2), but I prefer the former solution. > > The issue has been opened for nearly 2 months now, with nearly a month > without any news, and this makes me a bit nervous, as I need the py3 > support to be restored. > > What's holding you off more? Hi, As a proof of concept I've gone and done the changes needed to pull this off on a fork of the git repo in my personal namespace. https://salsa.debian.org/olasd/astroid The astroid source package is in the master / upstream branches; The astroid2 source package is in the astroid2 / upstream-1.x branches. I had to do some wrangling of the astroid source package, to convert it to pybuild, because the default setuptools buildsystem only works when python2 is in the build depends. I could see a point in splitting the git repositories but I don't think that's very critical. I'm happy to do a NMU in a week so that we can move forward with the split package plan. Cheers, -- Nicolas Dandrimont We come to bury DOS, not to praise it. (Paul Vojta, vo...@math.berkeley.edu, paraphrasing a quote of Shakespeare) signature.asc Description: PGP signature
Bug#902900: python3-celery: python3-celery fails to install with Python 3.7
found 902900 4.2.0-1 tags 902900 + upstream forwarded 902900 https://github.com/celery/celery/pull/4852 user debian-pyt...@lists.debian.org usertag 902900 + python3.7 thanks * Antoine R. Dumont [2018-07-03 10:09:56 +0200]: > Package: python3-celery > Version: 4.1.0-4 > Severity: serious > Hello, > > Setting up python3-celery (4.2.0-1) ... > File "/usr/lib/python3/dist-packages/celery/backends/redis.py", line 22 > from . import async, base > ^ > SyntaxError: invalid syntax > > File "/usr/lib/python3/dist-packages/celery/backends/rpc.py", line 20 > from .async import AsyncBackendMixin, BaseResultConsumer > ^ > SyntaxError: invalid syntax > > dpkg: error processing package python3-celery (--configure): > installed python3-celery package post-installation script subprocess > returned error exit status 1 Hi, Work on this issue seems to be ongoing upstream. Adding the relevant tags. Cheers, -- Nicolas Dandrimont signature.asc Description: PGP signature
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
* Anthony Towns <a...@erisian.com.au> [2018-04-18 18:02:22 +1000]: > Nicolas Dandrimont wrote: > > * Martin Michlmayr <t...@cyrius.com> [2018-03-30 17:14:49 +0200]: > > > beancount 2.0 was released a few days ago so it's time to get this > > > into Debian. > > > Anyone interested in packaging it? It's Python code. > > I've been meaning to look into this for a while, as I've been using > > beancount in an org I'm treasurer of. > > I'll put this in the python-team/applications group on > > salsa. Comaintainers welcome! > > Any luck here? I didn't see anything on salsa yet, but maybe I missed it. > Don't suppose you've looked at packaging fava as well? Hi! I've finally gotten around to finalizing the beancount packaging. I've run across a few test failures on the released 2.0.0, but I noticed that they have been fixed by tbm and Martin Blais in upstream PRs; I've followed the easy route and updated the packaging to a snapshot of the upstream mercurial repo: some of the test failures were fixed after a refactoring of the external price source handling, so the patch doesn't apply cleanly to 2.0.0... Yay. The packaging is on https://salsa.debian.org/python-team/applications/beancount and uses a standard gbp buildpackage (with pristine-tar) workflow. The only thing that's not working currently is the dependency split between default dependencies and optional dependencies for extra features. It's not exactly critical but it'd be nice to have. I'd also be happy with better wording for the long description of the packages. Once that's done and if you're happy I think the package should be ready for upload. Cheers, -- Nicolas Dandrimont BOFH excuse #223: The lines are all busy (busied out, that is -- why let them in to begin with?). signature.asc Description: PGP signature
Bug#896993: ITP: python-cmarkgfm -- GitHub-flavored Markdown renderer Python bindings
Package: wnpp Owner: Nicolas Dandrimont <ol...@debian.org> Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Control: block 896992 by -1 * Package name: python-cmarkgfm Version : 0.4.1 Upstream Author : Thea Flowers, The Python Packaging Authority (PyPA) * URL : https://github.com/jonparrott/cmarkgfm * License : Expat and BSD-2-Clause Programming Lang: Python Description : GitHub-flavored Markdown renderer Python bindings cmark is an extended version of the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec. The cmark-gfm fork adds GitHub Flavored Markdown extensions to the upstream implementation, as defined in the spec. This package provides Python bindings for the cmark-gfm library. This is a dependency for python-readme-renderer, which it itself a dependency for devpi-web. This will be packaged under the Debian Python Modules Team. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#896992: ITP: python-readme-renderer -- Library to safely render arbitrary README files into HTML
Package: wnpp Owner: Nicolas Dandrimont <ol...@debian.org> Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Control: block 896097 by -1 * Package name: python-readme-renderer Version : 20.0 Upstream Author : Donald Stufft * URL : https://github.com/pypa/readme_renderer * License : Apache-2.0 Programming Lang: Python Description : Library to safely render arbitrary README files into HTML Readme Renderer is a library that will safely render arbitrary README files into HTML. It is designed to be used in the PyPI Warehouse to render the long_description for packages. It can handle Markdown, reStructuredText (.rst), and plain text. This package is a dependency for devpi-web, and will be maintained within the Debian Python Modules Team. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#785048: ITP: python-pyramid-chameleon -- Chameleon templating addon for the Pyramid web application framework
Control: retitle 785048 ITP: python-pyramid-chameleon -- Chameleon templating addon for the Pyramid web application framework Control: owner 785048 ! Control: block 896097 by 785048 Hi, devpi-web depends on pyramid_chameleon, so I'm packaging it under the DPMT. * Ansgar Burchardt <ans...@debian.org> [2015-05-11 20:53:43 +0200]: > * License : BSD-4-clause, with non-free docs (will be removed) Looking at the git history of the project the docs seem to have been rewritten from scratch rather than imported from Pylons, and are licensed under the "standard" Pylons project BSD-4-clause license. I've therefore packaged them. Cheers, -- Nicolas Dandrimont signature.asc Description: PGP signature
Bug#855908: marked as done (hiro: FTBFS: test_segment_not_complete_error [...] AssertionError: False is not true)
45:
> ResourceWarning: unclosed file <_io.TextIOWrapper name=3 encoding='UTF-8'>
> self.assertEquals(int(time.time()), int(os.popen("date
> +%s").read().strip()))
> ok
> test_freeze_target (tests.test_context_mgr.TestTimelineContext) ...
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_context_mgr.py:91:
> DeprecationWarning: Please use assertAlmostEqual instead.
> self.assertAlmostEquals(time.time(), 0, 1)
> ok
> test_rewind (tests.test_context_mgr.TestTimelineContext) ... ok
> test_unfreeze (tests.test_context_mgr.TestTimelineContext) ...
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_context_mgr.py:116:
> ResourceWarning: unclosed file <_io.TextIOWrapper name=3 encoding='UTF-8'>
> self.assertTrue(int(time.time()) - int(os.popen("date
> +%s").read().strip()) <= 1)
> ok
> test_scale_up_runner (tests.test_runners.TestASyncRunner) ... ok
> test_scale_up_runner_fail (tests.test_runners.TestASyncRunner) ... ok
> test_segment_not_complete_error (tests.test_runners.TestASyncRunner) ...
> FAIL
> test_scale_up_runner (tests.test_runners.TestSyncRunner) ...
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_runners.py:17:
> DeprecationWarning: Please use assertEqual instead.
> self.assertEquals(f.get_response(), 1)
> ok
> test_scale_up_runner_fail (tests.test_runners.TestSyncRunner) ... ok
>
> ==
> FAIL: test_segment_not_complete_error (tests.test_runners.TestASyncRunner)
> --
> Traceback (most recent call last):
> File "«BUILDDIR»/.pybuild/pythonX.Y_3.5/build/tests/test_runners.py",
> line 59, in test_segment_not_complete_error
> self.assertTrue(f.get_execution_time() < 1 )
> AssertionError: False is not true
>
> --
> Ran 18 tests in 10.016s
>
> FAILED (failures=1)
> E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: cd
> «BUILDDIR»/.pybuild/pythonX.Y_3.5/build; python3.5 -m unittest discover -v
> dh_auto_test: pybuild --test -i python{version} -p 3.5 returned exit code 13
> debian/rules:5: recipe for target 'build' failed
> make: *** [build] Error 25
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> […]
>
> The full build log is attached.
>
>
> Regards,
>
> --
> ,''`.
> : :' : Chris Lamb
> `. `'` la...@debian.org / chris-lamb.co.uk
>`-
> Date: Tue, 24 Apr 2018 16:50:40 +
> From: Nicolas Dandrimont <ol...@debian.org>
> To: 855908-cl...@bugs.debian.org
> Subject: Bug#855908: fixed in hiro 0.5-1
> Message-Id: <e1fb19m-000aru...@fasolo.debian.org>
>
> Source: hiro
> Source-Version: 0.5-1
>
> We believe that the bug you reported is fixed in the latest version of
> hiro, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed. If you
> have further comments please address them to 855...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Nicolas Dandrimont <ol...@debian.org> (supplier of updated hiro package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 24 Apr 2018 18:29:51 +0200
> Source: hiro
> Binary: python-hiro python3-hiro python-hiro-doc
> Architecture: source all
> Version: 0.5-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Modules Team
> <python-modules-t...@lists.alioth.debian.org>
> Changed-By: Nicolas Dandrimont <ol...@debian.org>
> Description:
> python-hiro - time manipulation utilities for Python - Python 2.X
> python-hiro-doc - time manipulation utilities for Python - documentation
> python3-hiro - time manipulation utilities for Python
> Closes: 855908
> Changes:
> hiro (0.5-1) unstable; urgency=medium
> .
>[ Ondřej Nový ]
>* d/control: Set Vcs-* to salsa.debian.org
>* d/copyright: Use https protocol in Format field
> .
>[ Nicolas Dandrimont ]
>* New upstream release (Closes: #855908)
>* Update Standards-Version to 4.1.4 (no changes)
>* Bump
Bug#896097: ITP: devpi-web -- PyPI server and packaging/testing/release tool - Web and search component
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: devpi-web Version : 3.2.2 Upstream Author : Holger Krekel et al. * URL : https://github.com/devpi/devpi * License : MIT Programming Lang: Python Description : PyPI server and packaging/testing/release tool - Web and search component devpi provides a powerful PyPI-compatible server and complementary command-line tool to drive packaging, testing and release activities with Python. . Its main features are: - fast PyPI mirror - uploading, testing and staging with private indexes - index inheritance - web interface and search - replication - import/export - Jenkins integration . This package provides the web frontend and search component for the devpi server This will be maintained in the Python Applications Packaging Team.
Bug#896096: ITP: devpi-client -- PyPI server and packaging/testing/release tool - Command-line client
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: devpi-client Version : 4.0.1 Upstream Author : Holger Krekel et al. * URL : https://github.com/devpi/devpi * License : MIT Programming Lang: Python Description : PyPI server and packaging/testing/release tool - Command-line client devpi provides a powerful PyPI-compatible server and complementary command-line tool to drive packaging, testing and release activities with Python. . Its main features are: - fast PyPI mirror - uploading, testing and staging with private indexes - index inheritance - web interface and search - replication - import/export - Jenkins integration . This package provides the command-line client for the devpi server I will maintain this package in the Python Applications Packaging Team.
Bug#896095: ITP: devpi-server -- PyPI server and packaging/testing/release tool - Server
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: devpi-server Version : 4.4.0 Upstream Author : Holger Krekel et al. * URL : https://github.com/devpi/devpi * License : MIT Programming Lang: Python Description : PyPI server and packaging/testing/release tool - Server devpi provides a powerful PyPI-compatible server and complementary command-line tool to drive packaging, testing and release activities with Python. . Its main features are: - fast PyPI mirror - uploading, testing and staging with private indexes - index inheritance - web interface and search - replication - import/export - Jenkins integration . This package provides the devpi server component. I will maintain this package inside the Python Applications Packaging Team.
Bug#896094: ITP: devpi-common -- PyPI server and packaging/testing/release tool - Common modules
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: devpi-common Version : 3.3.2 Upstream Author : Holger Krekel et al. * URL : https://github.com/devpi/devpi * License : MIT Programming Lang: Python Description : PyPI server and packaging/testing/release tool - Common modules devpi provides a powerful PyPI-compatible server and complementary command-line tool to drive packaging, testing and release activities with Python. . Its main features are: - fast PyPI mirror - uploading, testing and staging with private indexes - index inheritance - web interface and search - replication - import/export - Jenkins integration . This package provides the base modules common to both devpi's server and client components. I will maintain the package in the Debian Python Modules Team.
Bug#895938: pypy-lib: ships the pypy-cffi pydist-override file in the wrong place
Package: pypy-lib
Version: 5.10.0+dfsg-3+b1
Severity: normal
Tags: patch
Hi,
pypy-lib ships a pydist override file for its built-in cffi module in
/usr/share/dh-python/dist/pypy/pypy-cffi. However, dh-python looks for those
files in /usr/share/pypy/dist/.
This makes builds of packages depending on cffi warn with:
I: dh_pypy pydist:220: Cannot find package that provides cffi. Please add
package that provides it to Build-Depends or add "cffi pypy-cffi" line to
debian/pypydist-overrides or add proper dependency to Depends by hand and
ignore
this info.
and, of course, the cffi backend version machinery is ignored.
As far as I can tell, the /usr/share/dh-python/dist path seems to be for
pydist-overrides shipped by dh-python directly.
The (untested) attached patch might do the right thing.
Thanks for considering,
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'buildd-unstable'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.15.0-1-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)
LSM: AppArmor: enabled
Versions of packages pypy-lib depends on:
ii dpkg 1.19.0.5
pypy-lib recommends no packages.
pypy-lib suggests no packages.
-- no debconf information
>From 0ef3df76767debdc3b0445019ab66049d2f1396a Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont <ol...@debian.org>
Date: Tue, 17 Apr 2018 18:13:21 +0200
Subject: [PATCH] Fix pypydist-override path
---
debian/scripts/gen-backend-versions.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/scripts/gen-backend-versions.py
b/debian/scripts/gen-backend-versions.py
index 36cdc37b..9dd5fa80 100755
--- a/debian/scripts/gen-backend-versions.py
+++ b/debian/scripts/gen-backend-versions.py
@@ -66,7 +66,7 @@ with codecs.open('debian/pypy-lib.substvars', 'a',
encoding='UTF-8') as f:
with codecs.open('debian/pypy.substvars', 'a', encoding='UTF-8') as f:
f.write('pypy-abi={}\n'.format(pypy_abi()))
-path = 'debian/pypy-lib/usr/share/dh-python/dist/pypy'
+path = 'debian/pypy-lib/usr/share/pypy/dist'
os.makedirs(path)
with codecs.open(os.path.join(path, 'pypy-cffi'), 'w', encoding='UTF-8') as f:
f.write('cffi pypy-cffi-backend-api-min (<= {target}), '
--
2.17.0
Bug#864156: RFP: python-argon2 -- Python bindings for the Argon2 password hash
Control: retitle -1 ITP: python-argon2 -- Python bindings for the Argon2 password hashing algorithm Control: owner -1 ! * Federico Ceratto <feder...@debian.org> [2017-06-04 15:02:57 +0100]: > Package: wnpp > Severity: wishlist > > * Package name: python-argon2 > Version : 0.1.10 > Upstream Author : Ilya Moroz > * URL : https://pypi.python.org/pypi/argon2 > * License : CC0 > Programming Lang: Python > Description : Python bindings for the Argon2 password hash > > The Argon2 library is already packaged as libargon2-0 I will package the argon2 python module from the following upstream: https://pypi.org/project/argon2_cffi/ https://argon2-cffi.readthedocs.io/ Which seems to be well alive upstream and well supported by downstreams (e.g. python-passlib). Cheers, -- Nicolas Dandrimont signature.asc Description: PGP signature
Bug#893884: [pkg-boost-devel] Bug#893884: libboost-locale1.62.0: LC_CTYPE overrides value of LC_ALL
* Steve M. Robbins <st...@sumost.ca> [2018-03-23 12:15:31 -0500]: > On Fri, Mar 23, 2018 at 03:52:38PM +0100, Nicolas Dandrimont wrote: > > > I've looked at the upstream history, but this source file has been imported > > as-is in SVN 7 years ago and hasn't been touched since, therefore I couldn't > > find the upstream rationale for this resolution order. > > Did you ask upstream? Or file a report in the upstream bug tracker? Hi, No, sorry. I mostly tracked the upstream history to check if the behavior was a conscious decision or not before filing the bug. And while I think this is a bug that should be fixed, it's easy enough to work around locally so I won't be able to put more time into it. I don't even really use Boost myself, only projects that use projects that use Boost ;-) Thanks for your maintenance efforts, and sorry I won't be able to help more. -- Nicolas Dandrimont BOFH excuse #314: You need to upgrade your VESA local bus to a MasterCard local bus. signature.asc Description: PGP signature
Bug#799626: RFP: beancount -- command line double-entry bookkeeping system
retitle 799626 ITP: beancount -- command line double-entry bookkeeping system owner 799626 ! thanks * Martin Michlmayr <t...@cyrius.com> [2018-03-30 17:14:49 +0200]: > * Petter Reinholdtsen <p...@hungry.com> [2015-09-21 00:17]: > > * URL : http://furius.ca/beancount/ > > * License : GPL v2+ > > > > A double-entry bookkeeping computer language that lets you define > > financial transaction records in a text file, read them in memory, > > generate a variety of reports from them, and provides a web interface. > > beancount 2.0 was released a few days ago so it's time to get this > into Debian. > > Anyone interested in packaging it? It's Python code. I've been meaning to look into this for a while, as I've been using beancount in an org I'm treasurer of. I'll put this in the python-team/applications group on salsa. Comaintainers welcome! Cheers, -- Nicolas Dandrimont signature.asc Description: PGP signature
Bug#893884: libboost-locale1.62.0: LC_CTYPE overrides value of LC_ALL
Package: libboost-locale1.62.0 Version: 1.62.0+dfsg-5 Severity: normal Tags: upstream Dear maintainer, libboost-locale's boost::locale::util::get_system_locale function gets the system locale using environment variables in the following order: LC_CTYPE, LC_ALL, LANG. LC_ALL should have precedence over all other variables, as written in locale(7): If the second argument to setlocale(3) is an empty string, "", for the default locale, it is determined using the following steps: 1. If there is a non-null environment variable LC_ALL, the value of LC_ALL is used. 2. If an environment variable with the same name as one of the categories above exists and is non-null, its value is used for that category. 3. If there is a non-null environment variable LANG, the value of LANG is used. I've looked at the upstream history, but this source file has been imported as-is in SVN 7 years ago and hasn't been touched since, therefore I couldn't find the upstream rationale for this resolution order. Thanks for considering this report, Nicolas Dandrimont -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-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) LSM: AppArmor: enabled Versions of packages libboost-locale1.62.0 depends on: ii libboost-chrono1.62.0 1.62.0+dfsg-5 ii libboost-system1.62.0 1.62.0+dfsg-5 ii libboost-thread1.62.0 1.62.0+dfsg-5 ii libc6 2.27-2 ii libgcc11:8-20180321-1 ii libicu57 57.1-9 ii libstdc++6 8-20180321-1 libboost-locale1.62.0 recommends no packages. libboost-locale1.62.0 suggests no packages. -- no debconf information
Bug#879938: pg-activity: Doesn't work with postgresql 10
Package: pg-activity Version: 1.3.1-1 Severity: important Tags: upstream Dear maintainer, The current version of pg_activity fails to detect the running postgresql version when the cluster runs postgresql 10 (which is the default in buster). Apparently, upstream doesn't have a released version with postgresql 10 support yet. Would you consider packaging a snapshot version of the upstream git repository, with postgres 10 support? Discussion of an upstream release with postgres 10 support: https://github.com/julmon/pg_activity/issues/67 Thanks! -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-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) Versions of packages pg-activity depends on: ii python 2.7.14-1 ii python-psutil5.0.1-1+b1 ii python-psycopg2 2.7.3-1 pg-activity recommends no packages. pg-activity suggests no packages. -- no debconf information
Bug#868818: RM: fedmsg -- RoQA; unmaintained, RC-buggy
* Chris Lamb <la...@debian.org> [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#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#851290: ITP: flask-limiter -- Rate-limiting for Flask routes
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * 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#851272: ITP: python-limits -- Rate limiting utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: python-limits Version : 1.2.1 Upstream Author : Ali-Akber Saifee <a...@indydevs.org> * 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#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 <ol...@debian.org> [2017-01-13 13:23:37 +0100]: > Package: wnpp > Severity: wishlist > Owner: Nicolas Dandrimont <ol...@debian.org> > > * Package name: redis-py-cluster Version : 1.3.3 Upstream Author : Johan Andersson <grok...@gmail.com> 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#851255: ITP: python-rediscluster -- Python interface to a cluster of Redis key-value stores
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * Package name: python-rediscluster Version : 0.5.3 Upstream Author : Salimane Adjao Moustapha <m...@salimane.com> * 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#851153: ITP: hiro -- time manipulation utilities for Python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont <ol...@debian.org> * 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#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#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 <tiago.my...@gmail.com> [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[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#704706: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)
* Pierre-Elliott Bécue <be...@crans.org> [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#798199: [Soc-coordination] Bug#798199: New list: debian-outre...@lists.debian.org
* Daniel Pocock <dan...@pocock.pro> [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#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#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 <dan...@pocock.pro> [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#794637: ITP: celerymon -- real-time monitoring of Celery workers
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: celerymon Version : 1.0.3 Upstream Author : Ask Solem a...@celeryproject.org * 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#779662: package fails to build without network connection
Control: tags -1 + unreproducible * Matthias Klose d...@debian.org [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#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 ol...@debian.org 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 dste...@suse.cz
+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 dste...@suse.cz
+---
+ 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 dste...@suse.cz
+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 dste...@suse.cz
+---
+ 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
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 s...@robots.org.uk [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 hyper...@debian.org} [gnome-do]
gnome-do: Changed location of homepage
Bug #757056 {Done: Chow Loong Jin hyper...@debian.org} [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 ol...@debian.org [2014-11-15 14:37:10 +0100]: * Sam Morris s...@robots.org.uk [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 w...@debian.org [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 ol...@debian.org [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 ol...@debian.org 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 dste...@suse.cz
+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 dste...@suse.cz
+---
+ 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 dste...@suse.cz
+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 dste...@suse.cz
+---
+ 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 btrfs/kerncompat.h
+ #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
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 nicolas.dandrim...@crans.org 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#754260: RFS: terminology/0.6.0-1 [ITP]
Control: owner -1 ! Hey bofh80, * bofh80 afm...@gmail.com [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 afm...@gmail.com [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#672845: RFH Packaging DNSSEC/TLSA Validator
Hey Ondřej, * Ondřej Surý ond...@sury.org [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, copyright holder gives permission to | link the code of project 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#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 none 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#689636: status?
* Bdale Garbee bd...@gag.com [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#747481: ITP: backports.ssl-match-hostname -- Backport of the Python 3.2 SSL hostname checking function
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * 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 ol...@debian.org [2014-05-09 10:34:09 +0200]: Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * 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#744726: websocket-client should be repacked
Control: tags -1 + fixed-upstream pending * Leo Iannacone l...@ubuntu.com [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 robie.ba...@ubuntu.com [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 robie.ba...@ubuntu.com [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#743132: ITP: python-fedora -- Python modules for interacting with Fedora Services
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: python-fedora Version : 0.3.33 Upstream Author : Toshio Kuratomi tkura...@redhat.com 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#742952: ITP: datanommer -- a storage consumer for the fedmsg bus
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * 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#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 nicolas.dandrim...@crans.org
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 EOF | gnuplot
set xdata time
set timefmt %Y%m%d%H%M
@@ -33,6 +39,13 @@ set yrange [0:]
#set nomxtics
set output /org/bugs.debian.org/www/bugscan/graph.png
plot $tmp using 1:2 with lines, $tmp2 using 1:2 with lines, $tmp3 using 1:2 with lines
+set xrange [$previous_release:]
+set output /org/bugs.debian.org/www/bugscan/graph-release.png
+plot $tmp using 1:2 with lines, $tmp2 using 1:2 with lines, $tmp3 using 1:2 with lines
+set xrange [$previous_month:]
+set format x %d\n%m\n%Y
+set output /org/bugs.debian.org/www/bugscan/graph-month.png
+plot $tmp using 1:2 with lines, $tmp2 using 1:2 with lines, $tmp3 using 1:2 with lines
quit
EOF
--
1.8.5.3
From 1407c6e2653d4dc0f4839d95e868edfc11192ce6 Mon Sep 17 00:00:00 2001
From: Nicolas Dandrimont nicolas.dandrim...@crans.org
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 EOF
/p
-div align=centerimg src=graph.png alt=Graph of RC bugs/div
+div align=centerimg src=graph-release.png alt=Graph of RC bugs/div
+
+pOther graphs:
+ ul
+lia href=graph-month.pngGraph for the last month/a/li
+lia href=graph.pngGraph with all the history/a/li
+ /ul
+/p
pThe 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#734952: ITP: cloud-sptheme -- Cloud Sphinx theme and related extensions
Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont ol...@debian.org
* 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#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#732837: ITP: vcversioner -- Use version control tags to discover version numbers
* Jeremy Stanley fu...@yuggoth.org [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#732837: ITP: vcversioner -- Use version control tags to discover version numbers
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * 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#731376: ITP: libextutils-typemap-perl -- ExtUtils::Typemap - Read/Write/Modify Perl/XS typemap files
* Piotr Roszatycki dex...@debian.org [2013-12-04 20:31:41 +0100]: Package: wnpp Severity: wishlist Owner: Piotr Roszatycki dex...@debian.org * Package name: libextutils-typemap-perl Version : 1.00 Upstream Author : Steffen Mueller smuel...@cpan.org * 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 dex...@debian.org [2013-12-05 00:46:40 +0100]: 2013/12/4 Nicolas Dandrimont ol...@debian.org: * 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#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library
* Bas Wijnen wij...@debian.org [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#728542: ITP: libpolyclipping -- polygon clipping, polygon offsetting and polyline offsetting library
* Bas Wijnen wij...@debian.org [2013-11-02 14:22:02 -0400]: Package: wnpp Severity: wishlist Owner: Bas Wijnen wij...@debian.org * 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 ol...@debian.org * Package name: libwx-glcanvas-perl Version : 0.09 Upstream Author : Mattia Barbon mbar...@cpan.org * 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#727759: ITP: websocket-client -- WebSocket client library for python
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * Package name: websocket-client Version : 0.12.0 Upstream Author : liris liris...@gmail.com * 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#710487: My recent bpo-uploads not appearing in my qa page
Control: tags 710487 + patch
[Trimming down the Cc: list a bit]
* Mike Gabriel mike.gabr...@das-netzwerkteam.de [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 rho...@deb.at [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 ol...@debian.org [2013-10-25 14:48:27 +0200]:
* Gerfried Fuchs rho...@deb.at [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#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 ol...@debian.org 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#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 tig...@aivazian.fsnet.co.uk, 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
Bug#718956: ITP: printrun -- 3D-printing host software
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont ol...@debian.org * 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 eugeniy.meshcherya...@googlemail.com [2013-08-07 10:58:34 +0200]: 7 серп. 2013 09:45, Nicolas Dandrimont ol...@debian.org напис. [ 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#715404: ITP: snapper -- Linux filesystem snapshot management tool
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont nicolas.dandrim...@crans.org * Package name: snapper Version : 0.1.4 Upstream Author : Arvin Schnell aschn...@suse.de * 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#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers
* Bas Wijnen wij...@debian.org [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 wij...@debian.org [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#689636: ITP: slic3r -- STL-to-GCODE translator for RepRap printers
* Bas Wijnen wij...@debian.org [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#712093: marionnet: bus address error on start and 3 popups
* Pierre M. adrp...@yahoo.fr [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#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 nicolas.dandrim...@crans.org * Package name: libmath-convexhull-monotonechain-perl Version : 0.01 Upstream Author : Steffen Mueller, smuel...@cpan.org * 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#692410: license information for Math::Libm
* Florian Schlichting fschl...@zedat.fu-berlin.de [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#702298: ITP: fabtools -- tools for writing awesome Fabric files
Package: wnpp Severity: wishlist Owner: Nicolas Dandrimont nicolas.dandrim...@crans.org Package name: fabtools Version : 0.12.0 Upstream Author : Ronan Amicel ronan.ami...@gmail.com 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
