Bug#1037273: dupeguru: immediately crashes: ModuleNotFoundError: No module named 'core.pe.photo'

[Luca Falavigna]

Control: severity -1 important

Il giorno sab 10 giu 2023 alle ore 01:57 Marc Lehmann
 ha scritto:
> while the package installs fine, it immediately crashes on startup:

Most likely a duplicate of bug #1033608, which was a false positive.

-- 
Cheers,
Luca

Bug#1034219: debomatic: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Luca Falavigna]

tags 1034219 + patch
thanks


Hi Laurent, hi Andreas,

First of all, thanks for the bug report and for the discussion so far!

Il giorno mer 12 apr 2023 alle ore 10:51 Andreas Henriksson
 ha scritto:
> I'm not sure exactly what the best option is to adress this for pybuild
> using packages, but my guess would be to have some debian/rules hack
> that moves the file (if it's not already located in the same path as
> returned by `pkg-config --variable=systemdsystemunitdir systemd`) after
> dh_install has run probably.

I made a patch adjusting upstream setup.py file to create a symlink of
usr/lb to lib, this is the easiest way to let the buildsystem to
handle with the correct path.

I built the package on debomatic itself where we can see the unit file
is now shipped under /lib/systemd/system:
http://debomatic-amd64.debian.net/distribution#unstable/debomatic/0.26-2/contents

Do you think this will be enough to solve the bug?

-- 
Cheers,
Luca


bug1034219.debdiff
Description: Binary data

Bug#1033608: Exception: ModuleNotFoundError: No module named 'core.pe.photo'

[Luca Falavigna]

tags 1033608 + moreinfo + unreproducible
thanks


Hi Ionuț,

Il giorno mar 28 mar 2023 alle ore 16:03 Ionuț Ciocîrlan
 ha scritto:
> In the debian package these symlinks are missing, and emptu directories
> are created instead (although the lib files are built and packaged).

I just checked in a fresh system and symlinks are correctly placed.
Also see latest amd64 build:
https://buildd.debian.org/status/fetch.php?pkg=dupeguru=amd64=4.3.1-3%2Bb1=1672837551=0
lrwxrwxrwx root/root 0 2023-01-04 13:05
./usr/share/dupeguru/core/pe -> ../../../lib/dupeguru/core/pe
lrwxrwxrwx root/root 0 2023-01-04 13:05
./usr/share/dupeguru/qt/pe -> ../../../lib/dupeguru/qt/pe

-- 
Cheers,
Luca

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Luca Falavigna]

Both ways are fine. If you upload -3 right now, NMU will be rejected
because of the newer version, otherwise it'll reach the archive when
time elapses.
A maintainer upload would be better, though :-)

-- 
Cheers,
Luca

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Luca Falavigna]

Il giorno lun 29 ago 2022 alle ore 07:34 Stephen Gelman
 ha scritto:
> Would you be interested in creating a MR for your changes to salsa? If not 
> that’s fine, just let me know and I will pull in the changes myself.

Sure, here it is:
https://salsa.debian.org/ssgelm/opentracing-cpp/-/merge_requests/1

-- 
Cheers,
Luca

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Luca Falavigna]

Control: tags 1017132 + patch
Control: tags 1017132 + pending


Dear maintainer,

I've prepared an NMU for opentracing-cpp (versioned as 1.6.0-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,
Luca

