Re: autoconf 2.72 to unstable?

[Emilio Pozuelo Monfort]

On 14/06/2024 18:24, Andreas Metzler wrote:

On 2024-06-14 Gürkan Myczko  wrote:
[...]

Have never done mass bug filings, any easy way, preferably something copy
pastable,
non-interactive.


Hej,

How about mass-bug(1) in devscripts?


Also set a user/usertag when doing an MBF in order to have a nice overview of 
all bugs with their status.


Cheers,
Emilio

Re: Epoch bump for bcachefs-tools

[Emilio Pozuelo Monfort]

On 26/04/2024 15:57, Jonathan Carter wrote:

Hi Debian Developers

In January, bcachefs[1] finally made it into the mainline Linux kernel as an 
experimental filesystem in to Linux 6.7


In 2022 something odd happened and the versions releases were 23 and 24 
(previously we had alpha versions in Debian that were just git snapshots) before 
reverting to 1.x.x release tags.


We released those higher numbers in Debian, which means that the current version 
in Debian, bcachefs-tools 1.7.0, has the upstream version number of 24~really1.7.0.


Since it's a filesystem (and experimental one at that), where the version number 
is quite important for both tools and humans alike (who might not understand the 
version number currently in use), I think it would be justified to bump the 
epoch of this package.


I'm mailing debian-devel before commiting such an epoch bump, as per our 
versioning policy[2].


Yesterday I made an upload with the 1.7.0 version to experimental, this version 
uses significantly more rust code compared to the old versions. If it doesn't 
manifest any major issues, I'd like to upload it to unstable along with the 
epoch bump.


That sounds fine. If this was a temporary thing (oops, I uploaded 1.8.0 but I 
have to revert to 1.7.0 since the new version requires kernel x.y) then +really 
is fine. But in this situation, let's just add an epoch and avoid the +really 
for the foreseeable future.


Cheers,
Emilio

Re: OpenMPI / MPI transition

[Emilio Pozuelo Monfort]

On 23/11/2023 14:14, Alastair McKinstry wrote:


On 23/11/2023 12:44, Drew Parsons wrote:

On 2023-11-23 12:13, Emilio Pozuelo Monfort wrote:

Hi,

On 23/11/2023 09:36, Alastair McKinstry wrote:

Hi,

OpenMPI has a new upstream release 5.0.0. It is in experimental now; the 
SOVERSION for libraries remains 40.X (minor version increment), there is  an 
SOVERSION increment for private libraries only so in theory this is not an 
ABI transition. However 5.0.0 drops 32-bit system support.


The default MPI implementation for each architecture is set in mpi-defaults; 
this allows a per-arch MPI choice; in practice we currently use OpenMPI for 
all archs. The other choice is MPICH.


So the question becomes: do we switch MPI for just 32-bit archs, or all? 
What are the release teams opinion on this transition?


Having the same implementation across the board makes things easier
for testing purposes et al, however I don't see that as a blocker for
not having separate implementations.


True, in one sense it's simpler to have the same default MPI.  But we've set 
up our package infrastructure so that in principle it should not matter.  One 
architecture does not (or should not) depend on another, so it shouldn't break 
packages just because we'd have different MPI implementations on different 
architectures.  On the contrary, "actively" using both implementations could 
lead to more robust packages overall as MPI bugs get fixed against both 
implementations.



What are your thoughts on it? Is there a strong reason why we should
stick with OpenMPI for 64bit releases? Or from a different POV, what
are the risks of changing the implementation? Introducing a different
set of bugs?


One point to consider is that upstream developers of several of our numerical 
libraries have time and again suggested to us that we use mpich instead of 
openmpi, even before this v5 shift. They perceive (rightly or wrongly) that 
mpich is more robust, more reliable.


It would be useful to know whether that changes with v5, or whether their 
complaints are historical and openmpi has already fixed the bugs that 
concerned them. mpich has had its own share of bugs over the years. My memory 
told me RMA support was an issue in openmpi, but when I checked my facts, it 
was mpich that had to be fixed (https://github.com/pmodels/mpich/issues/6110)


Drew

My understanding is that MPICH has been typically the reference implementation, 
higher quality but less performant, particularly with the range of fabrics. 
Certainly I've seen mostly OpenMPI but not MPICH on various HPC machines. People 
would use either OpenMPI or a vendors MPI (which may be forked MPICH with added 
network hardware support).


I'd really like to hear from upstream users whether they are still encountering 
OpenMPI issues.


Personally I favour splitting, using MPICH on 32-bit archs to flush out bugs, 
and doing so early in the dev cycle (now) so there is time to change if necessary.


Thank you both for your comments.

I don't think as the Release Team we have a preference one way or the other. 
We'll let you pick the approach that you consider better. Obviously the freeze 
is still a long ways off, so if something comes up it can be changed later.


Cheers,
Emilio

Re: OpenMPI / MPI transition

[Emilio Pozuelo Monfort]

Hi,

On 23/11/2023 09:36, Alastair McKinstry wrote:

Hi,

OpenMPI has a new upstream release 5.0.0. It is in experimental now; the 
SOVERSION for libraries remains 40.X (minor version increment), there is  an 
SOVERSION increment for private libraries only so in theory this is not an ABI 
transition. However 5.0.0 drops 32-bit system support.


The default MPI implementation for each architecture is set in mpi-defaults; 
this allows a per-arch MPI choice; in practice we currently use OpenMPI for all 
archs. The other choice is MPICH.


So the question becomes: do we switch MPI for just 32-bit archs, or all? What 
are the release teams opinion on this transition?


Having the same implementation across the board makes things easier for testing 
purposes et al, however I don't see that as a blocker for not having separate 
implementations.


What are your thoughts on it? Is there a strong reason why we should stick with 
OpenMPI for 64bit releases? Or from a different POV, what are the risks of 
changing the implementation? Introducing a different set of bugs?


For release architectures, the 32bit ones would be armel, armhf and i386.

Cheers,
Emilio

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emilio Pozuelo Monfort]

On 09/05/2023 09:51, Andrea Righi wrote:

On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:

Hello,

   virtme already exists in Debian, what would be the benefit of virtme-ng
over virtme?

https://salsa.debian.org/debian/virtme

Regards


