Bug#1064934: RFS: nanomsg/1.2.1+dfsg-1 -- nanomsg utilities

[Gianfranco Costamagna]

Hello,

+++ nanomsg-1.2.1+dfsg/src/utils/chunkref.c 2024-02-03 23:45:24.0 
+0100
@@ -1,5 +1,6 @@
 /*
 Copyright (c) 2013 Martin Sustrik  All rights reserved.
+Copyright 2024 Staysail Systems, Inc.


Anyway, I didn't sponsor, but gave you DM for the package. Feel free to add the 
missing
copyright holder and upload.

G.
On Tue, 27 Feb 2024 21:09:16 + Phil Wyett  wrote:

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : nanomsg
   Version  : 1.2.1+dfsg-1
   Upstream contact : Martin Sústrik 
 * URL  : https://nanomsg.org/
 * License  : Expat
 * Vcs  : https://salsa.debian.org/debian/nanomsg
   Section  : libs

The source builds the following binary packages:

  libnanomsg6 - high-performance implementation of scalability libraries
  libnanomsg-dev - nanomsg development files
  nanomsg-utils - nanomsg utilities

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nanomsg/nanomsg_1.2.1+dfsg-1.dsc

Changes since the last upload:

 nanomsg (1.2.1+dfsg-1) experimental; urgency=medium
 .
   * New upstream version 1.2.1.
   * Remove not required patches.
   * Remove not required lintian overrides.
   * 'd/libnanomsg6.symbols': Correct typographical error.

Note:

Could I be given upload rights to this package when accepted please.

Regards

Phil

--
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Remove package from unstable?

[Gianfranco Costamagna]

Did we ever implement the "bump epoch should go to new queue"?

I would like to see packages going in some new queue, this way ftpmasters can 
check if the epoch bump was a mistake or not.
(and I can't just test by myself, I don't want to risk bumping epoch on my 
packages!)

G.






Il giovedì 29 febbraio 2024 alle ore 01:15:59 CET, Dominik George 
 ha scritto: 





Hi,


> a) The version numbering rules provide for a '1:' prefix to be used to
>deal with version numbering mistakes. A version number starting with
>'1:' counts as higher than any without such a prefix; a '2:' counts as
>higher than '1:', etc. So you could re-upload 2.10.08+ds-1 with version
>number '1:2.10.08+ds-1' to supplant 2.11.01+ds-3. However the downside
>to this approach is that you're forevermore committed to having that
>prefix in the version numbering.


Don't do this.

Using am epoch has to be agreed on in the project, and for good reasons. First 
and foremost, the epoch is not encoded into the package file name, thus causing 
trouble when in the future you get to upload 1:2.11.01.

-nik

Bug#1059236: closed by Gianfranco Costamagna (Re: Bug#1057954: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities)

[Gianfranco Costamagna]

Hello,

>I think I need advice here. I am tempted to breaks replace and upgrade all to 
>libnanomsg6
>and then work with upstream on SONAMES etc. How would you and Tobias proceed?

yes, this is correct. Change soname and go for experimental, and ask upstream 
to change soname only
if symbols are changed.

G.

Bug#1063429: RFS: libfilezilla/0.46.0-1 -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

Hello Phil,
I'm sponsoring but next time don't forget to update copyright years, the diff 
shows:
- Copyright (C) 2023  Tim Kosse
+ Copyright (C) 2015-2024  Tim Kosse


(and also your d/copyright entry!)

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061079: RFS pidgin-skype

[Gianfranco Costamagna]

Hello,


>It is really random, for upstream modification.
>
>But it looks I could have to do something for auto-glib2.0 
> transition.
>Which I don't really understand yet.

Just don't do any action should be fine.
There is a time_t -> time64_t transition ongoing (not yet, but will start soon 
TM)
this should happen for armel/armhf only, 

https://lists.debian.org/debian-release/2024/01/msg00033.html

>I plan to make a backport for Bookworm. Do you think I should:
>- Backport this version even if VCS fields are not up to date?
>- Make a new version with update VCS fields and backport it as soon as 
>it is in testing?


up to you!

>- Wait again for the auto-glib2.0 
> 
>transition. to make all needed modifications, create a version with also 
>updated VCS fields and see what will happen for the backport?

This won't affect the package, it should be a no change rebuild done semi 
automatically
by Release Team, and only for 32 bit architectures excluded i386.

So, it is really up to you.

G.

Bug#1061079: RFS pidgin-skype

[Gianfranco Costamagna]

Hello,
please switch VCS fields to the new location
https://salsa.debian.org/debian/pidgin-skype/-/blob/master/debian/control?ref_type=heads

And then just delete the old repository once the new version is uploaded in sid.

There is no rush, if you plan some upload in the near future.


G.


Il martedì 30 gennaio 2024 alle ore 16:28:14 CET, Patrick ZAJDA 
 ha scritto: 





Hello,

On Fri, 26 Jan 2024 18:36:02 +0100 Gianfranco Costamagna 
 wrote:
> Happily done, btw how do you feel about pushing your work somewhere 
in Debian git repositories?
> https://salsa.debian.org/debian/pidgin-skype might be a good place.
>
> This way other people can help maintaining your package

I've just pushed all branches and tags to this repository and set CI.

What do you suggest me to do after knowing it is referenced in the 
package meta-data?
Maintaining both repositories synced until there is a new version to 
publish?

Thanks and best regards,

-- 
Patrick ZAJDA

Re: Remaining bug in pidgin-skype

[Gianfranco Costamagna]

Hello,

>Now pidgin-skype has been sponsored thanks to Gianfranco Costamagna, 
>what should I do with remaining?
>
>I have not read all of them yet but after a first look, the major part 
>(not to say all) of remaining bugs are not still relevant because 
>related to old plugins.
>This seems to be nothing more than common sense, but I prefer to ask the 
>question before acting: should I prepare a message and close all bugs 
>that are no longer relevant, specifying that only the web plugin is 
>available and that the bug should therefore be closed because related 
>plugin is not part of the package anymore?
>
>I found information about when a specific fix was implemented but not in 
>this kind of case.
>
>Thanks and best regards,

Looks you already correctly did it :)

thanks!

G.

Re: Version changing while there is an opened RFS

[Gianfranco Costamagna]

Hello,

You can maybe do something like:
download tarball from last master branch 
https://github.com/EionRobb/skype4pidgin/tarball/master
(automatic tarball generation)
call it something like

20240123+gitecef199+dfsg-1
20140930+svn665+dfsg-2


$ dpkg --compare-versions 20240123+gitecef199+dfsg-1 gt 20140930+svn665+dfsg-2 
&& echo true
true

G.


Il martedì 23 gennaio 2024 alle ore 09:40:11 CET, Patrick ZAJDA 
 ha scritto: 





Hello,

Le 23/01/2024 à 01:27, Gianfranco Costamagna a écrit :
>
>> I intent to adopt pidgin-skype package.
>> The package version is based on last upstream Git main branch commit, to
>> keep same versioning the package has already.
>>
>> To successfully enable hardening, I created a patch I contributed
>> upstream by opening a pull request.
>> The pull request was merged some hours after.
>>
>> What should I do now?
>> Continue with the same version using the patch?
>> Bump new version and in this case, should I only change the actual
>> version in debian/changelog or create a new version to change upstream
>> version and keep the version the RFS is opened for?
>>
>> Thanks and best regards,
>
> As first answer?
> Please ask upstream to release something new, don't make every distribution 
> rely on git snapshots,
> because it's hard to understand when something is "stable" enough without a 
> tagged release.
> If this isn't possible, either packaging a new snapshot or applying it as 
> patch and bump Debian
> revision from N to N+1 is ok.
> (maybe it depends on the patch size, if small, a patch is ok to avoid import 
> of a new tarball, if the patch
> is huge, maybe the latter is preferred. Also, there might be other commits 
> between the Debian snapshot
> and the patch upstream acceptance, so check all the commits for their 
> stability).
>
> Sorry for not providing a good answer but "it depends" is probably the right 
> one.
>
> G.
Firstly, I would really have preferred to avoid these kind of version :-)
But the latest release was about three years ago, maybe I could ask the 
project maintainer to tag a new version... Before the yesterday commit 
which applies the patch, previous was on July 10, 2023.

And because actual package version is an SVN snapshot, I don't know how 
I could change version chem without using epoch. Woule 
yyymmdd+realyversion+dfsg be OK?
But there is still the fact latest version is very old and a lot of 
fixes have been applied since.

Anyway, if I read you correctly and because my patch modifies only two 
lines with only one useful for the Debian package, maybe it is OK to 
wait for a review of the actual package I opened a RFS for.


Thanks and best regards,

-- 
Patrick ZAJDA

Re: Version changing while there is an opened RFS

[Gianfranco Costamagna]

Hello,

>I intent to adopt pidgin-skype package.
>The package version is based on last upstream Git main branch commit, to 
>keep same versioning the package has already.
>
>To successfully enable hardening, I created a patch I contributed 
>upstream by opening a pull request.
>The pull request was merged some hours after.
>
>What should I do now?
>Continue with the same version using the patch?
>Bump new version and in this case, should I only change the actual 
>version in debian/changelog or create a new version to change upstream 
>version and keep the version the RFS is opened for?
>
>Thanks and best regards,


As first answer?
Please ask upstream to release something new, don't make every distribution 
rely on git snapshots,
because it's hard to understand when something is "stable" enough without a 
tagged release.
If this isn't possible, either packaging a new snapshot or applying it as patch 
and bump Debian
revision from N to N+1 is ok.
(maybe it depends on the patch size, if small, a patch is ok to avoid import of 
a new tarball, if the patch
is huge, maybe the latter is preferred. Also, there might be other commits 
between the Debian snapshot
and the patch upstream acceptance, so check all the commits for their 
stability).

Sorry for not providing a good answer but "it depends" is probably the right 
one.

G.

Bug#1059784: RFS: golang-google-api/0.61.0-2 [Team] -- Google APIs Client Library

[Gianfranco Costamagna]

Hello Shengjing,



Uploaded, but I rewrote the git history for easy review.



thanks for the quick reupload!

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059236: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities

[Gianfranco Costamagna]

Hello Tobias

>This. Follow upstream's SONAME, otherwise this can become very tricky in the 
>future.

but please note that this requires work for ftp and release teams.
So, as said (this is also my best choice), make sure upstream fixes the SONAME 
bump for next releases,
we don't want a new SONAME every new release unless really needed, and 
versioning
is something needs to be fixed upstream.

Also, transitions means the package becomes tied to a specific library version, 
and in
this case this looks not needed at all, so there is no good reason to force user
to upgrade everything together.

But as Tobias said, better follow upstream naming, and ask them to fix when 
wrong :)


G. 

Bug#1059236: RFS: nanomsg/1.2+dfsg-1 [ITA] -- nanomsg utilities

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hello,

looking at nanomsg diff:

diff -Nru nanomsg-1.1.5+dfsg/src/nn.h nanomsg-1.2+dfsg/src/nn.h
--- nanomsg-1.1.5+dfsg/src/nn.h 2018-10-15 15:50:59.0 +0200
+++ nanomsg-1.2+dfsg/src/nn.h   2022-04-19 01:29:26.0 +0200
@@ -2,7 +2,7 @@
 Copyright (c) 2012-2014 Martin Sustrik  All rights reserved.
 Copyright (c) 2013 GoPivotal, Inc.  All rights reserved.
 Copyright (c) 2015-2016 Jack R. Dunaway.  All rights reserved.
-Copyright 2017 Garrett D'Amore 
+Copyright 2022 Staysail Systems, Inc. 

+++ nanomsg-1.2+dfsg/src/transports/utils/literal.c 2022-04-19 
01:29:26.0 +0200
@@ -1,5 +1,6 @@
 /*
 Copyright (c) 2012-2013 Martin Sustrik  All rights reserved.
+Copyright 2022 Staysail Systems, Inc.

+++ nanomsg-1.2+dfsg/src/utils/stopwatch.h  2022-04-19 01:29:26.0 
+0200
@@ -1,6 +1,6 @@
 /*
 Copyright (c) 2012 Martin Sustrik  All rights reserved.
-Copyright 2015 Garrett D'Amore 
+Copyright 2022 Staysail Systems, Inc.

These looks missing


But the main reason for the moreinfo tag is that I checked the whole diff file, 
and there is just a new symbols added.

void nn_literal_link_local_resolve(struct in6_addr *in6addr, int64_t 
*sin6_scope_id, char *addr)

And looks not part of the public API exposed, but just called from 
nn_literal_resolve function.

If the symbols are added and not changed, we should be ABI safe, so no 
transition is needed, right?

Please double check for ABI stability, because if this is true, we can save an 
useless trip to new queue.

I leave to you to create a new symlink for backward compatibility, to revert 
the library soname bump, or to keep things as
is.

Also, since the transition will likely involve a couple of packages, it might 
be a good point to just
follow what upstream named and let things go that way (and maybe open an 
upstream bug asking to avoid
changing soname if the API is stable)

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1042024: RFS: hintview/1.3.1-1 [ITP] -- Program to view HINT files

[Gianfranco Costamagna]

On Tue, 25 Jul 2023 23:41:04 +0200 =?UTF-8?Q?Hilmar_Preu=c3=9fe?= 
 wrote:

Control: block 1041668 by -1

On 7/25/23 23:12, Hilmar Preuße wrote:

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
Add blocking statement.




Hello, aren't some licenses MIT?
backend/stb_image.h: The Unlicense MIT License
Linux/main.c: MIT License
Linux/main.h: MIT License
Linux/renderOGL.c: MIT License


G.


OpenPGP_signature
Description: OpenPGP digital signature

Re: Help needed for libssl ABI change

[Gianfranco Costamagna]

For some reasons looks like you are using static libssl.a library.
I don't know if this is the issue, but with static library libssl.a and dynamic 
libcrypto, I don't know how much the linker will be happy to mix them together



quoting the upstream makefile
 ifneq ($(wildcard /usr/lib/x86_64-linux-gnu/libssl.a),)
   L+=/usr/lib/x86_64-linux-gnu/libssl.a
 else
   ifneq ($(wildcard /usr/local/opt/openssl/lib/libssl.a),)
  L+=/usr/local/opt/openssl/lib/libssl.a
   else
  L+=-lssl
   endif

(so for x86_64-linux-gnu only libssl.a is taken)

   ifneq ($(wildcard /opt/local/lib/libcrypto.a),)
  L+=/opt/local/lib/libcrypto.a
   else
  ifneq ($(wildcard /usr/local/opt/openssl/lib/libcrypto.a),)
 L+=/usr/local/opt/openssl/lib/libcrypto.a
  else
 L+=-lcrypto
  endif



You end up mixing static and dynamic ssl libraries.
If you remove the "x86_64-linux-gnu" from wildcard, the libssl.a wont' be found 
anymore, and you will end up with the very same behaviour and build failure of
i386 build, such as the one here:

PATH=/builds/med-team/libucsc/debian/output/source_dir/debian/tmp_blat/usr/bin:/usr/lib/ccache/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 make --directory=src/blat test
make[2]: Entering directory 
'/builds/med-team/libucsc/debian/output/source_dir/src/blat'
blat -verbose=0 hCrea.geno hCrea.mrna testRna.psl
make[2]: blat: No such file or directory
make[2]: *** [makefile:21: test] Error 127
make[2]: Leaving directory 
'/builds/med-team/libucsc/debian/output/source_dir/src/blat'
make[1]: *** [debian/rules:37: override_dh_auto_test] Error 2
make[1]: Leaving directory '/builds/med-team/libucsc/debian/output/source_dir'

G.


Il venerdì 15 settembre 2023 alle ore 12:56:32 CEST, Andreas Tille 
 ha scritto: 





Hi,

I'm trying to build libucsc which fails to build[1].  I suspect this is
due to an ABI change in libssl 1.1 to 3.x.  Any help how to fix this
would be really apreciated.

Kind regards
    Andreas.

[1] https://salsa.debian.org/med-team/libucsc/-/pipelines/579427

-- 
http://fam-tille.de

Re: Environment variable for package base dir

[Gianfranco Costamagna]

$CURDIR? 
G. 

Sent from Yahoo Mail on Android 
 
  On Thu, Aug 11, 2022 at 23:21, Ole Streicher wrote:   Hi,

one of my packages

https://salsa.debian.org/debian-astro-team/sep

requires to specify a path relative to the package base dir (the path to
a shared library), which is important for build and for testing. I,
Python, it is specified in setup.py.

I solved this the following way:

d/rules:
export BUILD_ROOT=$(shell pwd)

setup.py (patched):
buildroot = os.environ.get('BUILD_ROOT', '.')

This works nicely locally (cowbuilder) and in Salsa. However, on the
buildds, the build root is set empty and the build fails.

What is the normal way to get the package build root?

Best

Ole

  

Bug#988230: RFS: libfilezilla/0.28.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

(already sponsored, nevermind)






Il mercoledì 12 maggio 2021, 11:08:35 CEST, Gianfranco Costamagna 
 ha scritto: 





hello,

I can't find the file on mentors...

G.






Il sabato 8 maggio 2021, 10:45:45 CEST, Philip Wyett 
 ha scritto: 





Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name    : libfilezilla
  Version        : 0.28.0-1
  Upstream Author : Tim Kosse 
* URL            : https://lib.filezilla-project.org/
* License        : GPL-2+
* Vcs            : https://salsa.debian.org/debian/libfilezilla
  Section        : libs

It builds those binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla13 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.28.0-1.dsc

Changes since the last upload:

libfilezilla (0.28.0-1) experimental; urgency=medium

Bug#988230: RFS: libfilezilla/0.28.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

hello,

I can't find the file on mentors...

G.






Il sabato 8 maggio 2021, 10:45:45 CEST, Philip Wyett 
 ha scritto: 





Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name    : libfilezilla
  Version        : 0.28.0-1
  Upstream Author : Tim Kosse 
* URL            : https://lib.filezilla-project.org/
* License        : GPL-2+
* Vcs            : https://salsa.debian.org/debian/libfilezilla
  Section        : libs

It builds those binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla13 - build high-performing platform-independent programs (runtime 
lib)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.28.0-1.dsc

Changes since the last upload:

libfilezilla (0.28.0-1) experimental; urgency=medium

Bug#985850: RFS: filezilla/3.53.1-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Gianfranco Costamagna]

control: close -1

done thanks

G.

Re: Sending gpg keys to keyserver

[Gianfranco Costamagna]

Hello,


>I have an upload stuck in the upload queue due to an expired key, and I
>would like upload my newly unexpired key to the Debian keyservers so
>that it is eventually unblocked.
>
>But I get this error:
>$ gpg -v --keyserver keyring.debian.org --send-key 'fingerprint'
>gpg: sending key 0x to hkp://keyring.debian.org
>gpg: keyserver send failed: Connection refused
>gpg: keyserver send failed: Connection refused
>
>So how did I get into this mess?
>
>1. Many years ago followed the riseup.net guide to configure my keys.
>2. Over two years ago set the expiry date of my signing/encryption key
>forwad two years to about now.
>3. Weeks ago, sponsored a package to NEW.
>4. Package was rejected.
>5. The other day, uploaded a fixed package for my sponsee.
>6. Today, realise the upload has silently failed due to expired key.
>7. Extend expiry date of keys forward two more years.
>8. Issue above command, then spend hours of frustrated searching :-)
>
>I should say that I am on an Ubuntu machine (my Debian laptop has other
>issues that need fixing). Googling comes up with gpg changes with
>v2.1(?), and dirmngr now being the default - not curl ($ gpg --help
>gives > gpg (GnuPG) 2.2.19). Riseup.net has completely changed since I
>last looked, and there does not seem to be any updated advice on the
>Debian keysigning pages.
>
>Any ideas on what configuration I might need to update?

gpg --keyserver keyring.debian.org --send-keys mykeyID
works for me on Ubuntu 20.04

G.

Bug#981621: RFS: filezilla/3.52.2+dfsg-3 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Gianfranco Costamagna]

Hello Philip,

while we like to remove non-free stuff from our tarballs, I don't think 
removing dlls is a good use case.

Using the upstream tarball is quite convenient, since we have less importing 
errors, the md5 is the same
and can be verified, and we don't introduce patches that last forever.

DLL files are not used in our build process, so they are not impacting in any 
way the resulting deb file.

Do you think this repack is really worth?

I know sometimes we want to silence lintian, but the cost might just be too 
high for a little gain.

I would like to know if anybody else has a different opinion, please share it 
with me!

thanks for caring about DFSG-ness of the package!

Gianfranco

Bug#979392: RFS: libfilezilla/0.26.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

Hello,

On Thu, 07 Jan 2021 03:21:51 + Philip Wyett  
wrote:
> On Wed, 2021-01-06 at 13:27 +0100, Adam Borowski wrote:
> > On Wed, Jan 06, 2021 at 04:15:28AM +, Philip Wyett wrote:
> > >  * Package name: libfilezilla
> > >Version : 0.26.0-1
> > > 
> > > It builds those binary packages:
> > > 
> > >   libfilezilla0 - build high-performing platform-independent
> > > programs
> > > (runtime lib)
> > >   libfilezilla-dev - build high-performing platform-independent
> > > programs (development)
> > 
> > The soname has changed, you'd need to rename the runtime package to
> > libfilezilla1.
> > 
> > 

Looks like the SONAME is currently set to 11

objdump -p ../libfilezilla.so.11.0.0  |grep -i SONAME
  SONAME   libfilezilla.so.11


I fixed the number and uploaded to binNEW queue, will follow up with filezilla 
once accepted!

G.

Bug#973902: RFS: btrfs-progs/5.9-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities

[Gianfranco Costamagna]

Hello,


>I'm ready to advocate you

nevermind, looks like you are already doing your AM process :)

good luck!

G.





Il giovedì 12 novembre 2020, 00:27:19 CET, Nicholas D Steeves 
 ha scritto: 





Hi Gianfranco,

Thank you for sponsoring!

Gianfranco Costamagna  writes:

> Hello
> Sponsored after adding
>   * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools,
>     because these are not applicable to the backport.
>
> to changelog...
> G.
>

I don't understand why adding this line was required, because I'm using
best-practises for backports (merged changelog), and merging tag from
testing, rather than forking for each release, and I'm generating the
.changes file relative to the last upload to buster-backports (which is
why this entry didn't appear the 5.9-1~bpo10+1 entry).  Full changelog
for buster-backports shows:

btrfs-progs (5.9-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

-- Nicholas D Steeves   Thu, 05 Nov 2020 16:18:31 -0500

btrfs-progs (5.9-1) unstable; urgency=medium

  * New upstream release.

-- Adam Borowski   Fri, 23 Oct 2020 21:22:35 +0200

btrfs-progs (5.7-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.
  * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools,
    because these are not applicable to the backport.

-- Nicholas D Steeves   Tue, 28 Jul 2020 20:31:55 -0400

btrfs-progs (5.7-1) unstable; urgency=medium



Regards,
Nicholas

Bug#973902: RFS: btrfs-progs/5.9-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities

[Gianfranco Costamagna]

Hello,

sorry then, I usually prefer to mention each backport what changed between the 
stable/testing and the backport itself,
but if documentation says that this is not needed, I'm sorry for having changed 
it...

but the real question that comes out is:
why aren't you a DD? :)

you know your stuff, I never had to change a line on what I sponsor to you...

and when I do it, it turns out its a mistake from my side :p

I'm ready to advocate you

G.





Il giovedì 12 novembre 2020, 00:27:19 CET, Nicholas D Steeves 
 ha scritto: 





Hi Gianfranco,

Thank you for sponsoring!

Gianfranco Costamagna  writes:

> Hello
> Sponsored after adding
>   * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools,
>     because these are not applicable to the backport.
>
> to changelog...
> G.
>

I don't understand why adding this line was required, because I'm using
best-practises for backports (merged changelog), and merging tag from
testing, rather than forking for each release, and I'm generating the
.changes file relative to the last upload to buster-backports (which is
why this entry didn't appear the 5.9-1~bpo10+1 entry).  Full changelog
for buster-backports shows:

btrfs-progs (5.9-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

-- Nicholas D Steeves   Thu, 05 Nov 2020 16:18:31 -0500

btrfs-progs (5.9-1) unstable; urgency=medium

  * New upstream release.

-- Adam Borowski   Fri, 23 Oct 2020 21:22:35 +0200

btrfs-progs (5.7-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.
  * Drop hardcoded dep on modern libgcc-s1, and breaks old initramfs-tools,
    because these are not applicable to the backport.

-- Nicholas D Steeves   Tue, 28 Jul 2020 20:31:55 -0400

btrfs-progs (5.7-1) unstable; urgency=medium



Regards,
Nicholas

Bug#972276: RFS: olive-editor/20200620-1 -- Professional open-source NLE video editor

[Gianfranco Costamagna]

On Thu, 5 Nov 2020 10:43:40 +0100 Gianfranco Costamagna 
 wrote:
> Hello, thanks!
> 
> I was just looking to have the qt fixes uploaded and found your RFS
> 
> 

unfortunately it turned out to be not sufficient for qt 5.15.1, this additional 
patch is required
https://github.com/olive-editor/olive/commit/22c5b61898f75654bf889f55c447f4d1c400b8fd

Please prepare a new upload when possible, thanks

https://launchpad.net/ubuntu/+source/olive-editor/20200620-1ubuntu1

G.

G. 
> 
> On Thu, 15 Oct 2020 19:36:19 +0200 =?UTF-8?Q?G=C3=BCrkan_Myczko?= 
>  wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "olive-editor":
> > 
> >   * Package name: olive-editor
> > Version : 20200620-1
> > Upstream Author : Olive Team
> >   * URL : https://www.olivevideoeditor.org/
> >   * License : GPL-3+, MIT
> >   * Vcs : 
> > https://salsa.debian.org/multimedia-team/olive-editor
> > Section : video
> > 
> > It builds those binary packages:
> > 
> >olive-editor - Professional open-source NLE video editor
> > 
> > To access further information about this package, please visit the 
> > following URL:
> > 
> >https://mentors.debian.net/package/olive-editor/
> > 
> > Alternatively, one can download the package with dget using this 
> > command:
> > 
> >dget -x 
> > https://mentors.debian.net/debian/pool/main/o/olive-editor/olive-editor_20200620-1.dsc
> > 
> > Changes since the last upload:
> > 
> >   olive-editor (20200620-1) unstable; urgency=medium
> >   .
> > * New upstream version.
> > 
> > Regards,
> > --
> >Gürkan Myczko
> > 
> > 
> 
> 

Bug#972593: RFS: filezilla/3.51.0-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Gianfranco Costamagna]

Bug#972591: RFS: libfilezilla/0.25.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)

[Gianfranco Costamagna]

Hello,

just FYI, the upload fails on i386
https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial=i386=1.2.1-2=1600846376=0

Due to a difference between i686 and i386

The change in gst-omx might fix this problem

gst-omx (1.18.0-2) unstable; urgency=low

Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]

[Gianfranco Costamagna]

Hello,

> 
> The change from libsane to libsane1 requires IMHO a transition. Therefore only
> in experimental. 
> 
> > I saw you switched from "libsane" to "libsane1". This was not really
> > warranted, the lintian warning that you fixed with this rename
> > was harmless and you should consider the cost to update all the
> > reverse build dependencies (and there are quite a few). However
> > now that you have added the transitional package and that you are
> > already gone through NEW, I guess it's ok to push this to completion.
> 
> Thanks.
> 

We will have for some while, both libsane1 and libsane transitional package.
Rebuilding the reverse-dependencies will make libsane go away faster, but there 
is
no real need to rebuild anything right now, because both dependencies will be 
satisfied.

So, since the ABI seems to have not changed, this is not a "transition" but 
more a
"lets rebuild reverse dependencies so the transitional package can go away 
faster"

But in any case, reverse-dependencies are likely to have some unrelated upload 
in the next months,
so rebuilding them now might be unnecessary (for sure it isn't necessary for 
testing migration).

FWIW in Ubuntu I did the rebuilds :)

Gianfranco

Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3

[Gianfranco Costamagna]

control: tags -1 moreinfo
On Sat, 1 Aug 2020 10:25:24 +0200 Bastian Germann  wrote:
> On Wed, 29 Jul 2020 17:45:32 +0200 mat...@debian.org wrote:
> > That's the `clean` step that is failing, which is done outside of the
> > chroot.  That's responsability of whoever is calling `pdebuild` to
> > satisfy.
> > 
> > If you are sure your source is clean you may as well just skip cleaning
> > and not use pdebuild:
> > dpkg-source -b .
> > dpkg-source --after-build .
> > pbuilder b ../freetype-py_2.2.0-1.dsc
> > the above sequence should prove that nothing is at fault here.
> 
> The package builds fine with the given steps.
> 
> 


nack.
+Copyright 2010-2018 Adobe (http://www.adobe.com/), with Reserved Font Name 
'Source'. All Rights Reserved. Source is a trademark of Adobe in the United 
States and/or other countries.
+
+This Font Software is licensed under the SIL Open Font License, Version 1.1.

missing licenses

other stuff LGTM

G.

Bug#947270: RFS: libfilezilla/0.19.3-1 -- build high-performing platform-independent programs (development

[Gianfranco Costamagna]

 Hello Phil,


>Hi Adrien,
>
>I can use git that is not an issue, but I won't. gbp is a joke - look at
>fedora and pagure. I will put out RFS(s), which I have done, you merge
>them based on submission or not as I do not care. I have put time in and
>submitted updates. You explain to the community how submitters get
>treated. I am done with you lot and DM/DD power.

sorry if you felt bad for this...I admit I'm having not much time nowadays to 
keep up with RFS, and for newcomers the process is somewhat slower...I feel sad 
for your gbp sentence, I like instead it really a lot, next time (if you want 
of course),you can do something easy such as:git clone repocd repouscangbp 
import-orig --pristine-tar ../tarball.tar.gzdo your modifications and commitgbp 
dchfix changelogsend an email requesting sponsorhip without even having to do 
the RFS.
I don't think it is more difficult than your current workflow, but it makes 
easier to review single changes, and to know why you did and what (if 
commitmessages are self explanatory).
I have to say, at the end your work has gone into the archive, so the time was 
not lost at all, and I thank you for the nice contribution you did.
I only had to revert a Break relationship you had erroneously bumped, and 
everything else was nice on the first shot, something not easy to be seenon a 
first RFS bug.
Please let me know if you want to contribute more on Debian, I'm pretty sure 
you have the required skills to do it in the proper way, even if it might bea 
little bit more difficult than the Fedora approach (and trust me, it used to be 
even more difficult, now with salsa we at least have one common place forgit 
repositories)
Gianfranco
  

Bug#942313: RFS: codelite [QA] -- Powerful and lightweight IDE

[Gianfranco Costamagna]

control: close -1

hello, I sponsored it after doing a lot of tweaks, because looks like you 
started to work not from the version 12 in unstable, but from an older version.

Please make sure for the future that:
1) git is up-to-date
2) you start from a version that is in the archive

the code on
https://salsa.debian.org/debian/codelite
should now reflect what is being uploaded in unstable, please send a followup 
RFS in case I did something wrong.

thanks

G.

On Tue, 22 Oct 2019 08:48:35 +1300 Olly Betts  wrote:
> On Tue, Oct 15, 2019 at 10:28:04AM -0400, Anuradha Weeraman wrote:
> > On Tue, Oct 15, 2019 at 02:30:56PM +0100, da...@codelite.co.uk wrote:
> > > This was very quickly fixed by the wxsqlite3 maintainer. Codelite
> > > now builds cleanly in a sid sbuild.
> > 
> > Great, that was quick! Confirmed and looks good...
> 
> Is somebody actually planning to sponsor this upload?
> 
> This is one of the final 3 packages blocking completion of the
> wxwidget3.0-gtk3 transition.
> 
> Cheers,
> Olly
> 
> 

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Gianfranco Costamagna]

 control: owner -1 !control: tags -1 moreinfo
Hello Fabian, 

I tried many times to update it, would you mind pushing your work directly on 
the pkg-llvm repository?
In the meanwhile I'm having a look at your work
Gianfranco
Il martedì 27 agosto 2019, 19:39:28 CEST, Matthew Fernandez 
 ha scritto:  
 
 

On Aug 27, 2019, at 08:48, Fabian Wolff  wrote:
On 8/27/19 4:00 PM, Matthew Fernandez wrote:


z3 (4.8.4-0.1) unstable; urgency=medium


I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a
particular motivation for uploading a 4.8.4-based release?


Thanks for pointing this out; I did not notice this, because I was
using uscan, and upstream suddenly changed the tag format on Github for
tagging new releases:

  https://github.com/Z3Prover/z3/tags


Ah, I was not aware of this either, so we both learned something :)

In the last hour or so, I have tried to import version 4.8.5, but they
apparently changed something in the build system so that building with
Mono no longer works (it fails with 'dotnet: Command not found', and I
don't know what the Mono equivalent of the dotnet command is, or if one
exists at all).


I’ve built 4.8.5 before, but not the .net bindings which I guess is what you’re 
dealing with. I can attempt this but unfortunately won’t have time in the short 
term.

So, I'd say having version 4.8.4 is still better than 4.4.1, and if
someone else wants to give 4.8.5 another try in the future, they can do
so after this upload.


Agreed. Having 4.8.4 available would be a significant improvement. Thanks!  

Re: Debian Salsa and NMUs

[Gianfranco Costamagna]

 Hello,
>I have a question about handling NMUs in Salsa.
>
>Are the rules for NMUs disabled there just because a package is in the
>Debian namespace?

the salsa.d.o/debian is the new "collab-maint" space...collab-maint has been 
create for collaborative maintenance of shared packages, so sometimes people 
(hey, its me!), use that to "team upload" packages,considering it a global 
"team" of people.
I never got anybody angry because of this, and I think I'm not the only one 
doing it...
But in case somebody gets hurt, I think it might be better toa) move the repo 
into a less "shared" groupb) ask to avoid team uploads.
There are a few corner cases to the above...
G.
  

Bug#934478: RFS: sane-backends/1.0.28-1~experimental1

[Gianfranco Costamagna]

control: owner -1 !control: tags -1 moreinfoHello Joerg!
thanks for the update!
some nitpicks:


I would like to see fixed before having another deeper look:

debian/libsane1.NEWSis it still needed?
sane-backends-1.0.27/debian/libsane.dirs
sane-backends-1.0.27/debian/libsane.symbols
sane-backends-1.0.27/debian/libsane.install
last little thing: 
I don't want to start another flamerwar such as the one in #908681, I hope this 
time nobody will complain... :/
btw you can see the build with the changes I requested here
(mostly, delete old libsane.* files, and remove the NEWS file)

thanks!

Il domenica 11 agosto 2019, 13:57:33 CEST, Jörg Frings-Fürst 
 ha scritto:  
 
 Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "sane-backends"

  Package name    : sane-backends
  Version        : 1.0.28-1~experimental1
  Version        : 1.0.27-4~experimental1
  Upstream Author : sane-de...@alioth-lists.debian.net
  URL            : http://www.sane-project.org
  License        : GPL-2+ with sane exception, GPL-2+, GPL-3+,  
                    Artistic, LGPL-2.1+
  Section        : graphics

  It builds those binary packages:

    sane-utils - API library for scanners -- utilities
libsane-common - API library for scanners -- documentation and support files
      libsane1 - API library for scanners
  libsane-dev - API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends


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

    dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.28-1~experimental1.dsc

or from git

  
https://jff.email/cgit/sane-backends.git/?h=release%2Fexperimental%2F1.0.28-1_experimental1

 

Changes since the last upload:

  * New upstream release.
    - New debian/patches/0040-remove_git.patch to remove git access at
      build time.
    - Refresh patches:
      + debian/patches/0700-mk_reproducible_results.patch.
      + debian/patches/0710-sane-desc.c_debian_mods.patch.
      + debian/patches/0715-20-sane.hwdb_multi-arch.patch.
      + debian/patches/0725-fix_link_60-libsane_rule.patch.
      + debian/patches/0100-source_spelling.patch.
    - Refresh symbols file.
    - Refresh lintian overrides.
  * debian/rules:
    - Add --exclude=/sane/ to override_dh_makeshlibs-arch to generate
      only public symbols (Closes: #911597).
    - Don't install obsolete hal fdi file (Closes: #913282).
  * Remove architecture dependent symbols files.
  * Merge release 1.0.27-3.2 into source tree.
    - I disagree the changes from 1.0.27-3.1.
    - Thanks to John Paul Adrian Glaubitz for the bug fix.
  * New debian/patches/0725-fix_link_60-libsane_rule.patch:
    - Fix directory for 20-sane.hwdb (Closes: #916239).
  * New debian/patches/0155-genesys_gl847.patch:
    - Fix discolored bar on GL847 chip based scanners (Closes: #912603).
  * Fix missing set device to group scanner (Closes: #918358);
    - New debian/99-libsane.rules.
    - debian/libsane.install: Install File into /etc/udev/rules.d/
    - Change debian/TROUBLESHOOTING.Debian
  * debian/sane-utils.config: Remove the RUN parameter in compliance with
    Debian Policy Manual section 9.3.3.1 (Closes: #915197).
  * debian/copyright:
    - Add year 2019 for debian/*.
    - Add missing Uploaders to debian/*.
    - Refresh for the new upstream release.
  * Fix the lintian warning "libsane: package-name-doesnt-match-sonames
    libsane1":
    - debian/control: rename package libsane to libsane1.
    - debian/rules: Change filenames and directories from libsane to libsane1.
    - Rename debian/99-libsane.rules to debian/99-libsane1.rules.
  * Refresh debian/patches/0100-source_spelling.patch.
  * New debian/libsane-common.lintian-overrides and
    debian/libsane1.lintian-overrides to override false positive spelling-error.
  * Fix autopkgtest.
  * Migrate to debhelper 12:
    - Change debian/compat to 12.
    - Bump minimum debhelper version in debian/control to >= 12

Bug#928733: RFS: pysword/0.2.6-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hello,
> https://mentors.debian.net/debian/pool/main/p/pysword/pysword_0.2.6-1.dsc

https://salsa.debian.org/python-team/modules/pysword/commit/76182799b003ca504c74aa2a6383549095a65e2f

where are them taken? I can't see and find them in the original source tree...

Moreover they are not listed anywhere in debian/* files, so I presume they are 
dropped on next upstream release...

Please adjoust debian/{watch,copyright} to add/remove them during uscan or 
import of the source, or remove them,
or maybe move them to debian/* folder so they are kept during upgrades, and 
copy on build directory during build...

But in any case, we should have a way to know where they were taken, and to 
recreate them if needed (they look like binaries to me)

other things LGTM!

G.

Bug#931934: RFS: sane-backends/1.0.27-4~experimental1

[Gianfranco Costamagna]

 control: owner -1 !control: tags -1 moreinfo
Hello Joerg!thanks for the update!
some nitpicks I would like to see fixed before having another deeper 
look:debian/libsane1.NEWSis it still needed?
sane-backends-1.0.27/debian/libsane.dirssane-backends-1.0.27/debian/libsane.symbolssane-backends-1.0.27/debian/libsane.install
last little thing: 
I don't want to start another flamerwar such as the one in #908681, I hope this 
time nobody will complain... :/
btw you can see the build with the changes I requested 
herehttp://debomatic-amd64.debian.net/distribution#experimental/sane-backends/1.0.27-4~experimental1/buildlog
(mostly, delete old libsane.* files, and remove the NEWS file)
feel free to grab the dsc once the build is over, and then fix if you see other 
lintian complains.
thanks!
G.


Il venerdì 12 luglio 2019, 16:48:24 CEST, Jörg Frings-Fürst 
 ha scritto:  
 
 Package: sponsorship-requests
Severity: normal 

  Dear mentors,

  I am looking for a sponsor for my package "sane-backends"

  Package name    : sane-backends
  Version        : 1.0.27-4~experimental1
  Upstream Author : sane-de...@alioth-lists.debian.net
  URL            : http://www.sane-project.org
  License        : GPL-2+ with sane exception, GPL-2+, Artistic, 
                    LGPL-2.1+
  Section        : graphics

  It builds those binary packages:

sane-utils    - API library for scanners -- utilities
libsane-common - API library for scanners -- documentation and support files
libsane1      - API library for scanners
libsane-dev    - API development library for scanners [development files]

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

  https://mentors.debian.net/package/sane-backends


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

    dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.27-4~experimental1.dsc

or 

  https://jff.email/cgit/sane-backends.git/?h=release%2F1.0.27-4_experimental1


  Changes since the last upload:

  * debian/rules:
    - Add --exclude=/sane/ to override_dh_makeshlibs-arch to generate
      only public symbols (Closes: #911597).
    - Don't install obsolete hal fdi file (Closes: #913282).
  * Remove architecture dependent symbols files.
  * Merge release 1.0.27-3.2 into source tree.
    - I disagree the changes from 1.0.27-3.1.
    - Thanks to John Paul Adrian Glaubitz for the bug fix.
  * New debian/patches/0725-fix_link_60-libsane_rule.patch:
    - Fix directory for 20-sane.hwdb (Closes: #916239).
  * New debian/patches/0155-genesys_gl847.patch:
    - Fix discolored bar on GL847 chip based scanners (Closes: #912603).
  * Fix missing set device to group scanner (Closes: #918358);
    - New debian/99-libsane.rules.
    - debian/libsane.install: Install File into /etc/udev/rules.d/
    - Change debian/TROUBLESHOOTING.Debian
  * debian/sane-utils.config: Remove the RUN parameter in compliance with
    Debian Policy Manual section 9.3.3.1 (Closes: #915197).
  * debian/copyright:
    - Add year 2019 for debian/*.
    - Add missing Uploaders to debian/*.
  * Fix the lintian warning "libsane: package-name-doesnt-match-sonames
    libsane1":
    - debian/control: rename package libsane to libsane1.
    - debian/rules: Change filenames and directories from libsane to libsane1.
    - Rename debian/99-libsane.rules to debian/99-libsane1.rules.
  * Refresh debian/patches/0100-source_spelling.patch.
  * New debian/libsane-common.lintian-overrides and
    debian/libsane1.lintian-overrides to override false positive spelling-error.
  * Fix autopkgtest.
  * Migrate to debhelper 12:
    - Change debian/compat to 12.
    - Bump minimum debhelper version in debian/control to >= 12

Bug#922951: RFS: btrfs-progs/4.20.1-2~bpo9+1

[Gianfranco Costamagna]

 (side note: sorry for being late)Nicholas I just granted you DM for the 
package. This is something I wanted to do already a while ago, but I could do 
it onlynow that the package is QA maintained, so feel free to maintain it alone 
in backports, and in unstable if Adam is fine with that
thanks!
G.Il lunedì 18 marzo 2019, 03:12:25 CET, Nicholas D Steeves 
 ha scritto:  
 
 Hi Chris,

On Fri, Mar 15, 2019 at 08:15:04AM -0400, Chris Lamb wrote:
> Hi Nicholas,
> 
> > Here is another one that has been awaiting sponsorship for a while.
> 
> Uploaded:
> 
>    Uploading btrfs-progs_4.20.1-2~bpo9+1.dsc

Thanks!

Nicholas  

signature.asc
Description: PGP signature

Bug#911773: marked as done (RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP])

[Gianfranco Costamagna]

 
nack
Oct 25 17:42:59 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 17:47:59 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 17:47:59 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 17:53:00 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 17:53:00 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 17:58:01 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 17:58:01 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes processed 
successfully (uploader team+pkg...@tracker.debian.org)
Oct 25 18:03:01 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:03:01 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:08:01 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:08:01 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:13:05 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:13:05 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:18:06 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:18:06 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:23:08 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:23:08 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:28:18 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:28:19 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:33:20 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:33:20 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:38:21 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:38:21 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:43:36 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:43:36 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:48:36 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:48:36 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)
Oct 25 18:53:36 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 18:53:36 golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
doesn't exist (ignored for now)


G.
Il giovedì 25 ottobre 2018, 18:36:25 CEST, Alexandre Viau 
 ha scritto:  
 
 On 2018-10-25 11:58 a.m., Alexandre Viau wrote:
> I don't understand how some files are left on the queue.
> 
> the orig.tar.gz has been there for almost an hour now. But the .changes
> was processed. I don't understand what is going on...
> 

I cleaned the upload queue.

Uploaded again.

Sadly my connection was bad and I had to resume the upload.

Hopefully this works now.

-- 
Alexandre Viau
av...@debian.org
  

Bug#911773: marked as done (RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP])

[Gianfranco Costamagna]

 Oct 25 15:11:12 > rm golang-github-rivo-tview*
Oct 25 15:11:12 Files removed: 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1_source.changes 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1.debian.tar.xz 
golang-github-rivo-tview_0.0~git20181018.a7c1880.orig.tar.gz 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.buildinfo 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1_source.buildinfo 
golang-github-rivo-tview-dev_0.0~git20181018.a7c1880-1_all.deb 
golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:16:39 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:16:39 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 15:21:40 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:21:40 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 15:26:41 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:26:42 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc has 
incorrect md5 checksum; deleting it
Oct 25 15:31:42 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:31:43 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 15:36:43 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:36:43 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 15:41:48 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:41:48 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 15:46:48 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:46:48 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 15:51:51 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 15:51:51 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)

nack.

Il giovedì 25 ottobre 2018, 17:21:34 CEST, Alexandre Viau 
 ha scritto:  
 
 On 2018-10-25 10:48 a.m., Gianfranco Costamagna wrote:
> Hello,
> 
> Oct 25 14:45:36 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc
> doesn't exist (ignored for now)
> Oct 25 14:46:09 processing
> /golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
> Oct 25 14:46:10 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc
> doesn't exist (ignored for now)
> 
> 
> please redo it!
> 
> the upload process is stopped by that error

Done.

Let me know if it didn't work.

Cheers,

-- 
Alexandre Viau
av...@debian.org
  

Bug#911773: marked as done (RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP])

[Gianfranco Costamagna]

 Hello,
Oct 25 14:45:36 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)
Oct 25 14:46:09 processing 
/golang-github-rivo-tview_0.0~git20181018.a7c1880-1_amd64.changes
Oct 25 14:46:10 golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc doesn't 
exist (ignored for now)


please redo it!
the upload process is stopped by that error
G.

Il mercoledì 24 ottobre 2018, 18:48:56 CEST, Debian Bug Tracking System 
 ha scritto:  
 
 Your message dated Wed, 24 Oct 2018 12:45:45 -0400
with message-id <61c217d0-21df-c6c3-f44f-0c8d2fcfc...@debian.org>
and subject line Re: Bug#911773: RFS (team upload): 
golang-github-rivo-tview/0.0~git20181018.a7c1880-1 [ITP]
has caused the Debian Bug report #911773,
regarding RFS (team upload): golang-github-rivo-tview/0.0~git20181018.a7c1880-1 
[ITP]
to be marked as done.

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

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


-- 
911773: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911773
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problemsPackage: sponsorship-requests
Severity: wishlist
Control: -1 block 905240
X-Debbugs-CC: debian...@lists.debian.org, av...@debian.org

Dear mentors,

I am looking for a sponsor for my package "golang-github-rivo-tview".

This package is a prerequisite for upcoming package "git-lab" (#898246).

This package will be maintained as part of the Go Packaging Team going forward.

* Package name    : golang-github-rivo-tview
  Version        : 0.0~git20181018.a7c1880-1
  Upstream Author : Oliver Kuederle 
* URL            : https://github.com/rivo/tview
* License        : Expat
  Section        : devel

It builds those binary packages:

  golang-github-rivo-tview-dev - Rich interactive widgets for terminal-based 
UIs in Go

If you have access to Salsa, please check out:

  https://salsa.debian.org/go-team/packages/golang-github-rivo-tview

Otherwise, please visit the following URL (You can also find the orig.tar.gz 
here):

  https://mentors.debian.net/package/golang-github-rivo-tview

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-rivo-tview/golang-github-rivo-tview_0.0~git20181018.a7c1880-1.dsc

Thanks for your time! Any review is appreciated.

Regards,
 Jongmin Kim

-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8On 
2018-10-24 12:37 p.m., Jongmin Kim wrote:
> Thanks, Alexandre!
> 
> On Wed, Oct 24, 2018 at 12:17:49PM -0400, Alexandre Viau wrote:
>> Why would you set builder and cleaner in debian/gbp.conf?
>>
>> It has nothing to do with the layout of the repository. It should be up
>> to whoever maintains the package to decide how he wants to build it.
> 
> Yes, it can be personalisable. I removed it.
> 
> Many thanks for your careful review.

Uploaded!

Thank you for your contribution.

I am sorry for the delay, apparently you had asked me to review a while
ago but it started a discussion about repository layout that I did not
read on debian-go.

I think somebody else sponsored the upload because it looks like there
are already files on the UploadQueue.

I'll upload it again in 10 minutes just to be sure.

I'll close this bug.

Cheers,

> 

-- 
Alexandre Viau
av...@debian.org
  

Re: Debian package transition: Rename package and reuse old name with new content

[Gianfranco Costamagna]

>I'm not sure of the transition policies when handling transitions on
>testing and unstable only (ie: not involving stable).
>But that should ensure there is no breakage between package in the archive.


if you are just renaming a package,, and the reverse-deps are not too many,
better avoid transitional packages, ask for a transition slot on release.d.o,
open bugs (MBF?) with patches, and raise to serious once RT acks the transition.

G.

Bug#901726: RFS: json-c/0.13.1+dfsg-1 [QA] -- JSON manipulation library

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

> I need an upload to experimental so I can request a transition slot (the ABI
> changed, and so did the soname); I moved the packaging repository to 
> salsa.d.o,
> so please fetch the source from there (`git buildpackage` ought to do the 
> right thing):
> 
> I previously requested a sponsored upload from Stefano (in CC) privately,
> but he seems to not be very available currently.
> 
lets take this one:
some issues:

1) why are you repacking it? is really bundled jquery a "dfsg" problem?
In general, repack with dfsg is done to solve licensing issues, not because of 
bundled deps.
You might use "ds" (Debian source), if you think you can save useful bits, but 
I think 
this is not really the case.

Please instead, use rules file to ship the jquery you want, or remove it in 
clean target
(unless it really has some license issues).

BTW, replacing jquery for doc might even be a bad idea
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736360

So, please be careful with it.

2) missing copyrights:
+ * Copyright (c) 2016 Alexandru Ardelean.
+ * Copyright (c) 2016 Eric Haszlakiewicz
(and probably more)

so, once both issues are addressed, I can sponsor it!
(I still need to do a build test)

also, don't forget to request a transition slot!

G.






Il Domenica 17 Giugno 2018 16:12, Nicolas Braud-Santoni 
 ha scritto:



Package: sponsorship-requests

Severity: normal

Control: block 


Hi,


I am looking for a sponsor for a QA upload to “json-c”:


  * Package name: json-c

  * Version: 0.13.1+dfsg-1

  * Upstream: Metaparadigm Pte. Ltd. 

  * URL: https://github.com/json-c/json-c/

  * License: Expat

  * Section: main


It is a dependency of d-i (through cryptsetup), pam-u2f (through libu2f-*), ...


I need an upload to experimental so I can request a transition slot (the ABI

changed, and so did the soname); I moved the packaging repository to salsa.d.o,

so please fetch the source from there (`git buildpackage` ought to do the right 
thing):


  https://salsa.debian.org/debian/json-c



I previously requested a sponsored upload from Stefano (in CC) privately,

but he seems to not be very available currently.



Best,


  nicoo


-- System Information:

Debian Release: buster/sid

  APT prefers testing

  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')

Architecture: amd64 (x86_64)


Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)

Shell: /bin/sh linked to /bin/dash

Init: systemd (via /run/systemd/system)

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

[Gianfranco Costamagna]

Hello,

>The next thing you might try is `git deborig`.  But I understand just
>asking Dmitry!


git deborig -f upstream/3.14

same effect, as well
as 
git deborig -f v3.14...

G.

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

[Gianfranco Costamagna]

Hello,


>Please try typing `origtargz`.


it downloads the current one in the archive, without the patches, and then it 
fails with:


dpkg-source: warning: the diff modifies the following upstream files: 
.git/HEAD
.git/config
.git/description
.git/hooks/applypatch-msg.sample
.git/hooks/commit-msg.sample
.git/hooks/post-update.sample
.git/hooks/pre-applypatch.sample
.git/hooks/pre-commit.sample
.git/hooks/pre-push.sample
.git/hooks/pre-rebase.sample
.git/hooks/pre-receive.sample
.git/hooks/prepare-commit-msg.sample
.git/hooks/update.sample
.git/info/exclude
.git/logs/HEAD
.git/logs/refs/heads/master
.git/logs/refs/remotes/origin/HEAD
.git/packed-refs
.git/refs/heads/master
.git/refs/remotes/origin/HEAD
libinotifytools/src/test.c
man/inotifywait.1
man/inotifywatch.1
src/common.c
src/inotifywait.c
dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented 
changes to upstream files, see dpkg-source(1)


Dmitry, can you please upload the tarball somewhere?

I notice there is a 3.20.1 out there

G.

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

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hello Dmitry
sorry for taking too long for this one.
I did:
grab inotify-tools from experimental
grab the debian directory from the git repo, and debdiffed the results.
I'm worried about the disappear of "debian-changes" patch, is it somewhere 
else? should I get a new orig tarball?
I don't want my upload to make something disappear from the patch queue, due to 
my lack of dgit procedures.

Please tell me the commands to get the source in the right way(TM)
and then I'll look/sponsor if the patch has to disappear for some ways.
other things LGTM, the package builds in my pbuilder, and probably in ppas too.

Not sure why Sean has issues, I can't really reproduce them!

Gianfranco

Bug#887665: marked as done (RFS: usbguard/0.7.1+ds-1)

[Gianfranco Costamagna]

On Fri, 16 Mar 2018 16:50:18 +0100 Muri Nicanor <m...@immerda.ch> wrote:
> hm, somehow i didn't receive that mail...
> 
> On 03/15/2018 10:54 AM, Gianfranco Costamagna wrote:
> > control: owner -1 ! control: tags -1 moreinfo
> > 1) please fix the qt bug in this upload
> > 2) missing lots of copyrights, e.g. src/ThirdParty/Catch/* 
> > src/ThirdParty/PEGTL/*
> > do you need such external libraries? why aren't it packaged separately?
> they are- i apparently forgot to readd the folder to files-excluded at
> some point. i readded the folder now and repackaged and reimported the
> archive.
> 
> > 3) std-version is 4.1.3
> yes, should it not be?
> 
> > 4)  dh ${@} --parallel --with=autoreconf
> > isn't this automatic with compat level 10?
> both removed.
> 
> i've also fixed a bug in the usbguard.postinst script that errored out
> if one of the chmoded files didn't exist.
> 
> i've uploaded new versions of the packages to mentors.d.o and pushed all
> the commits to salsa.
> 
> cheers and thanks,

happily sponsored!

G.

> muri
> 

Re: Bug with sev: grave while new package waiting

[Gianfranco Costamagna]

Hello,

>please check if rebuilding works with the version in experimental, in that case
>you will need to do something like =5.9, and compute that value at runtime, 
>rather than hardcoding it
>(so a binNMU will work).


please fix the stuff I pointed in the rfs, and discard the qt commit.
Qt folks told me that stuff should probably auto-fix when qt will finish 
building, so this bug is
not worth the effort in fixing it.
(and meh, using experimental is a source of similar breakages anyway)

G.

Re: moving teams to salsa

[Gianfranco Costamagna]

hello, 


thanks you all! I already read all the docs, will do the migration :)

G.




Il Giovedì 15 Marzo 2018 15:39, Joseph Herlant  ha scritto:



Hi,


> Is anybody willing to point me some wiki and help in doing the migration?

Once you've read Paul and Mattia's docs (which will give you all the
needed informations) you can read how
https://salsa.debian.org/mehdi/salsa-scripts works (in its README) to
help an easier migration.

Joseph

Bug#890573: RFS: fcitx-qt5/1.2.2-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

> I am looking for a sponsor for team package "fcitx-qt5":

why can't people on the team process this one?


the packaging looks good, but not being part of the team, makes things harder 
for me

G.



signature.asc
Description: OpenPGP digital signature

Bug#890756: RFS: youtube-dl/2018.01.27/1.1 [NMU] -- downloader of videos from YouTube and other sites

[Gianfranco Costamagna]

Hello,

>All that being said, I will upload a new version of youtube-dl during the
>next few days...


do you have any update?

thanks

Gianfranco

Re: piuparts - installation and purging test

[Gianfranco Costamagna]

Hello,

>I am maintaining vim-lastplace. A few days ago I saw on my Debian
>Maintainer Dashboard that piuparts was failing at the installation and
>purging test. Today I wanted to fix this, but the message was gone. So
>piuparts now succeeds on piuparts.d.o .
>
>But when I run piuparts on my local machine, it still fails at the
>installation and purging test. I had a look at the test and have no idea
>what it fails.
>Are there any known issues like that?


yes, sometimes unrelated packages leave stuff on the system, for unrelated 
reasons,
stuff fix itself after some days (with some new uploads!)

G.

Re: Bug with sev: grave while new package waiting

[Gianfranco Costamagna]

>> "libqt5core5a (<<5.10)" this will make it uninstallable when 5.10 goes in 
>> unstable...
>> isn't it better to just make it compatible with new qt stack? I don't want 
>> to make qt folks
>> sad.
>hm, maybe i'm misunderstanding the problem, but i thought the applet
>only works with the qt version it was compiled with. is it even possible
>to build a package for unstable with a library from experimental? or is
>there a way to make it compatible with both versions?


please check if rebuilding works with the version in experimental, in that case
you will need to do something like =5.9, and compute that value at runtime, 
rather than hardcoding it
(so a binNMU will work).

see src:virtualbox-ext-pack to see how you can feed such values from rules file.

And please get in touch with qt folks, maybe they already have something to do 
that.

G.


signature.asc
Description: PGP signature

Re: Bug with sev: grave while new package waiting

[Gianfranco Costamagna]

Hello,
>Thanks, i've added some commits and specified the qt version and pushed
>everything to salsa.


please also address the stuff on RFS bug
and...
--with=autoreconf
isn't this useless too?


"libqt5core5a (<<5.10)" this will make it uninstallable when 5.10 goes in 
unstable...
isn't it better to just make it compatible with new qt stack? I don't want to 
make qt folks
sad.

G.

Bug#849754: RFS: guerillabackup/0.0.0-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
Hello,


>I am looking for a sponsor for my package "guerillabackup"


I would really like to see the package working, but I see the upstream repo
is lacking the history, this makes the Debian work less efficient in 
cherry-picking
new stuff.
Two commits are really not that much, seems like an inactive project.
Is it the case?

Please note: I maintain borgbackup, that I think is really more powerful 
(complete) than
your tool (please have a look at it).

G.

moving teams to salsa

[Gianfranco Costamagna]

Hello Mentors list, I would like to move pkg-boinc and pkg-virtualbox teams to 
salsa, problem is:

1) I can't create new teams
2) I don't know how to move the lists
3) I lack the time to find/look for the documentation (and I lost it)
4) I need some "import git repo" link, because uploading a git repo from 
scratch from my laptop will
takes days, specially for virtualbox-guest-additions-iso and vbox team packages.

Is anybody willing to point me some wiki and help in doing the migration?

thanks!

Gianfranco

Bug#887665: marked as done (RFS: usbguard/0.7.1+ds-1)

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

1) please fix the qt bug in this upload
2) missing lots of copyrights, e.g. src/ThirdParty/Catch/* 
src/ThirdParty/PEGTL/*
do you need such external libraries? why aren't it packaged separately?
3) std-version is 4.1.3
4)  dh ${@} --parallel --with=autoreconf
isn't this automatic with compat level 10?

dh ${@} should be enough now

other stuff LGTM

G.



signature.asc
Description: OpenPGP digital signature

Re: Bug with sev: grave while new package waiting

[Gianfranco Costamagna]

Hello,

>there is a bug with severity: grave in usbguard, because of a libqt5
>version incompatibility (#892045) and there is already a new version of
>usbguard waiting to be sponsored. Should i fix the bug in the new
>version or should i fix it in the version thats already in the archive?


I'm taking the new version, feel free to fix it on top of the new one.
(the new version has some issues, so maybe we will do only one upload)

G.

Bug#883379: RFS: deepin-voice-recorder/1.3.6-1 [ITP]

[Gianfranco Costamagna]

control: tags -1 moreinfo

> Is there any possibility of renaming this directory to deepin-manual
> or deepin-manuals (if deepin-manual is already taken by the
> deepin-manual package)? I think dman is too generic and likely to be
> confused for something related to man-db.
I agree here

G.



signature.asc
Description: OpenPGP digital signature

Bug#890666: RFS: mmh/0.3-3

[Gianfranco Costamagna]

On Sat, 17 Feb 2018 17:34:32 +0300 Dmitry Bogatov  wrote:
> 
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "mmh"
> 

ack, done

G.

> * Package name : mmh
>   Version  : 0.3-3
>   Upstream Author  : markus schnalke 
> * Url  : http://marmaro.de/prog/mmh/
> * Licenses : BSD-3-clause
>   Programming Lang : C
>   Section  : mail
> 
>  This is the mmh mail user agent (reader/sender), a command-line based mail
>  reader that is powerful and extensible.  mmh is an excellent choice for
>  people who receive and process a lot of mail.
>  .
>  Unlike most mail user agents, mmh is not a single program, rather it is a
>  set of programs that are run from the shell.  This allows the user to
>  utilize the full power of the Unix shell in coordination with mmh.
>  .
>  Mmh is a modified version of the electronic mail handling system nmh.
>  Nmh (new MH) itself was originally based on the package MH-6.8.3, and
>  was intended to be a (mostly) compatible drop-in replacement for MH.
>  In contrast, mmh is not intended to be a drop-in replacement for nmh,
>  rather mmh breaks compatibility to nmh in order to modernize and
>  simplify it.
> 
> It builds those binary packages:
> 
>   * mmh
> 
> This package succesfully builds on debomatic machine:
> 
>   https://debomatic-i386.debian.net/distribution#unstable/mmh/0.3-3
>  
> Please note, that package is maintained with dgit(1) tool
> using dgit-maint-merge(7) workflow. For more information about how to
> sponsor this package, see dgit-sponsorship(7).
> 
>   Git repository: https://salsa.debian.org/iu-guest/mmh.git
>   Git branch: master
> 
> With /bin/sh following commands should suffice:
> 
>   $ git clone https://salsa.debian.org/iu-guest/mmh.git mmh
>   $ cd mmh
>   $ make -f debian/rules get-orig-source # 'gbp buildpackage' is fine
>   $ dgit sbuild
> 
> 
> Changes since last upload:
> 
>   * Update Vcs-* fields in debian/control.
>   * Compile with large file support
>   * Update standards version to 4.1.3 (no changes needed)
>   * Bump compat version to 11 (added explicit --no-parallel, since upstream



signature.asc
Description: OpenPGP digital signature

Bug#883384: RFS: deepin-deb-installer/1.2.1-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

same dman directory, same reviews as previous packages needs fixing, lintian is 
complaining a lot
http://debomatic-amd64.debian.net/distribution#unstable/deepin-deb-installer/1.2.1-1/lintian


-> 0001-Enable-CMake-Debug.patch

this need to be upstreamed, and probably renamed, "remove-gcc-optimizations" or 
something like that, since it removes the
default O3 optimization level.

G.



signature.asc
Description: OpenPGP digital signature

Bug#883379: RFS: deepin-voice-recorder/1.3.6-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

grep DOCDIR . -R
./deepin-voice-recorder.pro:isEmpty(DOCDIR):DOCDIR=/usr/share/dman/deepin-voice-recorder
./deepin-voice-recorder.pro:manual.path = $$INSTROOT$$DOCDIR


Why is the package installing stuff in /usr/share/dman? nothing in the archive 
uses such directory.

I'm reluctant to sponsor it, unless you provide some good explanation, and post 
a patch to upstream.
(BTW the patch 0001 looks useless, please forward upstream).

The other std-version, debhelper bump, and so on still apply
also lintian
I: deepin-voice-recorder: desktop-entry-lacks-keywords-entry 
usr/share/applications/deepin-voice-recorder.desktop


Other stuff LGTM.



signature.asc
Description: OpenPGP digital signature

Bug#891005: RFS: gdbm/1.14.1-5

[Gianfranco Costamagna]

Hello Ansgar


>This means building the package will give different results depending
>on dietlibc-dev installed or not?  That shouldn't happen...
>
>Please check via some other means that a build using dietlibc has been
>requested; don't do different things just because a package happens to
>be installed.
mmm the result is not a different library, but an additional static library put
in a non-standard directory, built with another glibc.
I think there is nothing to worry about :)

this is the path:
/usr/lib/*/diet/*/libgdbm.a


G.

Bug#891005: RFS: gdbm/1.14.1-5

[Gianfranco Costamagna]

Hello 



>With all my respect, I am very relucant to solve problems of Ubuntu at
>expense of Debian output. What exactly is wrong, Debian-wise, in package
>we are discussing, apart the need to specify long list of architectures,
>so I could fix it?


this is not an "Ubuntu" problem, but something that even Debian
had (remember, 4 bugs opened in less than a week).
So I would say, I'm reluctant in re-enabling something that did cause a lot
of troubles to Debian folks :)

Anyhow, if you want to enable, you can do something like this, to make me and 
you
happy, and then easily revert when new bugs are opened

HAVE_DIETLIBC=no
ifeq ($(shell dpkg -s dietlibc-dev | grep -o installed), installed)
DIET_LIBDIR := $(shell diet -L gcc)
HAVE_DIETLIBC=yes
endif

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
HAVE_DIETLIBC=no
endif


>Short answer: >  because you need it to link program, using gdbm, with diet 
>libc,
>  resulting small static executable.
>Full answer: 
>  because I believe Debian should provide not only libraries for
>  build-dependencies of something in /bin, but also libraries for
>  developers to develop with.
>
>  I did some search, and seems this is already happening. We have a lot
>  of leaf libraries (mostly perl and java), for example: 
>- libxmlenc-java 
>- libwx-scintilla-perl

>

I can understand the reasons for having it, but the question is:
does it work?
How can I run some simple make commands to see if everything works?
because people on the bug reports tried and they said it wasn't working.

If you want to enable it, please make sure it works :)

>Or maybe we just need Guix/Nix?


I don't get this :)



cheers!

G.

Bug#891005: RFS: gdbm/1.14.1-5

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hello!
>!Important! This upload re-enables diet libc support {conditional, via
>build profiles}. Input from developers, experienced with Debian
>bootstrap is very, very welcome.


Since this is causing troubles in Ubuntu (Matthias, please give your opinion 
here),
because dietlibc is in main, and gives also troubles to maintain the list of 
dietlibc
architectures where it is available, since it causes troubles using dietlibc
(the build seems failing), I would prefer to actually implement it again once 
dietlibc folks
makes the whole stuff *working*.

Right now the approach is not usable, and makes things harder for Ubuntu and 
Debian.
(e.g. in Ubuntu we should conditionalize and remove it, with something like
if dpkg-vendor --derives-from Ubuntu; then

HAVE_DIETLIBC=nofi

but even in that case, the pulling of build-dependencies from universe will 
cause mismatches in the
archive.

I would prefer a patch from dietlibc folks, with an use case of *why* they need 
this static library,
rather than building/including something that caused 4 bugs in Debian, a lot of 
pain in Ubuntu
(and probably was even broken).

The other stuff looks good to me :)

What is your opinion? I would like to understand why we need this, and if this 
had even worked.

G.

Re: Change file permissions

[Gianfranco Costamagna]

Hello,
>they are not 600. should i set the file permissions on package upgrade
>or should i leave this to the user?

>if i should set them, should i use postinst or is there a better way?

is a dh_fixperms override helpful?

G.

Re: Problem with Git Push

[Gianfranco Costamagna]

Hello, please give me your salsa username and use that one.
I'm going to delete the one in collab-maint right now :)

G.




Il Giovedì 4 Gennaio 2018 22:33, eamanu15 .  ha 
scritto:



Gianfranco, 



>this is a private repo
>
>please push there
>git remote add upstream 
>git+ssh://youru...@anonscm.debian.org/git/collab-maint/cligh.git
>
>I just created a clone of that repo, and we will need a new unstable upload 
>with the new VCS fields in case.
>

I have this error:

remote: error: insufficient permission for adding an object to repository 
database ./objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To git+ssh://anonscm.debian.org/git/collab-maint/cligh.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 
'git+ssh://eamanu-gu...@anonscm.debian.org/git/collab-maint/cligh.git'

What happens? That sound like I don't authorized my ssh-key, but I do. 


-- 

Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Re: Problem with Git Push

[Gianfranco Costamagna]

Hello,

>Are there some chance that the repo of cligh is in Salsa?


I don't see any collab-maint on salsa, and I prefer to wait some more days 
before
migrating to it...
anyhow, created by importing from collab-maint https link
https://salsa.debian.org/debian/cligh

have fun!

G.

El jue., 4 de ene. de 2018 a la(s) 11:01, eamanu15 . 
 escribió:

please push there
>>git remote add upstream 
>>git+ssh://youru...@anonscm.debian.org/git/collab-maint/cligh.git
>>
>>I just created a clone of that repo, and we will need a new unstable upload 
>>with the new VCS fields in case.
>>
>>
>Ok, Thanks!.  I will make this tonight
>
>
>
>Regards!
>
>Emmanuel
>
>
>-- 
>
>Arias Emmanuel
>https://www.linkedin.com/in/emmanuel-arias-437a6a8a
>http://eamanu.com
>
-- 

Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Re: Problem with Git Push

[Gianfranco Costamagna]

Hello,


>Afterclone, I add the new changes and I try to make a push origin but I have 
>this error:The requested URL returned error: 403.


this is a private repo

please push there
git remote add upstream 
git+ssh://youru...@anonscm.debian.org/git/collab-maint/cligh.git

I just created a clone of that repo, and we will need a new unstable upload 
with the new VCS fields in case.

G.

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Gianfranco Costamagna]

Hello Hugh,


>33 reverse build dependences FTBFS after the removal of freetype-config.>11 
>don't care, and 42 already use pkg-config to detect freetype2.


ok, so fix all the reverse dependencies *before* dropping it, not after.
We don't usually "break stuff and let maintainers fixup things", but:
1) open bugs (maybe with patches)
2) integrate patches upstream
3) ask a transition slot (since this involves more than 10 packages, better ask 
on -devel
for an Mass Bug Filing)
4) Upload the breaking change after reverse-deps migrated to testing
>freetype-config is a wrapper for pkg-config if the latter is installed. 
>Unfortunately, 
>this outputs the wrong libdir when cross-compiling. This is also the case when 
>using the autoconf-detected path via the 'else' block.


ack, seems a good fallback method.

Anyhow, we are really blocked by Steve, I pinged him on irc, maybe we can fix 
this old bug
now!

G.

Bug#884769: RFS: freetype/2.8.1-0.2 [NMU]

[Gianfranco Costamagna]

control: tags -1 moreinfo

> >   - Exclude freetype-config, freetype-config.1 and freetype2.m4
> > from installation in libfreetype6-dev.
> > 

https://codesearch.debian.net/search?q=freetype-config

this is a big no-go, first, please ask Steve to review, but I would assume this 
patch
is wrong, because a lot of packages are right now calling freetype-config in 
their build
script.
(in libpng1.6 we kept it with removing of the multi-arch bits, to make it have 
the same
md5sum across multiple architectures).
See: 
https://sources.debian.org/src/libpng1.6/1.6.34-1/debian/patches/libpng-config.patch/

G.



signature.asc
Description: OpenPGP digital signature

Bug#884429: Uploaded to unstable

[Gianfranco Costamagna]

control: close -1
On Mon, 18 Dec 2017 17:31:27 +0100 Nicolas Braud-Santoni 
 wrote:
> Control: reopen -1
> 
> Upload was rejected (something something non-existing signature file 
> referenced
> in .changes); I'm just reopening this so we don't forget about it.

I'm trying harder.

G.



signature.asc
Description: OpenPGP digital signature

Re: How to switch all->any?

[Gianfranco Costamagna]

Hello,


>How can I get rid of that? 0.7.9-1 is in the Debian archives, but
>neither part of testing, nor of unstable. It would however useful to
>keep this version, f.e. for use in snapshots.d.o.


it will  be kept in snapshots regardless of your removal.


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

just ask to remove the arch:all too and you should be done

rmadison -u debian sunpy
sunpy  | 0.7.4-2   | stable | source
sunpy  | 0.7.9-1   | unstable   | source
sunpy  | 0.7.9-1   | unstable-debug | source
sunpy  | 0.8.1-2   | unstable   | source
sunpy  | 0.8.1-2   | unstable-debug | source
sunpy  | 0.8.2-1   | unstable   | source
sunpy  | 0.8.2-1   | unstable-debug | source


python-sunpy | 0.7.9-1   | unstable   | hurd-i386
python-sunpy | 0.8.1-2   | unstable   | kfreebsd-i386, powerpc
python-sunpy | 0.8.2-1   | unstable   | amd64, arm64, armel, i386, 
kfreebsd-amd64, mips, mips64el, mipsel, ppc64el, s390x


the old source seems to be still around in the archive, not sure why

G.

Re: source package upload fail? Bug - #859130 ITP: lina -- iso- Forth interpreter

[Gianfranco Costamagna]

>Sorry to have bothered you. All answers are in
>https://mentors.debian.net/qa


I'm quite busy right now, good luck with mentors uploads :)

G.

Re: ZFS packaging

[Gianfranco Costamagna]

>Would it be possible to have someone look over the changes I've made
>and/or make suggestions as to how I could get these changes incorporated
>into Debian?


it is usually better to open wishlist bugs for improvements (with patches)
and then in case open an RFS bug.

Looks the new release is already uploaded, not sure if anything is still missing
from your packaging wrt the upload one, feel free to contact the maintainers 
again
in case or open bugs.

G.

Re: Multi-arch header conflict and pkg-config

[Gianfranco Costamagna]

Hello,


>pkg-config --cflags also just outputs -I/usr/include/.
>Does pkgconfig support multiple paths like this?


add the triplet to your .pc shipped file
/usr/lib/x86_64-linux-gnu/pkgconfig/python-3.6m.pc:Cflags: 
-I${includedir}/python3.6m -I${includedir}/x86_64-linux-gnu/python3.6m


Other programs do this too, so with some sort of patch this should be possible
(they are sometimes created during build, otherwise you will need some sed 
during install or similar

G.

strange alternate dependencies behaviour.

[Gianfranco Costamagna]

Hello, I would like to package a new boinc-virtualbox metapackage, that installs
virtualbox and the extpack.

Unfortunately the upstream vbox provides a virtualbox-5.0, virtualbox-5.1 or 
virtualbox-5.2 (provides virtualbox)

and the debian one provides virtualbox, and nothing more (except from 
conflicting with the Oracle one)

Package: boinc-virtualbox
Architecture: amd64 i386
Section: contrib/misc
Priority: optional
Depends: ${misc:Depends}, boinc-client, boinc-manager, virtualbox | 
virtualbox-5.0 | virtualbox-5.1 | virtualbox-5.2

Now, I have installed the virtualbox-5.2 from Oracle website, and installing 
boinc-virtualbox tries to remove it

sudo apt-get install boinc-virtualbox 
Reading package lists... Done
Building dependency tree 
Reading state information... Done
The following additional packages will be installed:
virtualbox virtualbox-dkms virtualbox-ext-pack virtualbox-qt
Suggested packages:
vde2 virtualbox-guest-additions-iso
The following packages will be REMOVED:
virtualbox-5.2
The following NEW packages will be installed:
boinc-virtualbox virtualbox virtualbox-dkms virtualbox-ext-pack virtualbox-qt
0 upgraded, 5 newly installed, 1 to remove and 11 not upgraded.
Need to get 24,5 MB of archives.
After this operation, 60,5 MB disk space will be freed.

why?

I don't know what can cause such issue...


G.

Re: source package ready, lintian remark Bug - #859130 ITP: lina -- iso- Forth interpreter

[Gianfranco Costamagna]

Hello,


>At last I have a debian archive for lina that is generated using proper 
>procedures
>(debhelper, quilt etc.) from the (upstream) source package:


can you please upload to mentors.debian.org and open an RFS bug?

G.

Re: Packaging work is done for php-db-dataobject (a dependency for GNU Social)

[Gianfranco Costamagna]

Hello,

>suggestions and uploaded to mentors[1]. There was a sponsor in 2016, but
>he is not responding now. Can anyone look into this package!. Thank you.


done now

G.

Re: Doubt about using a forked version for a new package release

[Gianfranco Costamagna]

Hello Nelson,

>Debian has pngnq at version 1.0 with the latest upstream version at 1.1
>The fork https://sf.net/projects/pngnqs9 is at version 2.0.2
>
>The best option seems, indeed, to offer the forked version (as
>https://bugs.debian.org/862077 also says)


usually a good starting point is to see what other distro did (e.g. Fedora, 
Suse, Arch),
and discuss with old/new upstream.

Having a new package providing pngnq and conflicting / replacing it is feasible
https://www.debian.org/doc/debian-policy/ch-binary.html#virtual-packages

you can use update-alternative to let users choice their preferred 
implementation.

Honestly I would start by updating pngnq to the latest version + patches, and 
then
maybe pack the new one in experimental and ask for testing or whatever
(you can also pack it as patch on top of the non-fork version)

At the end, it should be up to you and your users (also debian-devel is 
probably a good
place to ask "which version is better")

G.

Re: Package rejected bc of missing .orig

[Gianfranco Costamagna]

Hello,

>usbguard   | 0.7.0+ds1-1   | unstable   | source, amd64, arm64, armel, 
>armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x

so it seems a mentors.d.o bug then (e.g. DebOMatic is smart enough to find the 
orig tarball automatically when already in the archive) :)

BTW: "changestool *.changes includeallsources" works to include the orig 
tarballs.



"Rejecting incomplete upload. You did not upload 
virtualbox_5.1.28-dfsg.orig.tar.xz and we didn't find it on any of our 
alternative resources.
If you tried to upload a package which only increased the Debian revision part, 
make sure you include the full source (pass -sa to dpkg-buildpackage)"

I just tried, I'm not sure if this is a regression, or never worked :)

G.

Re: Package rejected bc of missing .orig

[Gianfranco Costamagna]

> i'm trying to upload usbguard_0.7.0+ds1-2 to mentors, but it gets rejected:


but if the 0.7.0+ds1-1 is not in the archive... why upload a -2 version?
this seems a versioning bug to me, rather than a missing -sa.

(-1 revisions use -sa by default)

G.

Bug#862868: RFS: shc/3.9.4-4

[Gianfranco Costamagna]

control: tags -1 moreinfo
> 
> Uploaded a new one, kept the version same as the previous upload:
> shc-3.9.6-1
> 

sigh: missing changelog entries
1)  * new upstream release
  - closes foobar #bugNNN

^^ this is the correct syntax
2) bump compat level
3) std-version is now 4.1.0
4) autotoools-dev is now useless
5) switch to https
6) copyright changes: don't you think changing license from GPL-2 to GPL-3 is 
worth a changelog entry?
7) dropped debian/* copyright why?
8) patches dropped/foo
9) keys foo/added signatures
10) "--with autotools_dev" I would say useless in compat level 10, as well as 
the override_dh_auto_clean
11) update watch file location

and so on.

(the packaging looks mostly ok, the above points are missing in changelog

G.



signature.asc
Description: OpenPGP digital signature

Bug#876027: RFS: libcgicc/3.2.19-0.2 [NMU] -- C++ class library for writing CGI applications

[Gianfranco Costamagna]

Hello,


> This is the diff of /usr/bin/cgicc-config between packages from different
> architectures 


exactly :) sorry if I wasn't clear at the begin

BTW the only patch the package is carrying at this moment, has been created to 
make
the package multiarch. So, moving the configurator outside usr/bin, will make 
the patch
even useless.

we did this for some packages already, libsdl2 (only in git I patched it)
https://anonscm.debian.org/cgit/pkg-sdl/packages/libsdl2.git/commit/?id=d461026ee1fcbc930d51c6ce51d343ef9ef7fcc2

also, libpng, and I rebased the patch when we started the libpng1.6 transition 
to the new package.

patching it shouldn't be difficult to do, with some sed, or even if possible by 
just removing CXXFLAGS
from that file
(or splitting them into a reproducible and non-reproducible part)


>https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html>Links
> mentioned there may be useful to you too.


thanks, it was useful also for me :)

G.

Bug#876027: RFS: libcgicc/3.2.19-0.2 [NMU] -- C++ class library for writing CGI applications

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

>* Package name: libcgicc

hello, I find this approach a little bit too invasive

-cxxflags="-Wall -W -pedantic -g -O2 
-fdebug-prefix-map=/build/libcgicc-GEfIf8/libcgicc-3.2.19=. 
-fstack-protector-strong -Wformat -Werror=format-security"
+cxxflags="-Wall -W -pedantic -g -O2 
-fdebug-prefix-map=/build/libcgicc-pUjh6F/libcgicc-3.2.19=. 
-fstack-protector-strong -Wformat -Werror=format-security"


changes are just about that debug-prefix-map variable.. couldn't we just get 
rid of it and leave the file in that directory?

Moving the file outside $PATH is useless for its purpose.

maybe some sed magic can do the trick?


-fdebug-prefix-map=old=new
When compiling files in directory old, record debugging information describing 
them as in new instead.

so, probably not needed at runtime :)

G.

Re: Riddled by debian-policy 8.1.1 about ldconfig

[Gianfranco Costamagna]

Hello,

>Shared libraries must now invoke "ldconfig" by means of triggers,

>instead of maintscripts.


I think this is automatically generated during build, if you don't override it.

so, if you don't have them, you are safe :)

G.

Bug#848416: closing RFS: pyvtk/0.5.18-1 [ITA]

[Gianfranco Costamagna]

control: close -1

Hello,

>I'm still considering the idea, but your remarks are really relevant. As I
>will clearly have no time for that until march 2018 at the best, I think
>we'd better close the RFS and reset the things as they were.


lets re-evaluate this with a new RFS bug once things are clear/ready :)

G.

Re: Build-dependencies for qt5

[Gianfranco Costamagna]

Hello,

>instead. From this, I take that I have to use "export QT_SELECT = 5" in
>d/rules; but what are then my required build dependencies? Just
>qtchooser? Or do I need to install any qt5 development package as well?


I think qtbase5-dev is the minimum dependency you need to install, but
I'm not sure anymore, I remember asking Lisandro a while ago and getting
his working answer back (you can have a look at src:qviaggiatreno in case)

G.

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[Gianfranco Costamagna]

On Fri, 7 Jul 2017 10:04:49 + (UTC) Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> 
> 
> >I'm not sure what you mean.
> >These are dev dependencies, they are used by big-integer developers to 
> >perform various development tasks, but they are not required to simply 
> >use the library so there is no point in packaging them in Debian.
> >And they are *not* embedded in the package, they only appear in 
> >package.json.
> 
> 
> this makes sense, thanks.
> So the review goes to the next step.
> 1) licenses are missing (even if not used in the binary package, the copyright
> should list all the licenses in the source code).
> 2) please use the same copyright as upstream for Debian packaging, this will 
> make
> patch upstreaming possible without having to explicitly relicense them

ping

G.
> 
> G.
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#848416: closing RFS: pyvtk/0.5.18-1 [ITA]

[Gianfranco Costamagna]

On Fri, 19 May 2017 11:05:32 + (UTC) Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> Hi,
> 
> 
> >* Package the thing with this actual bug, but as far as I'm concerned I
> >   consider it as grave, so I'm not really a fan of this idea.
> 
> 
> me neither
> 
> >* Patch the issue myself, as a debian patch, and package the thing with it.
> 
> unmaintainable on the long run
> 
> 
> >* Fork the project (it's BSD 2-Clause license), patch it, and provide it as> 
> >  a personnal work, with credit to the original author.
> 
> 
> if you want to fork, consider that this might be a lot time consuming
> 

ping :)


G.



signature.asc
Description: OpenPGP digital signature

Bug#864241: RFS: pnmixer/0.7.2-1 -- Simple mixer application for system tray

[Gianfranco Costamagna]

Hello,


> > Done, the watch file seem to work according to `uscan`, but
> mentors.debian.net says there's a problem. I'm not sure what's wrong.
> 
> Take a look on [1] as an example, your `watch` file is broken
> presumably since you're calling `uupdate` directly.
> 
> [1]https://wiki.debian.org/debian/watch#GitHub
> 

what is the status of this RFS?

G.



signature.asc
Description: OpenPGP digital signature

Bug#862868: RFS: shc/3.9.4-4

[Gianfranco Costamagna]

Hello Tong,

On Mon, 24 Jul 2017 22:40:59 +0500 Andrey Rahmatullin  wrote:
> Control: tags -1 + moreinfo
> 
> On Thu, May 18, 2017 at 03:32:48AM +0600, Md Jahidul Hamid wrote:
> >   Changes since the last upload:
> > 
> >   * Fix for infinite loop (Closes: #861180)
> I don't think it's the only change as the last upload is 3.8.9b-1 and this
> version is 3.9.4-4. It seems you've made the packaging from scratch, which
> is wrong by the way, but that still doesn't mean you can drop the old
> changelog entries.
> 
> -- 

somebody (upstream?) is trying to update your package, can you please 
coordinate together?


G.



signature.asc
Description: OpenPGP digital signature

Re: javalib-but-no-public-jars lintian

[Gianfranco Costamagna]

>N:does not contain any JAR file in /usr/share/java, while the java policy


my $is_transitional = $info->is_pkg_class('transitional');
if (!$has_public_jars && !$is_transitional && $pkg =~ /^lib[^\s,]+-java$/){
# Skip this if it installs a symlink in usr/share/java
my $java_dir = $info->index_resolved_path('usr/share/java/');
my $has_jars = 0;
$has_jars = 1
if $java_dir
and any { $_->name =~ m@^[^/]+\.jar$@o } $java_dir->children;
tag 'javalib-but-no-public-jars' if not $has_jars;
}



I would say, it detects that the end of the link is outside usr/share/java, but
only usr/share.

Technically the symlink is in usr/share/java, but the link points to outside.

However, I'm really not sure if my perl-foo (close to zero) is correct enough

G.

Bug#868435: RFS: imglib2/4.3.0-1 [ITP]

[Gianfranco Costamagna]

control: tags -1 moreinfo

please remove the tag once the transfer is sorted out

G.



signature.asc
Description: OpenPGP digital signature

Bug#863010: RFS: golang-github-nebulouslabs-bolt/1.0+git20170131.0.ca9f208-1 [ITP]

[Gianfranco Costamagna]

On Fri, 16 Jun 2017 08:48:34 +0200 Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> >   * New upstream version 
> 
> missing changes, e.g.
> "add myself to uploaders"
> 

ping

G.



signature.asc
Description: OpenPGP digital signature

Bug#867617: RFS/ITP: node-rollup-plugin-replace/1.1.1-1

[Gianfranco Costamagna]

On Sat, 8 Jul 2017 08:00:08 + (UTC) Gianfranco Costamagna 
<locutusofb...@debian.org> wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> >  I am looking for a sponsor for my package "node-rollup-plugin-replace"
> 
> 
> I don't have the uploaded binaries with me anymore, so please
> remove moreinfo tag once they gets accepted and I'll have a look
> 
> the packaging is good, maybe you can:
> 1) go for debhelper compat level 10
> 2) use https in copyright file
> 
> but they are really nitpicks here :)
> 

ping

G.



signature.asc
Description: OpenPGP digital signature

Bug#868544: closing 868544

[Gianfranco Costamagna]

Seems to have been rejected

G.



signature.asc
Description: OpenPGP digital signature

Re: Search sponsor for package elog

[Gianfranco Costamagna]

>
>I search for a new sponsor for package elog: 
>https://tracker.debian.org/pkg/elog
>
>
>There are two versions to sponsor right now:
>
>1: 2.9.2+2014.05.11git44800a7-2+deb8u2 for jessie-pu --> see


since this was a grave bug fix I sponsored it, and also the one in unstable,
but *please* as said, open RFS bugs,
thanks

G.

Bug#868768: RFS: iperf3/3.2-1

[Gianfranco Costamagna]

control: owner -1 !

control: tags -1 moreinfo

Please:
Copyright (c) 2009-2017 Dave Gamble and cJSON contributors
Copyright (c) 2000 Markus Friedl.  All rights reserved.

Copyright (c) 2005,2006 Damien Miller.  All rights reserved.


Copyright: 1991-2016, The Regents of the University of California

 (year)


nice to have:
compat level 10
(drop autoreconf from rules and control files)

did the ABI change? I don't think, but please double check

G.

Bug#867617: RFS/ITP: node-rollup-plugin-replace/1.1.1-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

>  I am looking for a sponsor for my package "node-rollup-plugin-replace"


I don't have the uploaded binaries with me anymore, so please
remove moreinfo tag once they gets accepted and I'll have a look

the packaging is good, maybe you can:
1) go for debhelper compat level 10
2) use https in copyright file

but they are really nitpicks here :)

G.

Bug#862930: RFS: node-big-integer/1.6.22-1 [ITP]

[Gianfranco Costamagna]

>I'm not sure what you mean.
>These are dev dependencies, they are used by big-integer developers to 
>perform various development tasks, but they are not required to simply 
>use the library so there is no point in packaging them in Debian.
>And they are *not* embedded in the package, they only appear in 
>package.json.


this makes sense, thanks.
So the review goes to the next step.
1) licenses are missing (even if not used in the binary package, the copyright
should list all the licenses in the source code).
2) please use the same copyright as upstream for Debian packaging, this will 
make
patch upstreaming possible without having to explicitly relicense them

thanks

G.