Bug#930274: RFS: junitparser/1.3.2-1 [ITP]

[Herbert Fortes]

Hi Bastian Germann,


>>
>>> There is no 'debian/tests/control' file. No CI. Please see to how
>>> run upstream tests by autopkgtest. 
>>>
>>> https://ci.debian.net/
>>
>> I already had a "Testsuite: autopkgtest-pkg-python" line in d/control. I
>> guess this is also picked up by ci.debian.net. If not, what should I put
>> into debian/tests/control to run the same tests there?
> 

I uploaded with one of the packages I take care of with a similar
situation.

Your package is in 'NEW' until today. If you want to revert it and
use only the 'Testsuite: autopkgtest-pkg-python' it is fine to me.
Ask FTP-Master to Reject the package and do it. There is no problem.

I will re-upload the package I take care of with 'Testsuite' only.



Regards,
Herbert

Bug#931970: gphoto2: autopkgtest failure block readline migration

[Herbert Fortes]

Hi,

On Sat, 13 Jul 2019 07:49:23 +0200 Bas Couwenberg  wrote:
> Source: gphoto2
> Version: 2.5.20-3
> Severity: serious
> Justification: makes the package in question unusable or mostly so
> 
> Dear Maintainer,
> 
> The autopkgtest failures for gphoto2 are blocking the testing migration
> of readline and its reverse dependencies.
> 
> Please fix the tests in your package or remove them.

I ran 'autopkgtest' and see no errors.


All tests have PASSED
autopkgtest [14:14:29]: test upstream-test-suite.sh: ---]
autopkgtest [14:14:29]: test upstream-test-suite.sh:  - - - - - - - - - - 
results - - - - - - - - - -
upstream-test-suite.sh PASS
autopkgtest [14:14:29]:  summary
upstream-test-suite.sh PASS


Can you detail more what is wrong?



Regards,
Herbert

Bug#932547: RFS: desktopfolder/1.1.0-2

[Herbert Fortes]

Hi,

On 7/20/19 11:14 AM, David Mohammed wrote:
> Package: sponsorship-requests
> Severity: normal
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "desktopfolder"

I granted upload permissions to you.



Regards,
Herbert

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Herbert Fortes]

On 7/19/19 4:06 PM, Adam D. Barratt wrote:
> On Thu, 2019-07-18 at 16:30 -0300, Herbert Fortes wrote:
>> On 7/18/19 4:19 PM, Salvatore Bonaccorso wrote:
> [...]
>>> As discussed in the backlog of this bug, this should actually have
>>> been 3:3.4.4.1-*5*+deb9u1, but I see
>>>
>>> gthumb | 3:3.4.4.1-6+deb9u1 | oldstable-new   | source,
>>> amd64
>>>
>>> should that be rejected and re-uploaded?
>>>
>>
>> Yes! Reject the upload.
>>
>>> - gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz
> 
> Flagged for rejection.
> 
> Regards,
> 
> Adam
> 

Received: gthumb - rejecting for re-upload with fixed version number

Just uploaded it again.



Regards,
Herbert

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Herbert Fortes]

[...]

> >>
> >> Uploaded.
> >
> > As discussed in the backlog of this bug, this should actually have
> > been 3:3.4.4.1-*5*+deb9u1, but I see
> >
> > gthumb | 3:3.4.4.1-6+deb9u1 | oldstable-new   | source, amd64
> >
> > should that be rejected and re-uploaded?
> >
>
> Yes! Reject the upload.
>
> > - gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz
>

I did not receive the 'Reject' e-mail.

A 'dcut cancel' from me was expected?

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Herbert Fortes]

On 7/18/19 4:19 PM, Salvatore Bonaccorso wrote:
> hey!
> 
> On Thu, Jul 18, 2019 at 03:55:40PM -0300, Herbert Fortes wrote:
>> On Tue, 16 Jul 2019 20:38:15 +0100 "Adam D. Barratt" 
>>  wrote:
>>> On Sat, 2019-03-09 at 16:41 +, Adam D. Barratt wrote:
>>>> On Mon, 2018-12-03 at 08:17 +0100, Julien Cristau wrote:
>>>>> Control: tag -1 confirmed
>>> [...]
>>>>> Go ahead, thanks.
>>>>
>>>> Ping?
>>>
>>> Ping? If nothing happens by August 15th then I plan to close this bug.
>>>
>>> Regards,
>>>
>>> Adam
>>>
>>
>> Uploaded.
> 
> As discussed in the backlog of this bug, this should actually have
> been 3:3.4.4.1-*5*+deb9u1, but I see
> 
> gthumb | 3:3.4.4.1-6+deb9u1 | oldstable-new   | source, amd64
> 
> should that be rejected and re-uploaded?
> 

Yes! Reject the upload.

> - gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Herbert Fortes]

On Tue, 16 Jul 2019 20:38:15 +0100 "Adam D. Barratt"  
wrote:
> On Sat, 2019-03-09 at 16:41 +, Adam D. Barratt wrote:
> > On Mon, 2018-12-03 at 08:17 +0100, Julien Cristau wrote:
> > > Control: tag -1 confirmed
> [...]
> > > Go ahead, thanks.
> > 
> > Ping?
> 
> Ping? If nothing happens by August 15th then I plan to close this bug.
> 
> Regards,
> 
> Adam
> 

Uploaded.



Regards,
Herbert

Bug#923162: RFS: python-rfid/1.2 [ITP] -- friendly greeter

[Herbert Fortes]

On Sun, 24 Feb 2019 17:16:16 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-rfid"
> 
>  * Package name: python-rfid
>Version : 1.2
>Upstream Author : Philipp Meisberger 
>  * URL : https://github.com/philippmeisberger/pyrfid.git
>  * License : D-FSL
>Section : python
> 
> It builds those binary packages:
> 
> python-rfid - Python 2 written library for an 125kHz RFID reader
> python3-rfid - Python 3 written library for an 125kHz RFID reader

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.

One more link:
https://spdx.org/licenses/



Regards,
Herbert

Bug#923158: RFS: libpam-rfid/1.4 [ITP] -- friendly greeter

[Herbert Fortes]

On Sun, 24 Feb 2019 16:17:14 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libpam-rfid"
> 
>  * Package name: libpam-rfid
>Version : 1.4
>Upstream Author : Philipp Meisberger 
>  * URL : https://github.com/philippmeisberger/pam-rfid.git
>  * License : D-FSL
>Section : admin
> 
> It builds those binary packages:
> 
> libpam-rfid - Pluggable Authentication Module for hardware
> authentication via RFID

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.

One more link:
https://spdx.org/licenses/



Regards,
Herbert

Bug#922966: RFS: eclipse-package/1.0 [ITP]

[Herbert Fortes]

On Fri, 22 Feb 2019 12:24:51 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "eclipse-package"
> 
>  * Package name: eclipse-package
>Version : 1.0
>Upstream Author : Philipp Meisberger 
>  * URL :
> https://github.com/philippmeisberger/eclipse-package.git
>  * License : D-FSL
>Section : shells
> 
> It builds those binary packages:
> 
> eclipse-package - Utility for creating Eclipse Debian packages

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.

One more link:
https://spdx.org/licenses/



Regards,
Herbert

Bug#923157: RFS: libpam-fingerprint/1.5 [ITP]

[Herbert Fortes]

On Sun, 24 Feb 2019 16:17:04 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libpam-fingerprint"
> 
>  * Package name: libpam-fingerprint
>Version : 1.5
>Upstream Author : Philipp Meisberger 
>  * URL :
> https://github.com/philippmeisberger/pam-fingerprint.git
>  * License : D-FSL
>Section : admin
> 
> It builds those binary packages:
> 
> libpam-fingerprint - Pluggable Authentication Module for fingerprint
> authentication

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.

One more link:
https://spdx.org/licenses/



Regards,
Herbert

Bug#922965: RFS: arduino-package/1.0 [ITP] --friendly greeter

[Herbert Fortes]

Hi,

On Fri, 22 Feb 2019 12:39:52 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "arduino-package"
> 
>  * Package name: arduino-package
>Version : 1.0
>Upstream Author : Philipp Meisberger 
>  * URL :
> https://github.com/philippmeisberger/arduino-package.git
>  * License : D-FSL
>Section : shells
> 
> It builds those binary packages:
> 
> arduino-package - Utility for creating Arduino Debian packages

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.

One more link:
https://spdx.org/licenses/



Regards,
Herbert

Bug#922963: RFS: gamewake/3.5.1 [ITP] -- friendly greeter

[Herbert Fortes]

Hi,

On Fri, 22 Feb 2019 12:21:26 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "gamewake"
> 
>  * Package name: gamewake
>Version : 3.5.1
>Upstream Author : Philipp Meisberger 
>  * URL : https://github.com/philippmeisberger/gamewake.git
>  * License : D-FSL
>Section : utils
> 
> It builds those binary packages:
> 
> gamewake - Alarm clock application

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.


One more link:
https://spdx.org/licenses/



Regards,
Herbert

Bug#922964: RFS: python-fingerprint/1.5 [ITP]

[Herbert Fortes]

Hi,

On Fri, 22 Feb 2019 11:59:04 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-fingerprint"
> 
>  * Package name: python-fingerprint
>Version : 1.5
>Upstream Author : Bastian Raschke 
>  * URL : https://github.com/bastianraschke/pyfingerprint
>  * License : D-FSL
>Section : python
>

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.



Regards,
Herbert

Bug#930274: RFS: junitparser/1.3.2-1 [ITP]

[Herbert Fortes]

On 6/29/19 10:28 AM, Bastian Germann wrote:
> Hi Herbert,
> 
> Thanks for coming back to me. I uploaded a new version with the
> suggested changes.
> 
>> # lintian-info -t 'tag'
>>
>>  - upstream-metadata-file-is-missing
>>
>>It is pedantic. There are info here to fix that:
>>Refer to https://dep-team.pages.debian.net/deps/dep12/ and
>>https://wiki.debian.org/UpstreamMetadata for details.
> 
> I have included a metadata file.

Thanks for that.

> 
>>  - debian-watch-does-not-check-gpg-signature
>>
>>There is gpg signature. Ignore.
>>
>>  - library-package-name-for-application usr/bin/junitparser
>>application-in-library-section python usr/bin/junitparser
>>
>>Junitparser README.rst file shows how to use it as a module and
>>by command line. The command 'tree debian/python3-junitparser'
>>shows the module and the command line script. The manpage is
>>the README.rst file.
>>
>>Please split the package (one depends on other):
>>   
>>- python3-junitparser is the module
>>- junitparser is the 'utils' (in Section)
>>
>>The README.rst file. The command line part can be the manpage.
>>The rest can be a documentation in '/usr/share'
> 
> Okay. I have included the README.rst in python3-junitparser and moved
> the binary and its edited manpage to the package junitparser.

Ok.

> 
>> The package does not build twice because junitparser.egg-info dir
>> is not removed between builds. Please override dh_clean to do that.
> 
> I used the debian/clean file for that.

Good!

> 
>> There is no 'debian/tests/control' file. No CI. Please see to how
>> run upstream tests by autopkgtest. 
>>
>> https://ci.debian.net/
> 
> I already had a "Testsuite: autopkgtest-pkg-python" line in d/control. I
> guess this is also picked up by ci.debian.net. If not, what should I put
> into debian/tests/control to run the same tests there?

Using d/tests/control we can run the upstream tests too. Not only
a import module test.

The result:

[...]
--
Ran 59 tests in 0.040s

OK
[...]
autopkgtest [14:50:55]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import junitparser; print(junitparser)" ; done
autopkgtest [14:50:55]: test autodep8-python3: [---
Testing with python3.7:

autopkgtest [14:50:56]: test autodep8-python3: ---]
autopkgtest [14:50:56]: test autodep8-python3:  - - - - - - - - - - results - - 
- - - - - - - -
autodep8-python3 PASS (superficial)
autopkgtest [14:50:56]:  summary
command1 PASS
autodep8-python3 PASS (superficial)


debian/tests/control file:

Test-Command: python3.7 -m unittest discover -v
Restrictions: allow-stderr
Depends: @



Regards,
Herbert

Bug#930274: RFS: junitparser/1.3.2-1 [ITP]

[Herbert Fortes]

Hi!

On Sun, 9 Jun 2019 17:21:48 +0200 Bastian Germann  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "junitparser".
> 
>  * Package name: junitparser
>Version : 1.3.2-1
>Upstream Author : Joel Wang
>  * URL : https://github.com/gastlygem/junitparser
>  * License : Apache-2.0
>Section : python
> 
> It builds those binary packages:
> 
>   python3-junitparser - Manipulates JUnit/xUnit Result XML files
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/junitparser
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/j/junitparser/junitparser_1.3.2-1.dsc
> 
> junitparser is a JUnit/xUnit result XML Parser. It can parse and
> manipulate existing result XML files, or create new JUnit/xUnit result
> XMLs from scratch.
> 
> There are already two python packages in Debian that can create
> JUnit/xUnit result XML files but there does not seem to be any that can
> parse them to a domain specific object model.
> 
> More information about junitparser can be obtained from
> https://github.com/gastlygem/junitparser.

I did a fast review on the package:

Now running lintian junitparser_1.3.2-1_amd64.changes ...
X: junitparser source: upstream-metadata-file-is-missing
X: junitparser source: debian-watch-does-not-check-gpg-signature
X: python3-junitparser: library-package-name-for-application usr/bin/junitparser
X: python3-junitparser: application-in-library-section python 
usr/bin/junitparser

# lintian-info -t 'tag'

 - upstream-metadata-file-is-missing
   
   It is pedantic. There are info here to fix that:
   Refer to https://dep-team.pages.debian.net/deps/dep12/ and
   https://wiki.debian.org/UpstreamMetadata for details.

 - debian-watch-does-not-check-gpg-signature
   
   There is gpg signature. Ignore.

 - library-package-name-for-application usr/bin/junitparser
   application-in-library-section python usr/bin/junitparser

   Junitparser README.rst file shows how to use it as a module and
   by command line. The command 'tree debian/python3-junitparser'
   shows the module and the command line script. The manpage is
   the README.rst file.

   Please split the package (one depends on other):
  
   - python3-junitparser is the module
   - junitparser is the 'utils' (in Section)

   The README.rst file. The command line part can be the manpage.
   The rest can be a documentation in '/usr/share'

The package does not build twice because junitparser.egg-info dir
is not removed between builds. Please override dh_clean to do that.

There is no 'debian/tests/control' file. No CI. Please see to how
run upstream tests by autopkgtest. 

https://ci.debian.net/



Regards,
Herbert

   
  
 - 

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

Ok. No dm.txt.

Thanks Paul and Raphael.



Regards,
Herbert

Em sáb, 15 de jun de 2019 05:52, Raphael Hertzog 
escreveu:

> On Sat, 15 Jun 2019, Raphael Hertzog wrote:
> > I also don't know why you picked this bug report to start your journey
> > into distro-tracker. It's not a trivial issue to fix and the added value
> > is relatively low compared to other missing features.
> >
> > I took the time to highlight easy bugs with the newcomer tag,
> > maybe you should start with some of those?
>
> Ah, I see the bug was tagged as newcomer by Paul in fact. I suggest
> you first deal with all the requests in this bug except the last
> idea to display who approved the DM right... the rest should be relatively
> easy.
>
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> Learn to master Debian: https://debian-handbook.info/get/
>

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

 
> Should dm.txt file be downloaded and read once a day?
> (to update/save new info)
> 
> 'class DebianContributor(models.Model)' has 'allowed_packages' and
> 'is_debian_maintainer'
> 
> Or a dictionary.
> 
> I set 'DISTRO_TRACKER_DATA_PATH' + 'cache/dm.txt' for now. But no 
> downloads yet.
> 
> Here is the forked repository:
> https://salsa.debian.org/hpfn/distro-tracker/commit/56b2a5d95f9ce4aa3eaee9e21668a45d54a79094

I did a commit to use 'urlopen' and do not have to worry
about it.



Regards,
Herbert

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

On 6/13/19 6:14 PM, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 13 Jun 2019, Herbert Fortes wrote:
>> I found where to make the change. But the information about
>> who gave the permission I do not know where it is at *debian.org.
>>
>> In distro_tracker/vendor/debian/rules.py file:
>>
>> _add_dm_entry function - extra.append({'display': 'dm'})
>>
>> 'link': "https://ftp-master.debian.org/dm.txt;
>> 'description': "Debian Maintainer upload allowed by Andreas Henriksson"
> 
> In https://ftp-master.debian.org/dm.txt behind each package, there's a
> fingerprint between parenthesis. This fingerprint is the fingerprint
> of the key who signed the addition of the DM right. So if you can map
> that back to a name, then you're good.
> 
> There's some code doing that already with the help of the GPG keyring
> that we have configured, see verify_signature() in
> distro_tracker/core/utils/__init__.py (in particular
> ctx.get_key(...)).
> 