The original virtme project is not maintained anymore
(https://github.com/amluto/virtme), so we decided to fork the project
and continue the development / bug fixing in virtme-ng
(https://github.com/arighi/virtme-ng).


If the original project is no longer maintained, I'd suggest to keep the same 
name and move it into a github group, then invite the original author if he ever 
wants to come back. That way there's no need to add new packages with 
transitional packages in every distribution. That's e.g. what happened with 
terminator. Not sure if it's too late to do that in this specific case.


Cheers,
Emilio

Re: -ffile-prefix-map option and reproducibility

[Emilio Pozuelo Monfort]

On 07/02/2023 20:00, Sven Joachim wrote:

On 2023-02-07 17:50 +0100, Guillem Jover wrote:


On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote:

When building packages, a -ffile-prefix-map option is automatically injected
into CFLAGS. Where does it come from? Since when?


This is coming from dpkg-buildflags (in this case probably indirectly
via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default,
and then switched to enabled by default in dpkg 1.20.6 (see #974087).


I suspect this was added to improve reproducibility. Ironically, it makes
packages that capture this variable non reproducible, since the build path
seems to be randomized (has it always been the case? since when?). It is the
case of OCaml (see #1030785), and seemingly of R as well (found by grepping
in my /etc). I wouldn't be surprised other packages are affected as well.


AFAIR this was considered at the time, yes. If the flag is effectively
not fixing anything for the set of packages involved, and is in fact
actually making them unreproducible when they would not then, you can
disable the fixfilepath feature in the reproducible build flags area,
via DEB_BUILD_MAINT_OPTIONS.


This does not help for packages which capture all build flags and store
them in some file in the package (as is the case here).


What is the purpose of having the build flags in a file in the .deb?

Cheers,
Emilio

Re: Clarification regarding zlib1g-dev package for buster-slim s390x

[Emilio Pozuelo Monfort]

Hi Yasir,

On 11/08/2022 17:14, Yasir Ashfaq1 wrote:

Hi Team,

Hope you are doing well!

We are recently facing a problem installing zlib1g-dev package for 
s390x/debian:buster-slim tag.
Preinstalled zlib1g version for this tag is zlib1g/now 1:1.2.11.dfsg-1+deb10u1.
When we try to install zlib1g-dev, it is unable to do the same because 
available zlib1g-dev package is zlib1g-dev/oldstable 1:1.2.11.dfsg-1, which is 
an older version.
Due to this we get the following error :
zlib1g-dev : Depends: zlib1g (= 1:1.2.11.dfsg-1) but 1:1.2.11.dfsg-1+deb10u1 is 
to be installed

We confirmed the zlib1g-dev version used for buster for s390x on 
https://packages.debian.org/buster/zlib1g-dev

We also received below warning after ‘apt update’:
N: Skipping acquire of configured file 'main/binary-s390x/Packages' as 
repository 'http://security.debian.org/debian-security buster/updates 
InRelease' doesn't support architecture 's390x'

Could you please let us know why there is a discrepancy in version of zlib1g 
and zlib1g-dev package or whether there is a possibility that you have missed 
adding updates for s390x.


buster standard security support has ended as of August 1st. It's still 
supported by the LTS team, but for a limited set of architectures, which doesn't 
include s390x:


https://wiki.debian.org/LTS

Cheers,
Emilio

Re: Epoch bump for golang-github-valyala-fasthttp

[Emilio Pozuelo Monfort]

On 12/11/2021 16:26, Guillem Jover wrote:

On Fri, 2021-11-12 at 10:55:26 +0530, Pirate Praveen wrote:

On 12 November 2021 12:38:23 am IST, Guillem Jover  wrote:

The golang-github-valyala-fasthttp package used to have date-based
release numbers (current Debian version 20160617-2). Upstream has
since switched to semver (latest upstream version 1.31.0).

So the version scheme has been reset, and unfortunately given that no
prefix was used when initially packaging this, an epoch seems to be in
order now.

I'm planning on updating in the coming days to the latest upstream
release and bump the version using an epoch.


How about golang-github-valyala-fasthttp-v1 ?
Though it won't match import path, it can avoid the epoch.


While interesting, I think this might be worse. I'm not a fan of
epochs, but this is precisely the case they were intended for.


Indeed, I think an epoch bump here is sensible.

Cheers,
Emilio

Re: Proposed mass bug filing: packages without support for build-arch and build-indep

[Emilio Pozuelo Monfort]

On 06/11/2021 12:40, Simon McVittie wrote:

On Sat, 06 Nov 2021 at 11:31:25 +0100, Emilio Pozuelo Monfort wrote:

On 05/11/2021 21:22, Lucas Nussbaum wrote:

build-arch and build-indep are required targets according to Debian
Policy section 4.9.

...

Unfortunately this is only a warning in lintian, which might explain
why so many packages are still affected.


lintian should move those targets to the debian-rules-missing-required-target 
tag.


That request is #657390 (in cc).

When this was discussed some years ago, Niels Thykier pointed out that
debian-rules-missing-required-target is on the ftp team's list of Lintian
tags that cause automatic rejection[1], so making that change in Lintian
would make it impossible to do a sourceful upload of the affected packages
(for example to fix some unrelated RC issue) without also adding the
required targets.

This does not necessarily mean the Lintian change is a bad idea, it's just
something we should be aware of - expanding the scope of autorejections
should be intentional rather than accidental.


Ack, in that case let's wait until this mbf is done and some time is given for 
the packages to get fixed. After that, I think this should become an error and 
autorejection.


Cheers,
Emilio

Re: Proposed mass bug filing: packages without support for build-arch and build-indep

[Emilio Pozuelo Monfort]

Hi Lucas,

On 05/11/2021 21:22, Lucas Nussbaum wrote:

Hi,

I'd like to propose a MBF with severity:serious for the above issue.
build-arch and build-indep are required targets according to Debian
Policy section 4.9.  This rule was introduced in Policy version 3.9.4,
released in 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

There are 421 affected packages in unstable (389 in testing as of
2021-10-01).
The list of affected packages according to lintian is
https://lintian.debian.org/tags/debian-rules-missing-recommended-target
A dd-list is included below.


Thanks for looking at this.


Unfortunately this is only a warning in lintian, which might explain
why so many packages are still affected.


lintian should move those targets to the debian-rules-missing-required-target 
tag.


I have no strong feelings about this requirement, but I see it as a good
opportunity to identify packages whose packaging probably need a
refresh. Therefore it is a good target, especially at the beginning of a
release cycle, to either update old cruft or get it removed from the
next stable release.

This topic was raised back in April on debian-qa@, and saw no
objection back then. See
https://lists.debian.org/debian-qa/2021/04/msg00014.html (the thread
included other topics).

The bug template I plan to use is included below.

I would prefer to file bugs directly with severity:serious, but I'm fine
with starting with severity:important and bumping severity after a month
or two if the release team prefers it, of course.


I think severity serious is fine if you use an appropriate Version so that this 
won't block testing migration. I would still prefer if this was filed at 
important severity, and raised to serious after a month or so.


Cheers,
Emilio

Re: Adding an epoch to the 'steam' package

[Emilio Pozuelo Monfort]

On 16/08/2021 16:08, Simon McVittie wrote:

Before Valve's Steam game distribution platform became available on
Linux, the Debian source package name 'steam' was used by an unrelated
package sTeam, an "environment for cooperative knowledge managment"
(a wiki and related software). sTeam was removed from Debian in 2010,
and from Ubuntu in 2013. Valve's Steam was subsequently packaged for
Debian, also in 2013, reusing the 'steam' name.

sTeam had version numbers higher than Valve's Steam, and Launchpad is
stricter about monotonically increasing version numbers than dak is, so
Ubuntu added a 1: epoch to their 'steam' package when Valve's Steam
was introduced into Ubuntu.

This meant that the Ubuntu package superseded the native package
distributed by Valve, even if it was a lower version than Valve's, which
was needlessly confusing. As a result, Valve's native package now has the
same epoch as the Ubuntu package.

I would like to add the same 1: epoch to the steam package in Debian
and all of its binary packages, so that all of our version numbers
(Valve's, Debian's and Ubuntu's) are directly comparable again. This
would allow Ubuntu to sync the steam package from Debian unmodified,
if there are no functional changes that they need to make (at the moment
there are, but I intend to work on reducing or eliminating those during
the bookworm cycle).

As a side benefit from this, snapshot.debian.org would work properly again
(at the moment, it lists the historical sTeam as newer than Valve's Steam).


Sounds reasonable.

Cheers,
Emilio

Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

[Emilio Pozuelo Monfort]

On 20/09/2020 11:33, Félix Sipma wrote:
> Hello Emilio and others,
> 
> On 2020-09-10 19:32+0200, Emilio Pozuelo Monfort wrote:
>> I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that 
>> goes
>> well I'll start uploading things to buster (coordinating with the SRMs).
> 
> Was the build successful? Did you also try to build Thunderbird? Is there
> something else missing?

Yes, the Firefox build was successful and my runtime tests have been good too.

We're working on fixing the toolchain on mips* now (thanks to Aurelien), but
other than that there shouldn't be anything missing at this point with the
recent upload of rust-cbindgen.

I haven't managed to bootstrap rustc 1.41 on armel, that's not an issue for
FF/TB as they can't build on armel due to the lack of nodejs, but it's a problem
for armel itself if at some point an update to rustc is needed (e.g. to fix a
security bug). If someone can help with that front, please see the rustc pu bug
(#970132) and get in touch.

I haven't looked at Thunderbird yet (see Carsten's message) but the toolchain
should be the same, so in that regard we should be good.

Cheers,
Emilio

Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

[Emilio Pozuelo Monfort]

On 01/09/2020 19:17, Moritz Muehlenhoff wrote:
> On Tue, Sep 01, 2020 at 04:35:42PM +0200, Emilio Pozuelo Monfort wrote:
>> On 01/09/2020 14:05, Christoph Martin wrote:
>>> Hi,
>>>
>>> I am not shure if I can help, but I can try and have a look at it.
>>>
>>> Yes please upload your LLVM9 and wasi-libc backports.
>>
>> fwiw I started to look at this and have an LLVM 10 backport ready. Should we 
>> go
>> with that instead?
> 
> I'm fine either way. 
> 
>> It may be more future-proof, in case we need it for a future
>> rustc for the next ESR bump.
> 
> My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to
> be proven wrong :-) So maybe let's directly move to 10 directly.
> 
> Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against
> LLVM, then.

Status update:

- I've got a rustc bootstrap build (using upstream binaries) ready for
buster/stretch, using LLVM 7 and no wasi-libc.
- cargo using the above rustc and buster/stretch's cargo (no bootstrap 
necessary)
- cbindgen building with the above

That avoids the LLVM 9/10 update for this round.

I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that goes
well I'll start uploading things to buster (coordinating with the SRMs).

Cheers,
Emilio

Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

[Emilio Pozuelo Monfort]

On 01/09/2020 14:05, Christoph Martin wrote:
> Hi,
> 
> I am not shure if I can help, but I can try and have a look at it.
> 
> Yes please upload your LLVM9 and wasi-libc backports.

fwiw I started to look at this and have an LLVM 10 backport ready. Should we go
with that instead? It may be more future-proof, in case we need it for a future
rustc for the next ESR bump.

Cheers,
Emilio

> 
> Regards
> Christoph
> 
> Am 31.08.20 um 20:26 schrieb Moritz Mühlenhoff:
>>
>>> I think we can reuse the same approach as before, by staging uploads
>>> in -proposed-updates (or on stretch-security respectively) and then
>>> configure the security chroots to use -proposed-updates until 10.6
>>> is eventually released.
>>
>> I can upload my backports of LLVM and wasi-libc, but this still needs a 
>> volunteer for
>> the remaining parts (rustc/cargo) if we want to have firefox-esr / 
>> thunderbird
>> in Buster after the end of ESR68.
>>
> 
> Christoph
> 

Re: introducing an epoch for src:debian-security-support

[Emilio Pozuelo Monfort]

On 17/08/2020 12:01, Holger Levsen wrote:
> hi,
> 
>  debian-security-support | 2019.12.12~deb8u2  | jessie-security  | 
> source, all
>  debian-security-support | 2020.06.21~deb9u1  | stretch  | 
> source, all
>  debian-security-support | 2020.06.21~deb10u1 | buster   | 
> source, all
>  debian-security-support | 2020.07.12 | bullseye | 
> source, all
>  debian-security-support | 2020.07.12 | sid  | 
> source, all
> 
> is what we currently have in the archive and which is a bit of a hassle to
> maintain due to keeping version constraints sane (=newer releases should 
> always
> have higher versions) and since rather frequently there are changes only
> affecting older releases (so one has to upload to sid first, then do a stable 
> update and then update oldstable to propagate something which is only relevant
> for oldstable atm.)
> 
> Hence I propose to bump the epoch and introduce this versioning scheme:
> 
> sid:  0:11~2020.08.17
> bullseye: 0:11~2020.08.17
> buster:   0:10~2020.08.17
> stretch:  0:9~2020.08.17
> and so on.

A 0 epoch is equal to no epoch, so you need 1: here.

btw why keep the dates? I'd just do something like 11-1, 10-3, 9-5... The date
is still in the changelog if someone needs to look at it, but I don't think it
conveys any special information here. Anyway that's up to you. The epoch sounds
good to me to disentangle the updates as most of the time updates to d-s-s need
to happen to older releases, which carry older versions of packages, which are
no longer sustainable to maintain.

Cheers,
Emilio

Re: Python3 modules not built for all supported Python versions

[Emilio Pozuelo Monfort]

On 30/03/2020 16:08, Simon McVittie wrote:
> On Mon, 30 Mar 2020 at 15:30:01 +0200, Johannes Schauer wrote:
>> does this mean that build-depending on python3-dev is wrong in general and
>> should instead be replaced by build-depending on python3-all-dev?
> 
> It is only wrong for packages that build Python 3 extensions (binary
> modules) that are intended to be loadable by all supported Python
> 3 versions (roughly: `find /usr/lib/python3/dist-packages -name '*.so'`).
> 
> For packages that embed Python 3, like the versions of vim that
> have Python scripting support, or packages that use a Python 3
> extension as an internal implementation detail of some tool, like
> gobject-introspection, my understanding is that build-depending
> on python3-dev continues to be appropriate. These extensions would
> ideally be installed in a private directory, like gobject-introspection's
> /usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/_giscanner.cpython-38-x86_64-linux-gnu.so
> - but I know some upstreams and some downstream maintainers (arguably
> incorrectly) package private extensions as though they were public
> extensions, because the mechanics of doing so are much simpler.
> 
>> For example the package src:ros-geometry2 has a super simple
>> dh-style rules file, basically just doing:
>>
>> %:
>>  dh $@ --buildsystem=cmake --with python3
>>
>> What would I have to change to successfully fix this problem?
> 
> The general answer is that you would have to build it repeatedly in a
> loop, with each supported version of Python 3 in turn. I am not aware
> of a way to do this in a similarly simple rules file.

I've heard pybuild now has a cmake backend, so theoretically you could do
something like

%:
dh $@ --buildsystem=pybuild --system=cmake

Since I couldn't find any package in the archive that used pybuild with the
cmake backend, I have looked at this specific package and came up with the
attached debdiff. I added the dh_auto_install hack because the cmake build
system creates the python extension as _tf2.so, and is only renamed by
dh_python3 (as can be seen in current build logs). However when building for
both python3.7 and python3.8, the last installation will override the former,
and only one _tf2.so will be available.

However that workaround proved to not be enough, because dh_install3 renames
both the 3.7 and 3.8 versions as 3.8:

make[2]: Leaving directory 
'/build/ros-geometry2-0.6.6/.pybuild/cpython3_3.7/build'
I: pybuild pybuild:310: dh_python3
I: dh_python3 fs:343: renaming _tf2.so to _tf2.cpython-38-x86_64-linux-gnu.so
[...]
make[2]: Leaving directory 
'/build/ros-geometry2-0.6.6/.pybuild/cpython3_3.8/build'
I: pybuild pybuild:310: dh_python3
W: dh_python3 fs:340: destination file exist, cannot rename _tf2.so to
_tf2.cpython-38-x86_64-linux-gnu.so

Resulting in these installed files:

-rw-r--r-- root/root 69112 2020-03-30 14:56
./usr/lib/python3/dist-packages/tf2_py/_tf2.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- root/root 69128 2020-03-30 14:56
./usr/lib/python3/dist-packages/tf2_py/_tf2.so

I don't know if I'm missing an argument to dh_python3 so that it knows the
python version, or even if there's a better workaround. But perhaps pybuild
should be doing this automatically between the dh_auto_install calls so that
this kind of workarounds aren't necessary.

Piotr, is this a bug in pybuild, or am I doing something wrong?

Cheers,
Emilio
diff -Nru ros-geometry2-0.6.6/debian/changelog 
ros-geometry2-0.6.6/debian/changelog
--- ros-geometry2-0.6.6/debian/changelog2020-01-18 21:51:17.0 
+0100
+++ ros-geometry2-0.6.6/debian/changelog2020-03-30 16:56:18.00000 
+0200
@@ -1,3 +1,10 @@
+ros-geometry2 (0.6.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build for all supported versions of python3.
+
+ -- Emilio Pozuelo Monfort   Mon, 30 Mar 2020 16:56:18 +0200
+
 ros-geometry2 (0.6.6-1) unstable; urgency=medium
 
   * New upstream version 0.6.6
diff -Nru ros-geometry2-0.6.6/debian/control ros-geometry2-0.6.6/debian/control
--- ros-geometry2-0.6.6/debian/control  2020-01-18 21:51:17.0 +0100
+++ ros-geometry2-0.6.6/debian/control  2020-03-30 16:56:18.0 +0200
@@ -6,7 +6,7 @@
Leopold Palomo-Avellaneda 
 Build-Depends: debhelper-compat (= 12), dh-exec,
catkin (>= 0.7.14-4), libroscpp-core-dev, 
ros-message-generation, libstd-msgs-dev,
-   python3-dev, python3-setuptools, dh-python,
+   python3-all-dev, python3-setuptools, dh-python,
libgeometry-msgs-dev, ros-actionlib-msgs,
libconsole-bridge-dev, python3-rospy (>= 1.14.3+ds1-7), 
python3-rosgraph (>= 1.14.3+ds1-7),
libactionlib-dev, librosconsole-dev,
diff -Nru ros-geometry2-0.6.6/debian

Python3 modules not built for all supported Python versions

[Emilio Pozuelo Monfort]

Hi,

We've just finished the transition to python3.8 as the default python3
interpreter, which was a bit difficult due to some autopkgtest regressions in a
few rdeps, and to the fact that many modules only build their extensions for the
default python version, which means they have a strict dependency on the python3
version[1] and they need to be rebuilt and migrated in lockstep with
python3-defaults.

I have analyzed this based on current sid amd64 contents and have come up with
the following packages that don't ship extensions for both py3.7 and 3.8 (which
are the currently supported versions). Note that pure python packages that don't
build C extensions are not affected.

It would be great if this situation can be improved in order to help with future
python transitions. Building for all the supported python versions can be done
by build-depending on python3-all-dev and compiling your package (or just the
python bits) with PYTHON pointing to each version. Depending on your package's
build system, this could be largely automated using some helper, such as
pybuild. If you don't know how to add support for your package, feel free to 
ask.

Cheers,
Emilio

[1] e.g. python3 (>= 3.7), python3 (<< 3.8)


"Adam C. Powell, IV" 
   netgen (U)

A. Maitland Bottoms 
   gr-air-modes
   gr-fcdproplus (U)
   gr-fosphor
   gr-gsm (U)
   gr-iio
   gr-iqbal
   gr-limesdr (U)
   gr-osmosdr
   gr-rds
   quisk (U)
   uhd

Adam Borowski 
   btrfs-progs

Agustin Henze 
   logbook

Alan Boudreault 
   mapserver (U)

Alastair McKinstry 
   ecflow
   pyferret
   xdmf

Anders Waananen 
   nordugrid-arc (U)

Andreas Bombe 
   gr-limesdr (U)
   soapysdr (U)

Andreas Metzler 
   hugin (U)
   libvigraimpex (U)

Andreas Tille 
   atropos (U)
   conda-package-handling (U)
   epigrass (U)
   libsbml (U)
   obitools (U)
   python-thinc (U)
   umis (U)

Andrew Bartlett 
   samba (U)

Andrius Merkys 
   openbabel (U)

Anthony Wong 
   pycangjie (U)

Anton Gladky 
   python-demgengeo (U)

Aron Xu 
   ukui-menus (U)

Axel Beckert 
   gnudatalanguage (U)

Balint Reczey 
   libcec (U)

Barak A. Pearlmutter 
   mlpack (U)

Bas Couwenberg 
   mapserver (U)
   qgis (U)

Bastien Roucariès 
   pythonmagick (U)

Benjamin Drung 
   rdma-core

Bernd Zeimetz 
   ceph (U)

Boyuan Yang 
   libplist (U)

Carl Fürstenberg 
   pythonmagick (U)

Carsten Schoenert 
   kicad (U)
   kopanocore (U)

Ceph Packaging Team 
   ceph

Christoph Berg 
   gr-limesdr (U)
   gr-soapy (U)
   postgresql-multicorn (U)
   quisk (U)

Christoph Egger 
   fife (U)
   python-enet

Christopher Schramm 
   blueman

Daniel Kahn Gillmor 
   fontforge (U)

Daniel Leidert 
   openbabel (U)

Danny Edel 
   borgbackup (U)

Davide Viti 
   fontforge (U)

Debian 3D-Printer Packaging Team <3dprinter-gene...@lists.alioth.debian.org>
   printrun

Debian Astronomy Team 
   astrometry.net
   gnudatalanguage

Debian Borg Collective 
   borgbackup

Debian DNS Team 
   ldns

Debian Edu Packaging Team 
   sdaps

Debian Electronics Team 
   kicad

Debian Fonts Task Force 
   fontforge

Debian Fonts Task Force 
   psautohint

Debian Games Team 
   cegui-mk2
   fife

Debian GIS Project 
   mapserver
   qgis
   saga

Debian GNOME Maintainers 
   glom
   libpwquality

Debian Hamradio Maintainers 
   gr-fcdproplus
   gr-gsm
   gr-limesdr
   gr-soapy
   quisk
   soapysdr

Debian Input Method Team 
   pycangjie

Debian LibreOffice Maintainers 
   libixion
   liborcus

Debian Med Packaging Team 
   atropos
   biosig4c++
   conda-package-handling
   epigrass
   gdcm
   insighttoolkit4
   libsbml
   obitools
   pymia
   simpleitk
   umis
   vtk-dicom

Debian Multimedia Maintainers 
   csound
   libopenshot
   openvdb

Debian PhotoTools Maintainers 
   hugin
   opencolorio
   openimageio

Debian PostgreSQL Maintainers 
   postgresql-multicorn

Debian Printing Team 
   hplip

Debian Python Modules Team 
   portio
   pyodbc (U)
   pythonmagick

Debian QA Group 
   link-grammar

Debian Samba Maintainers 
   ldb
   samba
   talloc
   tdb

Debian Science Maintainers 
   caffe
   libvigraimpex
   mlpack
   netgen
   openturns
   orocos-kdl
   python-thinc
   ros-geometry2
   ros-image-common
   ros-ros-comm
   ros-rviz
   ros-vision-opencv
   siconos
   veusz

Debian Science Team 
   apertium
   apertium-lex-tools
   apriltag
   cg3
   cryptominisat
   getfem++
   lttoolbox
   morse-simulator
   neuron
   opencv
   plplot
   python-demgengeo
   sagemath
   vtk7

Debian Security Tools 
   libbde
   libesedb
   libevt
   libevtx
   libewf
   libfsapfs
   libfsntfs
   libfvde
   libfwnt
   libfwsi
   liblnk
   libmsiecf
   libolecf
   libpff
   libqcow
   libregf
   libscca
   libsigscan
   libsmdev
   libsmraw
   libvhdi
   libvmdk
   libvshadow
   libvslvm

Debian SSSD Team 
   sssd

Debian SSSD Team 
   pam-wrapper

Debichem Team 
   avogadrolibs
   chemps2
   openbabel
   rdkit

Deepak Tripathi 
   pyodbc

Denis Barbier 
   openturns (U)

Didier Raboud 
   hplip (U)

Dima Kogan 
   apriltag (U)

Dmitry Smirnov 
   

Re: julia_1.0.0-1_amd64.changes REJECTED

[Emilio Pozuelo Monfort]

Hi,

On 21/11/2018 14:56, Graham Inggs wrote:
> Hi Bastian
> 
> My apologies in advance for doing this, but another month has passed.
> Another ping from me.
> 
> On 2018/10/25 12:24, Ian Jackson wrote:
>> Ian Jackson writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
>>> Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
 1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
     Policy said "should" but not "must". Please tell me what I can do in
     order to help improve the src:julia package to satisfy the 
 requirements?
>>>
>>> My main concern here is this: AFAICT this package has been REJECTed
>>> solely for this reason.  Why is this bug[1] a reason for a REJECT ?
>>> ISTM that it should be filed in the BTS and handled like a normal bug.
>>
>> Ping, ftpmaster ?
>>
>> Ian.
>>
>>> [1] Assuming it is a bug.  The discussion here suggests to me that it
>>> is, but it is really unhelpful to be having it on debian-devel in the
>>> context of an ftpmaster REJECTion.
>>
> 
> From the original REJECTion email from mid-August [1], there were two issues,
> but I believe both have been explained in the follow-up emails and subsequent
> uploads.

Since you are cc'ing d-devel@, I'll chime in.

I'm not sure I understand the first concern. The package name is libjulia1,
which would indeed normally point to a libjulia.so.1 library. You ship this:

-rw-r--r-- root/root  36143904 2018-08-16 07:48
./usr/lib/x86_64-linux-gnu/libjulia.so.1.0
lrwxrwxrwx root/root 0 2018-10-13 06:16
./usr/lib/x86_64-linux-gnu/libjulia.so.1 -> libjulia.so.1.0

That would be standard for a libjulia.so.1 SONAME (though one would need to look
at the SONAME header in the ELF file to know for sure). Also I don't see a
lintian warning for 1.0.0-1 (or your latest upload), so it seems alright to me.
Maybe I'm missing something, or perhaps this was rejected and reuploaded and
that's why I don't see why that comment was made.

(I'm not sure why you need all those other symlinks in
./usr/lib/x86_64-linux-gnu/julia/ to files that are not shipped anywhere. That
smells like a bug, but I haven't investigated)

As for the other issue. It is very unusual to ship a non-stripped library. In
your lintian override, you point to [2], which mentions that it's ok to ship the
debug info in a separate file (the stripped symbol files found in -dbg or
-dbgsym packages) as long as the original files have a .gnu_debuglink section
pointing to that separate file. That is what dh_strip will do for you, as you
can see in its manpage and by inspecting the binary with readelf.

So why are you not stripping those couple of files?

Cheers,
Emilio

[2] https://github.com/JuliaLang/julia/issues/23115#issuecomment-320715030

Re: Opt-in to continue as DD/DM? (was: I resigned in 2004)

[Emilio Pozuelo Monfort]

On 12/11/2018 20:47, Mattia Rizzolo wrote:
> On Mon, Nov 12, 2018 at 09:43:20PM +0200, Lars Wirzenius wrote:
>> Tollef Fog Heen :
>>> (I also wonder if we should just require people to opt in to their
>>> DD-ship on a yearly basis instead of doing most of the WAT/MIA dance. If
>>> people can't be bothered to reply to a single email saying «yup, another
>>> year please» with some reasonable amount of pinging and time to reply,
>>> they are effectively MIA, at least if they haven't let people know on
>>> -private or similar.)
>>
>> I support automatically retiring DDs and DMs that don't repond to a
>> ping, or don't upload, or don't vote, or otherwise show activity.
> 
> Since last year it already kind of happens for DMs, that are removed
> from the keyring.  We in the MIA team still manually process all of them
> before orphaning the packages, which is the much more nasty task than
> you may think, given that apparently some people want to keep being in
> Maintainer of stuff despite not uploading for years and having lost the
> technical ability to upload years before as well (yes, I'm not kidding).

Might be less nasty if it was done by a cron job / role account, rather than
manually by a DD who can be blamed by the inactive maintainer.

Cheers,
Emilio

Re: SALSA migration of XML/SGML packages (sgml-data for me)

[Emilio Pozuelo Monfort]

On 11/07/18 15:38, Osamu Aoki wrote:
> Hi,
> 
> On Sun, Jul 08, 2018 at 07:51:53PM +0300, Adrian Bunk wrote:
>> On Sun, Jul 08, 2018 at 11:20:57PM +0900, Osamu Aoki wrote:
> ...
>> All this gives sgml-base impressive popcon numbers, but the actual usage 
>> is likely pretty limited. I'm sure we have users who still need tooling 
>> for SGML, but all this is now more a fringe area of the archive.
> 
> You missed my point.  I don't care about popcon.  Problem is "Reverse
> Build-depends in main".  Try:
> 
> ---
>  $ build-rdeps sgml-data
>  
> Found a total of 1336 reverse build-depend(s) for sgml-data.

wow, I get an entirely different number:

$ build-rdeps sgml-data
WARNING: dose-extra >= 4.0 is not installed. Falling back to old unreliable
behaviour.
Reverse Build-depends in main:
--

qmtest
python-ethtool

Found a total of 2 reverse build-depend(s) for sgml-data.

That says the results are unreliable, but manually checking
dists/sid/main/Sources gives me the same thing.

Cheers,
Emilio

Re: Mass filing on Python 3.7 async module import?

[Emilio Pozuelo Monfort]

On 08/07/18 00:17, Paul R. Tagliamonte wrote:
> Hey DPMT (BCC'ing -devel, let's keep conversaion on DPMT),
> 
> I see that Python 3.7 now raises a syntax error when you try to import
> a module that is named `async`.
> 
> ```
> $ python3.6
> Python 3.6.6 (default, Jun 27 2018, 14:44:17)
> [GCC 8.1.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import foo.async
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'foo'

> ```
> 
> With Python 3.7:
> 
> ```
> $ python3.7
> Python 3.7.0 (default, Jun 27 2018, 14:40:03)
> [GCC 8.1.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import foo.async
>   File "", line 1
> import foo.async
>^
> SyntaxError: invalid syntax

> ```
> 
> Quickly checking codesearch, there are a bunch of packages that have
> import lines that look like they'd fail.
> 
> Anyone mind if I do a MBF on libraries that are providing anything
> named `async.py`?

List of affected packages:

openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py
pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py
python3-astroquery: 
/usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py
python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py
python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py
python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py
python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py
python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py
python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py
python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py
python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py
python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py
python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py
python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py
python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py
python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py
python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py
python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py
salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py
visidata: /usr/lib/python3/dist-packages/visidata/async.py

and the dd-list:

Andriy Senkovych 
   salt (U)

Anja Boskovic 
   visidata

Bas Couwenberg 
   mapproxy (U)

Benjamin Drung 
   salt (U)

Brian May 
   celery (U)

Carl Suster 
   rpyc (U)

ChangZhuo Chen (陳昌倬) 
   pylama (U)

Chris Lamb 
   gunicorn

Debian Astro Team 
   astroquery

Debian GIS Project 
   mapproxy

Debian Python Modules Team 
   celery
   pexpect
   pylama
   pymodbus
   pyopengl
   python-dropbox
   python-ldap
   python-raven (U)
   python-tenacity
   rpyc

Debian Salt Team 
   salt

Debian Security Tools 
   openscap-daemon

Franklin G Mendoza 
   salt (U)

Joe Healy 
   salt (U)

Maximiliano Curia 
   pymodbus (U)

Michael Fladischer 
   celery (U)
   python-dropbox (U)

Ondřej Kobližek 
   python-tenacity (U)

Ondřej Nový 
   python-tenacity (U)
   salt (U)

Philippe Thierry 
   openscap-daemon (U)

Python Applications Packaging Team 
   pylint (U)

Sandro Tosi 
   pylint

Thomas Goirand 
   python-tenacity (U)

Tobias Hansen 
   pexpect (U)

Torsten Marek 
   pyopengl (U)

Vincent Bernat 
   exabgp
   python-raven

Vincent Prat 
   astroquery (U)

W. Martin Borgert 
   pymodbus (U)

Willem van den Akker 
   python-ldap (U)

Wolodja Wentland 
   salt (U)

Cheers,
Emilio

Re: packages which have not been rebuild since December 2016

[Emilio Pozuelo Monfort]

On 01-06-18 16:32, Chris Lamb wrote:
> … wouldn't we just binNMU these?

There are many packages in your list that are arch:all only, and those can't be
binNMU'ed. Still I'm not sure we can do some several thousand binNMUs. But that
number could get reduced due to maintainer uploads and binNMUs due to unrelated
transitions.

Cheers,
Emilio

Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".

[Emilio Pozuelo Monfort]

On 30/05/18 11:40, Geert Stappers wrote:
> On Wed, May 30, 2018 at 11:19:14AM +0200, Alexander Wirt wrote:
>> On Wed, 30 May 2018, Andreas Tille wrote:
>>> Hi again,
>  
>   :-)
> 
> 
>>> On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote:
>> Your repo has lfs disabled. You should enable it. 
>
> How can I do this?
> I've just found[1]:  "Your administrator only need to enable the LFS 
> option."
 *seufz* we enabled it, but as you can guess it needs to get enabled per 
 repo.

 Settings -> Permissions -> Git Large File Storage
>>>
>>> Thanks for the hint.  I would not call "Permissions" the obvious place to
>>> look for this and my web search did not uncover this, sorry.
>>>
>>> Unfortunately it does not work yet:
>> use the support tracker and I will look after it when I have time.
> 
> Where is that support tracker?
> 
> (It feels strang to report "salsa is broken" at Salsa itself.)

It's not broken. One feature for one package is not working, but the salsa issue
tracker is still working.

BTW you file BTS issues in the BTS. That doesn't feel weird to me.

>> debian-devel is not on the list of salsa supportchannels.
>  
> Even multiple suportchannels for salsa.
> What are the preferred top three?
>
> In other words
> How cool would it be if the "not here" would have travelled with
>  at URL you find a list of salsa supportchannels
> ???

https://salsa.debian.org/help has a "Support" section at the top.

Granted, that page is linked from every salsa page, but the link is not very
discoverable if you are logged in (it's on the top right drop down menu).

Cheers,
Emilio

Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

[Emilio Pozuelo Monfort]

On 25/05/18 12:24, Mattia Rizzolo wrote:
> On Fri, May 25, 2018 at 12:16:20PM +0200, Emilio Pozuelo Monfort wrote:
>> On 25/05/18 12:09, Mattia Rizzolo wrote:
>>> autoremoval mails contains tons of false positive and cases where
>>> regular package maintainers can do nothing about but watch.
>>
>> Can you give some examples of false positives in autoremoval mails?
>>
>> Do you mean the case where you just fixed your package but the information
>> hasn't reached the service and so you still get a mail about it?
> 
> That, yes.
> But rather than false positive I should have said "things a maintainer
> can usually do ~nothing about", like RC bugs on other package where NMUs
> are infaseable, or the migration is blocked by some transition, etc (in
> those case it's not like the information is false, it's simply not
> useful).

Even if there's not much one can do in some cases, I think it's still useful to
know that your package is scheduled for autoremoval.

> Anyway, doesn't really change my point that the autopkgtest mails are
> welcome to me :)

Certainly.

Cheers,
Emilio

Re: RFR: email about regressions [was: Dealing with ci.d.n for package regressions]

[Emilio Pozuelo Monfort]

On 25/05/18 12:09, Mattia Rizzolo wrote:
> autoremoval mails contains tons of false positive and cases where
> regular package maintainers can do nothing about but watch.

Can you give some examples of false positives in autoremoval mails?

Do you mean the case where you just fixed your package but the information
hasn't reached the service and so you still get a mail about it?

Emilio

Re: Firefox 60esr on Stretch ?

[Emilio Pozuelo Monfort]

On 16/05/18 19:12, Moritz Mühlenhoff wrote:
> I've started to look into this; I have created a llvm-4.0 build
> for stretch and build a bootstrap build of rustc 1.24 against it.
> Those two went fine.
> 
> However cargo's bootstrap is broken ATM which will need fixing (and
> it also requires a more recent libgit than we have in stretch).

Does it fail like in bug #858153 (which has a patch) or in a different way?

Cheers,
Emilio

Re: [1/2] MBF: Defunct alioth addresses in the Maintainer: field (serious)

[Emilio Pozuelo Monfort]

On 05/05/18 17:34, Christoph Biedl wrote:
> A lot of now defunct alioth addresses are used in the Maintainer:
> field. This makes the packages rc-buggy for an invalid address.

Before doing the MBF, can you send an email with all the people in Uploaders in
Bcc? It may trigger some package updates or some late list migrations. I would
prefer to avoid getting 700 RC bugs, but after that I guess there's no option
but to file them.

Cheers,
Emilio

Re: Firefox 60esr on Stretch ?

[Emilio Pozuelo Monfort]

On 04/05/18 17:42, W. Martin Borgert wrote:
> Quoting Moritz Mühlenhoff :
>> Julien Cristau  schrieb:
>>> I expect nothing much different from previous ESR cycles: stretch will
>>> move to 60 after 52 goes EOL in September.
>>
>> Exactly.
> 
> How will we deal with breaking extensions?
> 
> E.g. I'm using xul-ext-scrapbook a lot. AFAIK, upstream does
> not provide a post-XUL version. Probably other extensions will
> face the same compatibility issue.
> 
> Should we just remove them from stable?

I guess so, yes. There's not much we can do if there is no support for newer
versions.

Emilio

Re: why hasn't the debian transition freeze been announced or shared in debin testing info. or bits.debian.org ?

[Emilio Pozuelo Monfort]

On 26/04/18 02:20, Luke Faraone wrote:
> On 26 April 2018 at 00:16, shirish शिरीष  wrote:
>> I had read 
>> https://lists.debian.org/debian-devel-announce/2018/04/msg6.html
>> so knew when the transition freeze is going to happen. For a blog
>> post/technical article I wanted to share about the transition freeze
>> and went to https://www.debian.org/releases/testing/ as well as
>> https://bits.debian.org/ but neither seems to have that info.
>>
>> Shouldn't be the milestone including perhaps info. on tentative alpha
>> releases be put somewhere or are the dates subject to change ?
>>
>> If the dates are locked down, it would be nicer to be able to
>> share/link to an official page on debian website rather than just an
>> e-mail.
> 
> Messages to debian-devel-announce@ by DPL delegates within the scope
> of their responsibilities are official. This is explicitly called out
> in /releases/testing:
> 
> |> In addition, general status reports are posted by the release
> manager to the debian-devel-announce mailing list.

Yes. In any case, those dates (as well as links to the announcement) are also
available from https://release.debian.org/

Emilio

Re: Please do not drop Python 2 modules

[Emilio Pozuelo Monfort]

On 23/04/18 23:54, Thomas Goirand wrote:
> Also, I have noticed that when removing Python 2 legacy packages, a lot
> of cruft remains in the archive. This isn't trivial to track and clean.
> I'd love to have the opinion of the FTP master team about this. How can
> we file sensible bugs about it? How can I track what hasn't been un-crufted?

If the package that you removed has no reverse dependencies, then it will be
automatically removed (decrufted), and the removal will be mentioned in

https://ftp-master.debian.org/removals.txt

If it has rdeps and can't be auto-removed, then it will appear in the cruft 
report:

https://ftp-master.debian.org/cruft-report-daily.txt

But please do not remove packages that have rdeps if you don't have a transition
plan. Otherwise you're just going to cause your package to get stuck in unstable
with no chance to migrate to testing, see e.g.:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894560

By all means start getting your rdeps / python2 apps ported, so that when the
time comes, dropping Python 2 support won't be such a daunting task.

Cheers,
Emilio

Re: graphs at https://ftp-master.debian.org/stat.html have intermissions.

[Emilio Pozuelo Monfort]

On 24/04/18 07:34, Geert Stappers wrote:
> 
> Hello,
> 
> 
> The graphs at https://ftp-master.debian.org/stat.html have intermissions.
> 
> What used to be a contineus line is now a dotted line.
> 
> 
> This posting to d-devel@ldo is for asking where to report the issue.
> 
> Who to contact to get it fixed?

https://ftp-master.debian.org/#contact

Emilio

Re: Please add debian_releases to base-files (was Re: Bits from the release team: full steam ahead towards buster)

[Emilio Pozuelo Monfort]

On 20/04/18 16:46, Marvin Renich wrote:
> I would also like /etc/debian_version to contain both number and name,
> but I suspect there is some resistance to this on the grounds that
> scripts may be using $(cat /etc/debian_version) for comparisons.
> Perhaps /etc/debian_codename?  Since debian_version contains
> codename/sid for testing and unstable, debian_codename could just
> contain the codename.

You already have that information in /etc/os-release and the lsb_release 
command.

Cheers,
Emilio

Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Emilio Pozuelo Monfort]

On 18/04/18 01:30, Cyril Brulebois wrote:
> That's another perfect example why udeb additions should get reviewed:
> we would have noticed another buggy package, and its bugginess might not
> have been copied over to another package.

I'm sure people don't request those reviews because they don't know or because
they forget. A lintian warning could help, or ftp-masters enforcing an ack.
Though I'd prefer the former as I wouldn't like NEW to have another bottleneck.

> If someone wants to drive an effort to make -V a must for udebs in
> policy, that's probably fine. It doesn't strike me as ultimately needed
> (we've lived without it for quite some time because maintainers tend to
> just do the right thing), but if people have spare time, go for it.

It's not in policy (but I don't think it has to be), but following the
conversation on #-ftp yesterday I opened:

#895949 lintian: warn about packages with udebs but no udeb line in shlibs
#895953 lintian: check that shlibs-version >= higher-version-symbols-file

The latter wouldn't enforce -V, but would check that we at least get a high
enough version in shlibs as compared to the .symbols file (and would have solved
the zstd problem).

Cheers,
Emilio

Re: Completed: lists.alioth.debian.org migration

[Emilio Pozuelo Monfort]

On 17/04/18 22:42, Holger Levsen wrote:
> On Tue, Apr 17, 2018 at 10:39:22PM +0200, Christoph Biedl wrote:
>> Also, @lists.alioth.debian.org addresses that were *not* migrated now
>> result in bounces as expected. Are there already plans for a MBF
>> severity RC against all packages with a now-failing maintainer address?
>> This might become rather messy, I've counted some 1450 packages.
> 
> please file bugs, so that autoremovals can kick in. Thanks.

Not until we see a list of affected packages and maintainers.

Emilio

Re: Bits from the release team: full steam ahead towards buster

[Emilio Pozuelo Monfort]

Hi,

When all people can complain about are the codenames, it means we are doing
things fairly well :)