diff -Nru opentracing-cpp-1.6.0/debian/changelog opentracing-cpp-1.6.0/debian/changelog
--- opentracing-cpp-1.6.0/debian/changelog	2021-11-07 06:42:53.0 +0100
+++ opentracing-cpp-1.6.0/debian/changelog	2022-08-28 11:11:38.0 +0200
@@ -1,3 +1,11 @@
+opentracing-cpp (1.6.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/catch_SIGSTKSZ.patch:
+- Fix FTBFS with glibc 2.34 (Closes: #1017132).
+
+ -- Luca Falavigna   Sun, 28 Aug 2022 11:11:38 +0200
+
 opentracing-cpp (1.6.0-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru opentracing-cpp-1.6.0/debian/patches/catch_SIGSTKSZ.patch opentracing-cpp-1.6.0/debian/patches/catch_SIGSTKSZ.patch
--- opentracing-cpp-1.6.0/debian/patches/catch_SIGSTKSZ.patch	1970-01-01 01:00:00.0 +0100
+++ opentracing-cpp-1.6.0/debian/patches/catch_SIGSTKSZ.patch	2022-08-28 11:11:38.0 +0200
@@ -0,0 +1,40 @@
+Index: opentracing-cpp-1.6.0/3rd_party/include/opentracing/catch2/catch.hpp
+===
+--- opentracing-cpp-1.6.0.orig/3rd_party/include/opentracing/catch2/catch.hpp
 opentracing-cpp-1.6.0/3rd_party/include/opentracing/catch2/catch.hpp
+@@ -6571,6 +6571,17 @@ namespace Catch {
+ int id;
+ const char* name;
+ };
++
++// 32kb for the alternate stack seems to be sufficient. However, this value
++// is experimentally determined, so that's not guaranteed.
++#if defined(_SC_SIGSTKSZ_SOURCE) || defined(_GNU_SOURCE)
++// on glibc > 2.33 this is no longer constant, see
++// https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=85e84fe53699fe9e392edffa993612ce08b2954a;hb=HEAD
++static constexpr std::size_t altStackSize = 32 * 1024;
++#else
++static constexpr std::size_t altStackSize = std::max(static_cast(SIGSTKSZ), 32 * 1024)
++#endif
++
+ static SignalDefs signalDefs[] = {
+ { SIGINT,  "SIGINT - Terminal interrupt signal" },
+ { SIGILL,  "SIGILL - Illegal instruction signal" },
+@@ -6597,7 +6608,7 @@ namespace Catch {
+ isSet = true;
+ stack_t sigStack;
+ sigStack.ss_sp = altStackMem;
+-sigStack.ss_size = SIGSTKSZ;
++sigStack.ss_size = altStackSize;
+ sigStack.ss_flags = 0;
+ sigaltstack(, );
+ struct sigaction sa = { };
+@@ -6628,7 +6639,7 @@ namespace Catch {
+ bool FatalConditionHandler::isSet = false;
+ struct sigaction FatalConditionHandler::oldSigActions[sizeof(signalDefs)/sizeof(SignalDefs)] = {};
+ stack_t FatalConditionHandler::oldSigStack = {};
+-char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
++char FatalConditionHandler::altStackMem[altStackSize] = {};
+ 
+ } // namespace Catch
+ 
diff -Nru opentracing-cpp-1.6.0/debian/patches/series opentracing-cpp-1.6.0/debian/patches/series
--- opentracing-cpp-1.6.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ opentracing-cpp-1.6.0/debian/patches/series	2022-08-28 11:11:38.0 +0200
@@ -0,0 +1 @@
+catch_SIGSTKSZ.patch


signature.asc
Description: PGP signature

Bug#995720: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Build-Depends:
perl6-readline: perl6-tap-harness

Bug#995398: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Depends:
debian-design: design-desktop-web

Bug#993294: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Build-Depends:
libjxmpp-java: libidn11-java

Bug#993577: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A few dependencies still exist:

Checking reverse dependencies...
# Broken Depends:
bfh-metapackages: bfh-gnome-desktop
progress-linux-metapackages: progress-linux-gnome-desktop

Bug#993368: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Depends:
openscap-daemon: openscap-daemon

Bug#992819: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A few dependencies still exist:

Checking reverse dependencies...
# Broken Depends:
kmerresistance: kmerresistance [armel armhf i386 mipsel]
resfinder: resfinder
virulencefinder: virulencefinder

# Broken Build-Depends:
resfinder-db: kma

Bug#983538: debomatic: trivial suggestions for the packaging

[Luca Falavigna]

tags 983538 + pending fixed-upstream
thanks


Hi Nicolas,

first of all, thanks a lot for your patches! Most of them were
imported either upstream when relevant or in Salsa, with the exception
of the following:

0003-Merge-paragraphs-files-in-d-copyright.patch
 * I prefer to keep holders separate, although it's not strictly
required as you mentioned.

0005-Fix-license-GPL-3-no-later-version.patch
 * This is clarified upstream and will be part of the next release, so
I skipped it for the time being.

0008-Improve-debian-tests-build-with-variables.patch
 * Although it makes sense, would it be possible to provide patches
implementing the same approach for the other tests too?

Thanks again!

-- 
Cheers,
Luca

Bug#993271: RFA: ninka -- license identification tool for source code

[Luca Falavigna]

Package: wnpp
Severity: normal

I request an adopter for the ninka package.

The package description is:
 Ninka is a lightweight license identification tool for source code. It is
 sentence-based, and provides a simple way to identify open source licenses in
 a source code file. It is capable of identifying several dozen different
 licenses (and their variations).
 .
 Ninka has been designed to be lightweight, fast and accurate.
 .
 This package contains the standard ninka application.

Bug#987553: RM: pynn/experimental -- NVIU; package wasn't removed automatically

[Luca Falavigna]

Package: ftp.debian.org
Severity: normal

Bug#981169: RM: liblarch/experimental -- RoQA; removed from unstable as well

[Luca Falavigna]

Package: ftp.debian.org
Severity: normal

Please remove liblarch from experimental. It has been removed from
unstable as well (see #944568).

Bug#978558: ITP: gp-saml-gui -- login to a GlobalProtect VPN that uses SAML authentication

[Luca Falavigna]

Package: wnpp
Severity: wishlist
Owner: Luca Falavigna 

* Package name: gp-saml-gui
  Version : 0.0~git20201209.64c01f4+ds-1
  Upstream Author : Dan Lenski
* URL : https://github.com/dlenski/gp-saml-gui
* License : GPL-3
  Programming Lang: Python
  Description : login to a GlobalProtect VPN that uses SAML authentication

 Helper script to allow you to interactively login to a GlobalProtect VPN that
 uses SAML authentication, so that you can subsequently connect with
 OpenConnect application.

Bug#933897: RM: ruby-fog-cloudatcost/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933896: RM: tabmixplus/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933894: RM: open-infrastructure-system-images/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933898: RM: flif/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933895: RM: open-infrastructure-system-build/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933892: RM: targetcli/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933893: RM: pybliographer/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933890: RM: libjs-handlebars.runtime/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933888: RM: dh-haskell/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#933891: RM: configshell/experimental -- RoQA; already removed from unstable

[Luca Falavigna]

Package: ftp.debian.org

This package was removed from unstable but still has a version in
experimental without a valid reason to keep it (at least according to the
original removal bug). We should get rid of the package in experimental as
well.

Bug#931653: RM: node-json3 -- ROM; Dead upstream

[Luca Falavigna]

tags 931653 moreinfo
thanks


Il giorno lun 8 lug 2019 alle ore 23:09 Xavier Guimard
 ha scritto:
> This package has no reverse dependencies, so it can safely be removed
> from Debian archive.

Checking reverse dependencies...
# Broken Build-Depends:
rainloop: node-json3

Bug#895534: closed by Debian FTP Masters

[Luca Falavigna]

Hi Simon,

Il giorno gio 11 lug 2019 alle ore 23:24 Simon McVittie
 ha scritto:
> I asked for multiple binary packages to be overridden, including but not
> limited to libgtkgl2.0-1:

When fixing overrides, dak can cope with just one override at a time
and then it sends bug mail to -close with just one package listed.
If you look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895534,
you will see subsequent messages were sent to -close, but probably
weren't mailed because bug was already closed once.

> > libgtkgl2.0-1:oldlibs/optional
> > libgtkgl2.0-dev:oldlibs/optional
> > libgtkglext1-dev:oldlibs/optional
> > libgtkglext1-doc:oldlibs/optional
> > libgtkglext1:oldlibs/optional
> > libgtkglextmm-x11-1.2-0v5:oldlibs/optional
> > libgtkglextmm-x11-1.2-dev:oldlibs/optional
> > python-gtkglext1:oldlibs/optional
>
> Do the ftp team prefer to receive a separate bug report for each binary
> package that is deprecated and should be overridden into oldlibs?

You did it the right way :)

-- 
Cheers,
Luca

Bug#898738: debootstrap fails when specifying components

[Luca Falavigna]

Hi Hideki,

2018-05-16 2:03 GMT+02:00 Hideki Yamane :
>> See attached patch, against the offending commit. It doesn't apply to
>> master as-is because of the by-hash addition.
>
>  Simply initialize "ext" prevents this failure, could you check attached
>  patch, please?

I applied to 1.0.98 package in unstable, and it fixes the problem for me.

-- 
Cheers,
Luca

Bug#898738: debootstrap fails when specifying components

[Luca Falavigna]

found 898738 1.0.97
thanks



Hi,

2018-05-15 21:19 GMT+02:00 Cyril Brulebois :
> The issue seems to be the non-free Packages file being checked against
> the checksum of the contrib one (both sha256 checksum and size in fact),
> so that can't work.

Thanks for checking! Indeed the problem can be reproduced from 1.0.97
(hence adjusting found correctly). I'll have a look in the next few
days as well.

-- 
Cheers,
Luca

Bug#898738: debootstrap fails when specifying components

[Luca Falavigna]

Source: debootstrap
Version: 1.0.98
Severity: serious


debootstrap fails when specifying components on command line:

# debootstrap --components=main,contrib,non-free unstable unstable
http://deb.debian.org/debian
I: Target architecture can be executed
I: Checking Release signature
I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
I: Validating Packages
I: Retrieving Packages
I: Retrieving Packages
I: Validating Packages
W: Retrying failed download of
http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
I: Retrieving Packages
I: Validating Packages
W: Retrying failed download of
http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
I: Retrieving Packages
I: Validating Packages
W: Retrying failed download of
http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
I: Retrieving Packages
I: Validating Packages
W: Retrying failed download of
http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
I: Retrieving Packages
I: Validating Packages
W: Retrying failed download of
http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages.gz
W: http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages.gz
was corrupt
I: Retrieving Packages
E: Couldn't download
http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages


It works correctly when omitting ---components, or with --components=main only.

-- 
Cheers,
Luca

Bug#897519: bcron: diff for NMU version 0.11-1.2

[Luca Falavigna]

Control: tags 897519 + patch
Control: tags 897519 + pending

Dear maintainer,

I've prepared an NMU for bcron (versioned as 0.11-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Luca
diff -Nru bcron-0.11/debian/changelog bcron-0.11/debian/changelog
--- bcron-0.11/debian/changelog	2017-12-13 11:12:18.0 +0100
+++ bcron-0.11/debian/changelog	2018-05-11 12:42:54.0 +0200
@@ -1,3 +1,11 @@
+bcron (0.11-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add tzdata to build-depends to make sure test suite is executed
+correctly (Closes: #897519).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Fri, 11 May 2018 12:42:54 +0200
+
 bcron (0.11-1.1) unstable; urgency=medium
 
   * Non-maintainer uppload
diff -Nru bcron-0.11/debian/control bcron-0.11/debian/control
--- bcron-0.11/debian/control	2017-12-13 11:12:18.0 +0100
+++ bcron-0.11/debian/control	2018-05-11 12:42:54.0 +0200
@@ -12,7 +12,8 @@
 	   libbg-dev (>= 2),
 	   python,
 	   man2html-base,
-	   texinfo
+	   texinfo,
+	   tzdata
 Standards-Version: 4.1.2
 Homepage: http://untroubled.org/bcron
 Vcs-Browser: https://anonscm.debian.org/cgit/users/kaction-guest/bcron.git


signature.asc
Description: PGP signature

Bug#890944: new packages should not receive emails before email alias is created

[Luca Falavigna]

Hi Thorsten,

2018-03-06 22:10 GMT+01:00 Thorsten Alteholz :
> [1] https://salsa.debian.org/ftp-team/dak/merge_requests/9

I think daklib/queue.py needs tweaking too, cfr
https://salsa.debian.org/ftp-team/dak/commit/201d7e04ae2533791935ba0c0e9454f913df9c26#2f5b8224379fc6b2ea3cc7571d8fd5385715dec5

-- 
Cheers,
Luca

Bug#890944: new packages should not receive emails before email alias is created

[Luca Falavigna]

Hi Raphaël,

2018-03-04 21:15 GMT+01:00 Raphael Hertzog :
> No, @packages.qa.debian.org never forwarded to
> @packages.debian.org. It's the other way around.

Ah, noted. Thanks for clarifying.

> It works for whatever you want. Ansgar asked me a few questions on
> this topic recently and he said that DAK was already mailing the
> maintainer directly so he would certainly just mail the maintainer +
> dispatch@tracker.d.o in all cases and never use
> @packages.debian.org.

OK. Can you please indicate which header is used to reference the
source package when sending mails to dispatch@tracker.d.o? I suppose
dak is already generating it anyway, but double-checking won't hurt
:-)

-- 
Cheers,
Luca

Bug#890944: new packages should not receive emails before email alias is created

[Luca Falavigna]

Well, recent changes just changed email to
@packages.debian.org, so I'm not convinced this is a bug in
dak itself.

Could it be the small delay while processing mails to
@packages.qa.debian.org (which are then forwarded to
@packages.debian.org) could have hidden this for ages?

Anyway, does the solution to use dispatch@p.d.o works for source NEW,
or for binary-NEW too?

-- 
Cheers,
Luca

Bug#888287: debomatic: Unable to use local repository created by the Repository module

[Luca Falavigna]

Hi Yavor,


2018-01-24 18:14 GMT+01:00 Yavor Doganov :
> Package: debomatic
> Version: 0.22-1
> Severity: normal
>
> First of all, thank you for writing and maintaing this package; it's a
> great piece of software.

Thanks!

> The pubring as specified in the repository section in the
> configuration file is also not copied to the chroot's
> /etc/apt/trusted.gpg.d as it should be.

Odd, pubring should be copied in if the relevant configuration option
is defined in the configuration file and the file itself is found:
https://sources.debian.org/src/debomatic/0.22-1/Debomatic/build.py/#L464-L468

> W: Invalid 'Date' entry in Release file 
> /var/lib/apt/lists/partial/_home_yavor_incoming_experimental_dists_experimental_Release
> (The second warning appears to be fixed in the debomatic Git repository.)

Indeed: 
https://github.com/debomatic/debomatic/commit/b67593dc7b3c52d4e9569a686ab01bca8ccd1b31#diff-73b7bc9a2d28c58cb25074cfccea32e4

> The commands file I use is:
> builddep viewpdf.app_1:0.2dfsg1-6 experimental libgnustep-gui-dev (>= 0.26)
>
> I also tried copying the .debs and creating a local repository myself,
> as I do with semi-automatically with pbuilder.  This repository is
> also ignored if I add it to extramirrors under the experimental
> distribution.

I think this is due to how experimental pinning is handled by apt. If
you upload a new package revision (let's say 0.26.2-2+dom) in
debomatic, and then you change the builddep command to request
libgnustep-gui-dev (>= 0.26-2+dom), it should work.

-- 
Cheers,
Luca

Bug#889968: RFS: inotify-tools/3.14-4

[Luca Falavigna]

2018-02-13 4:18 GMT+01:00  :
>> I suspect that the debomatic sid chroot is out-of-date.

amd64 chroot was updated on Sunday, February 11, 2018 4:20:10 PM UTC
(1518366010.2514317).

-- 
Cheers,
Luca

Bug#860797: please make packages with epochs bump go in new queue

[Luca Falavigna]

Control: tags -1 + wontfix

2017-04-20 10:56 GMT+02:00 Gianfranco Costamagna :
> It started as a joke on #-devel, but it would be nice to have packages with 
> epoch bumped
> go in new queue

NEW is for new overrides, not for versions, sorry.

It should be responsibility of maintainers to select an appropriate
version for their uploads.
I think most of the cases could be covered by a lintian check (see
[0], but could be extended to cover more scenarios). In that case, it
would be easier to add the tag to the lintian autoreject list.

[0] https://lintian.debian.org/tags/epoch-change-without-comment.html

-- 
Cheers,
Luca

Bug#876224: Fixed in dak already

[Luca Falavigna]

Should be fixed with this commit:
https://salsa.debian.org/ftp-team/dak/commit/4988d9dd0713705751b962746bb73c56609f7ac6

Bug#846982: List of packages to change priority for

[Luca Falavigna]

Given Josh's attempt to provide an updated list, which was limited to
just amd64 and i386, I extracted all the packages with priority
standard or higher from projectb (therefore including all arches by
definition).

File "priorities" contains the full list of packages having standard
or higher priority, file "priorities to change" contains a filtered
list of packages which will have priority changed. Basically they are
all the packages having section libs or libdevel.

I had a look at the other packages to find potential candidates, but
it seems it's reasonable to leave them as they are.

Unless somebody objects, I'm going to change overrides in a few days.

-- 
Cheers,
Luca


priorities
Description: Binary data


priorities
Description: Binary data

Bug#846982: override: downgrade priority of all libraries to optional

[Luca Falavigna]

Hi Cyril,

2018-01-20 14:14 GMT+01:00 Cyril Brulebois :
> Just as a reminder, priority is archive-wise so we won't have that in
> unstable then in testing, right?

Normally overrides are changed for unstable, but are propagated to
testing during dinstall. If we have a look at a recent override change
(see #886053), we can notice exactly that:

projectb=> select o.package, s.suite_name as suite, p.priority
projectb-> from override o
projectb-> join suite s on s.id = o.suite
projectb-> join priority p on p.id = o.priority
projectb-> where o.package = 'libudev1'
projectb-> and o.type = (
projectb(>   select id
projectb(>   from override_type
projectb(>   where type = 'deb');
 package  |   suite   | priority
--+---+---
 libudev1 | wheezy-backports  | important
 libudev1 | oldstable | important
 libudev1 | stable| important
 libudev1 | jessie-backports  | important
 libudev1 | stretch-backports | important
 libudev1 | testing   | optional
 libudev1 | unstable  | optional
(7 rows)

projectb=>

> That being said, that looks reasonable enough; a bit curious as to which
> things might break, but let's do that, and we'll see…

Alright! Thanks both to you and Steve for the fast replies!

-- 
Cheers,
Luca

Bug#861625: ftp.debian.org: Allow DMs to upload to binary-NEW for their own packages

[Luca Falavigna]

Control: tags -1 wontfix


2017-05-01 21:48 GMT+02:00 Ximin Luo :
> Could we relax the ACL for DMs so that they can upload to binary-NEW?

GR 2007-003 [0] clearly states "none of the uploaded packages are NEW".
Allowing that would break what the GR explicitly say.

[0] https://www.debian.org/vote/2007/vote_003

-- 
Cheers,
Luca

Bug#846982: override: downgrade priority of all libraries to optional

[Luca Falavigna]

Dear -boot and -cd teams,

could you please comment on the request of demoting library priorities
from required and important to optional?

Thanks,
Luca

Bug#834811: override: wget:web/standard

[Luca Falavigna]

Dear -boot and -cd teams,

could you please comment on the request of demoting wget priority from
important to standard?

Thanks,
Luca

Bug#802849: Proposed patch

[Luca Falavigna]

Now patch builds, but apparently unsharing still does not work
because, even if the parameter is set via option, this->unshare_net is
not updated with the correct value.

Suggestions welcome :)
Description: Add support for unshare(CLONE_NEWNET)
Author: Luca Falavigna <dktrkr...@debian.org>
Bug-Debian: https://bugs.debian.org/802849

Index: schroot-1.6.10/CMakeLists.txt
===
--- schroot-1.6.10.orig/CMakeLists.txt
+++ schroot-1.6.10/CMakeLists.txt
@@ -274,6 +274,18 @@ endif (DOXYGEN_EXECUTABLE)
 option(doxygen "Enable doxygen documentation" ${DOXYGEN_DEFAULT})
 set(BUILD_DOXYGEN ${doxygen})
 
+# Namespace unshare feature
+# sched.h ==> UNSHARE_HEADER
+check_include_file_cxx (sched.h UNSHARE_HEADER)
+check_function_exists(unshare UNSHARE_FUNC)
+set(UNSHARE_DEFAULT OFF)
+if (UNSHARE_HEADER AND UNSHARE_FUNC)
+  set (UNSHARE_DEFAULT ON)
+endif (UNSHARE_HEADER AND UNSHARE_FUNC)
+option(unshare "Enable unshare support (Linux only)" ${UNSHARE_DEFAULT})
+set(BUILD_UNSHARE ${unshare})
+set(SBUILD_FEATURE_UNSHARE ${unshare})
+
 # Kernel personality feature
 # sys/personality.h ==> PERSONALITY_HEADER
 check_include_file_cxx (sys/personality.h PERSONALITY_HEADER)
Index: schroot-1.6.10/sbuild/CMakeLists.txt
===
--- schroot-1.6.10.orig/sbuild/CMakeLists.txt
+++ schroot-1.6.10/sbuild/CMakeLists.txt
@@ -80,6 +80,13 @@ if(BUILD_UNION)
   sbuild-chroot-facet-union.cc)
 endif(BUILD_UNION)
 
+if(BUILD_UNSHARE)
+  set(public_unshare_h_sources
+  sbuild-chroot-facet-unshare.h)
+  set(public_unshare_cc_sources
+  sbuild-chroot-facet-unshare.cc)
+endif(BUILD_UNSHARE)
+
 set(public_h_sources
 sbuild-basic-keyfile.h
 sbuild-basic-keyfile.tcc
Index: schroot-1.6.10/sbuild/sbuild-chroot-facet-unshare.cc
===
--- /dev/null
+++ schroot-1.6.10/sbuild/sbuild-chroot-facet-unshare.cc
@@ -0,0 +1,159 @@
+/* Copyright © 2005-2009  Roger Leigh <rle...@debian.org>
+ *
+ * schroot is free software: you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * schroot is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see
+ * <http://www.gnu.org/licenses/>.
+ *
+ */
+
+#include 
+
+#include "sbuild-chroot.h"
+#include "sbuild-chroot-facet-unshare.h"
+#include "sbuild-feature.h"
+
+#include 
+
+#ifdef SBUILD_FEATURE_UNSHARE
+#include 
+#endif // SBUILD_FEATURE_UNSHARE
+
+using boost::format;
+using namespace sbuild;
+
+namespace
+{
+
+  typedef std::pair<chroot_facet_unshare::error_code,const char *> emap;
+
+  /**
+   * This is a list of the supported error codes.  It's used to
+   * construct the real error codes map.
+   */
+  emap init_errors[] =
+{
+  // TRANSLATORS: %1% = integer personality ID
+  emap(chroot_facet_unshare::UNSHARE,
+	   N_("Could not unshare process execution context"))
+};
+
+#ifdef SBUILD_FEATURE_UNSHARE
+  sbuild::feature feature_unshare
+  ("UNSHARE",
+   N_("Linux dissassociation of shared execution context"));
+#endif
+
+}
+
+template<>
+error::map_type
+error::error_strings
+(init_errors,
+ init_errors + (sizeof(init_errors) / sizeof(init_errors[0])));
+
+chroot_facet_unshare::chroot_facet_unshare ():
+  chroot_facet(),
+  unshare_net(false)
+{
+}
+
+chroot_facet_unshare::~chroot_facet_unshare ()
+{
+}
+
+chroot_facet_unshare::ptr
+chroot_facet_unshare::create ()
+{
+  return ptr(new chroot_facet_unshare());
+}
+
+chroot_facet::ptr
+chroot_facet_unshare::clone () const
+{
+  return ptr(new chroot_facet_unshare(*this));
+}
+
+std::string const&
+chroot_facet_unshare::get_name () const
+{
+  static const std::string name("unshare");
+
+  return name;
+}
+
+bool
+chroot_facet_unshare::get_unshare_net () const
+{
+  return this->unshare_net;
+}
+
+void
+chroot_facet_unshare::set_unshare_net (bool unshare_net)
+{
+  this->unshare_net = unshare_net;
+}
+
+void
+chroot_facet_unshare::unshare () const
+{
+  if (this->unshare_net)
+{
+  log_debug(DEBUG_INFO) << "Unsharing network" << std::endl;
+  if (::unshare(CLONE_NEWNET) < 0)
+	throw error(UNSHARE, strerror(errno));
+}
+}
+
+void
+chroot_facet_unshare::setup_env (chroot const& chroot,
+ environment&  env) const
+{
+}
+
+sbuild::chroot::

Bug#802849: Proposed patch

[Luca Falavigna]

tags 802849 patch
thanks


I tried cherry-picking patches from master branch, and should have
come to something which can be tested.

Unfortunately it does not build, and can't really figure out the
reason why. I added the tag patch to attract more skilled C++
developers to fix it where I couldn't :)

-- 
Cheers,
Luca
Index: schroot-1.6.10/CMakeLists.txt
===
--- schroot-1.6.10.orig/CMakeLists.txt
+++ schroot-1.6.10/CMakeLists.txt
@@ -274,6 +274,18 @@ endif (DOXYGEN_EXECUTABLE)
 option(doxygen "Enable doxygen documentation" ${DOXYGEN_DEFAULT})
 set(BUILD_DOXYGEN ${doxygen})
 
+# Namespace unshare feature
+# sched.h ==> UNSHARE_HEADER
+check_include_file_cxx (sched.h UNSHARE_HEADER)
+check_function_exists(unshare UNSHARE_FUNC)
+set(UNSHARE_DEFAULT OFF)
+if (UNSHARE_HEADER AND UNSHARE_FUNC)
+  set (UNSHARE_DEFAULT ON)
+endif (UNSHARE_HEADER AND UNSHARE_FUNC)
+option(unshare "Enable unshare support (Linux only)" ${UNSHARE_DEFAULT})
+set(BUILD_UNSHARE ${unshare})
+set(SBUILD_FEATURE_UNSHARE ${unshare})
+
 # Kernel personality feature
 # sys/personality.h ==> PERSONALITY_HEADER
 check_include_file_cxx (sys/personality.h PERSONALITY_HEADER)
Index: schroot-1.6.10/sbuild/CMakeLists.txt
===
--- schroot-1.6.10.orig/sbuild/CMakeLists.txt
+++ schroot-1.6.10/sbuild/CMakeLists.txt
@@ -80,6 +80,13 @@ if(BUILD_UNION)
   sbuild-chroot-facet-union.cc)
 endif(BUILD_UNION)
 
+if(BUILD_UNSHARE)
+  set(public_unshare_h_sources
+  sbuild-chroot-facet-unshare.h)
+  set(public_unshare_cc_sources
+  sbuild-chroot-facet-unshare.cc)
+endif(BUILD_UNSHARE)
+
 set(public_h_sources
 sbuild-basic-keyfile.h
 sbuild-basic-keyfile.tcc
Index: schroot-1.6.10/sbuild/sbuild-chroot-facet-unshare.cc
===
--- /dev/null
+++ schroot-1.6.10/sbuild/sbuild-chroot-facet-unshare.cc
@@ -0,0 +1,159 @@
+/* Copyright © 2005-2009  Roger Leigh 
+ *
+ * schroot is free software: you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * schroot is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see
+ * .
+ *
+ */
+
+#include 
+
+#include "sbuild-chroot.h"
+#include "sbuild-chroot-facet-unshare.h"
+#include "sbuild-feature.h"
+
+#include 
+
+#ifdef SBUILD_FEATURE_UNSHARE
+#include 
+#endif // SBUILD_FEATURE_UNSHARE
+
+using boost::format;
+using namespace sbuild;
+
+namespace
+{
+
+  typedef std::pair emap;
+
+  /**
+   * This is a list of the supported error codes.  It's used to
+   * construct the real error codes map.
+   */
+  emap init_errors[] =
+{
+  // TRANSLATORS: %1% = integer personality ID
+  emap(chroot_facet_unshare::UNSHARE,
+	   N_("Could not unshare process execution context"))
+};
+
+#ifdef SBUILD_FEATURE_UNSHARE
+  sbuild::feature feature_unshare
+  ("UNSHARE",
+   N_("Linux dissassociation of shared execution context"));
+#endif
+
+}
+
+template<>
+error::map_type
+error::error_strings
+(init_errors,
+ init_errors + (sizeof(init_errors) / sizeof(init_errors[0])));
+
+chroot_facet_unshare::chroot_facet_unshare ():
+  chroot_facet(),
+  unshare_net(false)
+{
+}
+
+chroot_facet_unshare::~chroot_facet_unshare ()
+{
+}
+
+chroot_facet_unshare::ptr
+chroot_facet_unshare::create ()
+{
+  return ptr(new chroot_facet_unshare());
+}
+
+chroot_facet::ptr
+chroot_facet_unshare::clone () const
+{
+  return ptr(new chroot_facet_unshare(*this));
+}
+
+std::string const&
+chroot_facet_unshare::get_name () const
+{
+  static const std::string name("unshare");
+
+  return name;
+}
+
+bool
+chroot_facet_unshare::get_unshare_net () const
+{
+  return this->unshare_net;
+}
+
+void
+chroot_facet_unshare::set_unshare_net (bool unshare_net)
+{
+  this->unshare_net = unshare_net;
+}
+
+void
+chroot_facet_unshare::unshare () const
+{
+  if (this->unshare_net)
+{
+  log_debug(DEBUG_INFO) << "Unsharing network" << std::endl;
+  if (::unshare(CLONE_NEWNET) < 0)
+	throw error(UNSHARE, strerror(errno));
+}
+}
+
+void
+chroot_facet_unshare::setup_env (chroot const& chroot,
+ environment&  env) const
+{
+  env.add("UNSHARE_NEWNET", get_unshare_net());
+}
+
+sbuild::chroot::session_flags
+chroot_facet_unshare::get_session_flags (chroot const& chroot) const
+{
+  return sbuild::chroot::SESSION_NOFLAGS;
+}
+
+void

Bug#886412: Bug#884781: debomatic: issues on stretch: systemd, fakeroot, and stretch-backports

[Luca Falavigna]

Hi,

thanks for your bug report!

2017-12-19 17:56 GMT+01:00 marjoram :
> 2. While the first build succeeded, subsequent builds failed.

I tried reproducing the issue but I wasn't able to. Can you share your
configuration file and package, so I can try to debug this issue
further?

Bug#872337: Release file generates "W: Invalid 'Date' entry in Release file"

[Luca Falavigna]

Package: apt-utils
Version: 1.4.7


Generating a (In)Release file with apt-ftparchive, I get this date format:
Date: Tuesday, 15 August 2017 23:16:52

APT returns this warning message when attempting to download the Release file:
[...]
W: Invalid 'Date' entry in Release file [...]
[...]

Looking at an official (In)Release file (for instance
ftp://ftp.debian.org/debian/dists/unstable/Release), I can see the
date format is slightly different:
Date: Wed, 16 Aug 2017 08:29:09 UTC

-- 
Cheers,
Luca

Bug#840575: [buildd-tools-devel] Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Luca Falavigna]

2016-11-03 13:41 GMT+01:00 Thomas Goirand :
> Indeed, sbuild in backports is not not installable.

Indeed, I normally test all my packages, and I did this time too...
but I didn't realize I already had gnupg2 installed on stable (private
copy) and I trusted the last line of piuparts log without looking at
what was written a few lines above. Sorry for the mess.

> dkg, you had the intention to upload gnupg 2.1 to backports. Is there
> anything that's holding it?
>
> Lucas, could you upload a version of sbuild to BPO without this hard
> requirement, and maybe with the fix I suggested for the keygen thing?
> While not the definitive solution, this would fix it in the mean time.

If Daniel is willing to upload gnupg2, that would be cool! Otherwise
I'll try to see which other alternatives we have.

-- 
Cheers,
Luca

Bug#840575: [buildd-tools-devel] Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Luca Falavigna]

Hi,

2016-10-14 7:36 GMT+02:00 Johannes Schauer :
> don't know if our current sbuild backporter Luca (in CC) would be willing to
> write such a patch, especially considering that
>
>  - it is a feature of sbuild since version 0.67.0 (I corrected the wiki page
>accordingly) to *not* require signing of the internal dummy repository (and
>thus you don't need to run sbuild-update --keygen anymore) and that
>  - the next stable release is not far away.

Indeed, I think it's pointless to write a patch given that we no
longer suggest to sign the internal repository, and also that explains
why I didn't notice this issue since in order to build the sbuild
backport I used the very same version found in unstable/testing,
installed on a machine running stable where my Deb-o-Matic farm is
running on :-)

-- 
Cheers,
Luca

Bug#819755: Apparently solved for s390x

[Luca Falavigna]

Hi,

I tried again with version 1:2.6+dfsg-3.1, and despite mips and mipsel
are still not working, problem seems fixed for s390x at least.

-- 
Cheers,
Luca

Bug#755415: ITA: gexiv2 -- GObject-based wrapper around the Exiv2 library

[Luca Falavigna]

Hi Jason,

2016-10-03 13:23 GMT+02:00 Jason Crain :
> I would like to adopt gexiv2.  I've done a bit of work already for
> packaging the new version and I plan on uploading it to collab-maint
> soon.  I'll need a sponsor though.  Would you be willing to sponser it?

Great!
Feel free to ping me when ready, I'll be glad to sponsor it.

-- 
Cheers,
Luca

Bug#819755: qemu-user-static: "Temporary failure in name resolution" with qemu-{mips, mipsel, s390x}-static

[Luca Falavigna]

Package: qemu-user-static
Version: 1:2.5+dfsg-5
Severity: important

Dear Maintainer,

I just created a fresh mips schroot using qemu-debootstrap to emulate mips
architecture.

Unfortunately, I cannot resolve any name because it seems DNS resolution is not
working anymore. Attached is strace log of a simple ping against ftp.debian.org

This behaviour happens at least under mips, mipsel and s390x.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.6-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.15-1.1

-- no debconf information
(unstable-mips-test)root@winterfell:~# qemu-mips-static -strace /bin/ping -c 1 
ftp.debian.org
31258 brk(NULL) = 0x00442000
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x767ca000
31258 uname(0x76fff600) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
31258 open("/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3
31258 fstat64(3,0x76fff220) = 0
31258 mmap(NULL,9662,PROT_READ,MAP_PRIVATE,3,0) = 0x767c7000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libcap.so.2",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff364,512) = 512
31258 prctl(46,8,1996485476,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 fstat64(3,0x76fff228) = 0
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x767c6000
31258 mmap(NULL,82288,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x767b1000
31258 mprotect(0x767b5000,61440,PROT_NONE) = 0
31258 
mmap(0x767c4000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x3000)
 = 0x767c4000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/usr/lib/mips-linux-gnu/libidn.so.11",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff34c,512) = 512
31258 prctl(46,8,1996485452,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 fstat64(3,0x76fff210) = 0
31258 mmap(NULL,266688,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x7676f000
31258 mprotect(0x767a,61440,PROT_NONE) = 0
31258 
mmap(0x767af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x3)
 = 0x767af000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libresolv.so.2",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff334,512) = 512
31258 prctl(46,9,1996485428,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 lseek(3,724,0,1988008292,0,0) = 724
31258 read(3,0x76fff298,32) = 32
31258 fstat64(3,0x76fff1f8) = 0
31258 mmap(NULL,157936,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x76748000
31258 mprotect(0x7675b000,65536,PROT_NONE) = 0
31258 
mmap(0x7676b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x13000)
 = 0x7676b000
31258 
mmap(0x7676d000,6384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0)
 = 0x7676d000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libc.so.6",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff31c,512) = 512
31258 prctl(46,13,1996485404,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 lseek(3,520,0,0,0,0) = 520
31258 read(3,0x76fff278,36) = 36
31258 lseek(3,828,0,1988008292,0,0) = 828
31258 read(3,0x76fff250,32) = 32
31258 fstat64(3,0x76fff1e0) = 0
31258 mmap(NULL,1572624,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x765c8000
31258 mprotect(0x7673,65536,PROT_NONE) = 0
31258 
mmap(0x7674,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x168000)
 = 0x7674
31258 
mmap(0x76746000,7952,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0)
 = 0x76746000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libattr.so.1",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff254,512) = 512
31258 prctl(46,8,1996485204,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 fstat64(3,0x76fff118) = 0
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x765c7000
31258 mmap(NULL,82176,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x765b2000
31258 mprotect(0x765b6000,61440,PROT_NONE) = 0
31258 
mmap(0x765c5000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x3000)
 = 0x765c5000
31258 close(3) = 0
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 

Bug#813698: perhaps default to POWER8 only for ppc64el?

[Luca Falavigna]

Contol: -1 + patch


I tried changing default to POWER8 for ppc64el with the attached patch,
and it worked like a charm.

-- 
Cheers,
Luca
Index: qemu-2.5+dfsg/linux-user/main.c
===
--- qemu-2.5+dfsg.orig/linux-user/main.c
+++ qemu-2.5+dfsg/linux-user/main.c
@@ -4173,7 +4173,11 @@ int main(int argc, char **argv, char **e
 cpu_model = "or1200";
 #elif defined(TARGET_PPC)
 # ifdef TARGET_PPC64
+#  ifdef TARGET_WORDS_BIGENDIAN
 cpu_model = "POWER7";
+#  else
+cpu_model = "POWER8";
+#  endif
 # else
 cpu_model = "750";
 # endif


signature.asc
Description: Digital signature

Bug#817234: qemu-debootstrap: allow creation of mips64el chroots

[Luca Falavigna]

Package: qemu-user-static
Version: 1:2.5+dfsg-5
Severity: wishlist
Tags: patch


It could be great if qemu-debootstrap could allow creation of mips64el
chroots out of the box. Attached patch should do the trick.

-- 
Cheers,
Luca


mips64el.patch
Description: Binary data

Bug#813360: Overlayfs available on newer Linux kernel only

[Luca Falavigna]

Improved patch attached.

--
Cheers,
Luca
diff --git a/bin/sbuild-createchroot b/bin/sbuild-createchroot
index 2371999..4bfb73f 100755
--- a/bin/sbuild-createchroot
+++ b/bin/sbuild-createchroot
@@ -307,10 +307,23 @@ root-groups=root,sbuild
 profile=sbuild
 EOF
 } else {
+
+# Determine whether system has overlayfs capability
+my $uniontype = "union-type=none";
+if (lc("$^O") =~ /linux/) {
+system("/sbin/modprobe overlay");
+if (open(FILE, "/proc/filesystems")) {
+if (grep {/\soverlay$/} ) {
+$uniontype = "union-type=overlay";
+}
+close(FILE);
+}
+}
+
 $config_entry = <<"EOF";
 [$chrootname]
 type=directory
-union-type=overlay
+$uniontype
 description=Debian $suite/$arch autobuilder
 directory=$target
 groups=root,sbuild

Bug#813360: [buildd-tools-devel] Bug#813360: Overlayfs available on newer Linux kernel only

[Luca Falavigna]

Control: tags -1 + patch

2016-02-01 16:41 GMT+01:00 Johannes Schauer :
> You initially offered a patch - I'd definitely welcome one :)

Attached :)

-- 
Cheers,
Luca


union-type_runtime.patch
Description: Binary data

Bug#813360: Overlayfs available on newer Linux kernel only

[Luca Falavigna]

Package: sbuild
Version: 0.67.0-1
Severity: minor


Since version 0.67.0, sbuild create directory chroots using overlayfs.

Beside the fact overlayfs is available since 3.18 Linux kernels, which
makes a little bit harder to backport latest sbuild (for instance,
Jessie has 3.16), this change could cause issues on systems where
overlayfs is not available (thinking about kFreeBSD, for instance).

Would a patch adding a new switch to define a different union-type
method be welcome?

-- 
Cheers,
Luca

Bug#813360: [buildd-tools-devel] Bug#813360: Overlayfs available on newer Linux kernel only

[Luca Falavigna]

2016-02-01 12:32 GMT+01:00 Johannes Schauer :
> does there exist an easy way to detect at run-time whether overlayfs is
> available on the system?

A dumb method could be checking whether the filesystem is listed in
/proc/filesystems:
$ cat /proc/filesystems | grep overlay
nodev overlay
$

But I think it will return nothing if overlay module is not loaded via
modprobe first, and again it's Linux-specific...

A full check would be like this:
if system is Linux:
if /proc/filesystem contains overlayfs:
overlayfs available
else if modprobe overlay:
overlayfs available
else:
overlayfs not available
else:
overlayfs not available

... but my impression it's not 100% error-proof.

-- 
Cheers,
Luca

Bug#806587: Build-dependencies found

[Luca Falavigna]

Control: tags -1 + moreinfo


Not ready yet:
# Broken Depends:
upnp-inspector: upnp-inspector

# Broken Build-Depends:
upnp-inspector: python-coherence

Bug#804514: lilypond: diff for NMU version 2.18.2-4.1

[Luca Falavigna]

Control: tags 804514 + patch
Control: tags 804514 + pending

Dear maintainer,

I've prepared an NMU for lilypond (versioned as 2.18.2-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru lilypond-2.18.2/debian/changelog lilypond-2.18.2/debian/changelog
--- lilypond-2.18.2/debian/changelog	2014-11-17 02:38:32.0 +0100
+++ lilypond-2.18.2/debian/changelog	2015-12-30 14:58:24.0 +0100
@@ -1,3 +1,11 @@
+lilypond (2.18.2-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
+- Replace ttf-kochi fonts with ipafonts (Closes: #804514).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Wed, 30 Dec 2015 14:57:33 +0100
+
 lilypond (2.18.2-4) unstable; urgency=medium
 
   * Fix the wrong maintscript-helper invocation which was trying to
diff -Nru lilypond-2.18.2/debian/control lilypond-2.18.2/debian/control
--- lilypond-2.18.2/debian/control	2014-11-17 02:36:59.0 +0100
+++ lilypond-2.18.2/debian/control	2015-12-30 14:56:35.0 +0100
@@ -10,7 +10,7 @@
  emacs-intl-fonts, xfonts-intl-arabic, xfonts-intl-asian,
  xfonts-intl-chinese, xfonts-intl-chinese-big, xfonts-intl-european,
  xfonts-intl-japanese, xfonts-intl-japanese-big, xfonts-intl-phonetic,
- ttf-kochi-gothic, ttf-kochi-mincho, ttf-dejavu, ttf-freefont,
+ fonts-ipafont-gothic, fonts-ipafont-mincho, ttf-dejavu, ttf-freefont,
  texlive-lang-cyrillic,
  gsfonts | gsfonts-x11
 Section: tex

Bug#809502: RM: snooper -- RoQA; Orphaned, alternatives exist, depends on old library

[Luca Falavigna]

Package: ftp.debian.org
Severity: normal

Please remove snooper from unstable.

It's orphaned since three years already, it depends on lockdev which is
scheduled to be removed (#734086) and its functionalities could be implemented
by socat and other tools.

Bug#809414: RM: wdg-html-validator -- RoQA; unmaintained, depends on to-be-removed package

[Luca Falavigna]

Package: ftp.debian.org
Severity: normal

Please remove wdg-html-validator from unstable.

It is unmaintained since 2006, and depends on w3c-dtd-xhtml which is scheduled
to be removed (#711332).

Bug#807644: RM: haskell-mtl-compat -- ROM; Unneeded compat package

[Luca Falavigna]

Hi,

2015-12-27 15:12 GMT+01:00 Joachim Breitner :
> cannot reproduce, no mention of mtl-compat in
> http://ftp.uni-kl.de/debian/pool/main/h/haskell-haxr/haskell-haxr_3000.11.1.2-1.dsc
> Is there a cruft binary keeping an old version of the haskell-haxr
> source package around?

Good point, it seems it's the case:
$ dak ls -s unstable -a source haskell-haxr
haskell-haxr | 3000.10.4.2-1 | unstable   | source
haskell-haxr | 3000.11.1.2-1 | unstable   | source
$

-- 
Cheers,
Luca

Bug#807644: RM: haskell-mtl-compat -- ROM; Unneeded compat package

[Luca Falavigna]

Control: tags -1 + moreinfo


2015-12-11 10:06 GMT+01:00 Joachim Breitner :
> haskell-mtl-compat is a compat package that with GHC 7.10 becomes empty,
> so we patch out any use of it, to avoid shipping pointless packages in
> Debian. Hence it should be removed.

Not ready yet:

# Broken Build-Depends:
haskell-haxr: libghc-mtl-compat-dev
  libghc-mtl-compat-doc
  libghc-mtl-compat-prof

Bug#798478: ratpoison: diff for NMU version 1.4.8-1.1

[Luca Falavigna]

Control: tags 798478 + patch
Control: tags 798478 + pending

Dear maintainer,

I've prepared an NMU for ratpoison (versioned as 1.4.8-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru ratpoison-1.4.8/debian/changelog ratpoison-1.4.8/debian/changelog
--- ratpoison-1.4.8/debian/changelog	2014-10-10 12:01:48.0 +0200
+++ ratpoison-1.4.8/debian/changelog	2015-12-26 15:29:45.0 +0100
@@ -1,3 +1,10 @@
+ratpoison (1.4.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install files in python-support directories (Closes: #798478).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Sat, 26 Dec 2015 15:28:30 +0100
+
 ratpoison (1.4.8-1) unstable; urgency=medium
 
   * new upstream bugfix release
diff -Nru ratpoison-1.4.8/debian/dirs ratpoison-1.4.8/debian/dirs
--- ratpoison-1.4.8/debian/dirs	2014-10-10 12:01:22.0 +0200
+++ ratpoison-1.4.8/debian/dirs	2015-12-26 15:25:53.0 +0100
@@ -3,5 +3,4 @@
 var/lib/ratpoison/menu
 usr/share/emacs/site-lisp/ratpoison
 usr/share/perl5
-usr/share/python-support/ratpoison
 usr/lib/ruby/1.8
diff -Nru ratpoison-1.4.8/debian/postinst ratpoison-1.4.8/debian/postinst
--- ratpoison-1.4.8/debian/postinst	2014-10-10 12:01:22.0 +0200
+++ ratpoison-1.4.8/debian/postinst	2015-12-26 15:26:25.0 +0100
@@ -24,11 +24,6 @@
 ;;
 esac
 
-# taken from dh_pysupport
-if [ "$1" = "configure" ] && which update-python-modules >/dev/null 2>&1; then
-	update-python-modules -i /usr/share/python-support/ratpoison
-fi
-
 #DEBHELPER#
 
 exit 0
diff -Nru ratpoison-1.4.8/debian/prerm ratpoison-1.4.8/debian/prerm
--- ratpoison-1.4.8/debian/prerm	2014-10-10 12:01:22.0 +0200
+++ ratpoison-1.4.8/debian/prerm	2015-12-26 15:26:31.0 +0100
@@ -18,11 +18,6 @@
 ;;
 esac
 
-# taken from dh_pysupport:
-if which update-python-modules >/dev/null 2>&1; then
-	update-python-modules -c -i /usr/share/python-support/ratpoison
-fi
-
 #DEBHELPER#
 
 exit 0
diff -Nru ratpoison-1.4.8/debian/ratpoison.install ratpoison-1.4.8/debian/ratpoison.install
--- ratpoison-1.4.8/debian/ratpoison.install	2014-10-10 12:01:22.0 +0200
+++ ratpoison-1.4.8/debian/ratpoison.install	2015-12-26 15:26:50.0 +0100
@@ -1,4 +1,4 @@
 contrib/Ratpoison.pm /usr/share/perl5/
 contrib/ratpoison.rb /usr/lib/ruby/1.8/
-contrib/ratpoison.py /usr/share/python-support/ratpoison/
+contrib/ratpoison.py /usr/share/ratpoison/
 contrib/ratpoison-cmd.el /usr/share/emacs/site-lisp/ratpoison/

Bug#787925: RM: python-uniconvertor -- RoQA; unmaintained, RC buggy

[Luca Falavigna]

Hi,

2015-12-15 23:18 GMT+01:00 Mattia Rizzolo :
> maybe this RM can be withdrawed?

I have nothing against uniconvertor to stay in the archive. This RM is
purely meant to allow for a clean removal of python-support, but as
long as uniconvertor is pysupport-free I don't see added benefit in
removing it.

> If that's the case guess I can re-NMU tgif so it can beccome
> fully-featured again.

Indeed.

-- 
Cheers,
Luca

Bug#807744: sbuild: aptitude 0.7.5-2 breaks sbuild upon install-deps

[Luca Falavigna]

Source: sbuild
Severity: important

Dear Maintainer,

aptitude_0.7.5-2 breaks sbuild during its install-deps stage, when aptitude is
used as resolver to install build-dependencies.

This is the offending commit:
https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?h=debian-
sid=a865d7dd4040273eda0c012cfd20862de3c6622f

This is the portion of the log which exposes the problem:
Writing extended state information...
Building tag database...
E: Could not create directory: /sbuild-nonexistent/.cache:
boost::filesystem::create_directory: No such file or directory: "/sbuild-
nonexistent/.cache"



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Control: retitle -1 Commands for chroot update failed stage
Control: severity -1 wishlist


2015-10-31 8:32 GMT+01:00 Johannes Schauer :
> if you run multiple concurrent sbuild instances, would it not be a better idea
> to always run sbuild with --no-apt-update and instead run "sbuild-update
> -udcar" whenever it is actually needed? I imagine that lots of time is lost by
> "apt-get update" being run on every build even if there is nothing new to
> update.

Unfortunately my use case is a special (and therefore quite uncommon)
one, and everytime a build is scheduled there is always need to update
the APT cache because the local repository changes so often.

Anyway, I think you're right saying update and build-dep phases must
be handled separately because it is possible to install build-deps
without updating the chroot, but it would be nice to have a command
for update failures anyway. If you think this is not worth the burden,
feel free to close the bug, and I'll handle my use case in a different
way :)

-- 
Cheers,
Luca

Bug#803505: [buildd-tools-devel] Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Hi!

2015-10-30 22:00 GMT+01:00 Johannes Schauer :
> What would the benefit be to have a --apt-get-update-failed-commands hook?
> Which hook would one like to run when "apt-get update" failed?

I have a local repository of built packages linked to my sbuild
instances. Everytime a build is successful, the repository indexes are
updated. In case of multiple builds, it could happen newer concurrent
builds start to update apt cache just in the middle of a
apt-ftparchive run, resulting in a "hash sum mismatch" error.

I would like to implement a simple locking mechanism using plain files
(it's definitely not the best approach, I welcome better ideas ;). I
acquire the lock in the chroot-setup and I should manage the removal
of the lock if something goes wrong in whatever stage. With the
current status, if sbuild fails in apt-get-update the lock is never
deleted because no commands are triggered.

-- 
Cheers,
Luca

Bug#803505: sbuild: Run build-deps-failed-commands on apt-get-update fail stage too

[Luca Falavigna]

Source: sbuild
Version: 0.66.0-5
Severity: normal

Dear Maintainer,

sometimes my builds fail because of issues during apt-get-update phase. To
handle these cases, I would like to use --build-deps-failed-commands (or
alternatively --anything-failed-commands), but it seems neither of them are
triggered on apt-get-update failed stage.

Would it be possible to extend the scope of build-deps-failed-commands to
address this scenario too? After all, "Run  these  commands  we tried to
install the dependencies but failed for whatever reason" is somewhat included,
as build-deps won't be processed at all if update is not completed
successfully...

Alternatively, having another command type like --apt-get-update-failed-
commands would be fine too!



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#799946: RM: oggconvert -- ROM: no longer maintained upstream

[Luca Falavigna]

Package: ftp.debian.org
Severity: normal


Please remove oggconvert from unstable.

Last upstream release is dated 2010, and it seems it has been
abandoned (no commits in upstream repo since 2011). #785848 requires
porting work which I can't provide at the moment, and nobody stepped
in to maintain the package (#755300), so I think removing the package
from Debian is the right choice.

Bug#798429: ftp.debian.org: Reject messages about source-only uploads should be more informative

[Luca Falavigna]

Hi,

2015-09-09 11:25 GMT+02:00 Santiago Vila :
> binary:ekg2-api-docs is NEW.


> Omitting long explanations about how the NEW queue works is ok, but at
> the very minimum, the uploader should be told about *what* part of the
> upload is considered to be NEW.

The line above indicates which part is considered NEW.
It mentions both binary packages and source packages.

-- 
Cheers,
Luca

Bug#755303: RFA: remmina -- remote desktop client for GNOME desktop environment

[Luca Falavigna]

Hi Jörg,

I think no efforts have been made to adopt the package in the last
months, so feel free to adopt remmina. Don't hesitate to contact me if
you need a sponsor.

-- 
Cheers,
Luca

Bug#785992: couchapp: diff for NMU version 1.0.1+git20140213+dfsg1-1.1

[Luca Falavigna]

Control: tags 785992 + patch

Dear maintainer,

I've prepared an NMU for couchapp (versioned as 1.0.1+git20140213+dfsg1-1.1). 
The diff
is attached to this message.

Regards.
diff -Nru couchapp-1.0.1+git20140213+dfsg1/debian/changelog couchapp-1.0.1+git20140213+dfsg1/debian/changelog
--- couchapp-1.0.1+git20140213+dfsg1/debian/changelog	2014-04-15 22:57:28.0 +0200
+++ couchapp-1.0.1+git20140213+dfsg1/debian/changelog	2015-09-12 18:41:00.0 +0200
@@ -1,3 +1,10 @@
+couchapp (1.0.1+git20140213+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove useless python-support build-dependency (Closes: #785992).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Sat, 12 Sep 2015 18:40:23 +0200
+
 couchapp (1.0.1+git20140213+dfsg1-1) unstable; urgency=medium
 
   * Initial release. (Closes: #735479).
diff -Nru couchapp-1.0.1+git20140213+dfsg1/debian/control couchapp-1.0.1+git20140213+dfsg1/debian/control
--- couchapp-1.0.1+git20140213+dfsg1/debian/control	2014-05-12 16:18:43.0 +0200
+++ couchapp-1.0.1+git20140213+dfsg1/debian/control	2015-09-12 18:39:55.0 +0200
@@ -10,7 +10,7 @@
python-nose-testconfig,
python-restkit,
python-setuptools,
-   python-support,
+   dh-python,
python-unittest2
 Standards-Version: 3.9.5
 Homepage: http://couchapp.org/

Bug#785989: cwiid: diff for NMU version 0.6.00+svn201-3.2

[Luca Falavigna]

Control: tags 785989 + patch
Control: tags 785989 + pending

Dear maintainer,

I've prepared an NMU for cwiid (versioned as 0.6.00+svn201-3.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru cwiid-0.6.00+svn201/debian/changelog cwiid-0.6.00+svn201/debian/changelog
--- cwiid-0.6.00+svn201/debian/changelog	2014-02-16 08:46:48.0 +0100
+++ cwiid-0.6.00+svn201/debian/changelog	2015-09-12 18:36:25.0 +0200
@@ -1,3 +1,10 @@
+cwiid (0.6.00+svn201-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #785989).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Sat, 12 Sep 2015 18:35:59 +0200
+
 cwiid (0.6.00+svn201-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cwiid-0.6.00+svn201/debian/control cwiid-0.6.00+svn201/debian/control
--- cwiid-0.6.00+svn201/debian/control	2014-02-16 08:45:51.0 +0100
+++ cwiid-0.6.00+svn201/debian/control	2015-09-12 18:35:33.0 +0200
@@ -2,7 +2,6 @@
 Section: utils
 Priority: extra
 Maintainer: Romain Beauxis <to...@rastageeks.org>
-XS-Python-Version: all
 Build-Depends: cdbs (>= 0.4.85~),
  debhelper (>= 7.0.1),
  dh-buildinfo,
@@ -11,7 +10,7 @@
  autoconf,
  quilt,
  patchutils (>= 0.2.25),
-   python-all-dev, python, python-support, 
+   python-all-dev, python, dh-python, 
libbluetooth-dev, libgtk2.0-dev, flex, bison
 Standards-Version: 3.9.2
 Homepage: http://abstrakraft.org/cwiid/
@@ -19,8 +18,6 @@
 Package: python-cwiid
 Architecture: any
 Depends: ${python:Depends}, ${shlibs:Depends}, libcwiid1 (>= ${binary:Version}), ${misc:Depends}
-XB-Python-Version: ${python:Versions}
-Provides: ${python:Provides}
 Section: python
 Description: library to interface with the wiimote
  CWiid is a working userspace driver along with various
diff -Nru cwiid-0.6.00+svn201/debian/control.in cwiid-0.6.00+svn201/debian/control.in
--- cwiid-0.6.00+svn201/debian/control.in	2011-04-24 00:27:34.0 +0200
+++ cwiid-0.6.00+svn201/debian/control.in	2015-09-12 18:34:54.0 +0200
@@ -2,9 +2,8 @@
 Section: utils
 Priority: extra
 Maintainer: Romain Beauxis <to...@rastageeks.org>
-XS-Python-Version: all
 Build-Depends: @cdbs@, 
-   python-all-dev, python, python-support, 
+   python-all-dev, python, dh-support, 
libbluetooth-dev, libgtk2.0-dev, flex, bison
 Standards-Version: 3.9.2
 Homepage: http://abstrakraft.org/cwiid/
@@ -12,8 +11,6 @@
 Package: python-cwiid
 Architecture: any
 Depends: ${python:Depends}, ${shlibs:Depends}, libcwiid1 (>= ${binary:Version}), ${misc:Depends}
-XB-Python-Version: ${python:Versions}
-Provides: ${python:Provides}
 Section: python
 Description: library to interface with the wiimote
  CWiid is a working userspace driver along with various
diff -Nru cwiid-0.6.00+svn201/debian/rules cwiid-0.6.00+svn201/debian/rules
--- cwiid-0.6.00+svn201/debian/rules	2014-02-16 08:45:51.0 +0100
+++ cwiid-0.6.00+svn201/debian/rules	2015-09-12 18:35:22.0 +0200
@@ -25,7 +25,7 @@
 #LDFLAGS := -Wl,--as-needed -lbluetooth -lrt
 
 binary-install/python-cwiid::
-	dh_pysupport -ppython-cwiid
+	dh_python2 -ppython-cwiid
 
 configure/lswm::
 	mkdir -p $(CURDIR)/debian/tmp/usr/bin

Bug#785986: connectomeviewer: diff for NMU version 2.1.0-1.1

[Luca Falavigna]

Control: tags 785986 + patch
Control: tags 785986 + pending

Dear maintainer,

I've prepared an NMU for connectomeviewer (versioned as 2.1.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru connectomeviewer-2.1.0/debian/changelog connectomeviewer-2.1.0/debian/changelog
--- connectomeviewer-2.1.0/debian/changelog	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/changelog	2015-09-12 18:29:55.0 +0200
@@ -1,3 +1,10 @@
+connectomeviewer (2.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #785986).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Sat, 12 Sep 2015 18:29:30 +0200
+
 connectomeviewer (2.1.0-1) unstable; urgency=low
 
   * Namespace transition for Enthought Packages
diff -Nru connectomeviewer-2.1.0/debian/control connectomeviewer-2.1.0/debian/control
--- connectomeviewer-2.1.0/debian/control	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/control	2015-09-12 18:28:30.0 +0200
@@ -2,12 +2,13 @@
 Section: python
 Priority: extra
 Maintainer: Stephan Gerhard <deb...@unidesign.ch>
-Build-Depends: debhelper (>= 7.2.18), python-all (>= 2.6), python-support,
+Build-Depends: debhelper (>= 7.2.18), python-all (>= 2.6), dh-python,
 			   python-numpy (>= 1.3.0), python-setuptools, python-traits (>= 4)
 Standards-Version: 3.9.2
 Homepage: http://www.connectomeviewer.org
 Vcs-Git: git://github.com/LTS5/connectomeviewer.git
 Vcs-Browser: http://github.com/LTS5/connectomeviewer
+X-Python-Version: >= 2.6
 
 Package: connectomeviewer
 Architecture: all
diff -Nru connectomeviewer-2.1.0/debian/pyversions connectomeviewer-2.1.0/debian/pyversions
--- connectomeviewer-2.1.0/debian/pyversions	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/pyversions	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2.6-
\ No newline at end of file
diff -Nru connectomeviewer-2.1.0/debian/rules connectomeviewer-2.1.0/debian/rules
--- connectomeviewer-2.1.0/debian/rules	2012-05-03 17:47:08.0 +0200
+++ connectomeviewer-2.1.0/debian/rules	2015-09-12 18:27:13.0 +0200
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 
 %:
-	dh $@
+	dh $@ --with python2
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#786182: nglister: diff for NMU version 1.0.1+nmu2

[Luca Falavigna]

Control: tags 786182 + patch

Dear maintainer,

I've prepared an NMU for nglister (versioned as 1.0.1+nmu2). The diff
is attached to this message.

Regards.
diff -Nru nglister-1.0.1+nmu1/debian/changelog nglister-1.0.1+nmu2/debian/changelog
--- nglister-1.0.1+nmu1/debian/changelog	2010-03-07 14:16:40.0 +0100
+++ nglister-1.0.1+nmu2/debian/changelog	2015-09-09 20:58:44.0 +0200
@@ -1,3 +1,10 @@
+nglister (1.0.1+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #786182).
+
+ -- Luca Falavigna <dktrkr...@debian.org>  Wed, 09 Sep 2015 20:52:54 +0200
+
 nglister (1.0.1+nmu1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru nglister-1.0.1+nmu1/debian/control nglister-1.0.1+nmu2/debian/control
--- nglister-1.0.1+nmu1/debian/control	2010-03-07 14:16:40.0 +0100
+++ nglister-1.0.1+nmu2/debian/control	2015-09-09 20:56:34.0 +0200
@@ -2,12 +2,12 @@
 Section: news
 Priority: optional
 Maintainer: John Goerzen <jgoer...@complete.org>
-Build-Depends-Indep: debhelper (>> 3.0.0), python-dev (>= 2.3), python-support
+Build-Depends: debhelper (>> 3.0.0), python (>= 2.3), dh-python
 Standards-Version: 3.5.8
 
 Package: nglister
 Architecture: all
-Depends: python (>= 2.3)
+Depends: ${python:Depends}, ${misc:Depends}
 Description: Downloads information from NNTP server
  NGLister is a simple program designed to download information from an
  NNTP server.  It can download lists of newsgroups (active file),
diff -Nru nglister-1.0.1+nmu1/debian/copyright nglister-1.0.1+nmu2/debian/copyright
--- nglister-1.0.1+nmu1/debian/copyright	2003-11-20 03:51:29.0 +0100
+++ nglister-1.0.1+nmu2/debian/copyright	2015-09-09 20:55:41.0 +0200
@@ -1,7 +1,7 @@
 This package was debianized by John Goerzen <jgoer...@complete.org> on
 Wed, 12 Feb 2003 11:07:14 -0600.
 
-Upstream Author(s): John Goerzen <jgoer...@complete.org>
+Upstream Author: John Goerzen <jgoer...@complete.org>
 
 Copyright (C) 2003 John Goerzen
 <jgoer...@complete.org>
diff -Nru nglister-1.0.1+nmu1/debian/rules nglister-1.0.1+nmu2/debian/rules
--- nglister-1.0.1+nmu1/debian/rules	2010-03-07 14:23:24.0 +0100
+++ nglister-1.0.1+nmu2/debian/rules	2015-09-09 20:52:44.0 +0200
@@ -81,7 +81,7 @@
 	dh_installinfo
 #	dh_undocumented
 	dh_installchangelogs
-	dh_pysupport
+	dh_python2
 	dh_link
 	dh_strip
 	dh_compress

Bug#786558: RFS: sequitur-g2p/0.0.r1668-2 -- Grapheme to Phoneme conversion tool

[Luca Falavigna]

Hi Giulio,

are you still looking for a sponsor for sequitur-g2p? I could have a
look at it if you want. I'm mostly interested in having python-support
removed (#786139), but I'll be happy to help you with other issues.

-- 
Cheers,
Luca

Bug#794508: debomatic: [INTL:pt] Portuguese translation (update)

[Luca Falavigna]

2015-08-03 22:55 GMT+02:00 Américo Monteiro a_monte...@gmx.com:
 Updated Portuguese translation for debomatic's UI's messages.

Thanks a lot for your precious work on translating debomatic!

Could you please have a look at the updated .pot file with the latest
translations (some of them changed since version 0.20), and possibly
it will be the final version for the next upcoming release.

Thanks a lot!
Luca


debomatic.pot
Description: MS-Powerpoint presentation

Bug#785949: NMU cancelled

[Luca Falavigna]

Control: tags -1 - pending
Control: tags -1 + patch

Apparently the NMU was cancelled, reflecting this in the bug tags.

-- 
Cheers,
Luca

Bug#786049: pynn: diff for NMU version 0.7.5-1.1

[Luca Falavigna]

Dear maintainer,

I've prepared an NMU for pynn (versioned as 0.7.5-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru pynn-0.7.5/debian/changelog pynn-0.7.5/debian/changelog
--- pynn-0.7.5/debian/changelog 2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/changelog 2015-08-24 08:19:23.0 +0200
@@ -1,3 +1,10 @@
+pynn (0.7.5-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #786049).
+
+ -- Luca Falavigna dktrkr...@debian.org  Mon, 24 Aug 2015 08:18:43 +0200
+
 pynn (0.7.5-1) experimental; urgency=low
 
   * New upstream bugfix release
diff -Nru pynn-0.7.5/debian/control pynn-0.7.5/debian/control
--- pynn-0.7.5/debian/control   2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/control   2015-08-24 08:18:10.0 +0200
@@ -5,7 +5,7 @@
 Uploaders: Yaroslav Halchenko deb...@onerussian.com,
Michael Hanke m...@debian.org
 Build-Depends: debhelper (= 7.0.50~),
-   python, python-support,
+   python, dh-python,
python-numpy,
python-nose, python-mock,
python-cheetah, python-jinja2
diff -Nru pynn-0.7.5/debian/pyversions pynn-0.7.5/debian/pyversions
--- pynn-0.7.5/debian/pyversions2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/pyversions1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2.5-
diff -Nru pynn-0.7.5/debian/rules pynn-0.7.5/debian/rules
--- pynn-0.7.5/debian/rules 2013-02-06 15:52:46.0 +0100
+++ pynn-0.7.5/debian/rules 2015-08-24 08:18:28.0 +0200
@@ -2,7 +2,7 @@
 # -*- makefile -*-
 
 %:
-   dh $@
+   dh $@ --with python2
 
 override_dh_auto_test:
for PYVER in `pyversions -d -r -v`; do \

Bug#786112: python-edbus: diff for NMU version 0.7.3-1.1

[Luca Falavigna]

Dear maintainer,

I've prepared an NMU for python-edbus (versioned as 0.7.3-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru python-edbus-0.7.3/debian/changelog 
python-edbus-0.7.3/debian/changelog
--- python-edbus-0.7.3/debian/changelog 2010-10-17 21:41:04.0 +0200
+++ python-edbus-0.7.3/debian/changelog 2015-08-24 08:48:13.0 +0200
@@ -1,3 +1,10 @@
+python-edbus (0.7.3-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh_python2 (Closes: #786112).
+
+ -- Luca Falavigna dktrkr...@debian.org  Mon, 24 Aug 2015 08:47:48 +0200
+
 python-edbus (0.7.3-1) experimental; urgency=low
 
   * New upstream release
diff -Nru python-edbus-0.7.3/debian/control python-edbus-0.7.3/debian/control
--- python-edbus-0.7.3/debian/control   2010-10-17 21:41:04.0 +0200
+++ python-edbus-0.7.3/debian/control   2015-08-24 08:43:19.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Debian Pkg-e Team pkg-e-de...@lists.alioth.debian.org
 Uploaders: Jan Lübbe jlue...@debian.org, Albin Tonnerre lu...@debian.org
 Build-Depends: debhelper (= 5.0.38), cdbs (= 0.4.49),
- python-all-dev (= 2.3.5-11), python-support (= 0.5.3),
+ python-all-dev (= 2.3.5-11), dh-python,
  python-setuptools (= 0.6c9), cython, python-pyrex,
  libedbus-dev (= 1.0.0~), python-dbus (= 0.8.3)
 Standards-Version: 3.9.1
@@ -13,7 +13,6 @@
 Homepage: http://enlightenment.org
 
 Package: python-edbus
-XB-Python-Version: ${python:Versions}
 Provides: ${python:Provides}
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
diff -Nru python-edbus-0.7.3/debian/pycompat python-edbus-0.7.3/debian/pycompat
--- python-edbus-0.7.3/debian/pycompat  2010-10-17 21:41:04.0 +0200
+++ python-edbus-0.7.3/debian/pycompat  1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2
diff -Nru python-edbus-0.7.3/debian/pyversions 
python-edbus-0.7.3/debian/pyversions
--- python-edbus-0.7.3/debian/pyversions2010-10-17 21:41:04.0 
+0200
+++ python-edbus-0.7.3/debian/pyversions1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-2.4-
diff -Nru python-edbus-0.7.3/debian/rules python-edbus-0.7.3/debian/rules
--- python-edbus-0.7.3/debian/rules 2010-10-17 21:41:04.0 +0200
+++ python-edbus-0.7.3/debian/rules 2015-08-24 13:33:07.0 +0200
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 # -*- mode: makefile; coding: utf-8 -*-
 
-DEB_PYTHON_SYSTEM=pysupport
 DEB_DESTDIR = $(CURDIR)/debian/tmp
 
 include /usr/share/cdbs/1/rules/debhelper.mk

Bug#785953: biosig4c++: diff for NMU version 1.4.1-1.1

[Luca Falavigna]

Dear maintainer,

I've prepared an NMU for biosig4c++ (versioned as 1.4.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru biosig4c++-1.4.1/debian/changelog biosig4c++-1.4.1/debian/changelog
--- biosig4c++-1.4.1/debian/changelog	2012-10-25 16:22:45.0 +0200
+++ biosig4c++-1.4.1/debian/changelog	2015-08-23 09:31:51.0 +0200
@@ -1,3 +1,10 @@
+biosig4c++ (1.4.1-1.1) experimental; urgency=low
+
+  * Non-maintainer upload.
+  * Port from python-support to dh_python2 (Closes: #785953).
+
+ -- Luca Falavigna dktrkr...@debian.org  Sun, 23 Aug 2015 09:31:29 +0200
+
 biosig4c++ (1.4.1-1) experimental; urgency=low
 
   * Fresh upstream release:
diff -Nru biosig4c++-1.4.1/debian/control biosig4c++-1.4.1/debian/control
--- biosig4c++-1.4.1/debian/control	2012-10-25 16:22:45.0 +0200
+++ biosig4c++-1.4.1/debian/control	2015-08-23 09:33:09.0 +0200
@@ -2,9 +2,9 @@
 Priority: extra
 Maintainer: NeuroDebian Team t...@neuro.debian.net
 Uploaders: Yaroslav Halchenko deb...@onerussian.com, Michael Hanke michael.ha...@gmail.com
-Build-Depends: debhelper (= 7.0.50~),
+Build-Depends: debhelper (= 7.0.50~), dh-python,
gawk,
-   python-dev, python-support, swig, python-numpy,
+   python-dev, swig, python-numpy,
zlib1g-dev, libsuitesparse-dev,
octave-pkg-dev (= 0.5.7),
 Standards-Version: 3.9.3
diff -Nru biosig4c++-1.4.1/debian/rules biosig4c++-1.4.1/debian/rules
--- biosig4c++-1.4.1/debian/rules	2012-10-25 16:22:45.0 +0200
+++ biosig4c++-1.4.1/debian/rules	2015-08-23 09:31:20.0 +0200
@@ -4,7 +4,7 @@
 MAKEOPTS=LIBEXT=so
 
 %:
-	dh  $@
+	dh $@ --with python2
 
 override_dh_auto_configure:
 	dh_auto_configure
@@ -60,10 +60,6 @@
 
 override_dh_strip:
 	dh_strip --dbg-package=libbiosig1-dbg
-	: # Address lintian concern about location
-	[ -d debian/libbiosig1-dbg/usr/lib/debug/usr/lib/pyshared ]  \
-		mv debian/libbiosig1-dbg/usr/lib/debug/usr/lib/pyshared \
-		   debian/libbiosig1-dbg/usr/lib/debug/usr/lib/pymodules || :
 
 # Tune up permission for .mex files this late in the chain
 # Silly dh_strip, dh_shlibdeps do not process those since extension

Bug#785990: distcc: diff for NMU version 3.1-6.2

[Luca Falavigna]

Control: tags 785990 + patch
Control: tags 785990 + pending

Dear maintainer,

I've prepared an NMU for distcc (versioned as 3.1-6.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru distcc-3.1/debian/changelog distcc-3.1/debian/changelog
--- distcc-3.1/debian/changelog	2014-10-27 19:19:18.0 +0100
+++ distcc-3.1/debian/changelog	2015-08-23 09:55:23.0 +0200
@@ -1,3 +1,10 @@
+distcc (3.1-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Port to dh_python2 (Closes: #785990).
+
+ -- Luca Falavigna dktrkr...@debian.org  Sun, 23 Aug 2015 09:54:48 +0200
+
 distcc (3.1-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru distcc-3.1/debian/control distcc-3.1/debian/control
--- distcc-3.1/debian/control	2013-01-10 12:05:14.0 +0100
+++ distcc-3.1/debian/control	2015-08-23 09:51:39.0 +0200
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Daniel Hartwig mand...@gmail.com
-Build-Depends: debhelper (= 9), libpopt-dev, linuxdoc-tools, autoconf, libgtk2.0-dev, libgnomeui-dev, po-debconf, python-dev, python-support (= 0.90), autotools-dev
+Build-Depends: debhelper (= 9), libpopt-dev, linuxdoc-tools, autoconf, libgtk2.0-dev, libgnomeui-dev, po-debconf, python-dev, dh-python, autotools-dev
 Standards-Version: 3.9.3
 Homepage: http://code.google.com/p/distcc/
 
diff -Nru distcc-3.1/debian/pyversions distcc-3.1/debian/pyversions
--- distcc-3.1/debian/pyversions	2013-01-10 11:55:32.0 +0100
+++ distcc-3.1/debian/pyversions	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2.5-
diff -Nru distcc-3.1/debian/rules distcc-3.1/debian/rules
--- distcc-3.1/debian/rules	2013-05-06 15:47:08.0 +0200
+++ distcc-3.1/debian/rules	2015-08-23 09:53:27.0 +0200
@@ -14,7 +14,7 @@
 DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
-	dh $@ --with autotools_dev,python-support --parallel \
+	dh $@ --with autotools_dev,python2 --parallel \
 	  --sourcedirectory=source
 
 override_dh_auto_configure:

Bug#786366: pybliographer: diff for NMU version 1.3.2-1.2

[Luca Falavigna]

Control: tags 786366 + patch
Control: tags 786366 + pending

Dear maintainer,

I've prepared an NMU for pybliographer (versioned as 1.3.2-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u pybliographer-1.3.2/debian/rules pybliographer-1.3.2/debian/rules
--- pybliographer-1.3.2/debian/rules
+++ pybliographer-1.3.2/debian/rules
@@ -91,7 +91,7 @@
 
 	cp debian/pybliographic.xpm $(d)/usr/share/pixmaps
 	dh_installmenu
-	dh_pysupport
+	dh_python2
 	dh_strip
 	dh_compress
 	dh_fixperms
diff -u pybliographer-1.3.2/debian/control pybliographer-1.3.2/debian/control
--- pybliographer-1.3.2/debian/control
+++ pybliographer-1.3.2/debian/control
@@ -4,8 +4,7 @@
 Maintainer: Chris Lawrence lawre...@debian.org
 Standards-Version: 3.7.2
 Build-Depends: debhelper (= 5.0.37.2), python-setuptools
-Build-Depends-Indep: python-dev (= 2.5), python-bibtex (= 1.2.2-3), python-gnome2, python-glade2, gettext, python-support (= 0.3)
-XS-Python-Version: current
+Build-Depends-Indep: python-dev (= 2.5), python-bibtex (= 1.2.2-3), python-gnome2, python-glade2, gettext, dh-python
 
 Package: pybliographer
 Architecture: all
diff -u pybliographer-1.3.2/debian/changelog pybliographer-1.3.2/debian/changelog
--- pybliographer-1.3.2/debian/changelog
+++ pybliographer-1.3.2/debian/changelog
@@ -1,3 +1,11 @@
+pybliographer (1.3.2-1.2) experimental; urgency=low
+
+  * Non-maintainer upload.
+  * Port to dh_python2 (Closes: #786366).
+  * Recodec/setup.py: convert characters into UTF-8.
+
+ -- Luca Falavigna dktrkr...@debian.org  Sun, 23 Aug 2015 10:21:14 +0200
+
 pybliographer (1.3.2-1.1) experimental; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- pybliographer-1.3.2.orig/Recodec/setup.py
+++ pybliographer-1.3.2/Recodec/setup.py
@@ -10,7 +10,7 @@
 setup(name=version.package,
   version=version.version,
   description=Conversion between charsets, surfaces and structures.,
-  author='François Pinard',
+  author='François Pinard',
   author_email='pin...@iro.umontreal.ca',
   url='http://www.iro.umontreal.ca/contrib/recode/HTML',
   scripts=['recodec'],

Bug#786233: closed by Andrey Rahmatullin w...@debian.org ()

[Luca Falavigna]

2015-08-23 13:00 GMT+02:00 Debian Bug Tracking System ow...@bugs.debian.org:
 From: Andrey Rahmatullin w...@debian.org
 To: 786233-d...@bugs.debian.org
 Cc:
 Date: Sun, 23 Aug 2015 15:57:37 +0500
 Subject:
 Version: 2.0.0-1

 This was already fixed.

Is it a mistake? nitime still build-depends on python-support:
https://sources.debian.net/src/nitime/0.5-1/debian/control/#L6

-- 
Cheers,
Luca

Bug#796294: Possibly drop uniconvertor dependency

[Luca Falavigna]

Package: tgif
Version: 1:4.2.5-1.2
Severity: important
Control: block 787925 by -1


Dear Maintainer,

tgif gained support for SVG output by adding python-uniconvertor
dependency (#608243).

Unfortunately, python-uniconvertor is not maintaned anymore (#644559),
has a severe bug report (#699301) which needs to be fixed with the
next upload (otherwise dak will reject the package due to a lintian
autoreject tag), and it will become a blocker for the python-support
removal (#786179).

I'm wondering whether it would be possible to drop python-uniconvertor
from tgif dependencies, so it will allow us to get rid of
python-uniconvertor and tgif will migrate to testing again. Another
option would be to step in and maintain python-uniconvertor.

-- 
Cheers,
Luca

Bug#796065: chemps2: deprecation of python-support

[Luca Falavigna]

Source: chemps2
Version: 1.5-1
Severity: important
User: debian-pyt...@lists.debian.org
Usertags: pysupport-deprecation



Dear Maintainer,

your package either build-depends or depends on the python-support
package, or uses dh_pysupport in debian/rules file.

python-support has been deprecated for some time, and any package
still using it should be migrated to dh_python2 and dh_python3.
Instructions on how to migrate packages to dh_python2/dh_python3 can
be found on the Debian wiki [0]. An overview of the anatomy of a
package using the pybuild and dh_python{2,3} helpers can be found in
the Python Module Style Guide [1].

Please test your package thoroughly to make sure the transition to
dh_python2/dh_python3 is done correctly and does not cause a negative
impact on your package. In particular, please test upgrades from the
current jessie and stretch/sid versions of the package.

If your package does not yet use Python 3, please consider adding
Python 3 support to your package at the same time as updating the
build system; the py3k porters can offer assistance with that [2].

[0] https://wiki.debian.org/Python/TransitionToDHPython2 [1]
https://wiki.debian.org/Python/LibraryStyleGuide [2]
https://wiki.debian.org/Python/Python3Port

Thanks!

Bug#786366: closed by Matthias Klose d...@debian.org (Re: pybliographer: deprecation of python-support)

[Luca Falavigna]

reopen 786366
found 786366 1.3.2-1.1
thanks


2015-08-18 16:45 GMT+02:00 Debian Bug Tracking System ow...@bugs.debian.org:
 From: Matthias Klose d...@debian.org
 Subject: Re: pybliographer: deprecation of python-support
 no b-d or runtime dependency. looks like this is a false positive.

 closing. Matthias

This affects experimental only, the version in the original bug report
was correctly pointing to the experimental upload.

-- 
Cheers,
Luca

Bug#793359: ResolverBase does not handle adding a foreign architecture correctly

[Luca Falavigna]

Package: libsbuild-perl
Version: 0.65.2-1
Tags: patch


It seems ResolverBase does not handle adding a foreign architecture correctly.

This is due to a bug in the code of the setup_dpkg function:
add_foreign_architecture is passed $session, but session hasn't got
any 'Multiarch Support' value defined in in, but $self has.
=
sub setup_dpkg {
my $self = shift;

my $session = $self-get('Session');

# Record initial foreign arch state so it can be restored
$self-set('Initial Foreign Arches', $self-get_foreign_architectures());

if ($self-get('Host Arch') ne $self-get('Build Arch')) {
add_foreign_architecture($session, $self-get('Host Arch'))
}
}
=

 The first check in add_foreign_architecture is going to fail:
=
# just skip if dpkg is to old for multiarch
if (! $self-get('Multiarch Support')) { return 1 };
=

A test run with a debug statement just before this call ends up returning:
Use of uninitialized value in print at
/usr/share/perl5/Sbuild/ResolverBase.pm line 190.

I think $session shouldn't be passed as first argument, $self should.
The attached patch fixes this issue for me.

-- 
Cheers,
Luca


add_foreign_architecture.patch
Description: Binary data

Bug#789769: ftp.debian.org: removing a package from experimental that is not in unstable should close its bugs

[Luca Falavigna]

Hi Andreas,

2015-06-24 11:51 GMT+02:00 Andreas Beckmann a...@debian.org:
 If a source package gets removed from unstable, (usually) its bugs are
 closed. That same should happen if a package gets removed from
 experimental that is not (any more) in unstable.

Normally, bugs are closed automatically when packages are removed from
unstable. One exception of this is when there are multiple sources
available, and dak cannot tell (yet) which version to consider,
therefore bugs are intentionally left open.

Removing packages from experimental too is not automatically handled
at the moment. Sometimes FTP Team members spot this when removing
packages from unstable, sometimes not [ btw, thanks for your recent
efforts to catch up some of these ;-) ].

In the end, I think all the bugs were closed already when packages
were removed from unstable (unless the exception above was triggered).
Do you have some examples of packages removed from experimental with
bugs left open?

-- 
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779530: override: abs-guide:doc/optional

[Luca Falavigna]

Ciao Sandro,

2015-03-01 22:54 GMT+01:00 Sandro Tosi mo...@debian.org:
 the advanced bash script at version 10 has been released as public domain, so 
 I
 moved the package from non-free to main, at least in the source stanza of the
 package, but I guess you need to do something on your side too.

I see version 10 has been uploaded to experimental in main, therefore
FTP intervention is not really required. When you will upload
abs-guide to unstable, overrides will be set correctly, unless you'll
be hit by the dak bug when two packages are in different components.
If that will be the case, we'll help you reprocessing the upload :-)

-- 
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785375: override: xastir:hamradio/optional

[Luca Falavigna]

tags 785375 + moreinfo
thanks



Hi Iain,

2015-05-15 14:16 GMT+02:00 Iain R. Learmonth i...@fsfe.org:
 This package was previously listed as extra. There is no reason that
 this package should conflict with any oter package with optional or
 higher priority and so the override file priority should be changed to
 optional.

Some reverse dependencies are priority extra:

Checking compliance with related overrides...
xastir would have priority optional, its dependency libgdal1h has priority extra
xastir would have priority optional, its dependency libgeotiff2 has
priority extra
xastir would have priority optional, its dependency libjbig0 has priority extra

-- 
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789819: RM: kaptain -- ROM; dead upstream, uses Qt4, cannot be easily ported to Qt5, low popcon

[Luca Falavigna]

tags 789819 + moreinfo
thanks


2015-06-24 21:36 GMT+02:00 Dr. Tobias Quathamer to...@debian.org:
 please remove the package kaptain.


Not ready yet:

# Broken Depends:
axel: axel-kapt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#791487: antlr3: Depends on obsolete packages

[Luca Falavigna]

Source: antlr3
Version: 3.2-10
Severity: serious
Justification: renders package unusable

Dear Maintainer,

antlr3-gunit-maven-plugin and antlr3-maven-plugin depend on libplexus-compiler-
api-java, which is no longer built.

libplexus-compiler-api-java was a dummy package depending on libplexus-
compiler-java. Please consider switching to that package instead.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748181: ftp-master: add machine readable list of DELAYED packages, perhaps deferred.822

[Luca Falavigna]

2015-07-01 7:17 GMT+02:00 Paul Wise p...@debian.org:
 Link added to index.html

 Could you add it to deferred.html too?

Oh, indeed. I forgot that one. Fix committed, available after webpage
is recreated.

-- 
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785556: RM: php-math-biginteger -- ROM; Duplicate from php-seclib

[Luca Falavigna]

Hi Mathieu,

2015-06-23 13:31 GMT+02:00 Mathieu Parent (Debian) sath...@debian.org:
 This patch has been uploaded
 http://anonscm.debian.org/cgit/pkg-php/phpseclib.git/commit/?id=3bc33b2ddee43e621bcfba47acc212fd7d233147

 What else is needed?

I would have expected to find the provided package listed under
https://packages.debian.org/sid/php-math-biginteger , not sure why
it's not there...

-- 
Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787925: RM: python-uniconvertor -- RoQA; unmaintained, RC buggy

[Luca Falavigna]

tags 787925 + moreinfo
thanks


Not ready yet:

# Broken Depends:
tgif: tgif


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org