Ok.

What I did seems to work. I added two tests for a function that I
created - allowed_by(pkg).

Initial lines are copy from verify_signature (it does not work
when passing a fingerprint to it).

The function reads dm.txt file to get the fingerprint and gives it to
gpg.Context().get_key(). One test added to return 'None'. One test 
added to return 'PTS Tests'.

I edited these files:

 - distro_tracker/core/tests/tests-data/cache/dm.txt - one DM
 - distro_tracker/core/tests/tests_utils.py
 - distro_tracker/core/utils/__init__.py
 - distro_tracker/vendor/debian/rules.py
 - distro_tracker/vendor/debian/tests.py

It is a first step.

Should dm.txt file be downloaded and read once a day?
(to update/save new info)

'class DebianContributor(models.Model)' has 'allowed_packages' and
'is_debian_maintainer'

Or a dictionary.

I set 'DISTRO_TRACKER_DATA_PATH' + 'cache/dm.txt' for now. But no 
downloads yet.

Here is the forked repository:
https://salsa.debian.org/hpfn/distro-tracker/commit/56b2a5d95f9ce4aa3eaee9e21668a45d54a79094



Regards,
Herbert

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Herbert Fortes]

Hi,

On Wed, 21 Mar 2018 10:32:00 +0800 Paul Wise  wrote:
> On Tue, 20 Mar 2018 07:25:35 +0800 Paul Wise wrote:
> 
> > I think these changes are needed:
> 
> It would also be nice to have info on who approved the package.
> 
> > Here is how these changes should look in the HTML:
> 
> Updated version:
> 
>   
>   (https://ftp-master.debian.org/dm.txt;> title="Debian Maintainer upload allowed by Andreas 
> Henriksson">DM)
>   
>

I found where to make the change. But the information about
who gave the permission I do not know where it is at *debian.org.

In distro_tracker/vendor/debian/rules.py file:

_add_dm_entry function - extra.append({'display': 'dm'})

'link': "https://ftp-master.debian.org/dm.txt;
'description': "Debian Maintainer upload allowed by Andreas Henriksson"



Regards,
Herber

Bug#812609: tracker.debian.org: wrong versioned links for security versions

[Herbert Fortes]

On 6/10/19 9:10 AM, Ricardo Mones wrote:
> On Mon, Jun 10, 2019 at 08:09:23AM -0300, zaza wrote:
>> On Fri, 26 Apr 2019 16:17:15 +0200 Salman Mohammadi  wrote:
>>> On Mon, 25 Jan 2016 16:43:38 +0100 Ricardo Mones  wrote:

 The links to .dsc file wich appear on versioned links panel for security
 versions are using httpredir.d.o, which always gives 40x errors for those
 package versions. Example: https://tracker.debian.org/pkg/claws-mail
 (3.8.1-2+deb7u1 and 3.11.1-3+deb8u1 dsc links)

>>>
>>> Dear Recardo,
>>>
>>> I couldn't reproduce this bug in the package that you have mentioned.
>>
>>
>> Neither do I.
> 
> FWIW the link labeled 'old-sec' in today's claws-mail tracker page still
> fails. Not with a 404 though, it just says:
> 
> ,---
> | Error
> |
> | two or more packages specified (claws-mail updates)
> `---
> 
> regards,
> 

Yes.

The problem is the link in 'versions':

 - old-sec: 3.11.1-3+deb8u1
   https://packages.debian.org/source/oldstable/updates/claws-mail

The 'updates' should not be there. As bug 850409 made clear. All .dsc
links in 'versioned links' are fine.



Regards,
Herbert

Bug#927785: pyparted: FTBFS randomly (Floating point exception)

[Herbert Fortes]

forwarded 927785 https://github.com/dcantrell/pyparted/issues/57
thanks

Sent debugging.txt file (Bernhard Übelacker file)



On 4/23/19 6:35 AM, Bernhard Übelacker wrote:
> Dear Maintainer,
> I just tried to find some more information.
> 
> I could reproduce the issue in a unstable amd64 VM
> on the second attempt.
> 
> It looks like in a garbage collector run a
> division by zero is triggered because we
> get there with sector_size==0.
> 
> If wanted I can forward the core file.
> 
> Kind regards,
> Bernhard
> 
> 
> 
> 1708gpt_alloc_metadata (PedDisk *disk)
> 1709{
> ...
> 1718  gptlength = ped_div_round_up (sizeof (GuidPartitionTableHeader_t),
> 1719disk->dev->sector_size);
> 
> 
> (gdb) bt
> #0  0x7fb67449e727 in ped_div_round_up (divisor=0, numerator=100) at 
> ../../../include/parted/natmath.h:130
> #1  gpt_alloc_metadata (disk=0x558890efb060) at 
> ../../../libparted/labels/gpt.c:1718
> #2  0x7fb67448851a in _disk_alloc_metadata (disk=0x558890efb060) at 
> ../../libparted/disk.c:1164
> #3  _disk_pop_update_mode (disk=0x558890efb060) at ../../libparted/disk.c:1164
> #4  0x7fb6744890b2 in ped_disk_delete_all 
> (disk=disk@entry=0x558890efb060) at ../../libparted/disk.c:2104
> #5  0x7fb67449dd59 in gpt_free (disk=0x558890efb060) at 
> ../../../libparted/labels/gpt.c:622
> #6  0x7fb674abee82 in ?? ()
> #7  0x7fb673c46348 in ?? ()
> #8  0x55888eb4b67b in dict_dealloc (mp=0x7fb673c46280) at 
> ../Objects/dictobject.c:1086
> #9  0x55888ebf8339 in subtype_clear (self= 0x7fb673bbaa10>) at ../Objects/typeobject.c:912
> #10 0x55888eb3860c in delete_garbage (old=0x55888eda25b0 
> , collectable=0x7ffd0ab2f4e0) at 
> ../Modules/gcmodule.c:817
> #11 collect (generation=2) at ../Modules/gcmodule.c:981
> #12 0x55888eb9fcaa in PyGC_Collect () at ../Modules/gcmodule.c:1439
> #13 0x55888eb9ef44 in Py_Finalize () at ../Python/pythonrun.c:455
> #14 0x55888ebc92c8 in Py_Exit (sts=0) at ../Python/pythonrun.c:1795
> #15 0x55888ebc6a8d in handle_system_exit () at ../Python/pythonrun.c:1160
> #16 0x55888ebc63b6 in PyErr_PrintEx (set_sys_last_vars=, 
> set_sys_last_vars=) at ../Python/pythonrun.c:1170
> #17 0x55888ebc527d in RunModule (module=, 
> set_argv0=) at ../Modules/main.c:199
> #18 0x55888eb2cea2 in Py_Main (argc=, argv=0x7ffd0ab2f888) 
> at ../Modules/main.c:592
> #19 0x7fb674bc209b in __libc_start_main (main=0x55888eb2ca90 , 
> argc=5, argv=0x7ffd0ab2f888, init=, fini=, 
> rtld_fini=, stack_end=0x7ffd0ab2f878) at 
> ../csu/libc-start.c:308
> #20 0x55888eb2c9ca in _start () at ../Modules/gcmodule.c:1003
> 

Bug#927785: pyparted: FTBFS randomly (Floating point exception)

[Herbert Fortes]

Hi,

Thanks Santiago and Bernhard!

On 4/23/19 6:35 AM, Bernhard Übelacker wrote:
> Dear Maintainer,
> I just tried to find some more information.
> 
> I could reproduce the issue in a unstable amd64 VM
> on the second attempt.
> 
> It looks like in a garbage collector run a
> division by zero is triggered because we
> get there with sector_size==0.
> 
> If wanted I can forward the core file.

It is a good idea.

I read the debugging.txt file. divisor 0 is there.
The message is better now:

"Program terminated with signal SIGFPE, Arithmetic exception."

I can nothing about it. Just send a report to upstream.



Regards,
Herbert

> 
> Kind regards,
> Bernhard
> 
> 
> 
> 1708gpt_alloc_metadata (PedDisk *disk)
> 1709{
> ...
> 1718  gptlength = ped_div_round_up (sizeof (GuidPartitionTableHeader_t),
> 1719disk->dev->sector_size);
> 
> 
> (gdb) bt
> #0  0x7fb67449e727 in ped_div_round_up (divisor=0, numerator=100) at 
> ../../../include/parted/natmath.h:130
> #1  gpt_alloc_metadata (disk=0x558890efb060) at 
> ../../../libparted/labels/gpt.c:1718
> #2  0x7fb67448851a in _disk_alloc_metadata (disk=0x558890efb060) at 
> ../../libparted/disk.c:1164
> #3  _disk_pop_update_mode (disk=0x558890efb060) at ../../libparted/disk.c:1164
> #4  0x7fb6744890b2 in ped_disk_delete_all 
> (disk=disk@entry=0x558890efb060) at ../../libparted/disk.c:2104
> #5  0x7fb67449dd59 in gpt_free (disk=0x558890efb060) at 
> ../../../libparted/labels/gpt.c:622
> #6  0x7fb674abee82 in ?? ()
> #7  0x7fb673c46348 in ?? ()
> #8  0x55888eb4b67b in dict_dealloc (mp=0x7fb673c46280) at 
> ../Objects/dictobject.c:1086
> #9  0x55888ebf8339 in subtype_clear (self= 0x7fb673bbaa10>) at ../Objects/typeobject.c:912
> #10 0x55888eb3860c in delete_garbage (old=0x55888eda25b0 
> , collectable=0x7ffd0ab2f4e0) at 
> ../Modules/gcmodule.c:817
> #11 collect (generation=2) at ../Modules/gcmodule.c:981
> #12 0x55888eb9fcaa in PyGC_Collect () at ../Modules/gcmodule.c:1439
> #13 0x55888eb9ef44 in Py_Finalize () at ../Python/pythonrun.c:455
> #14 0x55888ebc92c8 in Py_Exit (sts=0) at ../Python/pythonrun.c:1795
> #15 0x55888ebc6a8d in handle_system_exit () at ../Python/pythonrun.c:1160
> #16 0x55888ebc63b6 in PyErr_PrintEx (set_sys_last_vars=, 
> set_sys_last_vars=) at ../Python/pythonrun.c:1170
> #17 0x55888ebc527d in RunModule (module=, 
> set_argv0=) at ../Modules/main.c:199
> #18 0x55888eb2cea2 in Py_Main (argc=, argv=0x7ffd0ab2f888) 
> at ../Modules/main.c:592
> #19 0x7fb674bc209b in __libc_start_main (main=0x55888eb2ca90 , 
> argc=5, argv=0x7ffd0ab2f888, init=, fini=, 
> rtld_fini=, stack_end=0x7ffd0ab2f878) at 
> ../csu/libc-start.c:308
> #20 0x55888eb2c9ca in _start () at ../Modules/gcmodule.c:1003
> 

Bug#927143: [Pkg-phototools-devel] Bug#927143: libgphoto2 2.5.22

[Herbert Fortes]

On 4/15/19 10:53 AM, Ole Aamot wrote:
> Package: libgphoto2
> Version: 2.5.22
> 
> I don't follow development these days, but I see that version 2.5.22 is 
> available from http://www.gphoto.org/
> 
> Best,
> Ole
> 
[copy what was sent to pkg-phototools-de...@alioth-lists.debian.net]

libgphoto2 (lib) Debian package in Buster and Sid is 2.5.22-3.
https://github.com/gphoto/libgphoto2/releases

The gphoto2 (command line tool) Debian package is 2.5.20-3. It
is the last release: https://github.com/gphoto/gphoto2/releases

They have different versions. Different repositories:
https://github.com/gphoto/

What is the intent of the bug report?



Regards,
Herbert

Bug#926940: unblock: watson/1.6.0-6

[Herbert Fortes]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package watson[0]

Version 1.6.0-6 fixes one Build-Depends and one upstream
test. It is a good fix for reproducibility[1]. The package
is "13 days old (2 needed)"

[0] - https://tracker.debian.org/pkg/watson
[1] - https://tests.reproducible-builds.org/debian/rb-pkg/watson.html


The fix in watson/tests/test_watson.py file is:

-@pytest.mark.datafiles(
-TEST_FIXTURE_DIR / 'frames-with-conflict',
-)
-def test_merge_report(watson, datafiles):
+#@pytest.mark.datafiles(
+#TEST_FIXTURE_DIR / 'frames-with-conflict',
+#)
+def test_merge_report(watson):  # , datafiles):
 # Get report
 watson.frames.add('foo', 4000, 4015, id='1', updated_at=4015)
 watson.frames.add('bar', 4020, 4045, id='2', updated_at=4045)
 
 conflicting, merging = watson.merge_report(
-str(datafiles) + '/frames-with-conflict')
+TEST_FIXTURE_DIR + '/frames-with-conflict')
 

Attached you will find the 'debdiff watson_1.6.0-5.dsc watson_1.6.0-6.dsc'
compressed file.



Regards,
Herbert


watson_deb_revision_5_to_6.debdiff.gz
Description: application/gzip

Bug#908879: pyparted: FTBFS randomly (ImportError: No module named _ped)

[Herbert Fortes]

fixed 908879 3.11.2-3
thanks

I am fixing what I did. It is registered that a fix was done by
skipping (empty override) the tests.

The fix for 'No module named _ped' was in version 3.11.2-3 when
a patch[0] from Steve Langasek added the deps to build the _ped 
module. Here is the debian/changelog[1]:

[0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922081
[1] - https://tracker.debian.org/media/packages/p/pyparted/changelog-3.11.2-10

In version 3.11.2-4 I tried to run tests for py3 only but forgot to
fix the search ('find') for the specific file ('*gnu.so'). Because of 
that this[2] happened multiple times:

File "/usr/lib/python3.7/unittest/loader.py", line 436, in _find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python3.7/unittest/loader.py", line 377, in 
_get_module_from_name
__import__(name)
  File "/<>/tests/test__ped_alignment.py", line 22, in 
import _ped
ImportError: /<>/.pybuild/cpython2_2.7_parted/build/_ped.so: 
undefined symbol: _Py_ZeroStruct

[2] - 
https://buildd.debian.org/status/fetch.php?pkg=pyparted=ia64=3.11.2-5=1550014323=0


I removed the wrong override in version 3.11.2-7. debhelper does a better
job doing a 'cd build dir'; 'pyX unittest discover'.

The problem now seems to be mainly in armhf (unitl now). There is a 
'Floating point exception'[3]:

[...]
runTest (tests.test_parted_disk.DiskUnsetFlagTestCase) ... ok

--
Ran 273 tests in 1.568s

OK (skipped=118)

/bin/sh: line 1: 26652 Floating point exceptionpython2.7 -m unittest discover -v

[3] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pyparted.html


obs:
./src/parted/device.py:264:return long(math.floor((float(sector) / 
(heads * sectors)) + 1))
./src/parted/device.py:271:return long(math.ceil(float((sector + 1)) / 
(heads * sectors)))
./src/parted/device.py:299:size = float(self.__device.length)

src/pytimer.c has float() - 222, 298

https://docs.python.org/2/library/decimal.html?highlight=floating



Regards,
Herbert

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

Hi,

> The last try is here:
> 
> mips,  mips64el and  mipsel are important
> for release and they fail.
> 

The test I skip for these archs has this first
assert:

self.assertGreater(len(parted.getLabels()), 0)

The __init__.py file inside parted has:

def getLabels(arch=None):
[...]
for label, regex in __archLabels:
if re.match(regex, arch):
labels.add(label)

return labels


__archLabels is a tuple without mips*. I think this is
why test fails.

https://sources.debian.org/src/pyparted/3.11.2-9/src/parted/__init__.py/#L362

Can you give me your opinion on that?



Regards,
Herbert

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

On 2/26/19 7:55 AM, Herbert Fortes wrote:
> On 2/26/19 6:07 AM, Steve Langasek wrote:
>> On Mon, Feb 25, 2019 at 01:43:03PM -0300, Herbert Fortes wrote:
>>> On Wed, 20 Feb 2019 17:37:35 -0300 Herbert Fortes  wrote:
>>

>> It looks like this build has passed now:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyparted.html
>>
>> Are you happy to close this bug?
>>
> 
> Honestly not yet.
> 
> There are two patches that I have to remove. One I am
> confidence to do so.
> 
> 
> armhf failed, but I think it is not the problem we treat
> here.
> 
> arm64 and i386 still missing.
> 
> kFreebsd and Hurd have problems. But it is ok.
> 
> I will upload a revision without one patch and Debian CI
> like debhelper does.
> 
> Don't worry. At the end everything will be fine.
> 

The last try is here:

mips,  mips64el and  mipsel are important
for release and they fail.

https://buildd.debian.org/status/package.php?p=pyparted=sid

E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_parted/build; python2.7 -m unittest 
discover -v 

exit code=1

They are similar error message that happens to amrhf in
reproducible-builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pyparted.html

E: pybuild pybuild:338: test: plugin distutils failed with: exit code=134: cd 
/build/pyparted-3.11.2/2nd/.pybuild/cpython2_2.7_parted/build; python2.7 -m 
unittest discover -v 

exit code=134

For release, 4 architectures still in 'needs-build'.

I was honestly confidence for  this one, but I will put back 
the patch I removed ( skip_0gt0.patch file). Let's not make 
this a big thing.

My wild-guess is that the env is not appropriated to parted.

I will talk to upstream about the 'find' anyway.

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

On 2/26/19 6:07 AM, Steve Langasek wrote:
> On Mon, Feb 25, 2019 at 01:43:03PM -0300, Herbert Fortes wrote:
>> On Wed, 20 Feb 2019 17:37:35 -0300 Herbert Fortes  wrote:
> 
>>> On 2/20/19 1:55 PM, Steve Langasek wrote:
>>>> Package: pyparted
>>>> Version: 3.11.2-6
>>>> Followup-For: Bug #922081
>>>> User: ubuntu-de...@lists.ubuntu.com
>>>> Usertags: origin-ubuntu disco ubuntu-patch
> 
>>>> I think the remaining issue is entirely a bug in the debian/rules
> 
>> When I try to build the package in a VM, I have no problems.
> 
>> When I try  to build the package in a 'chroot' it is not possible to build
>> the package.  No matter what.
> 
>> Debian CI have no problem, I will not touch it.
> 
>> I will upload a revision without the override:
> 
>>  - If reproducible-build does not complain.  Everybody is happy.
> 
>>  - If one test fails in reproducible-builds like here.
>>    It is only one more test to skip. Everybody is happy.
> 
> It looks like this build has passed now:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pyparted.html
> 
> Are you happy to close this bug?
> 

Honestly not yet.

There are two patches that I have to remove. One I am
confidence to do so.


armhf failed, but I think it is not the problem we treat
here.

arm64 and i386 still missing.

kFreebsd and Hurd have problems. But it is ok.

I will upload a revision without one patch and Debian CI
like debhelper does.

Don't worry. At the end everything will be fine.

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

Hi,


On Wed, 20 Feb 2019 17:37:35 -0300 Herbert Fortes  wrote:

> On 2/20/19 1:55 PM, Steve Langasek wrote:
> > Package: pyparted
> > Version: 3.11.2-6
> > Followup-For: Bug #922081
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu disco ubuntu-patch
> >
> > I think the remaining issue is entirely a bug in the debian/rules


When I try to build the package in a VM, I have no

problems.


When I try  to build the package in a 'chroot' it

is not possible to build the package. No matter what.


Debian CI have no problem, I will not touch it.


I will upload a revision without the override:

 

 - If reproducible-build does not complain. Everybody

   is happy.

 - If one test fails in reproducible-builds like here.

   It is only one more test to skip. Everybody is happy.




Regards,

Herbert

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

On 2/20/19 1:55 PM, Steve Langasek wrote:
> Package: pyparted
> Version: 3.11.2-6
> Followup-For: Bug #922081
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu disco ubuntu-patch
> 
> I think the remaining issue is entirely a bug in the debian/rules
> override_dh_auto_test rule.  When I dropped this override entirely in
> Ubuntu, the package builds fine.

The problem is reproducible-builds. Did you see the log? The
tests have a random problem.

> 
> The bug is that this override tries to use 'find | head', and expects that
> the result returned is the right directory for use when running the test
> suite under python3.  But the order in which results are returned from find
> is undefined, and likely filesystem-dependent; so on the builders for some
> architectures, it returns the python2.7 build instead of the python3 build.

I copy and paste from Makefile the 'find | head'.

Please, see this CI log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pyparted/1918396/log.gz

But it is true that it tries to use _ped.so from Python 2. The random
behavior can be from find. I put an find for each version. And got one 
more assertGreater error.

==
FAIL: runTest (tests.test__ped_ped.DeviceGetNextTestCase)
--
Traceback (most recent call last):
  File "/home/pyparted-3.11.2/tests/test__ped_ped.py", line 210, in runTest
self.assertGreater(len(lst), 0)
AssertionError: 0 not greater than 0

--

Only remove the override does not work. I tried now. I also tried a build 
for one Python version with an override with a find for it only.
./.pybuild/cpython2_2.7_parted/

AssertionError

version 3.11.2-3 has only the patch you sent. I did not work for everybody.

You can check upstream Makefile.



Regards,
Herbert

Bug#922402: lintian: False positive: pkg-config-references-unknown-shared-library

[Herbert Fortes]

Package: lintian
Version: 2.7.0
Severity: normal


I got these warnings:

W: libgphoto2-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libgphoto2.pc -lm (line 14)
W: libgphoto2-dev: pkg-config-references-unknown-shared-library 
usr/lib/x86_64-linux-gnu/pkgconfig/libgphoto2_port.pc -lm (line 12)

'libm.so' is shipped in libc6-dev.

Thanks Andreas at debian-mentors.



Regards,
Herbert

Bug#922379: [Pkg-phototools-devel] Bug#922379: libgphoto2: shuts down Sony cameras upon initialization

[Herbert Fortes]

Hi Ferenc,

> Source: libgphoto2
> Version: 2.5.22-2
> Severity: important
> Tags: upstream patch
> 
> Dear Maintainer,
> 
> I successfully used gvfs-gphoto2-volume-monitor to download photos from
> my Sony Alpha 5000 under jessie, but libgphoto2 broke for that camera in
> stretch (I don't know the exact version).  This regression has just been
> fixed upstream in commit f1e3b5ae8f9d8258db9a19861749b2bb6ad57b1e.  The
> patch applies cleanly to 2.5.22 and fixes the issue for me; judging by
> the issues referenced in the commit other users are affected as well.
> Please include this fix in buster if at all possible!  Having a 2.5.23
> would be best of course, but I've got no idea when that will happen.
> A quilt patch would still have a chance to reach buster, though.
> 

At least 3 tickets:
https://github.com/gphoto/libgphoto2/commit/f1e3b5ae8f9d8258db9a19861749b2bb6ad57b1e

I will see that. Thanks!



Regards,
Herbert

Bug#908879: pyparted: FTBFS randomly (ImportError: No module named _ped)

[Herbert Fortes]

Hi Santiago,

On 2/13/19 2:28 PM, Santiago Vila wrote:
> found 908879 3.11.1-12
> thanks
> 
> Sorry for the reopening but this problem is here again.
> I've put a bunch of build logs here:
> 
> https://people.debian.org/~sanvila/build-logs/pyparted/
> 
> and this problem also happens (randomly) in reproducible-builds:
> 
> https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/pyparted_3.11.2-5.rbuild.log.gz
> 
> If you need a test machine where this happens, please contact me
> privately and I will gladly provide one.
> 

No problem. It was expected. I had this
'undefined symbol: _Py_ZeroStruct' error
here in my notebook. But I decided to 
confirm doing the upload.

I received a bugreport with a patch and
asking to enable build-time tests again.

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




Regards,
Herbert

Bug#922081: fixed in pyparted 3.11.2-3

[Herbert Fortes]

Hi Steve,


THe build has some problems with Python 2.7:


  - armhf 


-mips 



  - mips64el 


- mipsel not tried yet


  - hppa 


-hurd-i386 


-riscv64 



https://buildd.debian.org/status/package.php?p=pyparted


I am going home to see this.


The patch in Debian package seems right:

--- pyparted.orig/tests/test__ped_ped.py
+++ pyparted/tests/test__ped_ped.py
@@ -48,7 +48,7 @@ class PartitionFlagGetNameTestCase(unitt
 self.assertNotEqual(_ped.partition_flag_get_name(attr), "", "Could 
not get name for flag _ped.%s" % f)
 
 self.assertRaises(ValueError, _ped.partition_flag_get_name, -1)
-    self.assertRaises(ValueError, _ped.partition_flag_get_name, 1000)
+    self.assertRaises(_ped.PartedException, _ped.partition_flag_get_name, 
1000)
 
 class PartitionFlagGetByNameTestCase(unittest.TestCase):
 def runTest(self):
@@ -82,7 +82,7 @@ class DiskFlagGetNameTestCase(unittest.T
 self.assertNotEqual(_ped.disk_flag_get_name(f), "", "Could not get 
name for flag %s" % f)
 
 self.assertRaises(ValueError, _ped.disk_flag_get_name, -1)
-    self.assertRaises(ValueError, _ped.disk_flag_get_name, 1000)
+    self.assertRaises(_ped.PartedException, _ped.disk_flag_get_name, 1000)
 
 class DiskFlagGetByNameTestCase(unittest.TestCase):
 def runTest(self):

-ValueError

+_ped.PartedException


And complete remove unknow_parttition_flag.patch.


Did you run tests against Python2.7?




Regards,

Herbert










http://incoming.debian.org/debian-buildd/pool/main/p/pyparted/

Bug#922081: pyparted: Please enable build-time tests in pyparted

[Herbert Fortes]

On 2/11/19 6:45 PM, Steve Langasek wrote:
> Package: pyparted
> Version: 3.11.2-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu disco ubuntu-patch
> 
> Dear Herbert,
> 
> In Ubuntu, we have applied the attached patch to pyparted in order to enable
> build-time tests of the package.  It appears you have similarly tried to fix
> the tests with one of your distro patches, however the dh_auto_test target
> is still empty in your package and no tests are run, so perhaps this work
> was incomplete?
> 
> With the attached patch, the tests run and pass on all Ubuntu architectures. 
> I notice that you had skipped some of the tests as "failing on some
> architectures", but I assume that the build-dependency fixes are sufficient
> to let the tests pass on all other Debian architectures as well.
> 
> Hope that helps,
> 

Big thanks Steve and Łukasz!

Uploaded.



Regards,
Herbert

Bug#922027: python-django: Django security release

[Herbert Fortes]

On Mon, 11 Feb 2019 10:15:54 -0200 Herbert Fortes  wrote:

> Package: python-django
> Version: Django 2.2, 1.11
> Severity: normal
>
>
> CVE-2019-6975: Memory exhaustion in django.utils.numberformat.format()
>
> If django.utils.numberformat.format() -- used by contrib.admin as well as the 
> the floatformat, filesizeformat, and intcomma templates filters -- received a 
> Decimal with a large number of digits or a large exponent, it could lead to 
> significant memory usage due to a call to '{:f}'.format().
>
> To avoid this, decimals with more than 200 digits are now formatted using 
> scientific notation.
>
> Thanks Sjoerd Job Postmus for reporting this issue.
> Affected supported versions
>
>     Django master branch
>     Django 2.2 (which will be released in a separate blog post later today)
>     Django 2.1
>     Django 2.0
>     Django 1.11
>
> Per our supported versions policy, Django 1.10 and older are no longer 
> supported.
>
> https://www.djangoproject.com/weblog/2019/feb/11/security-releases/

>


  Broken django 1.11.19 release for python2.7


It looks like the distributed django 1.11.19 release does not match the code in 
1.11.19 tag.

Component:  Uncategorized → Core (Other)
Triage Stage:   Unreviewed → Accepted
Type:   Uncategorized → Bug


https://code.djangoproject.com/ticket/30175

Bug#922027: python-django: Django security release

[Herbert Fortes]

Package: python-django
Version: Django 2.2, 1.11
Severity: normal


CVE-2019-6975: Memory exhaustion in django.utils.numberformat.format()

If django.utils.numberformat.format() -- used by contrib.admin as well as the 
the floatformat, filesizeformat, and intcomma templates filters -- received a 
Decimal with a large number of digits or a large exponent, it could lead to 
significant memory usage due to a call to '{:f}'.format().

To avoid this, decimals with more than 200 digits are now formatted using 
scientific notation.

Thanks Sjoerd Job Postmus for reporting this issue.
Affected supported versions

    Django master branch
    Django 2.2 (which will be released in a separate blog post later today)
    Django 2.1
    Django 2.0
    Django 1.11

Per our supported versions policy, Django 1.10 and older are no longer 
supported.

https://www.djangoproject.com/weblog/2019/feb/11/security-releases/




Regards,

Herbert

Bug#787603: [src:genshi] Some sources are not included in your package

[Herbert Fortes]

>
> In order to solve this problem, you could:
> 1. repack the origin tarball adding the missing source to it.
> 2 add the source files to "debian/missing-sources" directory
>


I will add the tarball.

892K jquery-1.1.4.tar.gz




Regards,

Herbert

Bug#920218: RFS: webcamoid/8.5.0+dfsg-1

[Herbert Fortes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "webcamoid".
  It is a upload to experimental. To test the new .symbols
  file, install via apt and run the software. My key is
  not in the archive yet.

  The new release closes two important bugs:

  https://github.com/webcamoid/webcamoid/issues/142
  https://github.com/webcamoid/webcamoid/issues/108



 * Package name: webcamoid
   Version : 8.5.0+dfsg-1
   Upstream Author : Gonzalo Exequiel Pedone 
 * URL : https://github.com/webcamoid/webcamoid
 * License : GNU General Public License v3.0
   Section : video

  It builds those binary packages:

akqml - full featured webcam capture application - qml module
libavkys-dev - full featured webcam capture application - dev
libavkys8  - full featured webcam capture application - library
webcamoid  - full featured webcam capture application
webcamoid-data - icons and locale files for webcamoid
webcamoid-plugins - full featured webcam capture application - plugins

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/w/webcamoid/webcamoid_8.5.0+dfsg-1.dsc

  More information about webcamoid can be obtained from 
https://github.com/webcamoid/webcamoid.

  Changes since the last upload:

  * New upstream version 8.5.0+dfsg
  * debian/control:
  - Update Build-Depends and Webcamoid pkg Depends
  - Bump Standards-Version from 4.2.1 to 4.3.0
  * debian/copyright:
  - Update year for myself and upstream
  * debian/clean:
  - Remove libAkQml.so file
  * debian/gbp.conf:
  - Remove sign-tags
  * debian/watch:
  - Add repacksuffix,repack,compression to opts
  - dversionmangle: remove number 1 from +dfsg
  * debian/patches:
  - Remove upstream patches
  - Add patch for .desktop file
  * Add new .symbols file
  * debian/webcamoid-data.install:
  - StandAlone does not have .json and effects.xml files



Regards,
Herbert

Bug#918580: RFS: libgphoto2/2.5.22-1

[Herbert Fortes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "libgphoto2" as I
  am without my key and no access to Salsa

 * Package name: libgphoto2
   Version : 2.5.22-1
   Upstream Author : Marcus Meissner and others
 * URL : https://github.com/gphoto/libgphoto2/
 * License : LGPL-2+
   Section : libs

  It builds those binary packages:

libgphoto2-6 - gphoto2 digital camera library
libgphoto2-dev - gphoto2 digital camera library (development files)
libgphoto2-dev-doc - gphoto2 digital camera library (development 
documentation)
libgphoto2-l10n - gphoto2 digital camera library - localized messages
libgphoto2-port12 - gphoto2 digital camera port library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/libg/libgphoto2/libgphoto2_2.5.22-1.dsc

  
  Changes since the last upload:


   * New upstream version 2.5.22
   * debian/control:
   - Bump Standards-Version from 4.2.1 to 4.3.0
   * debian/copyright:
  - Update year for myself
   * debian/watch:
  - sf.net only

It is a bugfix release.



Regards,
Herbert

Bug#918571: RFS: python-gphoto2/1.9.0-1

[Herbert Fortes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "python-gphoto2" as
  I am without my key and access to Salsa

 * Package name: python-gphoto2
   Version : 1.9.0-1
   Upstream Author : Jim Easterbrook 
 * URL : https://github.com/jim-easterbrook/python-gphoto2
 * License : GPL-3+
   Section : python

  It builds those binary packages:

python-gphoto2-doc - Python interface to libgphoto2 (common documentation)
python3-gphoto2 - Python interface to libgphoto2 (Python 3)

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

  https://mentors.debian.net/package/python-gphoto2


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/python-gphoto2/python-gphoto2_1.9.0-1.dsc

  More information about python-gphoto2 can be obtained from 
https://www.example.com.

  Changes since the last upload:

  * New upstream version 1.9.0
  * debian/control:
  - Bump Standards-Version from 4.2.1 to .4.3.0
  * debian/copyright:
  - Update year for myself



Regards,
Herbert

Bug#913363: RFS: desktopfolder/1.0.10-1 [ITP]

[Herbert Fortes]

On 07/12/2018 08:10, foss.freedom wrote:

It has been about a month since the initial package was uploaded to
mentors.  Still hoping for some feedback please.

Yesterday I've tweaked the package to remove an unnecessary
build-dependency after discussing with upstream.

I note one new "Information" lintian issue now occurs since the
initial upload.  Probably due to a slight tweak to the current debian
policy?

public-upstream-key-not-minimal
upstream/signing-key.asc has 1 extra signature(s) for keyid 92DED901DA15CC0D

Is this something I can deal with (if so how?) - or should I ask
upstream to create a signing-key.asc  for me using "gpg --armor
--export --export-options export-minimal,export-clean keyid"



The lintian tag is severity wishlist. But it is
good to save space in the archive.

"The package contains a public upstream signing key..."

The uscan man page says:

[...]
The armored keyring file debian/upstream/signing-key.asc can
be created by using the gpg (or gpg2) command as follows.
[...]

Did up try to run the command and see if there is any problem?

These would be my steps.

Bug#915041: does not create a subcommand '[test_without_migrations]'

[Herbert Fortes]

The package works. I forgot to declare it in

the settings.py file.


But it is a module to use when developping a

Django project. When one should use a virtual

env and 'pip'.


And the package has this lintian that I did a

*-overrides (severity: normal):

 - package-contains-python-tests-in-global-namespace

Bug#911711: svgwrite FTBFS: tests fail

[Herbert Fortes]

Hi,


Package uploaded to "directory: /pub/UploadQueue/DELAYED/4-day)"


debian/changelog file:

 svgwrite (1.2.1-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream version 1.2.1
 (Closes: #911711, #912155)
 .
   [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
   * d/control: Remove ancient X-Python-Version field
   * d/control: Remove ancient X-Python3-Version field
 .
   [ Herbert Parentes Fortes Neto ]
   * debian/control:
   - Remove version number for python-all
   * debian/copyright:
   - Update
   * debian/rules:
   - dh_installdocs -XLINCESE.TXT
   * debian/tests:
   - Add CI test - upstream test
   * debian/watch:
   - Github repository
 .
   [ David "foss.freedom" ]
   * DH_LEVEL: 11
   * debian/control:
   - Bump Standards-Version from 3.9.8 to 4.2.1
   * debian/python-svgwrite.docs:
   - Remove obsolete PKG-INFO




Regards,

Herbert

Bug#911711: svgwrite FTBFS: tests fail

[Herbert Fortes]

Hi,


I plan to work on this ticket[0] on

the weekend.


[0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911711




Regards,

Herbert

Bug#913261: RFS: chkboot/1.2-1 [ITP]

[Herbert Fortes]

On 21/11/2018 13:31, Baptiste BEAUPLAT wrote:

Hello Herbert,

I hope you are well.

I was wondering if you had time to take a second look at this package?



No.

I had to improve the Debian CI tests for some
of the packages I take care.

Anyone can take of that package if necessary.
I can not do it right now.



Regards,
Herbert

Bug#911711: svgwrite FTBFS: tests fail

[Herbert Fortes]

On Mon, 12 Nov 2018 23:06:30 + "foss.freedom"  
wrote:
> I can confirm that v1.2.0 that has been released a few weeks ago
> compiles just fine.
>
> If it helps I've created a debdiff for the changes between 1.1.8-2 and
> 1.2.0 - a few tweaks to the debian package is additionally required
> onto of the source diff.
>
> Note - I havent adjusted the obsolete vcs locations in debian/control
>


I can help with that.


I need to know what

 * *maintainer:* Debian Python Modules Team 
 
(archive ) [DMD 
]
 * *uploaders:* Steffen Moeller 
 [DMD 
]

wants to do.


I will wait until last week of November, 26/11 - monday.




Regards,

Herbert

Bug#913261: RFS: chkboot/1.2-1 [ITP]

[Herbert Fortes]

Hi,
On 08/11/2018 17:30, Baptiste BEAUPLAT wrote:

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

   Dear mentors,

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


The package does not build twice in a row:

dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building chkboot using existing ./chkboot_1.2.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: local changes detected, the modified files are:
 chkboot-1.2/man/chkboot-check.8
 chkboot-1.2/man/chkboot-desktopalert.8
 chkboot-1.2/man/chkboot.8
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/chkboot_1.2-1.diff.PNYbwP

Please clean these files.



Regards,
Herbert





  * Package name: chkboot
Version : 1.2-1
Upstream Author : Giancarlo Razzolini 
  * URL : https://github.com/grazzolini/chkboot
  * License : GPL-2.0+
Section : utils

   It builds those binary packages:

 chkboot- detection of malicious changes for boot files

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/c/chkboot/chkboot_1.2-1.dsc

   This is the first release of the package.

   Debian source is hosted on salsa, at:

 https://salsa.debian.org/debian/chkboot

   Regards,
 Baptiste BEAUPLAT - lyknode

-BEGIN PGP SIGNATURE-

iIcEARYIAC8WIQQt4kiVMTxdp/CJ4U4XSUsQeV3XMwUCW+SOxhEcbHlrbm9kZUBj
aWxnLm9yZwAKCRAXSUsQeV3XM9WlAP93vo64ZSAwvMJ0cnxLBPMTUFGmgipjC6uJ
9rdGnmkKagD9GSoBOM674HGZ2kRlmEncJ6mLS0FKUdqXnc2hShdPRw4=
=nA8y
-END PGP SIGNATURE-

Bug#912367: stretch-pu: package gthumb/3:3.4.4.1-5

[Herbert Fortes]

On 31/10/2018 05:32, Salvatore Bonaccorso wrote:

Hi Herbert,

[Dislcaimer: not SRM here, but only commenting on small issue below]

On Tue, Oct 30, 2018 at 03:31:27PM -0300, Herbert Parentes Fortes Neto wrote:

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I made Gthumb Debian package version 3:3.4.4.1-6+deb9u1


The version should actually be 3:3.4.4.1-*5*+deb9u1 given the last
version in stretch is 3:3.4.4.1-5.

Regards,
Salvatore



Thanks Salvatore!

Updated and a new file is attached:

 - gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz



Regards,
Herbert


gthumb_3.4.4.1-5_3.4.4.1-5+deb9u1.diff.gz
Description: application/gzip

Bug#908629: RFS: biometric-authentication/0.9.55-1 [ITP]

[Herbert Fortes]

>
> Another lintian:
>
> I: libbiometric0: symbols-file-missing-build-depends-package-field
>
>
> It is a whislist and I do not know how to fix it. But
>
> the version in it is not 0.9.56. The version that will
>
> be in Debian. Please redo the file.
>
>


As an information, lintian stops with:

libbiometric.so.0 libbiometric0 #MINVER#
* Build-Depends-Package: libbiometric-dev
 bio_base64_decode@Base 0.9.56
 bio_base64_encode@Base 0.9.56
 bio_check_app_api_version@Base 0.9.56
[...]


But I am not 100% sure. I do not have

this knowledge.


To do a symbols file: https://wiki.debian.org/UsingSymbolsFiles




Regards,

Herbert

Bug#908629: RFS: biometric-authentication/0.9.55-1 [ITP]

[Herbert Fortes]

Hi,

On Wed, 12 Sep 2018 10:54:44 +0800 handsome_feng  
wrote:

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "biometric-authentication"

About these lintians:

I: libbiometric0: hardening-no-bindnow 
usr/lib/x86_64-linux-gnu/libbiometric.so.0.0.0
I: libbiometric0: symbols-file-missing-build-depends-package-field
I: biometric-auth: hardening-no-bindnow 
usr/lib/biometric-authentication/biometric-authenticationd

Please, in debian/rules:

-# See debhelper(7) (uncomment to enable)
-# output every command that modifies files on the build system.
-#DH_VERBOSE = 1

DH_VERBOSE = 1


-# see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/*
-DPKG_EXPORT_BUILDFLAGS = 1
-include /usr/share/dpkg/default.mk

-# see FEATURE AREAS in dpkg-buildflags(1)
-#export DEB_BUILD_MAINT_OPTIONS = hardening=+all

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

-# see ENVIRONMENT in dpkg-buildflags(1)
-# package maintainers to append CFLAGS
-#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
-# package maintainers to append LDFLAGS
-#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed


Another lintian:

I: libbiometric0: symbols-file-missing-build-depends-package-field


It is a whislist and I do not know how to fix it. But

the version in it is not 0.9.56. The version that will

be in Debian. Please redo the file.


debian/copyright fiel does not seems right. The way it

is everything belongs to:

- Copyright: 2018, jianglinxuan 


But your name is in debian changelog and control(as uploader)

files.


The copyright headers says:

* Copyright (C) 2018 Tianjin KYLIN Information Technology Co., Ltd.

* Author: Droiing 


At least two entries in debian/copyright:

Files: *

Copyright: Tianjin etc

Comment: author Doiing email

License:


Files: debian/*

Copyright: 2018 you email

License:




Regards,

Herbert


> * Package name : biometric-authentication
> Version : 0.9.55-1
> Upstream Author : jianglinxuan 
> * URL : https://salsa.debian.org/kylin-team/biometric-
> authentication
> * License : LGPL-3+
> Section : admin
>
> It builds those binary packages:
>
> biometric-auth - Biometric Authentication Service
> biometric-driver-community-multidevice - Biometric Authentication Driver
> (community multidevice)
> biometric-utils - Biometric authentication utils
> libbiometric-dev - Biometric Identification DRIVER API - development files
> libbiometric0 - Biometric Identification library
>
> To access further information about this package, please visit the following
> URL:
>
> https://mentors.debian.net/package/biometric-authentication
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x https://mentors.debian.net/debian/pool/main/b/biometric-
> authentication/biometric-authentication_0.9.55-1.dsc
>
> More information about this can be obtained from https://github.com/ukui.
>
>
> Regards,
> handsome_feng
>
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.17.0-3-amd64 (SMP w/2 CPU cores)
> Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN:zh (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

Bug#911867: RFS: frr/6.0.1-1 [ITP]

[Herbert Fortes]

Hi,

On 10/25/18 3:17 PM, David Lamparter wrote:


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

  * Package name: frr
Version : 6.0.1-1
Upstream Author : FRRouting-dev 
  * URL : https://frrouting.org/
  * License : GPLv2 and LGPLv2.1
Section : net

This replaces the "quagga" package, which FRRouting is a fork of.

It builds those binary packages:

   frr   - BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon forked from Quagga
   frr-dbg- BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon (debug symbols)
   frr-doc- BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon (documentation)
   frr-pythontools - BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon (Python 
Tools)
   frr-rpki-rtrlib - FRRouting RTRlib RPKI support
   frr-snmp   - FRRouting SNMP support

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

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


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

   dget -x https://mentors.debian.net/debian/pool/main/f/frr/frr_6.0.1-1.dsc

More information about frr can be obtained from https://frrouting.org

Changes since the last upload is not applicable since this is the first
upload.

I expect there still is feedback that I need to address in regards to
the Debian packaging on this and I will likely be uploading further
revisions in the coming days.



I did not build the package. My comment:

There are many lintian info warnings that can be fixed easily:


I no-symbols-control-file
usr/lib/x86_64-linux-gnu/libfrrospfapiclient.so.0.0.0
usr/lib/x86_64-linux-gnu/libfrr.so.0.0.0

https://wiki.debian.org/UsingSymbolsFiles


I possible-documentation-but-no-doc-base-registration
I spelling-error-in-binary  # a lot
I spelling-error-in-manpage  # a lot

I systemd-service-file-missing-documentation-key
lib/systemd/system/frr.service
O package-name-doesnt-match-sonames
libfrr0 libfrrospfapiclient0 (override comment: libfrr* are for 
internal use only and do not provide a stable API or ABI. soname / library 
versioning is irrelevant and they must always be shipped exact-matching to the 
daemons compiled against it)

  It is a package name. That's all.
  The lib can not be trusted?


O systemd-service-file-refers-to-unusual-wantedby-target
lib/systemd/system/frr.service network-online.target (override comment: 
we're a bit special since we provide network connectivity by starting up 
routing protocols.)
X duplicate-files
usr/share/doc/frr/examples/pbrd.conf.sample 
usr/share/doc/frr/examples/staticd.conf.sample

frr-rpki-rtrlib

I extended-description-is-probably-too-short
I hardening-no-fortify-functions
usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so

frr source

I debian-control-has-obsolete-dbg-package
frr-dbg
I duplicate-long-description
frr-doc frr-pythontools
I ored-build-depends-on-obsolete-package
build-depends: dh-systemd  => use debhelper (>= 
9.20160709)
P debian-watch-does-not-check-gpg-signature
P package-uses-old-debhelper-compat-version
9

There is a problem with version 11?
 
O alternatively-build-depends-on-python-sphinx-and-python3-sphinx

(override comment: these are for build-compatibility on older distros 
(e.g. Ubuntu 14.04))

It is a new package. It is preferable to not upload Python 2
X upstream-metadata-file-is-missing

Bug#911867: RFS: frr/6.0.1-1 [ITP]

[Herbert Fortes]

Hi,

On 10/25/18 3:17 PM, David Lamparter wrote:


Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

  * Package name: frr
Version : 6.0.1-1
Upstream Author : FRRouting-dev 
  * URL : https://frrouting.org/
  * License : GPLv2 and LGPLv2.1
Section : net

This replaces the "quagga" package, which FRRouting is a fork of.

It builds those binary packages:

   frr   - BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon forked from Quagga
   frr-dbg- BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon (debug symbols)
   frr-doc- BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon (documentation)
   frr-pythontools - BGP/OSPF/RIP/RIPng/ISIS/PIM/LDP routing daemon (Python 
Tools)
   frr-rpki-rtrlib - FRRouting RTRlib RPKI support
   frr-snmp   - FRRouting SNMP support

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

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


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

   dget -x https://mentors.debian.net/debian/pool/main/f/frr/frr_6.0.1-1.dsc

More information about frr can be obtained from https://frrouting.org

Changes since the last upload is not applicable since this is the first
upload.

I expect there still is feedback that I need to address in regards to
the Debian packaging on this and I will likely be uploading further
revisions in the coming days.



I did not build the package. My comment:

There are many lintian info warnings that can be fixed easily:


I no-symbols-control-file
usr/lib/x86_64-linux-gnu/libfrrospfapiclient.so.0.0.0
usr/lib/x86_64-linux-gnu/libfrr.so.0.0.0

https://wiki.debian.org/UsingSymbolsFiles


I possible-documentation-but-no-doc-base-registration
I spelling-error-in-binary  # a lot
I spelling-error-in-manpage  # a lot

I systemd-service-file-missing-documentation-key
lib/systemd/system/frr.service
O package-name-doesnt-match-sonames
libfrr0 libfrrospfapiclient0 (override comment: libfrr* are for 
internal use only and do not provide a stable API or ABI. soname / library 
versioning is irrelevant and they must always be shipped exact-matching to the 
daemons compiled against it)

  It is a package name. That's all.
  The lib can not be trusted?


O systemd-service-file-refers-to-unusual-wantedby-target
lib/systemd/system/frr.service network-online.target (override comment: 
we're a bit special since we provide network connectivity by starting up 
routing protocols.)
X duplicate-files
usr/share/doc/frr/examples/pbrd.conf.sample 
usr/share/doc/frr/examples/staticd.conf.sample

frr-rpki-rtrlib

I extended-description-is-probably-too-short
I hardening-no-fortify-functions
usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so

frr source

I debian-control-has-obsolete-dbg-package
frr-dbg
I duplicate-long-description
frr-doc frr-pythontools
I ored-build-depends-on-obsolete-package
build-depends: dh-systemd  => use debhelper (>= 
9.20160709)
P debian-watch-does-not-check-gpg-signature
P package-uses-old-debhelper-compat-version
9

There is a problem with version 11?
 
O alternatively-build-depends-on-python-sphinx-and-python3-sphinx

(override comment: these are for build-compatibility on older distros 
(e.g. Ubuntu 14.04))

It is a new package. It is preferable to not upload Python 2
X upstream-metadata-file-is-missing



Regards,
Herbert

Bug#910966: RFS: 4pane/5.0-2

[Herbert Fortes]

Hi,

My final comments so I can upload the package:

The history of debian/changelog is been changed. Please,
keep the history.

https://tracker.debian.org/media/packages/4/4pane/changelog-5.0-1

diff -Nru 4pane-5.0/debian/changelog 4pane-5.0/debian/changelog
--- 4pane-5.0/debian/changelog  2017-07-20 11:18:45.0 -0300
+++ 4pane-5.0/debian/changelog  2018-10-08 13:15:58.0 -0300
@@ -1,12 +1,19 @@
-4pane (5.0-1) unstable; urgency=medium
+4pane (5.0-2) unstable; urgency=medium
+
+  * Depend on the gtk+3 version of wxWidgets: see #894663
+  * Override testsuite-autopkgtest-missing
+  * Add an upstream/metadata file
+  * Move the appdata.xml file from appdata/ to metadata/
+  * Change some links from http: to https:
+  * Update to the latest debhelper and policy versions
+
+ -- David Hart   Mon, 08 Oct 2018 17:15:58 +0100
+
+4pane (5.0-1) testing; urgency=medium
 
   * New upstream version.

 All the previous patches are now redundant and a dfsg tarball is
 no longer needed.
-  * Bump std-version to 4.0.0, no changes needed
-  * Update copyright file.
-  * Add dependency on gettext, msgfmt is used by upstream build system
-  * Update watch file
 
  -- David Hart   Thu, 20 Jul 2017 15:18:45 +0100




 - debian/rules does not need these two lines:

diff -Nru 4pane-5.0/debian/rules 4pane-5.0/debian/rules
--- 4pane-5.0/debian/rules  2017-07-20 11:18:45.0 -0300
+++ 4pane-5.0/debian/rules  2018-10-08 13:15:58.0 -0300
@@ -3,8 +3,6 @@
 DH_VERBOSE = 1
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all

-DPKG_EXPORT_BUILDFLAGS = 1
-include /usr/share/dpkg/buildflags.mk



Regards,
Herbert

Bug#910913: RFS: ghostwriter/1.7.3-1 [ITP]

[Herbert Fortes]

On 10/14/18 8:38 AM, ghost wrote:

Hi,

I've uploaded my version to mentors.d.n. I thought it would cause conflict 
since Sebastien already uploaded the same version, but never mind.



Thank you very much!

I did the upload. Let's see what FTP-Master thinks.



Regards,
Herbert
 

Bug#910966: RFS: 4pane/5.0-2

[Herbert Fortes]

On 10/14/18 11:24 AM, David Hart wrote:

Hi Herbert,


debian/changelog
- is "UNRELEASED".
- a comment: I never saw a changelog going to 'testing'. Like
   version 5.0-1. It is in Sid anyway. But there are less 4 lines
   in that part of the file


I wasn't sure what was right for that field. I've now changed it to 'unstable'.


debian/copyright
-  does not have a 'Files: debian/*". I never saw that either.


I don't think it's needed. As I'm both the packager and upstream, IIUC the
contents of a 'Files: debian/*' entry would just duplicate the overriding
'Files: *'. Please correct me if I'm mistaken.




I understand. I thought the same thing in a first time. And nobody
said anything before. Can not be wrong.

But then I thought the debian dir as a separated part. Not related
to other files.

If no sponsor does the upload the package before me, I will see it.



Regards,
Herbert

Bug#910966: RFS: 4pane

[Herbert Fortes]

Hi,

On 10/13/18 6:23 PM, David Hart wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an update of my package "4pane"


I can not build the package right now.  I did a download of
the debian dir.

debian/changelog

 - is "UNRELEASED".
 - a comment: I never saw a changelog going to 'testing'. Like
   version 5.0-1. It is in Sid anyway. But there are less 4 lines
   in that part of the file

debian/copyright

 -  does not have a 'Files: debian/*". I never saw that either.

I can not check control and rules.



Regards,
Herbert




   * Package name: 4pane
 Version : 5.0-2
 Upstream Author : David Hart 
   * URL : https://4Pane.co.uk
   * License : GPL3
 Section : x11

It builds these binary packages:

   4pane - four-pane detailed-list file manager

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

   https://mentors.debian.net/package/4pane


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

dget -x https://mentors.debian.net/debian/pool/main/4/4pane/4pane_5.0-2.dsc

There is also a git repo:
  https://github.com/dghart/4pane-debian-dir

The upload mostly changes to the latest debhelper and policy versions, with
consequent lintian fixes. However it also switches 4pane to use the GTK3 flavour
of wxwidgets3.0: see #894663.

This is a request for a review and upload of the update. The amended package
builds and works, and is lintian-clean.

Changes since the last upload:

4pane (5.0-2) unstable; urgency=medium

   * Depend on the gtk+3 version of wxWidgets: see #894663
   * Override testsuite-autopkgtest-missing
   * Add an upstream/metadata file
   * Move the appdata.xml file from appdata/ to metadata/
   * Change some links from http: to https:
   * Update to the latest debhelper and policy versions


Regards,

David Hart

Bug#910913: RFS: ghostwriter/1.7.3-1 [ITP]

[Herbert Fortes]

On 10/13/18 7:56 PM, ghost wrote:

Thanks for reviewing!

I am neither the upstream nor the person who originally uploaded to mentors.d.n,
though I am doing the most fixing part for the package for it to get into 
Debian...


OK. I am reading files from 1.7.3-4 and there is only Sebastien
name in it.





- debian/copyright seems to need an update.

Ouch, there are new assets not included in COPYING. I guess it's now blocked on
upstream.


 Different author from the project.

Do we need to list everyone?



If there is a file with something like:

Copyright  foo
License 

It must be in debian/copyright. In the 1.7.3 upstream tarball:

$ /tmp/ghostwriter-1.7.3$ egrep -sriA25 "(copyright|public dom)" ./  | less
[...]
./src/spell_checker.h: * Copyright (C) 2009, 2010, 2012 Graeme Gott 

./src/spell_checker.h: * Copyright (C) 2014 attercop
./src/spell_checker.h- *
./src/spell_checker.h- * This program is free software: you can redistribute it 
and/or modify
./src/spell_checker.h- * it under the terms of the GNU General Public License 
as published by
./src/spell_checker.h- * the Free Software Foundation, either version 3 of the 
License, or
./src/spell_checker.h- * (at your option) any later version.
[...]
./src/find_dialog.h: * Copyright (C) 2008, 2009, 2010, 2012 Graeme Gott 

./src/find_dialog.h: * Copyright (C) 2014, 2015 wereturtle
./src/find_dialog.h- *
./src/find_dialog.h- * This program is free software: you can redistribute it 
and/or modify
./src/find_dialog.h- * it under the terms of the GNU General Public License as 
published by
./src/find_dialog.h- * the Free Software Foundation, either version 3 of the 
License, or
./src/find_dialog.h- * (at your option) any later version.
[...]
./src/sundown/autolink.h: * Copyright (c) 2011, Vicent Marti
./src/sundown/autolink.h- *
./src/sundown/autolink.h- * Permission to use, copy, modify, and distribute 
this software for any
./src/sundown/autolink.h- * purpose with or without fee is hereby granted, 
provided that the above
./src/sundown/autolink.h: * copyright notice and this permission notice appear 
in all copies.
./src/sundown/autolink.h- *

And more. They must go to debian/copyright.

The entry about 'Files: debian/*': the maintainer of the Debian package
here. debian/control says Sebastien CHAVAUX

As noone is the upstream the patch files also need - no must - a header.
See debian/patches/clean-deps.patch

dpkg-shlibdeps says it's a useless dependency  # Looks like a description
--- a/ghostwriter.pro
+++ b/ghostwriter.pro
@@ -28,7 +28,7 @@
 
 TEMPLATE = app
 
-QT += printsupport webkitwidgets widgets concurrent svg

+QT += printsupport webkitwidgets widgets concurrent
 
 CONFIG -= debug

 CONFIG += warn_on


The header:

Description: (above)
Author: foo
Last-Update: a date


https://dep-team.pages.debian.net/deps/dep3/  # Sample DEP-3 compliant headers



Regards,
Herbert

Bug#910913: RFS: ghostwriter/1.7.3-1 [ITP]

[Herbert Fortes]

Hi,

On 10/13/18 7:52 AM, ghost wrote:

Package: sponsorship-requests
Severity: wishlist


 Forwarded Message  
Subject:RFS: ghostwriter/1.7.3-1 [ITP]
Date:   Mon, 08 Oct 2018 05:49:14 +1300
From:   Sebastien CHAVAUX 
To: 894...@bugs.debian.org, ghost 


 Dear mentors,

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


You sent a link to 1.7.3-1.dsc. But mentors also has others
revision number. The last one is 1.7.3-4.

The package is new in Debian. It must be 1.7.3-1. A few questions:

 - debian/changelog must has only one entry. About Debian. With an ITP number.
 - debian/compat is 10. Is there a reason to not use 11? I tried with 11
   and seems fine.
 - The package really does not have a git? Vcs-*.
 - patch files does not have info about description, author, last-update
   but as you are the upstream I think they will be removed in a next
   release.
 - debian/copyright seems to need an update. There are code with different
   license from the project. Different author from the project.

Please, fix the package.



Regards,
Herbert




* Package name: ghostwriter
  Version : 1.7.3-1
  Upstream Author :wereturtle 

* URL :http://wereturtle.github.io/ghostwriter/
* License : GPLv3
  Section : editors

 It builds those binary packages:

   ghostwriter - Distraction-free, themeable Markdown editor

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

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


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

   dget 
-xhttps://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_1.7.3-1.dsc

 More information about ghostwriter
can be obtained fromhttp://wereturtle.github.io/ghostwriter/.

 Changes since the last upload:

 - Update to version 1.7.3:
 * Fixed segfault that occurred when changing the theme or interface style 
after opening the Preview Options dialog


 Regards,
  Sebastien CHAVAUX

Bug#910245: RFS: engauge-digitizer/10.10+ds.1-1

[Herbert Fortes]

On 10/8/18 3:55 PM, Tobias Winchen wrote:

Dear Herbert,

I executed cowbuilder 2x in a fresh virtual machine and could not reproduce
this problem. Please let me know if I can do anything else.



Something was wrong with cowbuilder here. I reinstall it.
Then the package was compiled.

Uploading. Thanks!



Regards,
Herbert

Bug#910245: RFS: engauge-digitizer/10.10+ds.1-1

[Herbert Fortes]

Hi,

On 10/3/18 4:16 PM, Tobias Winchen wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "engauge-digitizer"


I ran 'cowbuilder' 2x and got this error:
# cowbuilder --build engauge-digitizer_10.10+ds.1-1.dsc

cklistWizardPoints.o src/.objs/moc_TutorialStateColorFilter.o 
src/.objs/moc_TutorialStateContext.o 
src/.objs/moc_TutorialStateCurveSelection.o 
src/.objs/moc_TutorialStateCurveType.o 
src/.objs/moc_TutorialStateIntroduction.o 
src/.objs/moc_TutorialStatePointMatch.o 
src/.objs/moc_TutorialStateSegmentFill.o src/.objs/moc_ViewPreview.o 
src/.objs/moc_ViewProfileDivider.o src/.objs/moc_WindowAbstractBase.o 
src/.objs/moc_WindowTable.o src/.objs/moc_LoadImageFromUrl.o 
src/.objs/moc_NetworkClient.o src/.objs/moc_DlgImportCroppingPdf.o   -L//lib 
-L/lib -lfftw3 -llog4cpp -lopenjp2 -lpoppler-qt5 -lQt5PrintSupport -lQt5Help 
-lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Sql -lQt5Network -lQt5Core -lpthread -lGL
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1707: bin/engauge] Error 1
make[2]: Leaving directory '/build/engauge-digitizer-10.10+ds.1'
dh_auto_build: make -j1 returned exit code 2
make[1]: *** [debian/rules:22: override_dh_auto_build] Error 25
make[1]: Leaving directory '/build/engauge-digitizer-10.10+ds.1'
make: *** [debian/rules:11: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: Cleaning COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.17395


Can you please check it?



Regards,
Herbert


















  * Package name: engauge-digitizer
Version : 10.10+ds.1-1
   Upstream Author : Mark Mitchell 
  * URL : https://github.com/markummitchell/engauge6
  * License : GPL-2+
Section : science

  It builds those binary packages:

 engauge-digitizer - interactively extracts numbers from bitmap graphs or
maps
  engauge-digitizer-doc - engauge-digitizer user manual and tutorial

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

   https://mentors.debian.net/package/engauge-digitizer

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

 dget -x https://mentors.debian.net/debian/pool/main/e/engauge-digitizer/
engauge-digitizer_10.10+ds.1-1.dsc

   Changes since the last upload:

   * New upstream release
   * Updated to standards version 4.2.1


Bests,
Tobias Winchen

Bug#910134: RFS: dmidecode/3.2-1

[Herbert Fortes]

Hi,

On 10/3/18 3:58 AM, Jörg Frings-Fürst wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

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


There are two changes made by Jean Delvare that is not
in debian/copyright:

+++ dmidecode-3.2/dmidecode.c   2018-09-14 10:52:12.0 -0300
@@ -2,7 +2,7 @@
  * DMI Decode
  *
  *   Copyright (C) 2000-2002 Alan Cox 
- *   Copyright (C) 2002-2017 Jean Delvare 
+ *   Copyright (C) 2002-2018 Jean Delvare 
--
+++ dmidecode-3.2/util.c2018-09-14 10:52:12.0 -0300
@@ -2,7 +2,7 @@
  * Common "util" functions
  * This file is part of the dmidecode project.
  *
- *   Copyright (C) 2002-2017 Jean Delvare 
+ *   Copyright (C) 2002-2018 Jean Delvare 


debian/copyright:

Files: *
Copyright: 2002-2017 Jean Delvare 


Can you please update it?



Regards,
Herbert





Package name: dmidecode
Version : 3.2-1
Upstream Author : dmidecode-de...@nongnu.org
URL : https://nongnu.org/dmidecode/
License : GPL-2+
Section : utils

   It builds those binary packages:

  dmidecode  - SMBIOS/DMI table decoder
  dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)

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

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


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

   dget -x 
https://mentors.debian.net/debian/pool/main/d/dmidecode/dmidecode_3.2-1.dsc

or

   git https://jff.email/cgit/dmidecode.git/?h=release%2Fdebian%2F3.2-1
   



   Changes since the last upload:

   * New upstream release:
 - Refresh patches.
   * Declare compliance with Debian Policy 4.2.1 (No changes needed).
   * debian/dmidecode.docs:
 - Add README.


   Regards,
Jörg Frings-Fürst
- -- 
New:

GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list:
  - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlu0aJAACgkQCfifPIyh
0l3QTRAAxgVCTNtbAQVGR1cjiMKaTUsw95jOxvuIDdsuqjxSwIG5LRt6BODCsbrH
3noioF6dzKo2NrSg3YDDNrqGI44CKmoJMH6h5HRz3Hg3HU7NMxWCP6z8ZflY6w1n
po/xY3TNo50xyY7Pq7g0G0458oy1FIiFHMJOgsRo/pe9WD++99cnpHX4gSM8vrgu
pXAMpeo7KpDn7cYQFUbX8F1/aiLVlnwX0wk2lTXU5lWIjnzuCiGLeXDurj1itum1
wzSkSH9jQ9Gvr2OLPc5opXzSu6WRWR7v0xFh60oj97rsqk0GTRzOe8mEJP1PpQA6
NQmrXqjkWtJ+DmAY2XjU93xpTQzczeD8Fxbsh28kBJSSr9IapkPDLH9GO9P/k03s
Qbc+ZcwBl+AOyCGnbY3AZK88hor2LpgGtiZN9wgY4UbRpoMOF0jY3e0siqrpzN+N
lQYA2K8rH4v6laCPjzdjw/AqZFXn7wEx2tIkqSoflxt9Qlp74b398SlqiUYKbUM1
jpQFSPUN73TN50VgLK7kv4o69T480LeIivRWbvhzY6CTFfzZyhx4Gz+7q230U/1O
Km3fBZXVd2SbHXn+9idKA1KUDARMnS0pMcqNJuBYH5m3LdAkxLVADV2QqoYkGcsd
bUHW6j6Tn4KzIrbtoL5JfES2o1jNxxAY/rKUwq17qeApcw/HYoE=
=g7Ry
-END PGP SIGNATURE-

Bug#906721: RFS: plowshare/2.1.7-2

[Herbert Fortes]

On 9/30/18 2:43 AM, Carl Suster wrote:

Hi Herbert,

Thanks for looking at my packages. I'm not really sure how the old changelog 
diff happened other than that the commit responsible must have been lost 
somewhere in the migration of the repository from GitHub to GitLab to salsa. I 
fixed the changelog in a new commit.

What did you want me to update about the copyright? Whenever I do a new 
snapshot I go through the upstream diff to check for copyright statement 
changes and I didn't notice anything. I've now updated the year range for the 
packaging copyright in case that's what you meant.



Some people update the upstream part by release. Not
only by copyright statement changes. The release has
2018 so I asked about it. Instead of '2010-2015',
'2010-2018'. This is not a problem.

I did ask because maybe it was forgotten to be updated,
as the year range for the packaging.

Package uploaded. Thanks for your work!



Regards,
Herbert

Bug#906721: RFS: plowshare/2.1.7-2

[Herbert Fortes]

Hi Carl Suster,


> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "plowshare" and the related
> package "plowshare-modules". The main reason this is worth an upload is
> that I'm shifting the way the two packages are related in order to
> follow upstream recommendations. Specifically plowshare-modules should
> be kept out of Debian releases (but I intend to keep it in unstable
> hence the placeholder RC bug to prevent migration), and this requires a
> slight adjustment in the dependencies of plowshare itself.
>
> Package name : plowshare
> Version : 2.1.7-2
> URL : https://salsa.debian.org/arcresu-guest/plowshare
> Section : web
>
> It builds these binary packages:
>
> plowshare - download and upload files from file sharing websites
> plowshare4 - transitional dummy package
>
> AND
>
> Package name : plowshare-modules
> Version : 0~git20180325.e4bd365-1
> URL : https://salsa.debian.org/arcresu-guest/plowshare-modules
> Section : web
>
> It builds these binary packages:
>
> plowshare-modules - plowshare drivers for various file sharing websites
>
> Getting the packages:
>
> https://mentors.debian.net/package/plowshare
> https://mentors.debian.net/package/plowshare-modules
>
> dget -x
> https://mentors.debian.net/debian/pool/main/p/plowshare/plowshare_2.1.7-2.dsc
> dget -x
> 
https://mentors.debian.net/debian/pool/main/p/plowshare-modules/plowshare-modules_0~git20180325.e4bd365-1.dsc
>
> Changes since the last upload:
>
> plowshare (2.1.7-2) unstable; urgency=medium
>
> * Update VCS to point to Salsa.
> * Correct typo in patch description.
> * Update debhelper compat to 11 (no changes).
> * Update to standards version 4.2.0:
> - use HTTPS URL in changelog.
> * Set Rules-Requires-Root to no.
> * De-emphasise plowshare-modules in favour of plowmod:
> - drop from Recommends to Suggests and
> - promote git from Suggests to Recommends since the plowmod script
> that replaces the modules package requires git.
>
> -- Carl Suster  Tue, 14 Aug 2018 10:54:27 +1000


I do not understand why the change in  the

debian/changelog file related to the current

version in Debian SID:


-  * Update to Standards-Version 4.1.1: no changes.
+  * Update to Standards-Version 4.0.0: no changes.

In the repository '4.1.1' seems to be the correct number:

https://salsa.debian.org/arcresu-guest/plowshare-modules/blob/debian/0_git20171112.e94a905-1/debian/control#L7


Please update debian/copyright file.




Regards,

Herbert

Bug#909134: Info received (Bug#909134: RFS: budgie-extras/0.6.1-1)

[Herbert Fortes]

Uploaded. And also sent the dak-comands to FTP-Master too.
Enjoy!



Regards,
Herbert

Bug#909134: RFS: budgie-extras/0.6.1-1

[Herbert Fortes]

Hi David Mohammed,


Package: sponsorship-requests
Severity: normal

   Dear mentors,

   I am looking for a sponsor for my package "budgie-extras"


I did a review and have two questions:

 The budgie-quicknote/QuickNoteApplet.vala file is GPL-2+. It
does not have an entry in debian/copyright. All project is GPL-3+
only.

 Did you mixed debian/changelog (Debian and Ubuntu) being aware
of that? I do not think it is good. It tends to confuse the projects.



Regards,
Herbert






  * Package name: budgie-extras
Version : 0.6.1-1
Upstream Author : Ubuntu Budgie Developers
  * URL : https://github.com/ubuntubudgie/budgie-extras
  * License : GPL-3+
Section : misc

   It builds those binary packages:

 budgie-app-launcher-applet - Applet to provide an alternative
means to launch applications
  budgie-clockworks-applet - Applet to display clock across multiple time zones
  budgie-countdown-applet - Applet providing a countdown capability on
the Budgie Desktop
  budgie-dropby-applet - Applet to popup when a USB device is connected
  budgie-hotcorners-applet - Applet providing hotcorners capabilities
for the Budgie Desktop
  budgie-kangaroo-applet - Applet to allow quick file-browsing
  budgie-keyboard-autoswitch-applet - Applet adding the ability to set
a different keyboard layout per
  budgie-previews-applet - Applet providing window previews
capabilities for the Budgie Desk
  budgie-quicknote-applet - Applet providing simple notes capability
for the Budgie Desktop
  budgie-recentlyused-applet - Applet displays files recently accessed
for the Budgie Desktop
  budgie-rotation-lock-applet - Applet to lock or unlock the screen rotation
  budgie-showtime-applet - Applet displaying date and time on the Budgie Desktop
  budgie-trash-applet - Applet allows access to trash capabilities for
the Budgie Desktop
  budgie-weathershow-applet - Applet to display the weather and forecast
  budgie-window-mover-applet - Applet allows moving windows between
workspaces for the Budgie De
  budgie-workspace-overview-applet - Applet providing quick access to
workspaces for the Budgie Deskto
  budgie-workspace-wallpaper-applet - Applet providing per workspace wallpaper

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

   https://mentors.debian.net/package/budgie-extras


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

 dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.6.1-1.dsc

Notes:
linitan -i -I --pedantic run on the built source and is lintian free
check-all-the-things run on the source and corrections made to the source
pbuilder-dist run to ensure builds correctly for unstable

This upload introduces new built binaries to be authorised by
archive-admins via the NEW queue:
- budgie-trash-applet
- budgie-recentlyused-applet
- budgie-app-launcher-applet
- budgie-weathershow-applet
- budgie-hotcorners-applet
- budgie-quicknote-applet

   May I request that this package be added to my debian maintainers
list of packages I'm allowed to look after (dak
fossfree...@ubuntu.com) ?

   Changes since the last upload:

(Most recent changelog)

 * New upstream release
 - see ChangeLog for details
 - Consolidated release to resync Debian and Ubuntu versions
   * Packaging Changes:
 - Bump Standards-Version - no changes required

   Regards,
David Mohammed

Bug#906877: RFS: yuma123/2.11-1

[Herbert Fortes]

Em 15-09-2018 14:36, Vladimir Vassilev escreveu:

Hi Herbert,


I fixed this issue and updated the package now uploaded on mentors.debian.net

Removed the netconf/src/yangdiff/Makefile target from configure.ac with new 
patch 0004-Removed-unused-autoconf-targets.patch

Updated debian/changelog.

Tested a second build in pbuild environment which now works.

Will do second build as part of my release routine from now on.



Cool!

Upload done. As there are new packages. Let's wait FTP-Master.

Thank you for the working done.



Regards,
Herbert

Bug#906877: RFS: yuma123/2.11-1

[Herbert Fortes]

Hi Vladimir Vassilev,

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "yuma123"

The package does not build twice because the generated
netconf/src/yangdiff/Makefile file.

Please add the file to dh_clean's routine. A debian/clean
file with 'netconf/src/yangdiff/Makefile' solves the
issue.



Regards,
Herbert

>
> * Package name    : yuma123
>   Version : 2.11-1
>   Upstream Author : Vladimir Vassilev 
> * URL :https://sourceforge.net/projects/yuma123
> * License : BSD
>   Section : net
>
> It builds those binary packages:
>
> libyangrpc-dev - NETCONF/YANG development files
> libyangrpc2 - NETCONF/YANG library for simple manager clients
> libyuma-base - Configuration script, YANG models and documentation
> libyuma-dev - NETCONF/YANG development files
> libyuma2 - NETCONF/YANG library
> netconfd - NETCONF (RFC-6241) agent
> netconfd-module-ietf-interfaces - SIL module for netconfd implementing
> ietf-interfaces.yang
> netconfd-module-ietf-system - SIL module for netconfd implementing
> ietf-system.yang
> yangcli - NETCONF/YANG command line client application
> yangdump - Validate YANG modules and convert them to different formats
>
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/yuma123
>
> Alternatively, one can download the package with dget using this command:
>
>     dget -x
> https://mentors.debian.net/debian/pool/main/y/yuma123/yuma123_2.11-1.dsc
>
> More information about yuma123 can be obtained
> fromhttp://yuma123.org/wiki   .
>
> Changes since the last upload:
>
> * New upstream release
>
> Regards,
> Vladimir Vassilev
>
>
>

Bug#908278: ITP: libimagequant -- palette quantization library (development files)

[Herbert Fortes]

Hi Andreas Tille,


Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libimagequant
   Version : 2.12.1
   Upstream Author : Kornel Lesiński 
* URL : https://github.com/ImageOptim/libimagequant
* License : GPL-3.0+
   Programming Lang: C
   Description : palette quantization library (development files)
  Small, portable C library for high-quality conversion of RGBA
  images to 8-bit indexed-color (palette) images.
  .
  This library powers pngquant and other PNG optimizers.

Remark: This package is maintained by Debian PhotoTools Maintainers at
https://salsa.debian.org/debian-phototools-team/libimagequant

This package was originally prepared by Herbert Parentes Fortes Neto
 in Git but there was no ITP for the package.  Since
I intend to upgrade pngquant which needs this library I polished the
package and send the ITP.  Herbert, please let me know if I missed
something.



Yes, the package was not ready. Good that you noticed

that.


I do not intend to be responsible for the package. Please

continue with your work.



Regards,
Herbert

Bug#907664: RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1

[Herbert Fortes]

 

Thanks Herver - due to the new binary with this upload (libbudgie-private0) 
FTP-Master has rejected the package with this message

"ACL dm: NEW uploads are not allowed

binary:libbudgie-private0 is NEW."

Can this be sponsored this time around please?



Uploaded to experimental.

But please update debian/copyright before the upload to SID.



Regards,
Herbert

Bug#907664: RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1

[Herbert Fortes]

Hi David Mohammed,

I am giving you budgie-desktop upload permission.



Regards,
Herver

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 16:14, Andrey Rahmatullin escreveu:

On Sun, Aug 05, 2018 at 03:54:23PM -0300, Herbert Fortes wrote:

Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

Why?

Becauso of 'blhc --all'

I'm sorry but that's not a valid reason.

Can you tell me why not?

Sure.
First of all, you should never do some change because some static analyzer
told you. You need to understand what did it tell you, why, and why it
thinks you should do that change.
blhc just analyzes build logs to make sure all expected flags are passed.
"--all   Force check for all +all (+pie, +bindnow) hardening flags. By default it's 
auto detected."
So if you use --all you either know that the package should pass the flags
for both pie and bindnow or must ignore the respective blhc warnings.
dpkg-buildflags(1) says that the pie hardening option has no effect on
most architectures, as it's enabled in gcc, so no flags are passed.
In such situations you need to check the result, in this case check
whether the binary has PIE enabled, not just blindly follow an
incorrectly used static analyzer (and even then you need to find out the
problem and not just pass some compiler/linker flags).



Ok. Thanks.

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 15:47, Andrey Rahmatullin escreveu:

On Sun, Aug 05, 2018 at 03:23:33PM -0300, Herbert Fortes wrote:

Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

Why?



Becauso of 'blhc --all'

I'm sorry but that's not a valid reason.



Can you tell me why not?

What I know is just 'blhc' is enough. But why not
use '--all'?

I do not know much about that and I can learn new
if you say a bit more.

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 15:27, Jörg Frings-Fürst escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Herbert,

thanks for your review.

Am Sonntag, den 05.08.2018, 15:02 -0300 schrieb Herbert Fortes:

Hi,


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 Package name: dmidecode
 Version : 3.1-2
 Upstream Author : dmidecode-de...@nongnu.org
 URL : https://nongnu.org/dmidecode/
 License : GPL-2+
 Section : utils

It builds those binary packages:

   dmidecode  - SMBIOS/DMI table decoder
   dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)



Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

It is just a copy and paste :)



Blame on me :-(

Added, tested and uploaded again.



thanks for your patience Jörg

Uploaded.



Regards,
Herbert

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Em 05-08-2018 15:10, Andrey Rahmatullin escreveu:

On Sun, Aug 05, 2018 at 03:02:39PM -0300, Herbert Fortes wrote:

Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

Why?



Becauso of 'blhc --all'

Bug#905455: RFS: dmidecode/3.1-2

[Herbert Fortes]

Hi,


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

Package name: dmidecode
Version : 3.1-2
Upstream Author : dmidecode-de...@nongnu.org
URL : https://nongnu.org/dmidecode/
License : GPL-2+
Section : utils

   It builds those binary packages:

  dmidecode  - SMBIOS/DMI table decoder
  dmidecode-udeb - SMBIOS/DMI table decoder (udeb) (udeb)



Sorry, but can you please add to debian/rules:

export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie
export DEB_CFLAGS_MAINT_APPEND = -fPIE

It is just a copy and paste :)



Regards,
Herbert

Bug#905375: RFS: bitz-server/2.0.1-1

[Herbert Fortes]

Em 04-08-2018 19:21, Jörg Frings-Fürst escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Herbert,


Am Samstag, den 04.08.2018, 09:05 -0300 schrieb Herbert Fortes:

Hi,

  > -BEGIN PGP SIGNED MESSAGE-
  > Hash: SHA512
  >
  > retitle 905375 RFS: bitz-server/2.0.1-1
  > thanks
  >

I ran 'blhc --all ../*.build and there are some

CXXFLAGS missing (-fPIE)
LDFLAGS missing (-fPIE -pie)

I saw debian/rules has 'hardening=+all' but can
you please add:

export DEB_CXXFLAGS_MAINT_APPEND  = -fPIE
export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie



Many thanks!!

Changed, tested and uploaded to mentors again.




Uploaded. Thanks.



Regards,
Herbert

Bug#905375: RFS: bitz-server/2.0.1-1

[Herbert Fortes]

Hi,

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> retitle 905375 RFS: bitz-server/2.0.1-1
> thanks
>

I ran 'blhc --all ../*.build and there are some

CXXFLAGS missing (-fPIE)
LDFLAGS missing (-fPIE -pie)

I saw debian/rules has 'hardening=+all' but can
you please add:

export DEB_CXXFLAGS_MAINT_APPEND  = -fPIE
export DEB_LDFLAGS_MAINT_APPEND = -fPIE -pie



Regards,
Herbert

Bug#898231: RFS: budgie-extras/0.5.0-1

[Herbert Fortes]

Hi,

Em 08-05-2018 20:25, foss.freedom escreveu:

Package: sponsorship-requests
Severity: normal

   Dear mentors,

   I am looking for a sponsor for my package "budgie-extras"

  * Package name: budgie-extras
Version : 0.5.0-1
Upstream Author : Ubuntu Budgie Developers
  * URL : https://github.com/ubuntubudgie/budgie-extras
  * License : GPL-3+
Section : misc

   It builds those binary packages:



I did the upload.

[...]  

   May I request that this package be added to my debian maintainers
list of packages I'm allowed to look after (dak
fossfree...@ubuntu.com) ?


I can see that.

I will learn on how to give you a DM permission to budgie-extras.

Thanks for the package.



Regards,
Herbert

Bug#897601: budgie-desktop: Budgie desktop and netinst

[Herbert Fortes]

Em 03-05-2018 10:39, David Mohammed escreveu:

There isn't any recommended requirement for lightdm to be included
with budgie upstream.

You should be able to install whichever  logon manager you would like
to use.  I don't think we should be dictating to everyone to use a
specific logon manager with a "recommends"



Ok.


Possibly I could add a Suggests: lightdm and maybe other packages so
we can have a one hit apt --install-suggests budgie-desktop


Good.



Just need to know the complete minimal list of packages to install
from a netinst to bring up a full graphical login.  Let me know your
thoughts.


I do not know if I understood correct. But here is my 'history | grep install'
after the netinst without X


sudo apt install budgie-desktop
sudo apt install brasero gnome-screenshot
sudo apt install virt-manager
sudo apt install debootstrap
sudo apt install lightdm
sudo apt install chromium
sudo apt install reportbug
sudo apt install gnome-terminal
sudo apt install unattended-upgrades
sudo apt install thunderbird
sudo apt install firefox-esr


I think 'install lightdm' right after 'install budgie-desktop' was enough
to have everything. On the login screen it is possible to choose between
'Default X' or 'Budgie Desktop'. Something like that. One 'obs' is: after
gnome-terminal install, it is not possible to login to 'Default X'.

'Default X' loads a terminal. And it must be a simple xterm.

$ df -h
Sist. Arq. Tam. Usado Disp. Uso% Montado em
udev   3,9G 0  3,9G   0% /dev
tmpfs  786M  9,3M  777M   2% /run
/dev/mapper/debian--main-root   19G  2,6G   15G  15% /

I do not have many packages installed right now.




On 3 May 2018 at 14:27, Herbert Fortes <terb...@gmail.com> wrote:

Package: budgie-desktop
Version: 10.2.9-2
Severity: normal

Dear Maintainer,

I did a netinst install with no X enviroment (GNOME, MATE, LXDE, etc). And
then did 'apt install budgie-desktop'.

I thought that I will reboot the system and see a graphical login and after
that the budgie-panel. But this does not happend. The easy fix was to
install
lightdm, login and run 'budgie-desktop' from a xterm.

Is it possible to have that configured from an 'apt install'?

obs: I copy/paste what was in
/tmp/reportbug-budgie-desktop-backup-20180503-1615-hv3hvwyv file.



Regards,
Herbert


-- System Information:
Debian Release: 9.4
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.2.9-2
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-budgie-desktop-1.010.2.9-2
ii  gnome-control-center 1:3.22.2-3
ii  gnome-menus  3.13.3-9
ii  gnome-screensaver3.6.1-7+b2
ii  gnome-session-bin3.22.3-1
ii  gnome-session-common 3.22.3-1
ii  gnome-settings-daemon3.22.2-2+deb9u2
ii  network-manager-gnome1.4.4-1

budgie-desktop recommends no packages.

budgie-desktop suggests no packages.

-- no debconf information

Bug#897601: budgie-desktop: Budgie desktop and netinst

[Herbert Fortes]

Package: budgie-desktop
Version: 10.2.9-2
Severity: normal

Dear Maintainer,

I did a netinst install with no X enviroment (GNOME, MATE, LXDE, etc). And
then did 'apt install budgie-desktop'.

I thought that I will reboot the system and see a graphical login and after
that the budgie-panel. But this does not happend. The easy fix was to
install
lightdm, login and run 'budgie-desktop' from a xterm.

Is it possible to have that configured from an 'apt install'?

obs: I copy/paste what was
in /tmp/reportbug-budgie-desktop-backup-20180503-1615-hv3hvwyv file.



Regards,
Herbert


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.2.9-2
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-budgie-desktop-1.010.2.9-2
ii  gnome-control-center 1:3.22.2-3
ii  gnome-menus  3.13.3-9
ii  gnome-screensaver3.6.1-7+b2
ii  gnome-session-bin3.22.3-1
ii  gnome-session-common 3.22.3-1
ii  gnome-settings-daemon3.22.2-2+deb9u2
ii  network-manager-gnome1.4.4-1

budgie-desktop recommends no packages.

budgie-desktop suggests no packages.

-- no debconf information

Bug#897059: [Pkg-phototools-devel] Bug#897059: (no subject)

[Herbert Fortes]

forwarded 897059 https://github.com/gphoto/libgphoto2/issues/265
thanks

Em 28-04-2018 11:10, Matti Hämäläinen escreveu:
> 
> Hello,
> 
> Submitted a report to libgphoto2 Github issue tracker: 
> https://github.com/gphoto/libgphoto2/issues/265
> 

Bug#897059: Your mail

[Herbert Fortes]

reopen 897059
thanks

On Sat, 28 Apr 2018 17:10:35 +0300 (EEST) 
=?ISO-8859-15?Q?Matti_H=E4m=E4l=E4inen?=  wrote:
>
> Hello,
>
> Submitted a report to libgphoto2 Github issue tracker:
> https://github.com/gphoto/libgphoto2/issues/265

Ok. I will set forwarded.



Regards,
Herbert

Bug#897059: [Pkg-phototools-devel] Bug#897059: Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers

[Herbert Fortes]

Em 28-04-2018 09:35, Matti Hämäläinen escreveu:
> On Sat, 28 Apr 2018, Herbert Fortes wrote:
> 
>> Em 27-04-2018 21:26, Matti Hämäläinen escreveu:
>>>
>>> Hello,
>>>
>>> I tested against the current upstream GIT version 
>>> (91a8425a4fa27def793fa9db2bcb4a71c26c927b)
>>> of libgphoto2, and the problem exists there as well.
>>>
>>> If gphoto debug logs are needed, I can provide ones against working 2.5.16 
>>> and non-working, but they are rather large (about 100M uncompressed each, 
>>> 75M both tar+xz'd).
>>>
>>
>> I think the problem is that you are using gphoto2 version 2.5.16
>> with libgphoto2 version 2.5.17.
>>
>> There is a gphoto2 version 2.5.17. I forgot to upload it. :(. I am
>> really sorry about that.
>>
>> I am starting to do the pachage now.
> 
> Sorry to bring bad news, but I now tested gphoto2 from GIT (with GIT 
> libgphoto2) as well, and the problem persists with that. :(

Humm, I just did the upload closing this bug. I will reopen it. 

And I think is better to send an email to the upstream as you 
suggested on the first email.

A debug log is good But with that size can you put somewhere?
Probably the upstream will like to see it.



Regards,
Herbert


> 
> --
> [ .. LD_LIBRARY_PATH=/opt/lib ]
> $ /opt/bin/gphoto2 --version
> gphoto2 2.5.17.1
> 
> Copyright (c) 2000-2018 Lutz Mueller and others
> 
> gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may
> redistribute copies of gphoto2 under the terms of the GNU General Public
> License. For more information about these matters, see the files named 
> COPYING.
> 
> This version of gphoto2 is using the following software versions and options:
> gphoto2 2.5.17.1   gcc, popt(m), exif, no cdk, no aa, jpeg, 
> readline
> libgphoto2  2.5.17.1   all camlibs, gcc, ltdl, EXIF
> libgphoto2_port 0.12.0 iolibs: disk ptpip serial usb1 usbdiskdirect 
> usbscsi, gcc, ltdl, USB, serial without locking
> 
> 
> I wrote a short shell script for testing, 
> https://tnsp.org/~ccr/gphoto2/testgphoto.sh
> probably not useful, but who knows. :) If more information is needed, I can 
> try things out.
> 
> Matti
> 
> 
> 
> ___
> Pkg-phototools-devel mailing list
> pkg-phototools-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-phototools-devel
> 

Bug#897059: [Pkg-phototools-devel] Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers

[Herbert Fortes]

Em 27-04-2018 21:26, Matti Hämäläinen escreveu:
> 
> Hello,
> 
> I tested against the current upstream GIT version 
> (91a8425a4fa27def793fa9db2bcb4a71c26c927b)
> of libgphoto2, and the problem exists there as well.
> 
> If gphoto debug logs are needed, I can provide ones against working 2.5.16 
> and non-working, but they are rather large (about 100M uncompressed each, 75M 
> both tar+xz'd).
> 

I think the problem is that you are using gphoto2 version 2.5.16
with libgphoto2 version 2.5.17.

There is a gphoto2 version 2.5.17. I forgot to upload it. :(. I am
really sorry about that.

I am starting to do the pachage now.



Regards,
Herbert

Bug#897059: [Pkg-phototools-devel] Bug#897059: libgphoto2-6: libgphoto2 causes corrupted image file transfers

[Herbert Fortes]

severity 897059 serious
thanks

I will read this tomorrow



Regards,
Herbert

Em 27-04-2018 16:23, Matti Hamalainen escreveu:
> Package: libgphoto2-6
> Version: 2.5.17
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading libgphoto2 to latest packaged version 2.5.17, I immediately
> noticed that the CR2 RAW files fetched via "gphoto2 -P" were unreadable by
> Darktable, Adobe Lightroom and other RAW image software. My cameras are Canon
> EOS 7D Mark II and Canon EOS 500D, connected via USB. The problem occurs with
> both cameras.
> 
> I quickly noticed that repeated transfers resulted in files with different
> SHA256 sums. Downgrading to libgphoto2 to previous 2.5.16 makes the problem go
> away, checksums are always consistent. With 2.5.17, each file had different
> checksum for each transfer, pointing to serious corruption.
> 
> I should state that this is a VERY SERIOUS ISSUE! Usually when I transfer
> photos from camera, I also immediately delete them from the camera's memory
> card. Fortunately I noticed the problem with only few pictures taken, so I
> personally suffered almost no loss... but it could have been much worse!
> 
> I have no idea if this affects only Canon cameras, as the changelog for 2.5.17
> states various EOS -related changes, but I think notifying upstream would be
> appropriate.
> 
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.16.5-qcmm (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> 
> ___
> Pkg-phototools-devel mailing list
> pkg-phototools-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-phototools-devel
> 

Bug#810054: gthumb: Memory leakage

[Herbert Fortes]

Hi,

As said about a month ago Gthumb version 3:3.6.1-1~bpo9+1
was accepted in backports[0] yesterday.

The NEWS file declare:

version 3.5.2 * Fixed big memory leak and other minor memory leaks.


If it is possible to use the backports, there will be
less problems with memory leak. Enjoy!

[0] - Backports instructions:
  https://backports.debian.org/Instructions/



Regards,
Herbert

Bug#894891: [Pkg-phototools-devel] Bug#894891: Bug#894891: Bug#894891: pngquant: please, package new upstream version

[Herbert Fortes]

Em 11-04-2018 14:46, Herbert Fortes escreveu:
> Em 06-04-2018 09:40, Herbert Fortes escreveu:
>> Em 06-04-2018 07:19, Rogério Brito escreveu:
>>> Hi, Herbert.
>>>
>>> On Thu, Apr 5, 2018 at 11:52 AM, Herbert Fortes <terb...@gmail.com> wrote:
>>>> Em 05-04-2018 06:57, Rogério Brito escreveu:
>>>>> The upstream of pngquant has released quite a few releases since 2.5.0
>>>>> that's currently in Debian. The current version is 2.11.7.
>>>>>
>>>>> Can we, please, have something newer than the current version?
>>>>
>>>> It is stopped because of a dependency:
>>>>
>>>> pngquant (2.8.2-1) UNRELEASED; urgency=medium
>>>>
>>>>   TODO: * Needs packaging of
>>>> https://github.com/ImageOptim/libimagequant
>>>>   (but no new packages for Stretch ...)
>>>> * check whether CVE-2016-5735 is fixed in latest upstream
>>> (...)
>>>
>>> Ah, I see... I didn't know that newer versions of the package required
>>> a new library...
>>
>>
>> I think the project was splitted.
>>
>> version 2.8
>> ---
>>  - libimagequant is a separate project
>>
>> The maintainer is very active. And I think the packages - pngquant
>> and libimagequant - should walk together.
>>
>>>
>>> BTW, taking a look at the repository for the library, it has bindings
>>> for a lot of languages and, perhaps, they should be built as needed,
>>> since, otherwise, they may be bloating the archive and never be used
>>> (depending if clients in the archive use this library)...
>>
>> I saw that too. I do not know what to do exactly (right now).
>>
>>>
>>>> I can send an ITP and try to do the Debian package if that helps.
>>>
>>> That would be awesome, if you could do that, because the lack of SSE2
>>> optimization (if I understood things correctly with the current
>>> binaries) is a pain with amd64 systems (especially on my Core 2 Duo
>>> notebook that is already being loaded with some image processing tasks
>>> and trying to help the kernel team with support for the recent
>>> oversized armel kernels).
>>>
>>
>> As said, the maintainer is very active. Let's wait a few days.
>>
> 
> I started the packaging - libimagequant0(shared) and libimagequant-dev.
> No *-doc package yet. I think it can be an overkill.
> 
> And I created a repository[0].
> 
> [0] - https://salsa.debian.org/debian-phototools-team/libimagequant
> 
> About the build:
> 
>  - debian/copyright must be checked.
>  - there is a lintian that I do not understand why:
> 
>W: file-name-contains-wildcard-character
>N:
>N:   The file name contains shell wildcard characters.
>N:   
>N:   These are most likely unexpanded wildcard characters from (for
>N:   example) debian/*.install files, or it may have been installed by
>N:   accident.
>N:   
>N:   Severity: normal, Certainty: possible
>N:   
>N:   Check: files, Type: binary, udeb
>N:
> 
>   It is true. The '*' is unexpanded. Here it should be 'x86_64-linux-gnu'
>   as it is in 'debian/tmp'.
> 
> 
> If someone wants to be a 'Uploaders', please do it.
> 

I just push to salsa a new debian directory.

The configure and Makefile files were made by hand. That's why the 
lintian above, I guess. So I put some extra lines in debian/rules file.

I also finished debian/copyrigh file and builded the debian/*.symbols
file.

Bug#894891: [Pkg-phototools-devel] Bug#894891: Bug#894891: pngquant: please, package new upstream version

[Herbert Fortes]

Em 06-04-2018 09:40, Herbert Fortes escreveu:
> Em 06-04-2018 07:19, Rogério Brito escreveu:
>> Hi, Herbert.
>>
>> On Thu, Apr 5, 2018 at 11:52 AM, Herbert Fortes <terb...@gmail.com> wrote:
>>> Em 05-04-2018 06:57, Rogério Brito escreveu:
>>>> The upstream of pngquant has released quite a few releases since 2.5.0
>>>> that's currently in Debian. The current version is 2.11.7.
>>>>
>>>> Can we, please, have something newer than the current version?
>>>
>>> It is stopped because of a dependency:
>>>
>>> pngquant (2.8.2-1) UNRELEASED; urgency=medium
>>>
>>>   TODO: * Needs packaging of
>>> https://github.com/ImageOptim/libimagequant
>>>   (but no new packages for Stretch ...)
>>> * check whether CVE-2016-5735 is fixed in latest upstream
>> (...)
>>
>> Ah, I see... I didn't know that newer versions of the package required
>> a new library...
> 
> 
> I think the project was splitted.
> 
> version 2.8
> ---
>  - libimagequant is a separate project
> 
> The maintainer is very active. And I think the packages - pngquant
> and libimagequant - should walk together.
> 
>>
>> BTW, taking a look at the repository for the library, it has bindings
>> for a lot of languages and, perhaps, they should be built as needed,
>> since, otherwise, they may be bloating the archive and never be used
>> (depending if clients in the archive use this library)...
> 
> I saw that too. I do not know what to do exactly (right now).
> 
>>
>>> I can send an ITP and try to do the Debian package if that helps.
>>
>> That would be awesome, if you could do that, because the lack of SSE2
>> optimization (if I understood things correctly with the current
>> binaries) is a pain with amd64 systems (especially on my Core 2 Duo
>> notebook that is already being loaded with some image processing tasks
>> and trying to help the kernel team with support for the recent
>> oversized armel kernels).
>>
> 
> As said, the maintainer is very active. Let's wait a few days.
> 

I started the packaging - libimagequant0(shared) and libimagequant-dev.
No *-doc package yet. I think it can be an overkill.

And I created a repository[0].

[0] - https://salsa.debian.org/debian-phototools-team/libimagequant

About the build:

 - debian/copyright must be checked.
 - there is a lintian that I do not understand why:

   W: file-name-contains-wildcard-character
   N:
   N:   The file name contains shell wildcard characters.
   N:   
   N:   These are most likely unexpanded wildcard characters from (for
   N:   example) debian/*.install files, or it may have been installed by
   N:   accident.
   N:   
   N:   Severity: normal, Certainty: possible
   N:   
   N:   Check: files, Type: binary, udeb
   N:

  It is true. The '*' is unexpanded. Here it should be 'x86_64-linux-gnu'
  as it is in 'debian/tmp'.


If someone wants to be a 'Uploaders', please do it.



Regards,
Herbert

Bug#894891: [Pkg-phototools-devel] Bug#894891: pngquant: please, package new upstream version

[Herbert Fortes]

Em 06-04-2018 07:19, Rogério Brito escreveu:
> Hi, Herbert.
> 
> On Thu, Apr 5, 2018 at 11:52 AM, Herbert Fortes <terb...@gmail.com> wrote:
>> Em 05-04-2018 06:57, Rogério Brito escreveu:
>>> The upstream of pngquant has released quite a few releases since 2.5.0
>>> that's currently in Debian. The current version is 2.11.7.
>>>
>>> Can we, please, have something newer than the current version?
>>
>> It is stopped because of a dependency:
>>
>> pngquant (2.8.2-1) UNRELEASED; urgency=medium
>>
>>   TODO: * Needs packaging of
>> https://github.com/ImageOptim/libimagequant
>>   (but no new packages for Stretch ...)
>> * check whether CVE-2016-5735 is fixed in latest upstream
> (...)
> 
> Ah, I see... I didn't know that newer versions of the package required
> a new library...


I think the project was splitted.

version 2.8
---
 - libimagequant is a separate project

The maintainer is very active. And I think the packages - pngquant
and libimagequant - should walk together.

> 
> BTW, taking a look at the repository for the library, it has bindings
> for a lot of languages and, perhaps, they should be built as needed,
> since, otherwise, they may be bloating the archive and never be used
> (depending if clients in the archive use this library)...

I saw that too. I do not know what to do exactly (right now).

> 
>> I can send an ITP and try to do the Debian package if that helps.
> 
> That would be awesome, if you could do that, because the lack of SSE2
> optimization (if I understood things correctly with the current
> binaries) is a pain with amd64 systems (especially on my Core 2 Duo
> notebook that is already being loaded with some image processing tasks
> and trying to help the kernel team with support for the recent
> oversized armel kernels).
> 

As said, the maintainer is very active. Let's wait a few days.



Regards,
Herbert

Bug#894891: [Pkg-phototools-devel] Bug#894891: pngquant: please, package new upstream version

[Herbert Fortes]

Em 05-04-2018 06:57, Rogério Brito escreveu:
> Package: pngquant
> Version: 2.5.0-2
> Severity: wishlist
> 
> Hi.
> 
> The upstream of pngquant has released quite a few releases since 2.5.0
> that's currently in Debian. The current version is 2.11.7.
> 
> Can we, please, have something newer than the current version?
> 

It is stopped because of a dependency:

pngquant (2.8.2-1) UNRELEASED; urgency=medium

  TODO: * Needs packaging of
https://github.com/ImageOptim/libimagequant
  (but no new packages for Stretch ...)
* check whether CVE-2016-5735 is fixed in latest upstream
  * New upstream version
  * Upstream moved source to Github
  * cme fix dpkg-control
  * debhelper 10


I can send an ITP and try to do the Debian package if
that helps.



Regards,
Herbert

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

[Herbert Fortes]

Em 01-04-2018 05:25, Jose G. López escreveu:
> On Sat, 31 Mar 2018 09:29:02 -0300
> Herbert Fortes <terb...@gmail.com> wrote:
> 
>> Hi Jose G. López,
>>
>> I ran 'blhc --all' and there are some CFLAGS, CXXFLAGS and LDFLAGS
>> missing '-fPIE' '-fPIE -pie'.
>>
>> Can you please fix them?
>>
> 
> Hi Herbert,
> 
> Fix it. Reuploaded to mentors and pushed to salsa.
> 

Uploaded.

Thank you for your work.



Regards,
Herbert

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

[Herbert Fortes]

Hi 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
>

I ran 'blhc --all' and there are some CFLAGS, CXXFLAGS and LDFLAGS
missing '-fPIE' '-fPIE -pie'.

Can you please fix them?



Regards,
Herbert

Bug#893661: gthumb: Memory leakage

[Herbert Fortes]

Hi Patrick,

> Package: gthumb
> Version: 3:3.4.4.1-5
> Severity: important
> 
> Dear Maintainer,
> 
> I'm using gthumb 3.4.4.1 which is the version available in the current Debian
> Stable repositories. It seems to have a big memory leak: From the moment I 
> open
> the program, every picture I watch seems to stay loaded in the RAM until it's
> full and then, the whole system becomes extremely slow.
> 
> The only way I found to avoid this is to keep an eye on the system monitor and
> close gthumb once in a while before the RAM usage reaches 100%. It seems like
> there's been issues like that in the past:
> 
> https://mail.gnome.org/archives/gthumb-list/2017-April/msg0.html
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810054
> 

The Debian stable missed the release with some
"fixed minor memory leaks" for too little.

There is a new upstream version - 3.6.1 (this month).
I will put it in Debian Sid this weekend. Then we 
have to wait about 10 days in Debian Testing. Total
15 days waiting (5 - Sid + 10 Testing).

Before the end of April it should be available by 
backports[0]. It is a good moment to do that.

[0] - https://backports.debian.org/



Regards,
Herbert

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Herbert Fortes]

Em 11-03-2018 17:35, Sven Joachim escreveu:
> On 2018-03-11 10:57 -0300, Herbert Fortes wrote:
> 
>> Em 10-03-2018 15:24, Sven Joachim escreveu:
>>> On 2018-03-10 09:31 -0300, Herbert Fortes wrote:
>>>
>>>> Em 09-03-2018 17:03, Sven Joachim escreveu:
>>>>> On 2018-03-09 15:18 -0300, Herbert Fortes wrote:
>>>>>
>>>>>> Hi Sven Joachim,
>>>>>>
>>>>>>>> My conclusion is that it is very risky to allow such combinations, and
>>>>>>>> to rule them out I propose to change the package name of the cdk
>>>>>>>> library, say to libcdk5a.  It would then have to build-depend on
>>>>>>>> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
>>>>>>>> libncurses6 and not libncurses5.  Of course this can only be uploaded
>>>>>>>> to experimental for now, but should go to unstable when the ncurses
>>>>>>>> transition starts there.
>>>>>>
>>>>>>
>>>>>> I am OK with changing the name. But libcdk5a does not say 
>>>>>> much about why the change.
>>>>>>
>>>>>> Since the package name will change because of SONAME of 
>>>>>> libncurses, I thought to follow the SONAME of the library.
>>>>>
>>>>> Well, the SONAME of the cdk library does not change with my proposal.
>>>>>
>>>>>> libcdk5-6
>>>>>
>>>>> If you like that better than libcdk5a, choose it.  Or any other name,
>>>>> it's rather arbitrary anyway.
>>>>>
>>>>>> But maybe this will cause misunderstanding. The change is
>>>>>> on version 6.1+20180210.
>>>>>
>>>>> That's why the build-dependency on libncurses-dev (>= 6.1+20180210) is
>>>>> needed.
>>>>>
>>>>> I am not sure we understand each other yet, but I'm happy to answer
>>>>> questions.
>>>>>
>>>>
>>>> Good! I am searching for a name. And talk about it could
>>>> help.
>>>>
>>>> cdk library had problems before (about name), and I belive
>>>> the number "5" (cdk SONAME) was the choice to differ from the
>>>> other package. That's what I remember.
>>>>
>>>>  - libcdk-java
>>>>  - libcdk-perl
>>>>  - libcdk5
>>>>
>>>> The "5" was accepted because the SONAME does not change much.
>>>
>>> The "5" is there because it is the standard convention for shared
>>> library packages: if you ship libfoo.so.5 in your package, the package
>>> is supposed to be called libfoo5.  See the chapter in the Policy about
>>> shared libraries.[1]
>>>
>>> Now, the "chtype" change in ncurses changes the ABI of the cdk library,
>>> and hence the package name must change to not break reverse dependencies
>>> (e.g. gphoto2).  Ideally, the SONAME would also change, but this means
>>> you would have to invent your own SONAME since upstream did not take it
>>> into account.  Therefore I proposed to only change the package name,
>>> from libcdk5 to libcdk5a (or any other name, it's really arbitrary).
>>> This means that the reverse dependencies have to be upgraded in
>>> lock-step, but since there are only three of them (cpm, libcdk-perl and
>>> gphoto2), that looks manageable.
>>
>> OK. I read what I wanted (SONAME part) and understood why the 
>> change. Thanks for that!
>>
>> I only managed one SONAME change (libgphoto2), more than a year ago.
>> After change the name I must email the reverse_dependencies and
>> ask them to use the new package and let the old one die. Is that
>> it?
> 
> No, reverse dependencies just have to be binNMU'ed.  For cpm and gphoto2
> this will happen anyway as part of the ncurses transition, for
> libcdk-perl we'll have to ask the release team separately.  But I can
> take care of that.
> 
>> (new package - add break, replaces)
> 
> Or Conflicts+Replaces as in my original patch.
> 
>> I also have to deal with the repo name. I created it two years ago.
>> Named libcdk5 (libcdk5.git).
> 
> It probably should have been named cdk instead, but I would postpone
> renaming the source package until the SONAME actually changes.  But
> that's up to you.  The downside (if you rename the source package now)
> is that the FTP masters may take longer to review it than if there's
> just a new binary package.

Yes. But cdk already exists[0]. 

[0] - https://tracker.debian.org/pkg/cdk

>  
>>>> The number "6" is from libncurses. If the two projects have
>>>> a strong link, it could be used. But seeing the two numbers,
>>>> which of them refers to what. I can put an explanation on 
>>>> debian/README.Debian file. But maybe the name will be changed
>>>> more than expected.
>>>
>>> Well, you could use libcdk5nc6 or something like that to indicate that
>>> the package name change is related to libncurses6, but there is no need
>>> to explain this in a README.Debian, since shared libraries are usually
>>> automatically installed as a dependency of some other package and not
>>> for their own merits.
>>>
>>
>> libcdk5nc6 sounds good to me.
> 
> Fine with me, I have attached an updated patch for that new name.
> 

Thank you very much!

I will get the new upstream version, apply the patch and send it to
experimental this week.



Regards,
Herbert

Bug#892114: libcdk5: libcdk5.symbols is not up to date

[Herbert Fortes]

Em 05-03-2018 16:41, Sven Joachim escreveu:
> On 2018-03-05 16:25 -0300, Herbert Fortes wrote:
> 
>> Em 05-03-2018 15:45, Sven Joachim escreveu:
>>> Source: libcdk5
>>> Version: 5.0.20161210-5
>>> Severity: minor
>>> Tags: patch
>>>
>>> One symbol is missing from debian/libcdk5.symbols, leading to a warning
>>> from dpkg-gensymbols seen in the build logs.  According to the CHANGES
>>> file it was added on 2016/11/19, so I have chosen 5.0.20161120 as the
>>> minimal version, as for the other symbols.  See the attached patch.
>>>
>>
>> The .symbols file, to pass on all architectures, should not have all symbols.
> 
> Well, it does not _need_ to have all symbols, unless you pass -c2 or
> higher to dpkg-gensymbols.  But I think -c4 is actually recommended to
> catch any problems that might result in an unexpected ABI change.
> 
>> Just the common symbols for every arch. That's what I learned.
>>
>> Are you saying something different from that? Can you explain a bit more?
> 
> I was referring to the following message from dpkg-gensymbols[1]:
> 
> ,
> | dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
> see diff output below
> | dpkg-gensymbols: warning: debian/libcdk5/DEBIAN/symbols doesn't match 
> completely debian/libcdk5.symbols
> | --- debian/libcdk5.symbols (libcdk5_5.0.20161210_hurd-i386)
> | +++ dpkg-gensymbols0_FMk7   2018-01-27 17:37:28.0 +
> | @@ -306,6 +306,7 @@
> |   positionCDKButton@Base 5.0.20161120
> |   positionCDKObject@Base 5.0.20161120
> |   raiseCDKObject@Base 5.0.20161120
> | + reRegisterCDKObject@Base 5.0.20161210
> |   readFile@Base 5.0.20161120
> |   refreshCDKScreen@Base 5.0.20161120
> |   refreshCDKWindow@Base 5.0.20161120
> `


The new cdk version:

2018/03/06
+ update versioned-symbol list for reRegisterCDKObject (prompted by
  Debian #892114, which adopted a different set of symbol versions
  such as "5.0.20161120", cf: 2014/11/06).

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Herbert Fortes]