On 18/04/18 08:20, Lars Wirzenius wrote:
> On Wed, 2018-04-18 at 11:16 +0500, Andrey Rahmatullin wrote:
>> No, users and, I suspect, a large part of admins and developers cannot
>> easily say which of two codenames is newer, and it doesn't matter what are
>> those two codenames. Numeric versions are usually used to help with this,
>> but not so much in Debian.
> 
> I've been developing a habit of writing both number and codename:
> Debian 9 (stretch) and Debian 42 (billgates).
> 
> I think it would be a good habit for others as well, especially in
> public-facing communication.

That's a very good point, particularly for announcements. I'll try to keep it in
mind.

Cheers,
Emilio

Re: Help: gpb buildpackage no longer builds

[Emilio Pozuelo Monfort]

On 08/04/18 20:25, Steve Robbins wrote:
> In the last upload of googletest -- December 2016 -- I successfully used "gbp 
> buildpackage".  Today, with zero changes, it fails to actually do the build: 
> it skips from configuration to running tests.
> 
> The rules file [1] is, I think, pretty simple: there are overrides for  
> dh_auto_configure , _test, _install, and _clean; nothing else.  Am I missing 
> something?
> 
> [1] https://salsa.debian.org/debian/googletest/blob/master/debian/rules

Which version of debhelper are you building with? The cmake support was recently
broken and just fixed in debhelper 11.2.1, so make sure you get that.

Cheers,
Emilio

Re: Usage of real m68k hardware

[Emilio Pozuelo Monfort]

On 28/03/18 12:00, Andreas Tille wrote:
> Hi John,
> 
> On Wed, Mar 28, 2018 at 06:36:16PM +0900, John Paul Adrian Glaubitz wrote:
>> Yes, of course. But Andreas hit a nerve with this on me.
> 
> Sorry, this was not intended.
> 
>>> In my experience, most arguments (not "mere" disagreements) have stemmed
>>> from regrettable miscommunication but all of them have ever helped by an
>>> argumentative or combative character, especially ones underlined with
>>> threats.
>>
>> Well, if Andreas wouldn't have asked for the ultima ratio right from
>> the beginning, there would probably have been a more constructive
>> discussion.
> 
> Just to not make that mistake again:  Is it the
> 
>   "I'm wondering when it might be time to fully drop a hardware
>port instead of draining developer time for ethernity"
> 
> in my mail you stumbled upon.  May be its the language barrier but I do
> not think that if a random developer is wondering about something this
> is equivalent to "asking for the ultima ratio".  I was honestly thinking
> about whether we are keeping alive an architecture by everybody using
> emulators.  I try to be more careful in my wording in the future when
> asking questions about ports (and hope I will manage).

