What problem might happen when bumping soname without adding Conflicts:/Breaks:?

[Boyuan Yang]

Hello debian-devel and mentors,

Recently I found a disagreement with my mentor about proper handling of 
library transition (bumping SONAME) and we agreed that we need some 
suggestions.

Transition documentation (written by Release Team) can be found at [1].

Some quick facts:

* We have a libdframeworkdbus1 with soname 1; it is a standard Multi-Arch 
library:

% dpkg -L libdframeworkdbus1 
/. 
/usr 
/usr/lib 
/usr/lib/x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libdframeworkdbus.so.1.0.0 
/usr/share 
/usr/share/doc 
/usr/share/doc/libdframeworkdbus1 
/usr/share/doc/libdframeworkdbus1/changelog.Debian.gz 
/usr/share/doc/libdframeworkdbus1/changelog.gz 
/usr/share/doc/libdframeworkdbus1/copyright 
/usr/lib/x86_64-linux-gnu/libdframeworkdbus.so.1 
/usr/lib/x86_64-linux-gnu/libdframeworkdbus.so.1.0 
/usr/share/doc/libdframeworkdbus1/CHANGELOG.md.gz

* Upstream released new version and bumped SONAME to 2
* -dev package didn't change its name
* My mentor suggests that the new library package (libdframeworkdbus2) should 
add the relationship "Conflicts: libdframeworkdbus1"

...and such necessity is not reflected in the documentation. My personal 
thought is that with "smooth updates" (as described in [1]), the old library 
and the new library (with different SONAME) should be able to installed 
simultaneously on any Debian Unstable / Debian Testing system without any 
problem during the transition. If that is true, the "Conflicts:" relationship 
shouldn't appear. The "Replaces:" relationship [2] should not appear as well 
because there won't be any file conflcts.

We'd like to know that with transitions for library soname bump, is 
"Conflicts:" relationship needed / not needed in all circumstances and what 
problem might users / developers encounter if it is added / not added.

Thank you very much.

--
Regards,
Boyuan Yang