Em 10-03-2018 15:24, Sven Joachim escreveu:
> On 2018-03-10 09:31 -0300, Herbert Fortes wrote:
> 
>> Em 09-03-2018 17:03, Sven Joachim escreveu:
>>> On 2018-03-09 15:18 -0300, Herbert Fortes wrote:
>>>
>>>> Hi Sven Joachim,
>>>>
>>>>>> My conclusion is that it is very risky to allow such combinations, and
>>>>>> to rule them out I propose to change the package name of the cdk
>>>>>> library, say to libcdk5a.  It would then have to build-depend on
>>>>>> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
>>>>>> libncurses6 and not libncurses5.  Of course this can only be uploaded
>>>>>> to experimental for now, but should go to unstable when the ncurses
>>>>>> transition starts there.
>>>>
>>>>
>>>> I am OK with changing the name. But libcdk5a does not say 
>>>> much about why the change.
>>>>
>>>> Since the package name will change because of SONAME of 
>>>> libncurses, I thought to follow the SONAME of the library.
>>>
>>> Well, the SONAME of the cdk library does not change with my proposal.
>>>
>>>> libcdk5-6
>>>
>>> If you like that better than libcdk5a, choose it.  Or any other name,
>>> it's rather arbitrary anyway.
>>>
>>>> But maybe this will cause misunderstanding. The change is
>>>> on version 6.1+20180210.
>>>
>>> That's why the build-dependency on libncurses-dev (>= 6.1+20180210) is
>>> needed.
>>>
>>> I am not sure we understand each other yet, but I'm happy to answer
>>> questions.
>>>
>>
>> Good! I am searching for a name. And talk about it could
>> help.
>>
>> cdk library had problems before (about name), and I belive
>> the number "5" (cdk SONAME) was the choice to differ from the
>> other package. That's what I remember.
>>
>>  - libcdk-java
>>  - libcdk-perl
>>  - libcdk5
>>
>> The "5" was accepted because the SONAME does not change much.
> 
> The "5" is there because it is the standard convention for shared
> library packages: if you ship libfoo.so.5 in your package, the package
> is supposed to be called libfoo5.  See the chapter in the Policy about
> shared libraries.[1]
> 
> Now, the "chtype" change in ncurses changes the ABI of the cdk library,
> and hence the package name must change to not break reverse dependencies
> (e.g. gphoto2).  Ideally, the SONAME would also change, but this means
> you would have to invent your own SONAME since upstream did not take it
> into account.  Therefore I proposed to only change the package name,
> from libcdk5 to libcdk5a (or any other name, it's really arbitrary).
> This means that the reverse dependencies have to be upgraded in
> lock-step, but since there are only three of them (cpm, libcdk-perl and
> gphoto2), that looks manageable.

OK. I read what I wanted (SONAME part) and understood why the 
change. Thanks for that!

I only managed one SONAME change (libgphoto2), more than a year ago.
After change the name I must email the reverse_dependencies and
ask them to use the new package and let the old one die. Is that
it?

(new package - add break, replaces)

I also have to deal with the repo name. I created it two years ago.
Named libcdk5 (libcdk5.git).

> 
>> The number "6" is from libncurses. If the two projects have
>> a strong link, it could be used. But seeing the two numbers,
>> which of them refers to what. I can put an explanation on 
>> debian/README.Debian file. But maybe the name will be changed
>> more than expected.
> 
> Well, you could use libcdk5nc6 or something like that to indicate that
> the package name change is related to libncurses6, but there is no need
> to explain this in a README.Debian, since shared libraries are usually
> automatically installed as a dependency of some other package and not
> for their own merits.
> 

libcdk5nc6 sounds good to me.



Regards,
Herbert

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Herbert Fortes]

Em 09-03-2018 17:03, Sven Joachim escreveu:
> On 2018-03-09 15:18 -0300, Herbert Fortes wrote:
> 
>> Hi Sven Joachim,
>>
>>>> My conclusion is that it is very risky to allow such combinations, and
>>>> to rule them out I propose to change the package name of the cdk
>>>> library, say to libcdk5a.  It would then have to build-depend on
>>>> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
>>>> libncurses6 and not libncurses5.  Of course this can only be uploaded
>>>> to experimental for now, but should go to unstable when the ncurses
>>>> transition starts there.
>>
>>
>> I am OK with changing the name. But libcdk5a does not say 
>> much about why the change.
>>
>> Since the package name will change because of SONAME of 
>> libncurses, I thought to follow the SONAME of the library.
> 
> Well, the SONAME of the cdk library does not change with my proposal.
> 
>> libcdk5-6
> 
> If you like that better than libcdk5a, choose it.  Or any other name,
> it's rather arbitrary anyway.
> 
>> But maybe this will cause misunderstanding. The change is
>> on version 6.1+20180210.
> 
> That's why the build-dependency on libncurses-dev (>= 6.1+20180210) is
> needed.
> 
> I am not sure we understand each other yet, but I'm happy to answer
> questions.
> 

Good! I am searching for a name. And talk about it could
help.

cdk library had problems before (about name), and I belive
the number "5" (cdk SONAME) was the choice to differ from the
other package. That's what I remember.

 - libcdk-java
 - libcdk-perl
 - libcdk5

The "5" was accepted because the SONAME does not change much.

The number "6" is from libncurses. If the two projects have
a strong link, it could be used. But seeing the two numbers,
which of them refers to what. I can put an explanation on 
debian/README.Debian file. But maybe the name will be changed
more than expected.

cdk stands for "Curses Development Kit". A C-based curses widget 
library. Curses/ncurses can be used.

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Herbert Fortes]

Hi Sven Joachim,

>> My conclusion is that it is very risky to allow such combinations, and
>> to rule them out I propose to change the package name of the cdk
>> library, say to libcdk5a.  It would then have to build-depend on
>> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
>> libncurses6 and not libncurses5.  Of course this can only be uploaded
>> to experimental for now, but should go to unstable when the ncurses
>> transition starts there.


I am OK with changing the name. But libcdk5a does not say 
much about why the change.

Since the package name will change because of SONAME of 
libncurses, I thought to follow the SONAME of the library.

libcdk5-6

But maybe this will cause misunderstanding. The change is
on version 6.1+20180210.



Regards,
Herbert