Note that m68k is not a release architecture, so those bugs do not affect the
release status of your packages. Thus, if you don't have the time to work on
such issues, you should feel free to note that and tag the bug 'help' or
similar, and wait for someone to provide a sensible patch.

OTOH, I'm not sure if those FTBFS for non-release architectures, without a patch
or a clue, coming from a non-porter, are that useful...

Cheers,
Emilio

Re: Removing packages perhaps too aggressively?

[Emilio Pozuelo Monfort]

On 01/02/18 09:45, Andrej Shadura wrote:
> On 01/02/18 09:40, Ansgar Burchardt wrote:
>> Andrej Shadura writes:
>>> On 31/01/18 21:01, Jeremy Bicha wrote:
> Here you go, there's #871004 for you. Missed jessie, stretch,
> not in testing, no uploads since the beginning of 2017.

 I don't think you'll get much sympathy for a package being removed
 from unstable when it hasn't shipped with a Debian release since
 Wheezy, and has continuously been out of Testing for 3.5 years.
>>>
>>> True, it hasn't. But if you look a little bit closer, you'll see both RC
>>> bugs it had were quite trivial to fix: two sourceless files (would be
>>> fixed by linking them to the packaged versions instead), and an failed
>>> attempt to download a build-dep (actually, fixed by an NMU while fixing
>>> another bug, just never marked as done).
>>
>> So there was plenty of time to fix them.
>>
>> Why would filing a third RC bug (the "proposed-RM") and waiting one
>> month more change anything?  Why would someone turn up to fix them now?
> 
> Why not? I *was* already doing just that, but with an RM bug filed
> elsewhere, I was unable to know it's about to be removed. I would have
> reacted and closed it before the package's got removed.

Doesn't the PTS^Wtracker service already do that? I.e. notify when an RM bug is
opened. At least it warns on the web interface, and I think I have seen email
notifications about it too. So you only need to subscribe to those packages that
interest you.

Cheers,
Emilio

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Emilio Pozuelo Monfort]

On 18/01/18 21:50, Adrian Bunk wrote:
> On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote:
>> On 10/01/18 01:29, Sam Hartman wrote:
>>> A build profile seems like a great way to express the flag, and like
>>> many things in Debian, the work would fall on those who would benefit
>>> from it.
>>
>> I think it'd be better to be able to mark a build-dependency as optional, and
>> then implement a mechanism in dpkg to disable the undesired 
>> build-dependencies.
>> E.g. if packages start marking libselinux-dev as , with autoconf or
>> similar automatically disabling selinux support when not present, then a user
>> could build the package with something like dpkg-buildpackage
>> --disable-optional=libselinux-dev. This way we don't need a different build
>> profile for each build-dep and package, which would end up in a mess. Of 
>> course
>> we need to change the above syntax to not clash with build profiles, and add
>> DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more
>> standard to me than having each package define its own profiles for each
>> optional dependency.
> 
> When the sole purpose of a rebuild is to get rid of unused library(ies),
> the rebuild only makes sense if this is supported throughout the whole
> distribution.
> 
> The problematic cases are the non-trivial ones,
> and what support Debian wants to provide for that.
> 
> It would make the life for the Devuan people much easier if Debian
> would be committed to have *all* packages in buster build and work
> with --disable-optional=libsystemd-dev.
> 
> Are you as release manager willing to make this a supported feature
> for buster, with breakages being RC bugs?
> 
> For small embedded systems, having this only for one library
> doesn't bring that many benefits.
> 
> For how many libraries are you release manager willing to make 
> --disable-optional a supported feature for buster, with breakages
> being RC bugs?

Nothing of this sort is going to be RC, no matter if we implement it via build
profiles or by some other mechanism. I'm not even sure we need it. My only point
is that if we are going to start adding this for every optional feature as it
was being suggested, we should do it properly and not abusing build profiles.

Cheers,
Emilio

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

[Emilio Pozuelo Monfort]

On 10/01/18 01:29, Sam Hartman wrote:
> A build profile seems like a great way to express the flag, and like
> many things in Debian, the work would fall on those who would benefit
> from it.

I think it'd be better to be able to mark a build-dependency as optional, and
then implement a mechanism in dpkg to disable the undesired build-dependencies.
E.g. if packages start marking libselinux-dev as , with autoconf or
similar automatically disabling selinux support when not present, then a user
could build the package with something like dpkg-buildpackage
--disable-optional=libselinux-dev. This way we don't need a different build
profile for each build-dep and package, which would end up in a mess. Of course
we need to change the above syntax to not clash with build profiles, and add
DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more
standard to me than having each package define its own profiles for each
optional dependency.

Cheers,
Emilio

Re: glibc-2.24-11+deb9u2 from s-p-u already in debian/dists/stretch/main/source/Sources.xz?

[Emilio Pozuelo Monfort]

On 21/12/17 11:53, Philipp Hahn wrote:
> Hi,
> 
> I have written a tool myself to parse Debian's Packages and Sources
> files to mirror all files belonging to one version for post-processing.
> Today I stumbled over "glibc-2.24-11+deb9u2":
> - it is *not* listed on
> 
> - it is listed on  for s-p-u
> - it is included in debian/dists/stretch/main/source/Sources.xz
> - it is *not* included in debian/dists/stretch/main/binary-amd64/Packages.xz
> 
> Is it normal for Sources to list source packages, which are not yet in
> Packages? (Probably yes, if there exists at least one architecture
> containing binary packages build from that source version)

It's listed as

Extra-Source-Only: yes

So yes, it's normal for it to be there, as another package has Built-Using on
that glibc version, so we need to ship the source.

Cheers,
Emilio

Re: custom packages and schroot workflow

[Emilio Pozuelo Monfort]

On 08/12/17 11:02, Frédéric Bonnard wrote:
> Hi,
> being new to the Debian schroot setup on Debian machines, I tried
> debugging some package. I found the crash happening in a library pulled
> as a runtime dependency.
> My idea was to recompile that library with some debug enabled and install
> those custom .deb's within the current schroot, to rerun the initial
> binary (with debug as well).
> Using dd-schroot-cmd -c $sessionid, I realized that this is limited to
> apt-get and not dpkg, and thus can't install .deb's not in the
> source.list ( https://dsa.debian.org/doc/schroot/ )
> Jumping as root in the schroot is not possible too.
> Did I miss something ?
> Am I following the wrong workflow with Debian machines or generally
> speaking ? :)
> How do you work for this kind of issue?

What library is that? Does it not have a -dbg or -dbgsym package?

Otherwise one option is to build the library and load it with LD_LIBRARY_PATH,
that way you don't have to install random packages with dpkg (which is not
allowed in porterboxes as you found).

Cheers,
Emilio

Re: recommends for apparmor in newest linux-image-4.13

[Emilio Pozuelo Monfort]

On 29/11/17 13:04, Michael Stone wrote:
> On Tue, Nov 28, 2017 at 08:22:50PM -0800, Russ Allbery wrote:
>> Maybe SELinux would be better, but various people have been trying to make
>> SELinux better-integrated with Debian for quite some time, and those
>> efforts don't seem to have been particularly successful.
> 
> Well, maybe it should just be turned on by default, then all the remaining
> issues will magically go away just like they will for apparmor!

If there are issues, file bugs and mention them. So far your attitude is not
helpful at all.

Nobody said problems are going to magically go away by enabling apparmor. OTOH,
we won't know to what extent problems exists until it gets enabled everywhere.
It is one thing to enable something for your particular setup, and it's a very
different thing to have it enabled across all the distribution. So don't blame
the maintainers if it worked for them but doesn't work for you. Once we know
what specific problems exist, we can work on fixing those and/or we can revert
the situation, if that turns out to be the best option. In my experience, I have
only encountered one problem so far and it's already been worked on.

Emilio

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Emilio Pozuelo Monfort]

On 18/11/17 12:41, Niels Thykier wrote:
> I have received several requests to make --list-missing or
> --fail-missing the default (#650129 and #858834) and I intend to do so
> eventually.  I am a little concerned with adding more changes to compat
> 11 (the list is rather long already), but I am happy with making
> --list-missing the default for compat 12.

Fair enough, though it seems unlikely that --list-missing would cause any
trouble... but you are the debhelper expert ;)

> As for the sequences; we can add those to the next version of debhelper
> (a sequence change the parameters passed to a helper).  If you file a
> bug for it with how you envision that, then I am happy to add it in one
> of the next uploads of debhelper. :)

No need for a sequence if dh_missing starts doing something useful by default.

Cheers,
Emilio

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Emilio Pozuelo Monfort]

On 12/11/17 11:25, Niels Thykier wrote:
> Hi,
> 
> 
> The debhelper compat level 11 is about to be finalized and we invite you
> to test it out.  There are no additional changes planned to compat 11 at
> the moment, but there might be changes in response to feedback from testers.

One thing with compat 10 that doesn't make a lot of sense to me is how
dh_missing is enabled by default but a no-op. It'd make more sense to me to
change that in compat 11 to be enabled by default and run with --list-missing
(--fail-missing is probably too much at this point), or make it run with --list
or --fail-missing, but not enabled by default, and make it an addon. So that one
can have:

No dh_missing:

%:
dh $@

Or for dh_missing:

%:
dh --with missing $@

I think one of those two options would make more sense than the status quo, and
I probably lean towards the first option (enabled by default with 
--list-missing).

Thoughts? Let me know if you want a bug report about this.

Cheers,
Emilio

Re: Removing obsolete GNOME libraries

[Emilio Pozuelo Monfort]

On 17/10/17 19:36, Emilio Pozuelo Monfort wrote:
> Hi,
> 
> We (the Debian GNOME team) have been removing obsolete, unmaintained GNOME
> libraries for several years. Now we think it's time to do another step in this
> never-ending task and remove libgnome and friends, which have been 
> unmaintained
> upstream since 7 years ago, as those libraries are from the GNOME 2 days and 
> are
> unused in the GNOME 3 platform.

FWIW the libraries we are looking to remove are (source packages):

libgnome libgnomeui gnome-vfs libbonobo libbonoboui libgnome2-perl
libgnome2-vfs-perl gnome-sharp2 gnome-python gnome-python-desktop

And binaries:

Binary: gnome-sharp2, gnome-sharp2-examples, libart2.0-cil, libart2.0-cil-dev, 
libgconf2.0-cil, libgconf2.0-cil-dev, libgnome2.24-cil, libgnome2.0-cil-dev, 
libgnome-vfs2.0-cil, libgnome-vfs2.0-cil-dev
Binary: libbonobo2-common, libbonobo2-dev, libbonobo2-0, libbonobo2-bin
Binary: libbonoboui2-common, libbonoboui2-dev, libbonoboui2-0, libbonoboui2-bin
Binary: libgnome2-0, libgnome2-bin, libgnome-2-0, libgnome2-dev, 
libgnome2-common, libgnome2-doc
Binary: libgnome2-perl
Binary: libgnome2-vfs-perl
Binary: libgnomeui-0, libgnomeui-0-dbg, libgnomeui-dev, libgnomeui-common, 
libgnomeui-doc
Binary: libgnomevfs2-common, libgnomevfs2-0, libgnomevfs2-bin, 
libgnomevfs2-extra, libgnomevfs2-0-dbg, libgnomevfs2-dev
Binary: python-gnome2-desktop-dev, python-gnomekeyring, python-rsvg, python-wnck
Binary: python-gnome2, python-gconf, python-gnome2-dev, python-gnome2-doc

Cheers,
Emilio

Removing obsolete GNOME libraries

[Emilio Pozuelo Monfort]

Debian QA Group 
   gdesklets
   gdevilspie
   gnome-alsamixer
   gnome-btdownload
   gnomint
   hamster-applet
   maximus
   notebook
   x-tile
   zapping

Debian Science Maintainers 
   linsmith

Debian Sugar Team 
   sugar-toolkit

Debichem Team 
   p4vasp

Dmitry Smirnov 
   planner (U)
   winswitch

Dominique Belhachemi 
   amide (U)

Emilio Pozuelo Monfort 
   alleyoop (U)
   gnome-speech (U)

Eric Dorland 
   lat

Fabrice Coutadeur 
   aptoncd

Frederic Peters 
   gnome-blog

Free Ekanayaka 
   invada-studio-plugins-lv2 (U)

Gaudenz Steinlin 
   passepartout

Gert Wollny 
   amide (U)

Gert Wollny 
   mialmpick (U)

Graham Inggs 
   linsmith (U)
   p4vasp (U)

Guido Günther 
   icedove (U)

Guus Sliepen 
   coriander

Harald Dunkel 
   network-manager-strongswan

Henrik Andreasson 
   pike7.8 (U)
   pike8.0 (U)

Herbert Parentes Fortes Neto 
   gthumb
   sagasu

Iain Lane 
   gnome-do (U)
   gnome-do-plugins (U)
   tomboy (U)

Jakub Adam 
   swt-gtk (U)
   swt4-gtk (U)

Jaromír Mikeš 
   invada-studio-plugins-lv2 (U)

Jean-Michel Vourgère 
   mdbtools

Jeremy Bicha 
   kabikaboo (U)

Jesse van den Kieboom 
   gnoemoe

Jo Shields 
   monodevelop (U)

Joachim Breitner 
   yarssr

John Sullivan 
   xword

Jonas Smedegaard 
   sugar-toolkit (U)

Jordi Mallach 
   alleyoop (U)
   gtetrinet

Josselin Mouette 
   gnome-hearts (U)
   gnome-speech (U)

Josue Abarca 
   planner (U)

José Ernesto Dávila Pantoja 
   glipper

Julien Lavergne 
   screenlets

Jörg Frings-Fürst 
   rapid-photo-downloader

Kartik Mistry 
   gnome-specimen

Laszlo Boszormenyi (GCS) 
   graphviz
   revelation

Loic Minier 
   alleyoop (U)
   gnome-hearts (U)
   gtetrinet (U)

Luca Niccoli 
   grcm

Ludovic Drolez 
   gjiten (U)

Magnus Holmgren 
   pike7.8
   pike8.0

Margarita Manterola 
   linsmith (U)

Mario Lang 
   gnome-speech

Markus Koschany 
   gamazons (U)
   teg (U)

Matteo F. Vescovi 
   camorama (U)

Maximiliano Curia 
   gmotionlive
   oregano

Michael Biebl 
   alleyoop (U)
   gnome-speech (U)

Michael Levin 
   cellwriter

Michael Vogt 
   gnome-commander
   vdk2

Mirco Bauer 
   bareftp (U)
   gnome-subtitles (U)
   mono-tools (U)
   monodevelop (U)
   smuxi

Miriam Ruiz 
   gnomekiss (U)

Niels Thykier 
   swt-gtk (U)

Patrick Matthäi 
   etherape

Paul Brossier 
   kino

Paul van Tilburg 
   gnoemoe (U)

Paulo Roberto Alves de Oliveira (aka kretcheu) 
   gresolver

Peter De Schrijver (p2) 
   coriander (U)

Python Applications Packaging Team 
   glipper (U)
   kabikaboo
   screenlets (U)

Reinhard Tartler 
   xine-lib-1.2 (U)

Richard Laager 
   gbonds

Rico Tzschichholz 
   docky (U)

Roberto Lumbreras 
   cbrpager

Roland Clobus 
   pioneers

Rolf Leggewie 
   gjots2

Ron Lee 
   mp3splt

Ryan Niebur 
   gstm
   shutter (U)

Sam Hocevar (Debian packages) 
   gco
   gniall
   langdrill (U)
   vdk2 (U)

Sander Marechal 
   gnome-hearts

Santiago Ruano Rincón 
   sugar-toolkit (U)

Sebastian Dröge 
   alleyoop (U)
   banshee (U)
   gnome-hearts (U)
   gshare (U)
   mono-tools (U)
   tomboy (U)

Siegfried-Angel Gevatter Pujals 
   gnome-activity-journal

Stefan Ebner 
   bareftp (U)
   yahtzeesharp (U)

Stephen Kitt 
   mail-notification

Steve Langasek 
   pioneers (U)

Thanasis Kinias 
   sanduhr

Thibaut Paumard 
   dasher (U)

Tiago Bortoletto Vaz 
   gnome-subtitles (U)

Tomasz Buchert 
   verbiste

tony mancill 
   gbonds (U)

Torsten Werner 
   lybniz (U)

Varun Hiremath 
   agave
   dissy
   lybniz

Victor Seva 
   smuxi (U)

Vincent Bernat 
   xnee

Vincent Cheng 
   monster-masher (U)

Vincent Legout 
   gnome-breakout (U)
   grhino (U)

Wences Arana 
   planner

Werner Pantke 
   gnome-color-chooser

Ying-Chun Liu (PaulLiu) 
   gbatnav

Yoann Gauthier 
   postr (U)

أحمد المحمودي (Ahmed El-Mahmoudy) 
   swt-gtk (U)
   swt4-gtk (U)

$ dak rm -Rn libgnome libgnomeui gnome-vfs libbonobo libbonoboui libgnome2-perl 
libgnome2-vfs-perl gnome-sharp2 gnome-python gnome-python-desktop
Will remove the following packages from unstable:

gnome-python | 2.28.1+dfsg-1.2 | source
gnome-python-desktop | 2.32.0+dfsg-4 | source
gnome-sharp2 |   2.24.2-4 | source, all
gnome-sharp2-examples |   2.24.2-4 | all
 gnome-vfs | 1:2.24.4-6.1 | source
libart2.0-cil |   2.24.2-4 | all
libart2.0-cil-dev |   2.24.2-4 | all
 libbonobo |   2.32.1-3 | source
libbonobo2-0 | 2.32.1-3+b1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
libbonobo2-bin | 2.32.1-3+b1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
libbonobo2-common |   2.32.1-3 | all
libbonobo2-dev | 2.32.1-3+b1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
libbonoboui |   2.24.5-4 | source
libbonoboui2-0 |   2.24.5-4 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
libbon

Re: Removing Qt4 in Buster

[Emilio Pozuelo Monfort]

On 22/09/17 14:09, Jonathan Dowland wrote:
> On Tue, Sep 05, 2017 at 03:29:31PM -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> Jonathan Dowland 
>>   qtscrob
> 
> The right thing to do here is probably to remove this from the archive.
> But out of curiosity I did look at porting it forward to qt5: I found
> someone else's patch for the code, then got as far as wondering why
> there wasn't a libqt5-dev available to my Debian machines before I ran
> out of time.

You probably want qtbase5-dev.

Emilio

Re: how to build dependency of python-webkit if python-webkit is not maintained?

[Emilio Pozuelo Monfort]

On 15/08/17 19:03, 慕 冬亮 wrote:
> Hello all,
> 
> I have a python pacakge which depends on python-webkit(or pip package 
> pywebkitgtk).
> 
> However, pywebkitgtk is not maintained now. Is there alternative pip 
> package to replace webkit python module?

The alternative is gir1.2-webkit2-4.0. See e.g. my mail at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749253#5

Cheers,
Emilio

Re: Intended MBF: maintainer scripts not using strict mode

[Emilio Pozuelo Monfort]

On 27/06/17 18:47, Russ Allbery wrote:
> Ralf Treinen  writes:
>> On Mon, Jun 26, 2017 at 11:09:26PM +0200, Mattia Rizzolo wrote:
> 
>>> sigh.
>>> And using `#!/bin(ba)?sh -e` is not good either (there is a lintian tag
>>> about it, iirc).
> 
>> what is the rationale for this? Is anyone calling maintainer scripts
>> like "sh 

Re: Intended MBF: maintainer scripts not using strict mode

[Emilio Pozuelo Monfort]

On 27/06/17 07:04, Bastian Blank wrote:
> On Mon, Jun 26, 2017 at 11:47:53PM +0200, Emilio Pozuelo Monfort wrote:
>> Btw I just fixed these:
>> ekiga-dbg_4.0.1-6+b5/postinst
>> ekiga-dbg_4.0.1-6+b5/postrm
>> ekiga-dbg_4.0.1-6+b5/preinst
> 
> While you are at it, please convert these to automatic debug symbol
> packages.  This can be done by just removing all traces of ekiga-dbg and
> let debhelper do it's magic.

Well, that's exactly what I did.

Emilio

Re: Intended MBF: maintainer scripts not using strict mode

[Emilio Pozuelo Monfort]

On 26/06/17 22:23, Ralf Treinen wrote:
> Hi,
> 
> we currently have in sid 84 maintainer scripts not using strict mode.
> That is, they neither start on "#!/bin/[ba]sh -e", nor do a "set -e".
> The list is attached. This list includes the 12 remaining scripts not
> starting on #! (bugs are already filed for these).
> 
> Policy says in Section 10.4:
> 
>  Shell scripts (sh and bash) other than init.d scripts should almost
>  certainly start with set -e so that errors are detected.
>  [..]
>  Every script should use set -e or check the exit status of every
>  command.
> 
> I had a cursory look over the listed maintainer scripts, and did not
> find any that does a careful checking of exit statuses. Though some
> of them are quite trivial, or even sometimes empty. It looks to me
> as not using strict mode in these cases is an oversight, and I would
> like to file bugs for these.
> 
> What is your opinion? Policy says "should", not "must". If you agree
> with the MBF, what do you think would be the appropriate severity?

Important.

Btw I just fixed these:

ekiga-dbg_4.0.1-6+b5/postinst
ekiga-dbg_4.0.1-6+b5/postrm
ekiga-dbg_4.0.1-6+b5/preinst

Cheers,
Emilio

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Emilio Pozuelo Monfort]

On 30/05/17 18:32, Ian Jackson wrote:
> David Kalnischkies writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
> build-deps with mk-build-deps"):
>> I would recommend not to recommend it because apt follows the general
>> recommendation of not recommending the installation of recommendations
>> of build-dependencies by default for all recommended Debian releases.
> 
> When you install the build-depends for unfamiliar programs, you are
> trying to debug, do you install recommends ?  I have found that it is
> usually wiser not to.
> 
> Installing the recommends of build-depends typically shovels in
> massive piles of junk, which is (a) a big download (b) often contains
> daemons and other weirdness that is obviously not needed.

I think what David wanted to say is:

`apt-get install $foo' install recommends
`apt-get build-dep $foo' does not install recommends

Thus you don't need to pass --no-install-recommends when doing build-dep.

Cheers,
Emilio

Re: Firefox ESR large text file rendering problem

[Emilio Pozuelo Monfort]

On 26/05/17 10:40, Jari Ruusu wrote:
> This problem is now solved.
> 
> The problem was that "offmainthread" rendering requires that SKIA [1]
> graphics library must be compiled-in at compile time.
> 
> In firefox-45-esr SKIA appears to be disabled by default, and requires
> opt-in at compile time to enable it. "offmainthread" is enabled by default
> (but can be disabled by about:config entries). By using all defaults, you
> end up with incorrectly working Firefox binary.
> 
> In firefox-52-esr SKIA appears to be enabled by default, and can be opt-out
> at compile time to disable it. "offmainthread" is hard-coded-enabled. By
> using all defaults, you end up with correctly working Firefox binary.
> 
> My problem with firefox-52-esr builds was that I had these in my .mozconfig
> 
> ac_add_options --disable-skia
> ac_add_options --disable-skia-gpu
> ac_add_options --disable-skia-pdf

Indeed, my 52.1esr works fine.

Cheers,
Emilio

Re: A proposal for a tool to build local testing debs

[Emilio Pozuelo Monfort]

On 25/05/17 20:59, Nikolaus Rath wrote:
> On May 25 2017, Sean Whitton  wrote:
>> Then in dgit-user(7), the SUMMARY would become
>>
>> SUMMARY
>>(These runes will be discussed later.)
>>
>>% dgit clone glibc jessie,-security
>>% cd glibc
>>% wget 
>> 'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250;mbox=yes;msg=89' | 
>> patch -p1 -u
>>% git commit -a -m 'Fix libc lost output bug'
>>% sudo apt-get build-dep glibc
> 
> I think the last line should better be
> 
> $ mk-build-deps -i
> 
> ..in that case you won't get bitten if the build deps of the new package
> differ from the build deps of the package in the archive.
> 
> Does build-dep require deb-src in sources.list? If so, the above removes
> that requirement as well.

Or you can just do

$ sudo apt-get build-dep ./

Cheers,
Emilio

Re: Firefox ESR large text file rendering problem

[Emilio Pozuelo Monfort]

On 08/05/17 09:05, Jari Ruusu wrote:
> On 5/7/17, Marc SCHAEFER  wrote:
>> I cannot reproduce that problem on:
>>
>> $ cat /etc/debian_version
>> 7.11
>>
>> firefox 52.1.1-ESR, installed manually from
>> http://ftp.mozilla.org/pub/firefox/releases/52.1.1esr/linux-x86_64/en-US/firefox-52.1.1esr.tar.bz2
> 
> I can confirm that the Mozilla pre-compiled version works OK. But the Debian
> pre-compiled stable or LTS version (45.9.0-ESR) does fail when when those
> "offmainthread" setting are default TRUE. Self compiled version fails too,
> same as Debian pre-compiled version.
> 
> The difference seem to be that Mozilla pre-compiled version embeds one more
> shared library. This is the diff of "ls *.so" files between self compiled
> and mozilla pre-compiled version:
> 
> --- foo1.txt2017-05-08 09:56:45.0 +0300
> +++ foo2.txt2017-05-08 09:56:51.0 +0300
> @@ -2,6 +2,7 @@
>  liblgpllibs.so
>  libmozavcodec.so
>  libmozavutil.so
> +libmozgtk.so
>  libmozsandbox.so
>  libmozsqlite3.so
>  libnspr4.so
> 
> The menus also look little bit different on mozilla pre-compiled version.

The difference is that the mozilla binaries are built against GTK+ 3, whereas
the Debian 45esr binaries are built against GTK+ 2. I don't know whether that in
itself causes the bug that you reported.

What about your 52 builds? Were those built against GTK+ 2 or 3?

I am building 52.1esr on wheezy now [1], which will be built against GTK+ 3 when
we upload it (45esr is now discontinued, so we'll upload 52esr with the next
round of updates in about three weeks). I'll test it and see if that helps.

Cheers,
Emilio

[1] I had a build around, but removed it on a quest to free some disk space.

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Emilio Pozuelo Monfort]

On 22/05/17 16:25, James Clarke wrote:
> On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote:
>> On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote:
>>> Someone else already had this idea:
>>>
>>> https://people.debian.org/~stapelberg//2016/11/25/build-tools.html
>>
>> Excellent, this is a great start, and seeing "Michael Stapelberg" for me is 
>> an
>> indication of quality.
> 
> You say that, but this is incredibly biased. Even he admits that in the
> colour choice. Disclaimer: as the cowbuilder maintainer (which comes
> from the cow*dancer* source package, for historical reasons, despite
> what the diagram may tell you) I am of course also biased. But I notice
> that for the sbuild path, schroot is completely missing, which is
> implemented in C++ and therefore probably deserves a bright red colour
> just like cowbuilder in his second picture (or maybe even something
> worse, depending on your views of C++). Then there's the extremely
> unhelfpul, hostile comment at the end:
> 
>> I propose to eliminate complexity in Debian by deprecating the
>> pbuilder toolchain in favor of sbuild.
> 
> Now, I am not necessarily against simplifying workflows, but choosing
> one to rule the all arbitrarily because you prefer the language it's
> written in is not the way to go about it. There are also benefits to
> having a variety of implementations; they behave slightly differently,
> sometimes not implementing policy in the same way, and this can be a
> good thing, allowing policy to be clarified, or finding mistakes in the
> other builder, or just exposing flaws in your package. For example,
> pbuilder will by default use a new isolated network namespace for the
> build, whereas sbuild won't, so if you just use sbuild you may not be
> aware of violating policy (4.9). I'm not trying to sell pbuilder over
> sbuild here though; there are also many ways in which sbuild is better
> than pbuilder.

Besides, the sbuild/pbuilder duplicity is the least of your problems in terms of
multiple workflows, because once you choose one of those and set it up, you can
build all packages, and don't have to set the other one up or learn it.

Compare that to hacking on a package which may use
 - debhelper, dh, cdbs or no helper at all (!) for debian/rules
 - quilt, dpatch, simple-patchsys, single-debian-patch for patch management
 - format 1.0, 3.0, native, non-native, multiple tarballs... for the source
 - git-buildpackage, git-dpm, other git repo structure with no helper tools,
svn, bzr, etc for the repository
 - ...

Some of those are easy to learn, and some you don't have to deal with if you are
doing an NMU (e.g. the repository). It's still a pretty complicated picture and
a steep learning curve if you want to start contributing, or want to join a team
that has a completely different setup.

I have to deal with packages in svn, git-bp and plain git, and have started to
write a set of (ugly) scripts that perform common actions in each of those
formats, and a generic wrapper that calls the right one depending on which repo
I'm on, so that I can just do e.g. 'deb update; dch; deb commit; deb build; deb
release; deb tag' and not having to remember all the different command line
switches and options and so on (I have a bad memory and am lazy). This shouldn't
be necessary in the first place; at least a bit of homogenization would make
sense imho.

Cheers,
Emilio

Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)

[Emilio Pozuelo Monfort]

On 22/05/17 11:29, Jonathan Dowland wrote:
> I often think about this problem, and I start to wonder if step 0 is to try 
> and
> enumerate it properly. That is: I picture in my mind some kind of huge diagram
> (perhaps generated from more structured data, I dunno, something into a 
> graphviz)
> of a landscape of debian developer tools, grouped by some kind of
> categorisation that might overlap (venn diagram style), so you'd have dh and
> cmake in one place, git-buildpackage, dgit, possibly others in another; and
> also our documentation: not just maint-guide but developers-reference, wiki
> pages, etc.
> 
> Such a thing could potentially be annotated with relevant statistics (number
> of source packages in archive using dh; cmake; etc.; number with Vcs headers,
> pointing at git or svn or ... repos;)

Do you mean cdbs rather than cmake? I'm struggling to make a connection between
dh and cmake.

Cheers,
Emilio

Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian

[Emilio Pozuelo Monfort]

On 19/02/17 08:37, Carsten Schoenert wrote:
> Hello,
> 
> Am 19.02.2017 um 07:12 schrieb Josh Triplett:
>> Mike Hommey wrote:
>>> Why not just create a ~/.thunderbird symlink to ~/.icedove if
>>> ~/.icedove exists?
>>
>> This seems like the right solution.  (Or, equivalently, rename
>> ~/.icedove to ~/.thunderbird and place a symlink in the other
>> direction.)
>>
>> Any particular reason not to do this?
> 
> given to the feedback on the list and BTS we will change the current
> behavior to "just" symlink to ~/.icedove.

Maybe you should rename the folder and make ~/.icedove a symlink 
instead.

Cheers,
Emilio

Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian

[Emilio Pozuelo Monfort]

On 16/02/17 20:14, Adam Borowski wrote:
> Following good general practice and having the disk encrypted is of no
> help as they force you to enter your password, often with multi-year jail
> time (UK) if you fail to comply.

Link?

Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED

[Emilio Pozuelo Monfort]

Hi,

On 09/02/17 17:47, Pirate Praveen wrote:
> Thorsten Alteholz  wrote:
> 
>> Hi,
> 
>> I am sorry, but I don't understand why you module makes sense.
>> Please add a more detailed description to your debian/control.
> 
> This is seriously becoming too much. "This module is a dependency
> for browserify." is already present in the description. And short
> description says "tty module from node core for browsers".
> 
> We are not expecting anyone to install this module directly. You
> can't apply the same standard of a full featured application to a
> small module. The whole node eco system is different from what we
> are used to before or after.
> 
> You can't ask to do two mutually exclusive things at the same
> time. You have to either grant an exception to browserified
> javascript or accept small modules. You can't have it both ways.
> How do you expect we package browserify if you reject its
> dependencies like tty-browserify?
> 
> I'm not super thrilled to package so many small dependencies, but
> I'm forced to package them because ruby-handlebars-assets won't
> be accepted without browserify. I'd happily stop packaging all
> these small modules if you grant an exception for
> ruby-handlebars-assets.

tiny node packages are being accepted all the time, but you're still expected to
follow policy and do your job as a maintainer - otherwise, things will get 
rejected.

If you took a couple of minutes to write a proper package description that
wasn't "some package needs it", then your package would get accepted (assuming
there are no other problems) and everyone would be happy. And you would get less
complains on debian-devel@ to your ITPs as well.

It doesn't matter that your package is small and that users won't normally
install it directly. It's still mandated that it includes a description, and
ftpmasters are only doing their job.

Cheers,
Emilio

PS: many thanks to the ftpmaster for doing a (so often) thankless job!

Re: Where to report Wayland-related bugs

[Emilio Pozuelo Monfort]

On 03/02/17 11:42, Thibaut Paumard wrote:
> Dear fellow developers,
> 
> I have started using GNOME Wayland possibly as my primary session. It
> sort of feels different from the default X11 GNOME session in surprising
> ways (overall rather more comfortable I would say).
> 
> I am seeing issues in some software that don't seem usable at all in
> GNOME Wayland, e.g.:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852699
> 
> Where is the correct place to report such issues: the individual
> affected packages (as I did with the above-mentionned bug), xwayland,
> something else?

It depends on the bug. If you want an app to be ported to wayland, then either
the app or the toolkit/framework, as appropriate. If an X app doesn't behave
properly, then XWayland. If you see a WM/compositor bug, then whatever
compositor you are using (gnome-shell/weston/...) ...

> Is there a usertag defined for such issues?

There isn't (yet).

Cheers,
Emilio

Re: What is exactly the "canonical URI" for Vcs-{Git,Browser}?

[Emilio Pozuelo Monfort]

On 20/01/17 13:43, Jonas Smedegaard wrote:
> Quoting Boyuan Yang (2017-01-20 13:19:44)
>> 在 2017年1月20日星期五 SGT 下午12:45:53，Sebastiaan Couwenberg 写道：
>>> On 01/20/2017 11:56 AM, Boyuan Yang wrote:
 # This one seems acceptable, too
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-foo/bar.git

 # This one is also acceptable
 Vcs-Git: https://anonscm.debian.org/git/pkg-foo/bar.git
>>>
>>> These are the ones you should use, because both use encryption for the
>>> connection and contrary to git+ssh URLs, and account on Alioth is not
>>> required to checkout.
>>
>> Well... this is not exactly what I mean. When we compare
>>
>> Vcs-Git: https://anonscm.debian.org/git/pkg-foo/bar.git
>> Vcs-Browser: https://anonscm.debian.org/cgit/pkg-foo/bar.git
>>
>> with
>>
>> Vcs-Git: https://anonscm.debian.org/git/pkg-foo/bar.git
>> Vcs-Browser: https://anonscm.debian.org/git/pkg-foo/bar.git
>>
>> I would use the latter one. Would that be better?
> 
> No: The latter one does not serve content usable in a browser.

Because pkg-foo doesn't exist.

But see e.g.:

https://anonscm.debian.org/cgit/pkg-freedesktop/poppler.git
https://anonscm.debian.org/git/pkg-freedesktop/poppler.git

Emilio

Re: [RFC] The PIE unholy mess

[Emilio Pozuelo Monfort]

On 18/01/17 18:23, Matthias Klose wrote:
> At this point, I would prefer to revert the PIE changes for the release and
> discuss these after the release with all parties involved.

It's not the time to revert that, thanks.

Emilio

Re: Bug#850182: Please disable TSX in stretch and backport to jessie

[Emilio Pozuelo Monfort]

On 04/01/17 20:04, Ian Jackson wrote:
> Package: eglibc

eglibc got renamed back to src:glibc a while ago.

Cheers,
Emilio

> 
> Gilles Filippini writes ("Request for help - scilab segfaults with TSX"):
>> I've just noticed this RC bug [1] against scilab. [...]
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134
>> [2] https://lists.debian.org/debian-devel/2016/11/threads.html#00210
> ...
>> I don't have access to any box with TSX enabled, and failed to find any
>> porterbox as well. [...]
> 
> amd64 with TSX is for the purposes of pthreads like a new
> architecture: the locking primitives behave differently and expose
> extra bugs.
> 
> These extra bugs will be discovered only by chance (as we see in that
> bug report and in the earlier bugs #843324 and maybe #842796).  As
> more TSX-capable hardware becomes available, we will discover more of
> them, during the life of stretch, when they are hard to fix.
> 
> Also, we don't have the capability to debug them.  I don't think we
> can have a release architecture for stretch that has no porterboxes.
> 
> So please would the libc be changed not to make use of these features
> for stretch.  The downsides will be somewhat lower performance and
> not detecting some preexisting bugs; but the upsides are not shipping
> undetected bugs, and not throwing useful software out of Debian.
> 
> Please would you make a decision quickly.
> 
> Regards,
> Ian.
> 

Re: wanna-build doesn't email the maintainer on build failures by default

[Emilio Pozuelo Monfort]

On 31/12/16 10:40, Philipp Kern wrote:
> On 12/31/2016 09:58 AM, Emilio Pozuelo Monfort wrote:
>> Somewhat related, and something I think ought to be changed... wanna-build
>> doesn't email the maintainer when a package fails to build... you have to
>> explicitly subscribe to buildd failures in the PTS. I think we should change
>> that, and instead make this opt-out.
> 
> It's not "explicitly subscribe to buildd failure" AIUI, but "subscribe
> to the package". I.e. it's part of the default set of tags and anyone
> who was subscribed to "default" when the buildd was added got it added
> to their subscription.

Hmm. Maybe the issue is when you don't subscribe to the PTS because you're the
maintainer, or the maintainer is a team and you're subscribed to the team
mailing list. In those cases, neither the team nor you are subscribed to the PTS
directly because the BTS, dak, etc email the Maintainer directly... but then you
miss wanna-build mails... is that right?

Cheers,
Emilio

wanna-build doesn't email the maintainer on build failures by default

[Emilio Pozuelo Monfort]

On 26/12/16 17:29, Samuel Thibault wrote:
> This happens again and again...  Quite a few maintainers don't seem to
> realize that mails sent to n...@bugs.debian.org are not sent to the bug
> submitter, and the bug tracking thus halts down completely when the
> maintainer asks for information only to the bot, and not to the human.

Somewhat related, and something I think ought to be changed... wanna-build
doesn't email the maintainer when a package fails to build... you have to
explicitly subscribe to buildd failures in the PTS. I think we should change
that, and instead make this opt-out.

Doing release work, I usually find packages that have FTBFS issues on release
architectures where they built before (so RC bugs) for quite a while, with no
open bug report and no sign of activity. I think we should change this so
maintainers are aware of buildd issues early.

Thoughts?

Cheers,
Emilio

Re: Specification of FTP upload queue management commands

[Emilio Pozuelo Monfort]

On 29/12/16 20:49, Ben Finney wrote:
> Afif Elghraoui  writes:
> 
>> Hi, Ben,
> 
> Thanks for the feedback. One specific suggestion appears to already have
> a bug report; I'm redirecting this sub-thread there.
> 
>> على الثلاثاء 27 كانون الأول 2016 ‫20:31، كتب Ben Finney:
>>> The ‘dput-ng’ package is one alternative that is sometimes suggested
>>> when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’
>>> or other alternatives, so am also seeking feedback from people who
>>> have informed positions on choosing one over the other.
>>
>> I always have to use dput-ng in order to be able to use the dcut dm
>> […] command and grant DMs upload permissions.
> 
> There is not ‘dm’ command is not mentioned at the upload queue Read Me
> document ftp://ftp.upload.debian.org/pub/UploadQueue/README>.
> 
> As best I can tell, that document is the specification for queue
> manipulation commands. What am I missing?

Those are the queued commands.

>> So as far as I'm concerned, if the dput package had a dcut that supports
>> the dm subcommand, I'd be very happy.
> 
> Where is the canonical specification of the commands accepted by ‘dak’?

See gregor's link, or read the source:

https://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/command.py

> Should ‘dcut’ support only one of those specifications, or should it be
> attempting to support the ‘…/UploadQueue/README’ commands as well?

It should surely support the queued commands, so that you can remove a bad
upload, reschedule a delayed upload, etc.

Whether it's dput's job to support dak commands or that belongs to a different
tool is up to you. But maybe you should support it just to stop losing users to
dput-ng :P

Cheers,
Emilio

Re: Migration despite an RC bug?

[Emilio Pozuelo Monfort]

On 29/12/16 23:36, Christoph Biedl wrote:
> Emilio Pozuelo Monfort wrote...
> 
>> Unforunately, the BTS exported a broken/incomplete RC bug list, and britney 
>> used
>> that and didn't see that some packages had an RC bug, so it allowed them to 
>> migrate.
> 
> Ouch, that's quite a nightmare. While I'm curious to learn how this
> happened and what is done to prevent this from happening again -

I don't know what will happen in the BTS side to avoid this in the future - but
we'll add a check on the britney side to abort if the RC bug list looks
suspiciously small.

> please rather focus on restoring the correct state. Installations
> running testing already might have got packages they shouldn't see.

We thought about rolling back to the previous state, but that means testing
users who have already upgraded would need to manually downgrade... which is not
good.

So we may just wait for the auto-removal hinter to do its job for
non-key-packages, and for the rest to be fixed or manually downgraded, or
whatever other solution...

Cheers,
Emilio

Re: Migration despite an RC bug?

[Emilio Pozuelo Monfort]

On 29/12/16 17:24, Ole Streicher wrote:
> Hi,
> 
> the python-numpy package in unstable has an RC bug:
> 
> https://bugs.debian.org/849196
> 
> however, today it migrated to testing, the migration status still says
> however "valid candidate".
> 
> I thought that RC bugs would prevent packages from migration -- what is
> the exception here?

Unforunately, the BTS exported a broken/incomplete RC bug list, and britney used
that and didn't see that some packages had an RC bug, so it allowed them to 
migrate.

Cheers,
Emilio

Re: python3 reportbug in experimental: call for testing

[Emilio Pozuelo Monfort]

On 14/12/16 09:22, Emilio Pozuelo Monfort wrote:
> Hi Sandro,
> 
> On 14/12/16 00:40, Sandro Tosi wrote:
>> i intend to upload reportbug 7.x series (python3 only) to unstable
>> this coming weekend, so it'd be really great if you could give it a
>> shot from experimental before then -- thanks!!
> 
> I've been using it (the ncurses interface) since you uploaded it and it's been
> working fine.

Sorry, I meant the text interface.

Emilio

Re: python3 reportbug in experimental: call for testing

[Emilio Pozuelo Monfort]

Hi Sandro,

On 14/12/16 00:40, Sandro Tosi wrote:
> i intend to upload reportbug 7.x series (python3 only) to unstable
> this coming weekend, so it'd be really great if you could give it a
> shot from experimental before then -- thanks!!

I've been using it (the ncurses interface) since you uploaded it and it's been
working fine.

Cheers,
Emilio

Re: auto-removal and alternative dependencies

[Emilio Pozuelo Monfort]

On 08/12/16 13:02, Daniel Pocock wrote:
> I have two packages that depend on: nagios3 | icinga
> 
> nagios3 is being removed[1], but icinga[2] is still available, so why
> can't my packages continue to list nagios3 as a possible dependency for
> the convenience of those people who continue to use it?

I would need to check the code, but the auto-remover probably checks the first
dependency and ignores the rest (just like e.g. wanna-build and britney). So you
could just swap them and make that: icinga | nagios3.

Cheers,
Emilio

Re: armel after Stretch

[Emilio Pozuelo Monfort]

On 07/12/16 16:53, Steve McIntyre wrote:
>  * It will need somebody happy to dive into the lower levels of the
>various toolchains to verify support for atomics and make things
>work where it's not already, by adding support for the kernel
>helpers.

There has been some recent work on this, but it seems stalled and it's not clear
whether it works on all the armel targeted hardware (e.g. v4t), see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

Emilio

Re: https://manpages.debian.org/man/1/uscan

[Emilio Pozuelo Monfort]

On 06/12/16 09:21, Javier Fernandez-Sanguino wrote:
> Dear Geert,
> 
> On 3 December 2016 at 14:33, Geert Stappers  > wrote:
> 
> Hi,
> 
> The URL https://manpages.debian.org/man/1/uscan
>  gives me a 403 error.
> 
> This e-mail is to report that issue.
> 
> 
> The URL now should work fine. If you have any future issues, please report 
> them.

You may want to add some contact information to https://manpages.debian.org/

Cheers,
Emilio

Re: https://manpages.debian.org/man/1/uscan

[Emilio Pozuelo Monfort]

On 03/12/16 14:40, Andrey Rahmatullin wrote:
> On Sat, Dec 03, 2016 at 02:33:44PM +0100, Geert Stappers wrote:
>> The URL https://manpages.debian.org/man/1/uscan gives me a 403 error.
> https://manpages.debian.org/ gives me "The service you have requested is
> currently disabled."
> Googling for "manpages.debian.org" gives me
> https://wiki.debian.org/manpages.debian.org which says "The current
> manpages.debian.org service has been disabled by Teams/DSA because of
> performance issues.".

Also see https://db.debian.org/machines.cgi?host=glinka

Emilio

Re: MIA maintainers and RC-buggy packages

[Emilio Pozuelo Monfort]

On 03/12/16 11:42, Mattia Rizzolo wrote:
> On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote:
>> * So, the final question: how much time should pass since the last
>> maintainer upload (since removal from testing, since the first still
>> unfixed RC bug, how many NMUs should exist since the last maintainer
>> upload) to be able to just do a QA upload (without changing the Maintainer
>> field as it's prohibited on the https://wiki.debian.org/Teams/MIA page)
>> instead of finely-crafting minimal diffs and fixing only things allowed by
>> devref 5.11.1?
> 
> We discussed several times internally in the MIA team during the year
> how to just "declare" a maintainer gone based on the current state
> (last upload, gpg key ok, number of RCs, number of NMUs, etc), but the
> consensus has been that it's just plain hard/impossible to give an
> appropriate answer good for all cases.  We shall discuss this again at
> DebConf instead.

I would suggest to come up with some algorithm to determine if a package is
effectively unmaintained, and implement it in an automatic way that gives
maintainers prior notice and a chance to react, like we do with auto-removals.
Then if nothing happens in a reasonable time frame, the package gets orphaned.

I think we should also have an auto-removals-from-sid[1] (the crowd applauded
when I mentioned that in my Debconf talk), which would solve/help your high
number of orphaned packages.

Cheers,
Emilio

[1] With a *very* conservative criteria. We don't want to remove a package from
the archive after 30 days because of 1 RC bug.

[MBF] mysql meta-packages

[Emilio Pozuelo Monfort]

Hi,

In order to allow moving to MariaDB, the pkg-mysql maintainers introduced some
meta-packages, as was announced in [1]. This way, not only this transition is
possible, but we can move to another provider in the future if necessary.
(Please, don't turn this into a discussion of how those meta-packages should
have been named).

Please find attached a list of packages that build-depend or depend on
libmysqlclient-dev or mysql-{server,client}. Note that if you don't fix this,
your package will pick up a dependency on libmysqlclient20 from src:mysql-5.7,
which is not in testing, thus getting stuck in unstable. Thus, I'd appreciate if
fixes for this could be uploaded soon, in order to prevent packages not
migrating to testing, and in order to move with this transition.

Please forgive me if there are any false positives. Those are due to old
packages still present in Sources/Packages files due to outdated binaries /
Built-Using etc.

An updated list can be found in [2] looking for mysql.

An MBF will likely follow in a few days. Hopefully a lot of packages are fixed
by then so that no longer is 'massive'!

Thank you for your cooperation.

Cheers,
Emilio

[1] https://lists.debian.org/debian-devel/2016/07/msg00232.html
[2] https://lintian.debian.org/tags/build-depends-on-obsolete-package.html
Adam Conrad 
   cyrus-sasl2 (U)

Adam Majer 
   isc-kea
   mosquitto-auth-plugin

Alastair McKinstry 
   libterralib (U)

Alexander Sack 
   gnash (U)

Alexander Wirt 
   icinga2 (U)

Alexandre Mestiashvili 
   gearmand

Andreas Henriksson 
   libgda5 (U)

Andreas Tille 
   embassy-domainatrix (U)
   embassy-domalign (U)
   embassy-domsearch (U)
   emboss (U)
   gentle (U)

Andrew Lee (李健秋) 
   ruby-riddle (U)

Anton Gladky 
   paraview (U)
   vtk6 (U)

Antonio Radici 
   cfengine3

Arno Töll 
   lighttpd (U)
   trafficserver

Aron Xu 
   trafficserver (U)

Athena Capital Research 
   mysql++
   quickfix

Balint Reczey 
   kodi (U)

Bareos Packaging Team 
   bareos

Bartosz Fenski 
   qsf (U)

Bernd Zeimetz 
   pmacct

Bertrand Marc 
   gnunet

Bradley Smith 
   inspircd (U)

Brian May 
   mysql-connector-python (U)
   python-mysqldb (U)

Charles Plessy 
   embassy-domainatrix (U)
   embassy-domalign (U)
   embassy-domsearch (U)
   emboss (U)

Christoph Berg 
   postgresql-mysql-fdw (U)

Christophe Prud'homme 
   paraview (U)

Cristian Greco 
   poco
   poco (U)

Cédric Boutillier 
   ruby-dataobjects-mysql (U)
   ruby-mysql2 (U)

Daniel Echeverry 
   hydra (U)

Daniel Pocock 
   captagent (U)
   resiprocate (U)

Darren Blaber 
   inspircd (U)

Dave Beckett 
   redland

David Martínez Moreno 
   hhvm (U)

Debian Apache Maintainers 
   apr-util

Debian BOINC Maintainers 
   boinc

Debian Cyrus SASL Team 
   cyrus-sasl2

Debian DNS Packaging 
   opendnssec

Debian Flash Team 
   gnash

Debian FreeRADIUS Packaging Team 

   freeradius

Debian GIS Team 
   libterralib

Debian GNOME Maintainers 
   libgda5

Debian GNUstep maintainers 
   gnustep-sqlclient

Debian HHVM packaging team 
   hhvm

Debian IRC Team 
   inspircd

Debian Kannel maintainers 
   kannel

Debian lighttpd maintainers 
   lighttpd

Debian Med Packaging Team 
   embassy-domainatrix
   embassy-domalign
   embassy-domsearch
   emboss
   gentle

Debian Multimedia Maintainers 

   kodi

Debian multimedia packages maintainers 

   mediatomb

Debian Nagios Maintainer Group 
   icinga2

Debian OCaml Maintainers 
   mysql-ocaml

Debian PHP Maintainers 
   php5
   php7.0

Debian PostgreSQL Maintainers 
   postgresql-mysql-fdw

Debian Python Modules Team 
   mysql-connector-python (U)
   python-mysqldb
   python-testing.mysqld

Debian QA Group 
   libnss-mysql-bg

Debian Ruby Extras Maintainers 

   ruby-carrierwave
   ruby-dataobjects-mysql
   ruby-em-synchrony
   ruby-mysql
   ruby-mysql2
   ruby-riddle

Debian Science Maintainers 
   apophenia

Debian Science Team 
   glpk
   paraview
   vtk6

Debian Security Tools Packaging Team 
   hydra

Debian VoIP Team 
   captagent
   resiprocate
   yate

Debian XMPP Maintainers 
   jabberd2

Debian/Kubuntu Qt/KDE Maintainers 
   akonadi

Deepak Tripathi 
   ruby-dataobjects-mysql (U)

Dmitry Borodaenko 
   ruby-mysql (U)

Dmitry E. Oboukhov 
   tarantool-lts

Dmitry Smirnov 
   zoneminder

Dominic Hargreaves 
   anope

Dominik George 
   python-testing.mysqld (U)

Emilio Pozuelo Monfort 
   libgda5 (U)

Enrico Tassi 
   lua-dbi
   lua-sql

Enrico Zini 
   dballe

Ernesto Nadir Crespo Avila 
   flow-tools (U)

Evgeni Golov 
   bareos (U)

Fabian Fagerholm 
   cyrus-sasl2 (U)

Faidon Liambotis 
   hhvm (U)
   yate (U)

Falk Hueffner 
   glpk (U)

Fathi Boudra 
   akonadi (U)

Francesco Paolo Lovergine 
   aolserver4-nsmysql
   dbf2mysql
   proftpd-dfsg (U)

Gabriele Giacone <1o5g4...@gmail.com>
   gnash (U)

Gerrit Pape 
   cvm

Gert Wollny 
   vtk6 (U)

Giacomo Catenazzi 
   inspircd (U)

Gianfranco Costamagna 
   boinc (U)

Guillaume Delacour 
   inspircd (U)

Guo Yixuan (郭溢譞) 
   boi

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 10:33, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
>> These days, a changelog entry is added to a changelog.$arch. This is to avoid
>> problems when co-installing ma:same packages, as the changelog entries 
>> will/may
>> differ between different architectures.
> 
> I see. And this changelog.$arch is neither part of the source package,
> the .changes file nor the .buildinfo file, it's just included in the
> binary packages? Or is it also part of the .changes file?

It's in .changes as well. No idea if (any of it) is in .buildinfo

Cheers,
Emilio

Re: More 5 november in the release schedule [and 1 more messages]

[Emilio Pozuelo Monfort]

On 10/11/16 08:26, Christoph Biedl wrote:
> Ian Jackson wrote...
> 
>> I think what is really worrying people is the fear that they might
>> miss something, for good reasons, and then find that their work that
>> they care about is thrown out of stretch.
>>
>> It is difficult to address this fear with logical arguments intended
>> to demonstrate that "it won't happen to a responsible maintainer",
>> because it is so easy to think of scenarios where, at the very least,
>> it's hard to be sure that the right things would happen.
> 
> For me it's a bit different. If John S.(lacker) Maintainer ignored the
> messages about debhelper compat 4 removal for ten and about the
> openssl 1.1 transition for seven months, and in January suddenly finds
> his packages got kicked out and cannot return for stretch - he had it
> coming.
> 
> If however Jane R.(esponsible) Maintainer did everything right but did
> not realize somebody else's non-action affects her packages as well,
> through a build dependency or whatever ... until the "Your package was
> removed from testing" e-mail arrives: That's quite a nuisance.
> 
> So if I, in Jane's position, could be certain I'll learn about a
> pending removal that affects my packages early enough I can avoid this
> (by kicking the maintainer or NMU), my concerns were neglectable. A
> grace period of just a few days was sufficient. This mechanism is
> implemented for install dependencies, but after reading this thread
> I'm not sure it exists for other scenarios as well. 
> 
>> On the other hand, it would be really easy for the Release Team to
>> address this fear.  All they have to say is that if there is a really
>> good excuse (maintainer seriously ill; build-dependency broken and
>> maintainer not notified; or whatever), they will be willing to
>> consider exceptions.
> 
> I guess the Release Team plays tough in the first place so people do
> their job *now* instead of asking for exceptions later. I'd call that
> wise tactics. The e-thing still might happen if there's really, really
> good reason. But creating false hope sends the wrong signal. 
> 
> Finally, there's a thing called "trust": I trust the Release Team does
> this solely in order to keep the freeze time as short as possible,
> everybody hates that time anyway. This trust was created by the very
> people behind it, and the way they acted in the past months.

+1.

And yes, we will give exceptions on a case by case basis, as we have always 
done.

Also, as has been noted in this thread, it looks like some processes could be
improved (e.g. notifying rdeps when removing a package from unstable). Let's see
what affects the release process and then let's try to improve those things.

Cheers,
Emilio

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 10:00, Ansgar Burchardt wrote:
> On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
>> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
>>> It seems that sbuild indeed re-uses the timestamp from the last
>>> debian/changelog entry in the binNMU changelog entry.
>>
>> This has been done in an early attempt to make binNMUs co-installable 
>> in a multiarch world:
>>
>> ,
>>> sbuild (0.62.2-1) unstable; urgency=low
>>> [...]
>>> - Improve binNMU handling to permit binNMUs for multiarch
>>> packages
>>>   (Closes: #620112).  Currently, binary NMUs use the current
>>> date
>>>   in the new changelog entry, but co-installable packages
>>> require
>>>   an identical changelog.  To avoid this, take the date from
>>> the
>>>   previous changelog entry to ensure the same date for all
>>> binNMUs.
>>> [...]
>>>  -- Roger Leigh   Tue, 05 Apr 2011 10:46:49
>>> +0100
>>
>> `
>>
>> Which did not help, because the changelog is not actually identical
>> anyway.
> 
> The date from the last sourceful upload should probably still be used
> for any date/time information included in generated files to ensure
> they are identical on all architectures (or at least to try to do so).
> 
> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
> probably be set to the date of the last sourceful upload (instead of
> just using the most recent changelog entry).

There are many differences among different architectures, see e.g.:

lame (3.99.5+repack1-9+b1) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild against ncurses 6.0.

 -- amd64 / i386 Build Daemon (x86-csail-01)
  Thu, 11 Jun 2015 12:33:22 +0200

But that is not a problem as the entry is added to changelog.$arch for this 
reason.

Cheers,
Emilio

Re: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 00:53, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 10:41:09PM +, Ian Jackson wrote:
>> Is this a recommended recipe ?  AIUI a buildd doing a binnmu will not
>> modify the debian/changelog file.
> 
> Are you sure? When last I checked, this was not true (it may have
> changed since, however).

These days, a changelog entry is added to a changelog.$arch. This is to avoid
problems when co-installing ma:same packages, as the changelog entries will/may
differ between different architectures.

Cheers,
Emilio

Re: More 5 november in the release schedule

[Emilio Pozuelo Monfort]

On 09/11/16 04:16, Paul Wise wrote:
> On Wed, Nov 9, 2016 at 1:36 AM, Emilio Pozuelo Monfort wrote:
> 
>> Right. We want auto-removals to be useful for the release process, so that we
>> don't end up with a thousand of RC bugs in testing when we freeze, most of 
>> them
>> on packages that nobody cares about, not even their maintainers.
>>
>> However, we don't want auto-removals to drop your package behind your back. 
>> If
>> that happens, that's a bad thing and you should let us know so we can fix
>> things. auto-removals should notify the maintainer in advance, and only act
>> after a reasonable period of time.
>>
>> The "packages can't re-enter testing during the freeze" is an incentive so 
>> that
>> maintainers don't wait to fix a package after a few months, and so that we 
>> don't
>> have to go and remove them manually. This way you know that something is 
>> going
>> to happen if you don't act, yet you should have a reasonable amount of time 
>> to
>> do something. Hopefully this helps have a short(er) freeze, which is good for
>> everyone.
> 
> FYI, it looks like at least buildd stuff (IIRC that uses dose3),
> rt.d.o, snapshot.d.o and the Debian VoIP services will need to remain
> on jessie until the affected packages reach stretch-backports as a
> result of the autoremovals stuff:
> 
> https://lists.debian.org/debian-services-admin/2016/10/msg2.html
> 
> I guess alioth will remain on wheezy too.

dose3 is fixed now, so that's not a problem anymore. I have no idea about the
others, but I'm happy to see that respighi is not on that list!

Emilio

Re: Newer version of xz-utils for Stretch / NMU a wishlist bug

[Emilio Pozuelo Monfort]

On 25/09/16 23:57, Sebastian Andrzej Siewior wrote:
> Hi,
> 
> we have xz-utils 5.1.1alpha+20120614 since Wheezy. Upstream ist at
> 5.2.2 right now. There is a wishlist bug #731634 [0] asking for
> something newer. By the end of JAN I prepared a 5.2.2 package and
> pointed Jonathan to it and from his response he liked it.
> Now. A few people pinged about an upload since. I don't mind waiting a
> month or two longer for a new version to hit the archive if now is a bad
> time. But if nothing happens in that time we might get into the freeze
> phase first.
> Any suggestions on how to proceed?

NMU to delayed/10, leave a note in the bug that you did so. Then wait and see
what happens. Or just upload it directly, given

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731634#65

Cheers,
Emilio

Re: liblemon_1.3.1+dfsg-1_amd64.changes REJECTED [and 2 more messages]

[Emilio Pozuelo Monfort]

On 09/08/16 19:40, Ian Jackson wrote:
> Do we _usually_ have files in .debs which are *derived from* (not just
> generated by) files from other packages, whose authorship is not
> represented in the resulting .deb ?
> 
> (I think it is fair to disregard things like libgcc, whose authors
> have explicitly disclaimed the requirement to notify recipients of
> executables about the inclusion of libgcc.)

Any package calling inline or #defined functions from a different package?

Emilio

Re: [Pkg-sugar-devel] MBF: Removing old GNOME python bindings

[Emilio Pozuelo Monfort]

On 01/08/16 17:37, Jonas Smedegaard wrote:
> Yes, most of those activities are not in Debian - just as most of shell 
> scripts depending on Zsh is not in Debian, but it would still be a bad 
> idea to kick that package judging from its reverse dependencies (I 
> guess: I am not a Zsh user myself).

The difference is that zsh doesn't depend on and isn't blocking the removal of a
bunch of deprecated packages :P

There is software out there using all kinds of old libraries - yet we keep
removing old and unmaintained stuff from Debian.

Cheers,
Emilio

Re: MBF: Removing old GNOME python bindings

[Emilio Pozuelo Monfort]

On 29/07/16 00:20, Jonas Smedegaard wrote:
> Quoting Emilio Pozuelo Monfort (2016-07-28 23:29:00)
>> It is high time that we remove the old GNOME python bindings. We have 
>> had the "new" GObject introspection support since at least Squeeze. 
>> The old ones are completely unmaintained and unsupported.
>>
>> I'd like to get gnome-python, gnome-python-extras, pyorbit, 
>> nautilus-python and pygtksourceview removed from testing for the 
>> Stretch release. Most of the gnome-python and gnome-python-extras 
>> binaries have already been removed. This is the final push.
>>
>> Removing pygtk and pygobject-2 may be unreasonable for Stretch, so if 
>> that can't happen we'll file bugs soon after the Stretch release (or 
>> file them earlier and bump the severity after the release) to get it 
>> done for Buster.
>>
>> For gnome-python{,-extras}, pyorbit, nautilus-python and 
>> pygtksourceview there are 54 reverse dependencies, and only 2 of them 
>> are key packages. One of those (cinnamon) doesn't actually need to 
>> depend on any of these packages and can just drop the dependency, and 
>> the other (hamster-applet) will need to be updated to a new upstream 
>> version or get removed as well.
> 
> The Sugar project is actively working towards migration from pygtk to 
> pygobject but is unlikely to finish that work before the freeze of 
> Stretch, unfortunately.

I see that some of sugar has already been ported, e.g. sugar-toolkit-gtk3. Is
there really no way things can be ported in time? These modules have been
deprecated for years and we'd really like to get rid of them.

Also, I wonder if we really need three versions of sugar. The only remaining
rdep for 0.88 seems to be sugar-moon-activity. That seems unmaintained: we have
version 11 while upstream has 17, and the last maintainer activity was in 2010.
Thus I have filed an RC bug on sugar-base-0.88 to get it out of Stretch.

As for sugar-toolkit 0.98, there's only sugar-calculate-activity and
sugar-presence-service (last upstream activity 2011, package description says it
is deprecated) still depending on it. Maybe we should remove those as well so we
can kill sugar 0.98?

Getting those fixed or removed would mean that we don't have to ship multiple
versions of sugar, and that we can get rid of the static GNOME python bindings.

Cheers,
Emilio

MBF: Removing old GNOME python bindings

[Emilio Pozuelo Monfort]

Hi,

It is high time that we remove the old GNOME python bindings. We have had the
"new" GObject introspection support since at least Squeeze. The old ones are
completely unmaintained and unsupported.

I'd like to get gnome-python, gnome-python-extras, pyorbit, nautilus-python and
pygtksourceview removed from testing for the Stretch release. Most of the
gnome-python and gnome-python-extras binaries have already been removed. This is
the final push.

Removing pygtk and pygobject-2 may be unreasonable for Stretch, so if that can't
happen we'll file bugs soon after the Stretch release (or file them earlier and
bump the severity after the release) to get it done for Buster.

For gnome-python{,-extras}, pyorbit, nautilus-python and pygtksourceview there
are 54 reverse dependencies, and only 2 of them are key packages. One of those
(cinnamon) doesn't actually need to depend on any of these packages and can just
drop the dependency, and the other (hamster-applet) will need to be updated to a
new upstream version or get removed as well.

There is a porting guide upstream:

https://wiki.gnome.org/action/show/Projects/PyGObject/IntrospectionPorting

Also see:

https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
https://wiki.gnome.org/action/show/Projects/PyGObject

Packages can use the replacements:

pygtksourceview -> gir1.2-gtksource-3.0
python-gnomekeyring -> gir1.2-gnomekeyring-1.0
python-rsvg -> gir1.2-rsvg-2.0
python-wnck -> gir1.2-wnck-3.0

etc.

Please find attached a list of rdeps and a dd-list.

Cheers,
Emilio
aptoncd
cherrytree
cinnamon
clamtk
dissy
dragbox
dreampie
gallery-uploader
gco
gdesklets
gdevilspie
ghextris
gjots2
glipper
gnome-activity-journal
gnome-blog
gnome-btdownload
gnome-specimen
gnome3-emblems
guake
gvrng
hamster-applet
kabikaboo
lybniz
nautilus-admin
nautilus-compare
nautilus-hide
nautilus-image-manipulator
owncloud-client
pida
policycoreutils
postr
pybliographer
pyrenamer
rabbitvcs
rapid-photo-downloader
revelation
routeplanner
sbackup
screenlets
specto
startupmanager
subliminal
sugar-calculate-activity
sugar-toolkit
sugar-toolkit-0.88
system-config-lvm
tortoisehg
txaws
udev-discover
w3af
winswitch
x-tile
xword
Adolfo González Blázquez 
   pyrenamer

Aigars Mahinovs 
   sbackup

Alexander Alemayhu 
   postr

Andrea Veri 
   gnome-btdownload
   nautilus-compare (U)

Andreas Cadhalpun 
   clamtk (U)

Bruno Nova 
   nautilus-admin
   nautilus-hide

Caitlin Matos 
   dreampie

Chris Lawrence 
   pybliographer
   routeplanner

Chris Silva 
   gdevilspie

Christoph Egger 
   ghextris (U)

Christopher James Halse Rogers 
   specto

ClamAV Team 
   clamtk

Clint Byrum 
   txaws (U)

Daniel Echeverry 
   guake

Dave Kerr 
   kabikaboo (U)

David Paleino 
   clamtk (U)

Debian Cinnamon Team 
   cinnamon

Debian Games Team 
   ghextris

Debian GNOME Maintainers 
   hamster-applet

Debian OLPC 
   sugar-toolkit-0.88

Debian Python Modules Team 
   subliminal
   txaws

Debian QA Group 
   gdesklets
   startupmanager
   x-tile

Debian SELinux maintainers 
   policycoreutils

Debian Sugar Team 
   sugar-calculate-activity
   sugar-toolkit

Dmitry Smirnov 
   winswitch

Emilien Klein 
   nautilus-image-manipulator

Etienne Millon 
   subliminal (U)

Fabio Fantoni 
   cinnamon (U)

Fabrice Coutadeur 
   aptoncd

Francois Marier 
   gnome3-emblems

Frederic Peters 
   gnome-blog

Guido Tabbernuk 
   nautilus-compare

J. Félix Ontañón 
   udev-discover

Jan Luebbe 
   pida (U)

Jeremy Bicha 
   kabikaboo (U)

John Sullivan 
   xword

Jonas Smedegaard 
   sugar-calculate-activity (U)
   sugar-toolkit (U)
   sugar-toolkit-0.88 (U)

Josselin Mouette 
   hamster-applet (U)

José Ernesto Dávila Pantoja 
   glipper

Julien Lavergne 
   screenlets

Jörg Frings-Fürst 
   rapid-photo-downloader

Kartik Mistry 
   gnome-specimen

Laszlo Boszormenyi (GCS) 
   revelation

Luciano Bello 
   w3af

Ludovico Cavedon 
   tortoisehg

Manoj Srivastava 
   policycoreutils (U)

Margarita Manterola 
   cinnamon (U)

Max Bowsher 
   tortoisehg (U)

Maximiliano Curia 
   cinnamon (U)

Michael Biebl 
   hamster-applet (U)

ownCloud for Debian maintainers 

   owncloud-client

Oxan van Leeuwen 
   subliminal (U)

Philipp Huebner 
   system-config-lvm

Philipp Kaluza 
   pida

Pietro Battiston 
   gallery-uploader

Python Applications Packaging Team 
   cherrytree
   dreampie (U)
   glipper (U)
   kabikaboo
   rabbitvcs
   screenlets (U)

Rolf Leggewie 
   gjots2

Russell Coker 
   policycoreutils (U)

Sam Hocevar (Debian packages) 
   gco

Sandro Knauß 
   owncloud-client (U)

Santiago Ruano Rincón 
   sugar-toolkit (U)

Scott Kitterman 
   clamtk (U)

Sebastian Andrzej Siewior 
   clamtk (U)

Sergio Talens-Oliag 
   gvrng

Siegfried-Angel Gevatter Pujals 
   gnome-activity-journal

Torsten Werner 
   lybniz (U)

Ulrik Sverdrup 
   dragbox

Varun Hiremath 
   dissy
   lybniz

Vincent Cheng 
   cherrytree (U)

W. Martin Borgert 
   rabbitvcs (U)

Yoann Gauthier 
   postr (U)

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Emilio Pozuelo Monfort]

On 11/07/16 18:48, Michael Biebl wrote:
> Hi
> 
> Am 11.07.2016 um 18:41 schrieb Raphael Hertzog:
>> On Mon, 11 Jul 2016, Emilio Pozuelo Monfort wrote:
>>> The other good option I can think of is to make GNOME prefer libinput by 
>>> passing
>>> some options to X through gdm. No idea how feasible that is.
>>
>> It would still break KDE or XFCE started by gdm then.
> 
> Well, gdm would obviously only do that for a GNOME3 session, otherwise
> it would be pretty pointless.

Yes, that is what I meant.

> But starting GNOME from lightdm or kdm would still lead to a broken
> behaviour. So this approach would only be a partial solution.

I thought about that, but Andreas told me that screen locking is already broken
if you don't use gdm. Dunno if that got fixed or if it's still an issue.

Emilio

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Emilio Pozuelo Monfort]

On 11/07/16 16:34, Raphael Hertzog wrote:
> [ Bcc debian-x and debian-gtk-gnome, discussion on -devel as the topic
>   crosses the boundaries of multiple teams ]
> 
> Hello,
> 
> it has been some time that GNOME 3.20 users have been unable to configure
> their touchpad[1] because:
> 1/ xserver-xorg-input-synaptics cherry-picked an upstream commit[2]
>that gives the priority to the synaptics driver to handle touchpads
> 2/ xserver-xorg-input-synaptics is always installed as a dependency
>of xserver-xorg-input-all
> 3/ gnome-control-center 3.20 uses libinput and no longer support synaptics
> 
> Clearly points 1 and 2 are in conflict: the upstream explanation is that that 
> the
> package should not be installed by default and we do install it by default.
> 
> Looking at https://anonscm.debian.org/cgit/pkg-xorg/debian/xorg.git I see
> that we have unreleased changes to not install the synaptics driver by
> default. Timo or Emilio, can you upload those changes?

That would break non-GNOME installations as you said. We should find a good
solution before breaking more stuff.

> Even with this driver no longer installed by default, this will not fix
> the setup for users who are upgrading. Do you have any suggestion on how
> we should handle upgrades?
> 
> My best idea right now is that gnome-control-center's postint should
> do something like this:
> if [ -e /usr/share/X11/xorg.conf.d/60-libinput.conf ] && \
>dpkg -s xserver-xorg-input-synaptics >/dev/null 2>&1 && \
>[ ! -e /etc/X11/xorg.conf.d/90-libinput.conf ]
> then
> echo "Creating /etc/X11/xorg.conf.d/90-libinput.conf to workaround 
> xserver-xorg-input-synaptics"
> mkdir -p /etc/X11/xorg.conf.d
> ln -sf /usr/share/X11/xorg.conf.d/60-libinput.conf 
> /etc/X11/xorg.conf.d/90-libinput.conf
> fi

Please no.

> The other solution is to add a "Conflicts: xserver-xorg-input-synaptics"
> but this is rather extreme. Although it is somewhat in line with
> the upstream views on the topic.

Not that either.

> The best solution would be to have gnome-control-center handle properly
> synaptics-managed touchpads but I don't think that upstream developers are
> very open to that idea given that they have dropped the support on
> purpose.
> 
> What do you think?

We thought about backporting synaptics support back for Stretch, to give more
time to libinput to mature and to other DEs to add support for it. Not sure how
much work that would be though.

The other good option I can think of is to make GNOME prefer libinput by passing
some options to X through gdm. No idea how feasible that is.

Cheers,
Emilio

Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

[Emilio Pozuelo Monfort]

On 10/07/16 15:14, Bjørn Mork wrote:
> Emilio Pozuelo Monfort  writes:
>> On 09/07/16 22:31, Franciscarlos Santos Soares wrote:
>>> Hi Emilio!
>>>
>>> Thank you for contacting us. In fact, like independent application of any 
>>> DE, 
>>> but they were compatible with the traditional look of windows and based on 
>>> the 
>>> GTK library. So would provide a good working environment in the old 
>>> computers 
>>> that read daily in public schools that work.
>>
>> I found 
>> http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/,
>> which makes things clearer. This seems to be a cross-desktop (Mate, 
>> Cinnamon...
>> XFCE?) project to provide some core apps. Which we wouldn't end up with 
>> multiple
>> forks of the same stuff, and that addresses my concerns.
> 
> That's the forking version of https://xkcd.com/927/ , isn't it?

That blog post made me think this was a coordinated effort between various DEs
to create some apps that they all would use. Which would mean we wouldn't need a
gnome-$foo fork Cinnamon, another one for Mate, etc...

But it seems I was too naïve and that is not the case, and we're just going to
end up with one more fork as I initially feared.

I so hope I am wrong on this...

Cheers,
Emilio

Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

[Emilio Pozuelo Monfort]

Hi,

Please keep the bug report and debian-devel@ in Cc.

On 09/07/16 22:31, Franciscarlos Santos Soares wrote:
> Hi Emilio!
> 
> Thank you for contacting us. In fact, like independent application of any DE, 
> but they were compatible with the traditional look of windows and based on 
> the 
> GTK library. So would provide a good working environment in the old computers 
> that read daily in public schools that work.

I found http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/,
which makes things clearer. This seems to be a cross-desktop (Mate, Cinnamon...
XFCE?) project to provide some core apps. Which we wouldn't end up with multiple
forks of the same stuff, and that addresses my concerns.

Maybe the XFCE / Cinnamon / Mate maintainers can confirm if that is indeed the 
plan.

Cheers,
Emilio

Re: [MBF] Obsoleting Source-Version substvar

[Emilio Pozuelo Monfort]

On 10/07/16 02:16, Guillem Jover wrote:
> Hi!
> 
> I'd like to obsolete the ${Source-Version} substvar, which has very
> misleading semantics, and has been deprecated since dpkg 1.13.19 in
> 2006-05-04. This currently emits warnings from various dpkg-dev
> scripts and from lintian.
> 
> 
> 
> I'm attaching the prospective dd-list, and the template bug report. I'd
> like do the MBF in 1 or 2 weeks, and turn the warnings into errors in
> the first dpkg release after 1 or 2 months from now. I'm easy if people
> would like more or less time?

Sounds good to me.

Cheers,
Emilio

Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

[Emilio Pozuelo Monfort]

On 09/07/16 22:05, Franciscarlos Santos Soares wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Franciscarlos Santos Soares 
> 
> * Package name: xplayer
>   Version : 1.0.7
>   Upstream Author : Bastien Nocera 
> * URL : https://github.com/linuxmint/xplayer
> * License : GPL, LGPL
>   Programming Lang: C
>   Description :  Simple media player based on GStreamer
> 
>   Xplayer is part of X-App project, is a simple yet featureful media player

Do we really need yet another fork of GNOME?

Emilio

Re: preparing for GCC 5, especially libstdc++6

[Emilio Pozuelo Monfort]

On 01/07/15 14:39, Matthias Klose wrote:
> On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote:
>> On 25/06/15 17:44, Matthias Klose wrote:
>>> On 06/25/2015 01:20 PM, Matthias Klose wrote:
>>>> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote:
>>>>> - You suggest that some libraries may need to be renamed due to the ABI 
>>>>> breaks.
>>>>> Do you have a list of affected libraries?
>>>>
>>>> No. Getting this list is a bit difficult. Candidates for these packages 
>>>> are the
>>>> GCC 5 build failures due to mismatched symbols files. However there may be 
>>>> more
>>>> packages which successfully build, but have additional symbols (this may 
>>>> be an
>>>> empty set, because usually some symbol names should be just replaced by 
>>>> new ones).
>>>
>>> If symbol versioning is used in a library, you probably won't see this at 
>>> all,
>>> until the package is built using GCC 5. I'll ask for another test rebuild 
>>> with a
>>> diverted dpkg-gensymbols to look at the generated symbols files.
>>
>> Thanks Matthias. I'd be very interested in knowing more about what breaks.
> 
> We have 361 C++ libraries which define at least one of these new symbols [1].
> Note this list only includes the packages which succeed to build with GCC 5.
> Another 70 packages might need the same action (the issues at [2] with 
> severity
> important, which fail during the dpkg-gensymbols call).
> 
> So my proposal would be to file bug reports for each of these packages, asking
> the maintainers for what to do with this library. Actions could be:
> 
>  - do nothing, if none of these symbols are part of the library ABI. That
>would be a rebuild of the library and its reverse dependencies.
> 
>  - add breaks to all reverse dependencies on this library, and rebuild
>the library and the reverse dependencies.
> 
>  - rename the library package and rebuild all reverse dependencies.
> 
> The default action should be the most conservative action (the renaming of the
> library package).

But let's not do transitions unnecessarily... we have hundreds of libraries
there, so if we can avoid a bunch, then we should avoid them. So I'd say the
default action should be to investigate if a transition is needed or not. I'm
not advocating to blindly ignore the problem, fwiw, just want to try to make
this a little manageable.

I see there are quite a few FTBFS bugs for the affected libraries, but since the
plan is to do the switch to GCC 5 first, and the libstdc++6 transition later,
there would be time in between to fix those bugs and prepare for the transition.
Right?

> These bug reports could be used as transition bug reports as well, once GCC 5 
> is
> the default. Then these could be reassigned to release.debian.org once the
> transitions start.

Yeah, that or new bugs. As long as usertags / titles are set properly, I don't
mind. :)

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55956ab2.8030...@debian.org

Re: preparing for GCC 5, especially libstdc++6

[Emilio Pozuelo Monfort]

On 25/06/15 17:44, Matthias Klose wrote:
> On 06/25/2015 01:20 PM, Matthias Klose wrote:
>> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote:
>>> - You suggest that some libraries may need to be renamed due to the ABI 
>>> breaks.
>>> Do you have a list of affected libraries?
>>
>> No. Getting this list is a bit difficult. Candidates for these packages are 
>> the
>> GCC 5 build failures due to mismatched symbols files. However there may be 
>> more
>> packages which successfully build, but have additional symbols (this may be 
>> an
>> empty set, because usually some symbol names should be just replaced by new 
>> ones).
> 
> If symbol versioning is used in a library, you probably won't see this at all,
> until the package is built using GCC 5. I'll ask for another test rebuild 
> with a
> diverted dpkg-gensymbols to look at the generated symbols files.

Thanks Matthias. I'd be very interested in knowing more about what breaks.

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558ca482.3090...@debian.org

Re: preparing for GCC 5, especially libstdc++6

[Emilio Pozuelo Monfort]

On 16/06/15 23:37, Matthias Klose wrote:
> Hi,
> 
> it's time to prepare for GCC 5 as the default compiler in unstable.  Compared 
> to
> earlier version bumps, the switch to GCC 5 is a bit more complicated because
> libstdc++6 sees a few ABI incompatibilities, partially depending on the C++
> standard version used for the builds.  libstdc++6 will support two ABI's, the
> classic cxx98 ABI (currently in testing/unstable) and the new cxx11 ABI
> (currently enabled in experimental as the default ABI).
> 
>  - the majority of packages using c++98 or earlier c++ standards
>should just continue to work.
>  - In GCC 4.9 and earlier versions the libstdc++6 C++11 support was
>still marked as experimental, and upstream doesn't (and didn't in the past)
>guarantee c++11 ABI compatibility across major GCC versions.
>It worked somehow ok in the past, however it won't this time.
>  - some c++98 code won't work when parts are built using GCC 4.9, and some
>parts with GCC 5 (see PR66145 upstream).
> 
> Unfortunately due to PR66145 we already have an incompatible libstdc++6 (at
> least for some packages) in testing/unstable, which was only seen after the
> first packages were rebuilt and issues like #784655 were reported.
> 
> My goal is to make the GCC version bump in early July, and use the time until
> then to prepare libstdc++6 depending packages to get ready for GCC 5, and
> avoiding version bumps for C++ libraries until this time.
> 
> Details for the whole transition are outlined in
> 
>   https://wiki.debian.org/GCC5
> 
> I'd appreciate feedback for this plan, clarify the wiki page, and would like 
> to
> post a finalized plan next week to d-d-a, and file appropriate transition bugs
> next week.

Hi Matthias,

Thanks for the report. I have looked at the wiki page, but it's not entirely
clear to me how the libstdc++ transition will go, so I have a few questions to
better understand it.

- You suggest that some libraries may need to be renamed due to the ABI breaks.
Do you have a list of affected libraries?

- Will those libraries need to migrate all at the same time with libstdc++, or
could libstdc++/gcc-5 migrate first, and then the libraries can slowly migrate
independently?

My main concern with all this is if we'll have a huge transition with lots of
libraries been renamed and having to migrate at the same time with their rdeps.

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558bc883.1060...@debian.org

Re: Q: Which is suitable "distribution" in changelog for point release?

[Emilio Pozuelo Monfort]

On 22/06/15 15:54, Hideki Yamane wrote:
> On Mon, 22 Jun 2015 15:41:30 +0200
> Emilio Pozuelo Monfort  wrote:
>>>  Then, which is better: jessie or jessie-proposed-updates?
>>>  and {testing,stable,oldstable}-security and 
>>> {stretch,jessie,wheezy}-security?
>>
>> jessie and jessie-security.
> 
>  Thanks Emilio, but why?
>  Because I also note this as best practice in developers-reference, so want
>  to know the reason.

As Joss said, because that avoids confusion.

E.g. imagine you uploaded a package to p-u targeting stable (wheezy) before
Jessie was released. Your package was accepted and all. However, the next wheezy
point release only happened after the Jessie release. Then your package that
targeted stable was shipped in the new oldstable (as intended though).

Another case: you prepare an upload for stable (wheezy) and file a p-u bug. A RM
acks it. Jessie is released. Then you upload your package. You intended for it
to go to wheezy, but it now goes to jessie.

Using wheezy and jessie avoids all these kind of problems. That's why it is
preferred.

HTH,

Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55881628.10...@debian.org

Re: Q: Which is suitable "distribution" in changelog for point release?

[Emilio Pozuelo Monfort]

On 22/06/15 13:43, Hideki Yamane wrote:
> On Sun, 21 Jun 2015 23:13:53 +0200
> Emilio Pozuelo Monfort  wrote:
>>> $ dch -r -D jessie
>>> dch warning: Recognised distributions are: unstable, testing, 
>>> stable,
>>> oldstable, experimental, 
>>> {testing-,stable-,oldstable-,}proposed-updates,
>>> {testing,stable,oldstable}-security, wheezy-backports, 
>>> jessie-backports and UNRELEASED.
>>> Using your request anyway.
>>> dch: Did you see that warning?  Press RETURN to continue...
>>> 
>>> I don't see any bugs about not accepting Jessie here and if it weren't
>>> deliberate I'd expect older releases to be listed (i.e. it's not just
>>> that devscripts hadn't caught up with Jessie yet).
>>
>> Then please file a bug.
> 
>  Okay, filed as Bug#789587
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789587
> 
>  
>  Then, which is better: jessie or jessie-proposed-updates?
>  and {testing,stable,oldstable}-security and {stretch,jessie,wheezy}-security?

jessie and jessie-security.

Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5588108a.3030...@debian.org

Re: Q: Which is suitable "distribution" in changelog for point release?

[Emilio Pozuelo Monfort]

On 21/06/15 10:39, Ian Campbell wrote:
> On Fri, 2015-06-19 at 16:37 +0200, Josselin Mouette wrote:
>> Hi,
>>
>> Hideki Yamane  wrote: 
>>  Which is suitable "distribution" in changelog for Jessie and wheezy
>>  point release? (and why) I just looked debian-release posts and 
>> confused...
>> 
>>  - stable / oldstable
>>  - stable-proposed-updates / oldstable-proposed-updates
>>  - jessie / wheezy
>>
>> The recommended distribution is the codename (jessie, wheezy). This way
>> there can be no confusion. 
> 
> That's what I would have thought, but:
> 
> $ dch -r -D jessie
> dch warning: Recognised distributions are: unstable, testing, stable,
> oldstable, experimental, 
> {testing-,stable-,oldstable-,}proposed-updates,
> {testing,stable,oldstable}-security, wheezy-backports, 
> jessie-backports and UNRELEASED.
> Using your request anyway.
> dch: Did you see that warning?  Press RETURN to continue...
> 
> I don't see any bugs about not accepting Jessie here and if it weren't
> deliberate I'd expect older releases to be listed (i.e. it's not just
> that devscripts hadn't caught up with Jessie yet).

Then please file a bug.

Cheers,
Emilio


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55872911.4070...@debian.org