[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[2] https://www.debian.org/doc/debian-policy/#s-replaces

signature.asc
Description: This is a digitally signed message part.

Bug#894163: RFS: streamlink/0.11.0+dfsg-1~bpo9+1

[Alexis Murzeau]

Le 28/03/2018 à 03:46, Paul Wise a écrit :
> On Tue, 2018-03-27 at 22:49 +0200, Alexis Murzeau wrote:
> 
>> Can you post your logs ?
> 
> Attached.
> 
>> I cannot reproduce this error either with sbuild or pbuilder.
> 
> I guess the LANG/LC_ALL in your chroots has UTF-8 in the name,
> for some reason mine only has LANG=C LC_ALL=C.
> 
> Strangely, the RB infra builds fine with LANG=C LC_ALL=C:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/streamlink.html
> 
>> I previously encountered this encoding error and it should have been fixed
>> by debian/patches/0006-Avoid-use-of-non-ASCII-in-plugins.patch.
> 
> You only patched one of the UTF-8 files, not all of them:
> 
> $ file src/streamlink/plugins/* | grep -v ASCII
> src/streamlink/plugins/showroom.py:   Python script, UTF-8 
> Unicode text executable
> 
> This file includes some Chinese characters in the keys of a dict,
> so I don't think you will be able to patch them out.
> 
> $ grep -C3 --color='auto' -P -n "[^\x00-\x7F]" 
> src/streamlink/plugins/showroom.py
> 42-
> 43-# the "low latency" streams are rtmp, the others are hls
> 44-_rtmp_quality_lookup = {
> 45:"オリジナル画質": "high",
> 46:"オリジナル画質(低遅延)": "high",
> 47-"original spec(low latency)": "high",
> 48-"original spec": "high",
> 49:"低画質": "low",
> 50:"低画質(低遅延)": "low",
> 51-"low spec(low latency)": "low",
> 52-"low spec": "low"
> 53-}
> 
> So upstream needs to load the plugin files using the UTF-8 encoding.
> 

I think I have found the cause.
I found that the failing test was loading python modules using
imp.load_module with possibly closed file descriptor.
In that case, python reopen the file descriptor using open() which use
the system encoding by default (here, ASCII).

This does not always happen reliably and I'm not sure why, but I think
this the reason we have not the same test behavior.

I've replaced the patch 0006-Avoid-use-of-non-ASCII-in-plugins.patch
with another patch ensuring load_module is given an open file descriptor.

I've uploaded the resulting package on mentors.debian.net.
Does it work for you ? Thanks :)

dget
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.11.0+dfsg-1~bpo9+1.dsc


PS: Note that this uploaded package does not contain the build twice in
a row fix.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#894307: RFS: pgn2web/0.4-2 [ITA]

[Jose G. López]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pgn2web":

* Package name: pgn2web
  Version : 0.4-2
  Upstream Author : William Hoggarth 
* URL : http://pgn2web.sourceforge.net/
* License : GPL-3+
  Section : web

It builds those binary packages:

  pgn2web - convert PGN chess game files into webpages

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/pgn2web

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pgn2web/pgn2web_0.4-2.dsc

Package development is on the following repo:

https://salsa.debian.org/josgalo-guest/pgn2web

Changes since the last upload:

pgn2web (0.4-2) unstable; urgency=medium

  * Set myself as Maintainer (Closes: #835308)
  * debian/compat: Upgrade to version 11.
  * debian/control:
- Bump to Standards-Version 4.1.3. No changes required.
- Use optional priority.
- Add Vcs-* fields pointing to Salsa.
  * debian/copyright: Convert to Machine-readable format.
  * debian/patches:
- compilation.patch: Add to fix compilation errors.
- makefile.patch: Add to enable hardening flags.
- install-location.patch: Move install location fix to makefile.patch.
  * debian/rules: Enable hardening flags and use verbose mode.
  * debian/watch: Add to track upstream releases.
  * Add and install a desktop file.

 -- Jose G. López   Wed, 28 Mar 2018 19:08:10 +0200

Thanks and regards,


pgpUuz1GFybCv.pgp
Description: PGP signature

Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Albert van der Horst]

Walter Landry schreef op 2017-07-03 20:59:

Albert van der Horst  wrote:

For those not versant with assembler. The binary that is generated is
supposed to be byte for byte the same with both assemblers. If not it
is a bug. The sources are equivalent, the binaries are the same, it
really is the same program.

Note, that I could not have told that I use an internal representation
and nobody could have guessed (nor benefited.)

So is the .s accepted as source conform Debian policies?


Unpopular or obscure source formats can still be the preferred source.
Presumably you use this internal representation for a good reason.  If
it helps you, it can help others.


As you may see in a separate post i've made an essentially larger upload
of lina, mainly to preempt legalistic reasons that would prevent 
acceptance.


It contains the "obscure source format".

The basic idea is that in the main directory building is from the
assembler file, but it is a target build from an extract directory.
So there is still a clear separation between meta building and
final building where the final build is very simple.

More about the basic idea in
https://github.com/albertvanderhorst/ciforth/wiki/Philosophy-behind-ciforth

Note that the extract directory (even containing a small fraction of the
files in the generic system) can generate 2 source files in 4 assembler
formats. 6 of those 8 I've tested. Tinkering with configuration files
multiplies the number of possible generated files by 512.
Most of those assembler source program's won't work.

I invite mentors interested in the "preferred source" matter to check
whether they can agree that the package now complies with debian guide 
lines.





Cheers,
Walter Landry


--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Bug#881032: marked as done (RFS: icecc/1.1-2~bpo9+1 NMU)

[Debian Bug Tracking System]

Your message dated Wed, 28 Mar 2018 10:20:34 +
with message-id 
and subject line closing RFS: icecc/1.1-2~bpo9+1 NMU
has caused the Debian Bug report #881032,
regarding RFS: icecc/1.1-2~bpo9+1 NMU
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
881032: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881032
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "icecc"

 * Package name    : icecc
   Version : 1.1-2~bpo9+1
   Upstream Author : schumac...@kde.org
 * URL : https://github.com/icecc/icecream
 * License : GNU General Public License v2.0
   Section : devel

I request for sponsorship for a backport of icecc (version 1.1-2) for
stretch-backports.

I'm not the maintainer, nor I'm involved with the development of this
package on Debian. I'm CC'ing current maintainers.

I have updated the changelog accordingly and rebuilt the package in
a pristine environment (stretch cowbuilder). No more changes than
updating the changelog were needed.

After that I tested the package on a stretch machine and all works as
expected.

It builds those binary packages:

  icecc - distributed compiler (client and server)
 libicecc-dev - development files for icecc (distributed compiler)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/icecc


Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/i/icecc/icecc_1.1-2~bpo9+1.dsc


Changes since the last upload:

  icecc (1.1-2~bpo9+1) stretch-backports; urgency=medium

  * Rebuild for stretch-backports.

  -- Pablo Saavedra   Mon, 06 Nov 2017 11:14:34 +

Therefore, I request for sponsorship for this backport.


  Regards,
   Pablo Saavedra Rodiño



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Package icecc has been removed from mentors.--- End Message ---

Bug#881118: marked as done (RFS: boost-numeric-bindings/0.99-1 [ITP] -- Numeric Library Bindings for Boost)

[Debian Bug Tracking System]

Your message dated Wed, 28 Mar 2018 10:20:34 +
with message-id 
and subject line closing RFS: boost-numeric-bindings/0.99-1 [ITP] -- Numeric 
Library Bindings for Boost
has caused the Debian Bug report #881118,
regarding RFS: boost-numeric-bindings/0.99-1 [ITP] -- Numeric Library Bindings 
for Boost
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
881118: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881118
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "boost-numeric-bindings":

* Package name: boost-numeric-bindings
  Version : 0.99
  Upstream Author : Kresimir Fresl et. al.
* URL : https://github.com/uBLAS/numeric_bindings
* License : Boost Software License - Version 1.0
  Programming Lang: C++
  Description : boost-numeric-bindings -- Numeric Library Bindings for Boost


Boost Bindings is a bindings library (not just) for Boost.Ublas.
It offers an easy way of calling BLAS, LAPACK, UMFPACK, MUMPS and
many other mature legacy numerical codes from within C++.

The package source may be found at:

http://anonscm.debian.org/cgit/debian-science/packages/boost-numeric-bindings.git

And the package description may be found at:

https://mentors.debian.net/debian/pool/main/b/boost-numeric-bindings/boost-numeric-bindings_0.99-1.dsc

Previously an ITP bug was filed by someone else (#536270) but then
dropped.  Since then a github repo was created by an upstream author
and a "pre-release 0.99" was released with a bit more work, in 2015.
I have updated the preliminary package by Teemu Ikonen from that bug
to the latest version, as well as the latest Debian compat and policy
versions.

This version of the package installs the header files to the
/usr/include/boost directory.

Please note that this version 0.99 did not include a LICENSE file in
the main directory, however all files nonetheless still have a
reference to their license at the top and it remains the same as in
debian/copyright.  (I have filed an upstream issue to restore the
license file.)

Preliminary support for running some of the tests should hopefully
come in the near future.  I intend to improve this, add documentation
if possible, and keep it up to date with any future releases.  It
would be beneficial to Debian to have these headers more easily
available, since projects are currently often embedding them in their
source distributions.
--- End Message ---
--- Begin Message ---
Package boost-numeric-bindings has been removed from mentors.--- End Message ---

Bug#890379: RFS: python-jsonrpc/1.10.8-1 [ITP]

[Ghislain Vaillant]

Hi Gianfranco, could you upload this please?

Cheers,
Ghis

Le jeu. 15 févr. 2018 à 15:59, Ghislain Vaillant  a
écrit :

> Le jeudi 15 février 2018 à 15:51 +, Lumin a écrit :
> > Hi,
> >
> > On 15 February 2018 at 13:52, Ghislain Vaillant 
> > wrote:
> >
> > > > 1. please fix the following copyright issue:
> > > I will update d/copyright accordingly.
> > > > 2. This package failed to build when python2 version of sphinx
> > > > exists:
> > >
> > > I don't care to be honest.
> > >
> > > It builds fine on a clean chroot with the Python 3 version of
> > > Sphinx:
> >
> > OK. Let's omit the failure in an unclean build environment.
> >
> > @Gianfranco: Would you mind sponsoring this package after
> > Ghislain uploaded updated package to mentors?
> > I've checked several lists [1][2][3] and the package LGTM,
> > expect for the license issue mentioned above.
> >
> > ✔ control and rules in good shape
> > ✔ debomatic build and tests successful
> >
> > [1] devref section 7.5.1 Sponsoring packages
> > [2] https://wiki.debian.org/SponsorChecklist
> > [3] https://wiki.debian.org/LucaFalavigna/NEWChecklist
>
> I have just pushed the change requested by Lumin in the packaging
> repository, retagged and submitted an updated tarball to mentors.
>
> Also, hi Gianfranco, been a while...
>
> ...yes I know my DD application :-)
>
> Ghis
>

Re: Need to manage my incoming

[Narcis Garcia]

El 27/03/18 a les 13:29, Mel Mac ha escrit:
> I need guidance with appxmanifest ?
> 

$ apt-cache search appx
libwordnet-querydata-perl - Perl interface to WordNet database

Bug#883840: Retitling the bug report as per new upstream release of spglib

[Andrius Merkys]

retitle 883840 RFS: spglib/1.10.3-1 [ITP] -- C library for crystal symmetry 
determination
thanks

I have updated the package as per new upstream patch release of "spglib".

Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania