Different symbols for different architectures

[Mattia Rizzolo]

I maintain a new package, licenseutils, for witch I had a very bad
response from buildd:
https://buildd.debian.org/status/package.php?p=licenseutils&suite=sid

Seems that different architectures have different symbols. So I'm
looking for a way to address this issue.
As dh_makeshlibs(1) states if I need to provide different symbols file
for different architectures I have to append $arch at the end of the
file name, but in this way I have to ship 12 symbols files! Doesn't
seem a very clean solution to me.

Anybody has a better solution than mine?

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHKYmeu8j4=uqu72kh8mg1jpnwfvmvsn4f2nkfl5sxw9e5x...@mail.gmail.com

Re: Different symbols for different architectures

[Mattia Rizzolo]

On Dec 29, 2013 11:43 AM, "Paul Wise"  wrote:
>
> On Sun, Dec 29, 2013 at 5:24 PM, Mattia Rizzolo wrote:
>
> > Seems that different architectures have different symbols.
>
> To me it doesn't look that simple, since the missing symbols are the
> same on many arches. It seems like upstream is basing the
> presence/absence of some public functions on what is returned by
> ./configure.
> If rpl_* means replacement for broken functions (I guess it does), it
> may even be leaking symbols that are meant to be private, which should
> definitely be fixed.

After some considerations I think you are right..

Anyway, I kindly forwarded the issue upstream and he though that a shared
library for such a program was too much, and changed the makefile to build
only the three binaries. I imported the upstream commit as a quilt patch,
and uploaded a new release.

Now licenseutils build quite fine (I'm looking forward to fix also the
remaining FTBFSes  on the exotic arches)

Re: Cjs failing test

[Mattia Rizzolo]

On Wed, Feb 5, 2014 at 6:14 PM, Roelof Wobben  wrote:
> oke, and how can I override to not using test or not using a particular test.
> What the test actually test I do not know.
> I made a issue on the githb page of cjs : 
> https://github.com/linuxmint/cjs/issues/5

In my (currently unique) package in debian, there is a test that
require network access to work. Since there are various buildd that
disallow internet access from inside the chroot the test failed. I
addressed this issue patching the affected tests [0] so they exit the
test if there is no network available (exit code 77 marks the test as
skipped, as you can see in the buildlog the test is skipped, not
failed nor passed).
I think in your case should be better to mark it as xfail, not skip,
since you expect a fail, but I don't know how to do so.


[0] 
http://sources.debian.net/src/licenseutils/0.0.7-3/debian/patches/skip-test-if-network-is-not-available.patch

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cahkymesqbaurvgof3pmqm9x+atnwwbuqwmqkkrv0vpnfead...@mail.gmail.com

Re: How to deal with reviews in mentors.debian.net and repositories for new packaging work

[Mattia Rizzolo]

On Feb 26, 2014 10:56 AM, "Emmanuel Kasper"  wrote:
> I have also read on the list that some mentors like to have a link to a
> VCS to review the pacaking work. Is it possibile to host the packaging
> work on alioth when you're not a Debian Developper ?
>

Sure, but you need a DD to advocate you. See
https://wiki.debian.org/Alioth/PackagingProject

> I know for instance NetBSD has an extra CVS repo called pkgsrc-wip where
> all newbies can out their stuff before it's added to the real thing.
> If not I can use github/gitorious.

Usually for a simple package should be used collab-maint project, and not
an external project.

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Feb 28, 2014 10:52 AM, "Mikhail Morfikov"  wrote:
>
> I'm new to building packages by using pbuilder tool, and I have to build
> a package multiple times before it builds successfully, or in the way
> I prefer. The most annoying part ot this is installation of
> dependencies -- each time I build a package, it has to install
> the same dependencies over and over.

You shouldn't try to preserve the environment, every time you build stuff
you should have a clean installation.

I "developed" a set of scripts to easy have and manage multiple chroots and
speed up building.

See
https://gitlab.com/mapreri/settings/blob/master/pbuilder/scripts/pbuilder-common(rename
the file like pbuilder-sid-amd64 (or symlink,as you prefer) that
works in combo with this .pbuilderrc (
https://gitlab.com/mapreri/settings/blob/master/pbuilderrc) install on the
host ccache and eatmydata, all the stuff will live in ~/pbuilder.

Maybe you can catch some hints on how to resolve your issue

(That repo is there to let me deploy a new system and keep track of some
settings of some tools I use.)

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Feb 28, 2014 11:17 AM, "Vincent Cheng"  wrote:
> Hmmm, out of curiousity, how is this different from pbuilder-dist (in
> ubuntu-dev-tools)?

The concept is the same, but it is quite different:
* integrate support for ccache and apt caching for separate dists (every
dists uses a different directory, while pbuilder-dist uses a single
/var/cache/pbuilder/apt that causes me some issues, iirc)
* it does a lot more checks (e.g., it checks if the correct qemu package is
installed if needed)
* correct support for non x86 arches (for now only arm64, it uses
qemu-debootstrap for it)
* with the pbuilderrc I set up like eatmydata witch speed up all the steps,
the apt depends resolver to gdebi, witch is quite faster than the default
(I don't remember the default now), ccahe
* other thing I don't remember now.
Out of that script there is also some pbuilder hooks, for example.

In short, it's write around my needs :)

Yes, the concept is the same, but since it doesn't satisfied me I wrote my
own pbuilder-dist-like script+pbuilderrc.
Since I keep all my configurations in git and that script is quite good
looking I though other can benefit of it.
Maybe when it's better write, better support of all the cases I'll
encounter I'll  ask the maintainer of ubuntu-dev-tools (or devscripts,
maybe) to include it or part of it.

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Fri, Feb 28, 2014 at 10:42 PM, Barry Warsaw  wrote:
> This is one of the reasons why I prefer to use sbuild for most of my local
> builds.  You can tell it to preserve the chroot when the build fails, and it's
> easy to go in, inspect the build environment, and tweak your package into
> building.  Occasionally, it's even useful to preserve the chroot when the
> package build succeeds, just to poke around.

Just to point out that you can do the same with pbuilder (using
hooks). At this time there is no so much differences between sbuild
and pbuilder.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAHKYmevanxkkh0ZWqhOKP=e4xsVQpoM_ui2dN=7s_cdmybk...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Sat, Mar 1, 2014 at 4:17 AM, Paul Wise  wrote:
> If you can convince the pbuilder and sbuild maintainers to work
> together to merge all the missing parts of
> pbuilder/cowbuilder/qemubuilder into sbuild,

That would be a great adventure!


-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymevzugact_9yfc_pcu687-36zv43ruwejy0mmjszmee...@mail.gmail.com

Re: Sponsor for haxe package maintaining

[Mattia Rizzolo]

On Thu, Mar 6, 2014 at 4:32 PM, Bo Lorentsen  wrote:
> Hi ...
>
> I have been building haxe locally for a while now, on both stable and
> testing (and have been using Debian as a developer for more than 10 years),
> and I really would like to try maintaining the haxe package, as it need some
> attention and to be able to give just a bit back to Debian.

Great!

> Need I sign this mail using a gpg signature ? or is it ok just to ask ?

The process is quite "harder" than that, nothing difficult, though :)

In this page is explained quite well:
https://mentors.debian.net/intro-maintainers (please, follow links
from that page)

Anyway, this is not the right list to write, debian-mentors (here
CC'ed) is far better, where you can find a sponsor, by filing a bug
against the pseudo-package sponsorship-request (using the template
from mentors.d.n)
If you have any question about the packaging, please write to that ML.
Any review to your package will be a follow-up to the RFS bug, and
thus an email to the debian-mentors ml.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymeuzqdvy8f0cj0xmy9oof8bgicvnzsetfcz+491rawg...@mail.gmail.com

Re: Sponsor for haxe package maintaining

[Mattia Rizzolo]

On Mar 6, 2014 10:16 PM, "Bo Lorentsen"  wrote:
>
> On 03/06/2014 05:01 PM, Mattia Rizzolo wrote:
>>
>> Need I sign this mail using a gpg signature ? or is it ok just to ask ?
>> The process is quite "harder" than that, nothing difficult, though :)
>
> Ok, thanks for the pointer, it is a bit confusing to navigate between all
this, otherwise fine, documentation :-)

No worries. :)
Debian docs cover every aspect of every field, but it's spread all around
the web :S

>> In this page is explained quite well:
>> https://mentors.debian.net/intro-maintainers (please, follow links
>> from that page)
>
> I will read a bit more 
>
> /BL

Only a note: you replied only to me. Often in debian's MLs there are a lot
of people cc'ed on emails. When replying is considered polite keeping the
cc list, if you don't know who you are dropping from that list.

Anyway, I'm not a DD, but if you are in touch with a DD you can avoid most
of the passage enumerated in the page I linked and contact him. In fact,
you should contact him before filing a rfs.

Re: No upstream versioning

[Mattia Rizzolo]

On Apr 24, 2014 1:00 PM, "Benjamin Donald-Wilson"  wrote:
>
> On Thu, Apr 24, 2014 at 8:49 PM, Christian Kastner  wrote:
>> If that doesn't work, another possibility would be to create a mock
>> version number based on the date, for example
MMDD.{7-digit-commit-ID}.
>>
> ​So I will most likely go with this option and build the package tomorrow.
>

Consider using 0+gitMMDD.commitID

So if upstream start tagging their release will be simpler.

Bug#827355: RFS: burp/1.4.40-1 [QA] -- Simple cross-platform network BackUp and Restore Program

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

continuing over IRC :)

On Wed, Jun 15, 2016 at 06:36:20PM +0900, Sean Whitton wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a QA upload of burp.
> 
> * Package name: burp
>   Version : 1.4.40-1
>   Upstream Author : Graham Keeling 
> * URL : http://burp.grke.net/
> * License : AGPL-3
>   Section : utils
> 
> Changes since the last upload:
> 
>   * QA upload.
>   * Set maintainer to QA team.
>   * Package new upstream release (Closes: #774715).
> Upstream identifies version 1.4.40 as their "stable" release.
>   * Apply patch from Svante Signell to fix build on the GNU Hurd
> (Closes: #675761, #747672).
>   * Add Recommends: openssl (Closes: #745376).
>   * Repair d/copyright:
> - Move 'Files: *' paragraph to the top of the file
> - Move src/win32/compat/getopt.c and src/win32/compat/sys/mtio.h
>   paragraphs to end of file
> - Add myself to paragraph for debian/ subdir
> - Correct invalid shortname agplv3 -> AGPL-3
> - Factor out AGPL-3 license to a License: paragraph.
> - Correct invalid shortname Troy D. Hanson License -> custom1
> - Correct copyright years for src/win32/compat/sys/mtio.h
> - Correct some indentation and trailing whitespace
>   * Replace burp-dbg with automatically generated burp-dbgsym.
> - Drop obsolete rules target override_dh_strip.
> - Drop obsolete burp.install.
> - Drop obsolete burp.dirs.
> - Drop obsolete burp-dbg.maintscript.
>   * Drop endian.patch.
> Merged upstream.
>   * Drop wait_for_backup_to_finish.patch.
> Merged upstream.
>   * Refresh a patch.
>   * Bump standards version to 3.9.8 (no changes required).
>   * Update Vcs-* URIs.
>   * Add gbp.conf.
> 
> Download with dget:
> 
> dget -x 
> http://mentors.debian.net/debian/pool/main/b/burp/burp_1.4.40-1.dsc
> 
> Or build it with gbp:
> 
> gbp clone --pristine-tar --debian-branch=debian 
> https://git.spwhitton.name/burp
> cd burp
> git checkout debian/1.4.40-1
> git verify-tag debian/1.4.40-1 # if you have my key
> gbp buildpackage
> 
> Notes:
> 
> 1. I am using a branch called 'debian' because the master branch in the
>collab-maint repo seems to be used for experimental, not sid.  I
>added a gbp.conf so everything should work in the expected way.
> 
> 2. I have an application for collab-maint pending.  When it goes through
>I intend to push my work there; the above git clone URI is temporary.
> 
> 3. Successful sbuild: 
> http://debomatic-i386.debian.net/distribution#unstable/burp/1.4.40-1/buildlog
> 
> Thanks.
> 
> -- 
> Sean Whitton



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#827700: RFS: cplay/1.50-1 [NMU]

[Mattia Rizzolo]

On Wed, Jun 22, 2016 at 10:10:37AM +0200, Tobias Frost wrote:
> > I'm ccing them both, and a member of MIA team, even if I'm unsure about the
> > MIA process for non DD people,
> 
> MIA Team is also handling non-DD, so I'm on it already.

BTW, the maintianer *is* a DD (the comaintainer is not).
And the MIA process is not "just" about orphaning packages, but also
making sure whether the involved person is still interested in being
part of the project.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Blocked bugs

[Mattia Rizzolo]

On Mon, Jul 04, 2016 at 09:25:02PM +0200, Christian Seiler wrote:
> So the RFS bug blocking the ITP is actually correct. In your case,
> someone was so nice to add the information that the RFS bug blocks
> the ITP bug for you.

FTR, that's an automated thing by bartm.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#822634: RFS: magit-svn/2.1.1-1 [ITP]

[Mattia Rizzolo]

Hi there.

On Sun, May 15, 2016 at 05:23:20PM +, Mattia Rizzolo wrote:
> On Mon, Apr 25, 2016 at 10:43:41PM +0200, Alberto Luaces wrote:
> >   I am looking for a sponsor for my package "magit-svn"
> 
> o/

1,5 months ago I provided a review of this.

Are you still interested in getting this package into debian?

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#823742: RFS: hdf-compass/0.6.0-1 [ITP]

[Mattia Rizzolo]

On Thu, Jul 07, 2016 at 12:34:10PM +0100, Ghislain Vaillant wrote:
> I have addressed Mattia's comments regarding the tests and manpage. I
> am now happy with the state of the package and believe it to be fit for
> upload.
> 
> The new version is available on mentors:
> 
> 
> https://mentors.debian.net/debian/pool/main/h/hdf-compass/hdf-compass_0.6.0-1.dsc

the git repository is not up to date, please push, I prefer doing stuff
over git for team maintained packages where git is used.
besides, the previous version was versioned 0.6.0b5-1 which is greater
than this one.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: reproducible-builds

[Mattia Rizzolo]

On Mon, Jul 18, 2016 at 06:20:51PM -0300, Herbert Fortes wrote:
> Em Seg, 2016-07-18 às 20:28 +0800, Paul Wise escreveu:
> > On Mon, Jul 18, 2016 at 8:18 PM, Herbert Fortes wrote:
> > 
> > > I did a QA and reproducible-builds says that
> > > it FTBFS with armhf on 2016-07-09. The
> > > build was not tried again.
> > 
> > Which package ?
> 
> 
> dvbackup
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/dvbackup.html
> 
> At the end has:
> 
> [...]
> I: Current time: Fri Jul  8 18:38:51 GMT+12 2016
> I: pbuilder-time-stamp: 1468046331
> Sat Jul  9 06:41:09 UTC 2016 - the second build failed, even though the first 
> build was successful.
> 
> https://tests.reproducible-builds.org/debian/unstable/armhf/dvbackup : 
> reproducible ➤ FTBFS
> Sat Jul  9 06:41:11 UTC 2016 - total duration: 0h 6m 25s.

Something failed somewhere in the second build, not in the package build
itself but rather in the building script and was not properly detected
as an infrastructure error (but rather as a FTBFS).
I triggered another build of the package and not it has built
successfully.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: reproducible-builds

[Mattia Rizzolo]

On Tue, Jul 19, 2016 at 09:38:44AM -0300, Herbert Fortes wrote:
> I do not have a special interest in the package. Just
> a QA to do. I also did a repository (collab-maint) for
> it.

You could/shoud have set Vcs-* in d/control for that.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: How get overrides into ftp.debian.org/debian/indices/override.sid.main.gz ?

[Mattia Rizzolo]

On Fri, Jul 22, 2016 at 09:59:19PM +0200, Thomas Schmitt wrote:
> Well, i don't have a strong opinion myself but rather wonder how it was
> decided to put the lines into override.sid.main.gz .

All packages have an override line there.  That's an implementation
detail of the archive software.
at the first acceptance time the ftp guy get to chose whether to leave
what the maintainer picked up, or to change it.

> Are there reverse dependencies which require priority "optional" ?

dunno, but I can tell you that really ftpmasters don't care about
optional vs extra.  As most other people don't…

> Shall i change the priorities in debian/control ?

If you'd like to…
It's possibly nice to have the same value, not personally sure what it
would buy though.

> (Is it a bug or a feature that the new package tracker does not warn ?
>   https://tracker.debian.org/pkg/libburn
> )

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

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#833621: RFS: libgap-sage/4.8.3+ds-1 [ITP] -- GAP kernel as a C shared library

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sun, Aug 07, 2016 at 02:49:38AM +0100, Jerome Benoit wrote:
> [1] https://anonscm.debian.org/cgit/debian-science/packages/libgap-sage.git

d/*.lintian-overrides + d/*.README.Debian:
 you use the word 'furnished', which really means "providing
 forniture" (or "provided with forniture"), afaik.  I'm positive Debian
 doesn't ship forniture :D
 I think you meant 'provided' there.
debian/adhoc/doc/libGAP.pdf:
 you provide that pdf, which is bad:
 pdf are not considered sources (of course), you'd need to have the
 sources near it, and possibly build it during the build process. PDFs
 are also listed in the REJECT-FAQ; that said, I saw pdf in the archive
 before, and I personally don't have hard feeling towards them, so if
 you want I can try to upload it nonetheless.
upstream-autotoolization-test-systemwide.patch + 
upstream-autotoolization-header_folder.patch
 s/hardden/harden/ (in the description)
debianization.patch:
 i think these kind of patches like 'Forwarded: not-needed'
debianization-pkgconfig.patch
 s/surch/such/ (in the description)
d/copyright:
 i see several files in src/ with this header:
 *Y  Copyright (C)  1996,  Lehrstuhl D für Mathematik,  RWTH Aachen, Germany
 *Y  (C) 1998 School Math and Comp. Sci., University of St Andrews, Scotland
 *Y  Copyright (C) 2002 The GAP Group
 those are not rapressented in your copyright.


That said, your work is as usual outstanding :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#834288: RFS: dblatex/0.3.8-1

[Mattia Rizzolo]

[ as a non-native speaker ]

On Sun, Aug 14, 2016 at 08:53:12PM +0200, Jakub Wilk wrote:
> * Sean Whitton , 2016-08-14, 11:35:
> > >   * Actualize debian/watch.
> > 
> > Do you mean that you added a debian/watch file in this version, that was
> > previously not present?
> 
> In many European languages, including German[0], "actualize" has a false
> friend that means "update". I guess that's what Andreas wanted to say. :)

I *believe* that a correct reading of "actualize" is "to make actual" or
"to make true".  That can be interpreted as the action of replacing some
not reference not real/true/actual anymore with something more
current¹/actual/real/true.


Surely this is not a thought I'd like to need to make when reading a
changelog though...



¹ at least in Italian "currently" *can*² be translated to "attualmente"
  which is dangerously similar to "actually" ;)
² "can" as there is also a "correntemente" which can be consider more
  precise, and I prefer using since when I learned what "actually"
  means.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#834768: RFS: codicefiscale/0.9-1

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Thu, Aug 18, 2016 at 10:24:31PM +0200, Elena ``of Valhalla'' Grandi wrote:
> On 2016-08-18 at 21:48:05 +0200, Elena ``of Valhalla'' wrote:

FYI: no need to explicitly CC d-mentors@, RFSes are somehow sent there
anyway.

> > To access further information about this package, please visit the 
> > following URL:
> > 
> >   https://mentors.debian.net/package/codicefiscale
> > 
> > 
> > Alternatively, one can download the package with dget using this command:
> > 
> > dget -x 
> > https://mentors.debian.net/debian/pool/main/c/codicefiscale/codicefiscale_0.9-1.dsc
> > 
> > Or directly from git at:
> > 
> > https://anonscm.debian.org/git/python-modules/packages/codicefiscale.git
> 
> sorry, I forgot about removing the codicefiscale.egg-info, the actual
> dsc is:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/c/codicefiscale/codicefiscale_0.9+ds0-1.dsc
> 
> (all other urls are ok, and their content have been updated, sorry)

This is DPMT, where the usage of git is mandated, so I expect the git
repository to match the generated .dsc (hence I'm ignoring mentors here)


A few small things I'd like to see:

* you email address in d/copyright
* Files-Excluded in d/copyright doesn't list all the files that are
  removed (at least according to `git diff --stat
  upstream/0.9..upstream/0.9+ds0`)
  besides, wrapping that list might not be a bad idea
* Also would be nice to see Build-Depends wrap-and-sort'ed
* python3-codicefiscale uses ${python:Depends} instead of
  ${python3:Depends}
* why do you disable the tests?  (a comment on d/rules might not be a
  bad idea here either)
  + I see setup.py lists non-existant tests, if that's the issue maybe
you can get that tests= arg removed (or the actual tests included)
upstream?
* in d/watch, you dversionmangle '.ds0' away, but you're using '+ds0'
  actually, so it's not actually mangling anything
* just quickly skimming over the README, I think it would make sense to
  include in the binaries, as it provides quick documentation (I think)


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#834768: RFS: codicefiscale/0.9-1

[Mattia Rizzolo]

On Fri, Aug 19, 2016 at 10:47:37PM +0200, Elena ``of Valhalla'' wrote:
> On 2016-08-18 at 22:27:42 +, Mattia Rizzolo wrote:
> > * Files-Excluded in d/copyright doesn't list all the files that are
> >   removed (at least according to `git diff --stat
> >   upstream/0.9..upstream/0.9+ds0`)
> >   besides, wrapping that list might not be a bad idea
> 
> Uhm, I used uscan to remove the files, so nothing that wasn't listed was
> removed.
> 
> Do you mean that I should explicitely list all of the content of the
> directory ``codicefiscale.egg-info``, instead of just listing the
> directory?

No, it just means that I rashed too much at reviewing it last night and
was already sleeping.
I didn't notice all those files where inside a directory -.-'

> > * why do you disable the tests?  (a comment on d/rules might not be a
> >   bad idea here either)
> >   + I see setup.py lists non-existant tests, if that's the issue maybe
> > you can get that tests= arg removed (or the actual tests included)
> > upstream?
> 
> That's exactly the issue, I've added a comment with a pointer to 
> https://github.com/ema/pycodicefiscale/issues/6

The project doesn't strike me as very active, but thanks :)

> > * just quickly skimming over the README, I think it would make sense to
> >   include in the binaries, as it provides quick documentation (I think)
> 
> yes, it does, you're right (added in git)

You did this:

diff --git a/debian/docs b/debian/docs
new file mode 100644
index 000..a1320b1
--- /dev/null
+++ b/debian/docs
@@ -0,0 +1 @@
+README.rst

This is not going to do what you expect, check both the produced
binaries ;)
(`debc` right after having built the package is handy for that, I run
it in a pbuilder hook for example)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: pacakge suffix: noSOMETHIN vs bare (or something)

[Mattia Rizzolo]

On Fri, Sep 09, 2016 at 01:45:07PM +0100, Jerome BENOIT wrote:
> For the package
> supporting the library I plan to append the suffix -[LIBRARY SHORT NAME]. 
> Concerning the other one,
> I am wondering if -bare or -pure (or something) would be a better choice than 
> -no[LIBRARY SHORT NAME].
> What do you think ? Any hint is welcome.

Why not just calling the "slimmer" one without any prefix?
So you'd have (assuming a SONAME of "foo1"):
 * libfoo1 => regular library most people would want
 * libfoo1-something => library engrossed of the heavy lib/feature

Given that you say the most of the users would not be interested on the
pumped one, I see no reason to highlight the absence of the "something"
in the other one.

PS: if the ABI on the libfoo1-something is compatible with libfoo1 (at
least for the non-something bits), remember to add a Provides:libfoo1 on
it, so packages not needed the "something" could link against simple
libfoo1, but users needed that application but also the "something" can
install libfoo1-something and the rdep package dependencies can be
satisfied by it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#827397: RFS: vlc/2.0.3-5+deb7u3

[Mattia Rizzolo]

Dear LTS team, Mateusz:

On Thu, Jun 16, 2016 at 09:12:47AM +0200, Adam Borowski wrote:
> On Thu, Jun 16, 2016 at 06:53:49AM +, Gianfranco Costamagna wrote:
> > Hi Adam,
> > (answering in general, not in this particular situation)
> > 
> > 
> > >I've reviewed the upload, but I'm not sure if you coordinated it
> > >with the LTS team.  I find a contradition:
> > >  https://lists.debian.org/debian-lts/2016/06/msg00031.html
> > >says vlc is no longer supported in wheezy, yet in
> > >  https://lists.debian.org/debian-lts/2016/06/msg00035.html
> > >the quoted mail sounds as if the upload is expected.
> > >
> > >Should I proceed?
> > 
> > I guess not
> > 
> > In general, for security pocket, you need to do:
> > - check/test the patch
> > - wait for an ack from security team
> > - upload (binary-upload, not sure if source only is allowed, but I think 
> > not IIRC)  on security-master
> > e.g.
> 
> The docs on the LTS wiki suggest it is, but I asked to confirm.

I think you also need to do the build with -sa, as you need to upload
the full sources to security-master.

> > BTW according to security tracker wheezy is EOL for that cve, no DSA is 
> > released, so I guess you won't
> > have the ack
> > https://security-tracker.debian.org/tracker/CVE-2016-5108
> 
> The discussion continued after the EOL was mentioned, and Mateusz was
> obviously aware of it, thus I assume the RFS he filed was acked in parts of
> the discussion that are missing from list archives.
> 
> In any case, the patch is simple and works for me.
> 
> > (well, since there is a patch and an upload ready they might give an 
> > exception, but I think
> > asking before is the right way to deal with this bug)
> 
> Right... which is exactly what I'm doing right now :)
> Wheezy has been handed off from security to the LTS team.

We haven't heard anything on this RFS for nearly 3 months.
Can you see if there is anythin that you'd like.  For example, I don't
see a DLA enrty in dla-needed for VLC (nor I'd expect one considering
VLC is not declared as support iirc).
Anyway I suppose that a one-shot update can't really harm anybody.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#827397: RFS: vlc/2.0.3-5+deb7u3

[Mattia Rizzolo]

On Sun, Sep 11, 2016 at 08:27:11PM +0200, Mateusz Łukasik wrote:
> > I think you also need to do the build with -sa, as you need to upload
> > the full sources to security-master.
> 
> I pushed it to the mentors.

That wasn't really something for you, but more something for whoever
sponsor this.

The real question is: is this upload ACKed by the LTS team?  I don't
have a hold on LTS workflow, and in my thoughts I believe uploads have
to be ACKed, pretty much like regular security uploads, and stable
uploads?

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#838014: RFS: imagemagick

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Fri, Sep 16, 2016 at 02:29:45PM +0200, Bastien ROUCARIES wrote:
>   I am looking for a sponsor for my package "imagemagick"

great!

> dget -x 
> https://mentors.debian.net/debian/pool/main/i/imagemagick/imagemagick_6.9.5.9+dfsg-1.dsc

I've eventually managed to domate gitpkg, and I succeeded at building a
.dsc out of it.  dsc that matches yours in all the things, except for
the timestamps in debian.tar.xz.  Am I right that you built your package
in jessie?  (Or anyway, with a dpkg << 1.18.10, which is the one that
started to build reproducible source packages).

This also means that with me you don't really need (anymore) to provide
me a .dsc to dget, git pushing changes is going to be enough.

Another question about that git repository: I see there are very few
tags.  Shall I suppose tags means nothing in this repository format?


I recall you were saying something about this aiming to experimental,
because some SONAME changed (I didn't really checkout), which must also
be the reason you're asking for sponsorship (=> the package will go
through NEW, so you can't upload yourself).  But your upload is
targetting unstable.


Things I want to see fixed:

1/ you didn't incorporate any NMU, nor mine (which upsets me as a NMUer
trying to do QA work), nor pochu's (which is fixing a CVE, that I
suppose has been fixed upstream already so that's not so relevant.
Not including my NMU means your package gains another RC bug, and just
because you're lucky (src:kodi has yet to be fixed…) your package would
migrate to testing, but in normal circumstances it wouldn't.
The changelog is also lacking the unstable uploads for -6 and -7.  I can
understand -7 where you only backported some patches that are probably
already present, but judging by the changelog I suppose -6 is also some
packaging changes; have them be included?

2/ the Vcs-* field, Vcs-Git is plain broken.  If I were you I'd set both
Vcs fields to
https://anonscm.debian.org/git/collab-maint/imagemagick.git
That url works both as a cgit frontend.
It's something that I'm pointing out and "forcing" to be fixed due to so
seldom uploads of imagemagick...  and it's fairly annoying not being
able to use `debcheckout`.


Other things that you may consider changes in future, not needed now:
I've only peaked randomly at d/rules, nothing more, so this is probably
incomplete.

1/
STATIC_DEB_SOURCE_PACKAGE could be take by
dpkg-parsechangelog -SSource
Also STATIC_DEB_VERSION you could use
dpkg-parsechangelog -SVersion
instead of doing grep/cut.  Or you could include
/usr/share/dpkg/pkg-info.mk and use the variables provided by it (not
exported though).

2/
Actually I'm really not sure why you export all the variables...  I'm
sure you don't need all of them exported.

3/
you have a weird if in the % target.  The bug cited there is long fixed,
so probably that if is not needed anymore?

4/ you got a 'fpu_is present' target, totally unused.  The most funny
bit is the presence of the space in the target name.  I figure you are
better by removing the target.  And if you don't want to remove it, then
you might avoid a small DRY violation by making override_dh_autoreconf
depend on that target (after the name is fixed).

5/ all the patches have 'Forwarded: Yes'.  That's cool, but according
to DEP-3, Forwarded should contain the place where they have been
forwarded, not just "Yes".  i.e., a patch reviewing place, an upstream
bug, a mailing list post, ...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#838014: RFS: imagemagick

[Mattia Rizzolo]

On Sat, Sep 17, 2016 at 06:23:19PM +0200, Bastien ROUCARIÈS wrote:
> > I recall you were saying something about this aiming to experimental,
> > because some SONAME changed (I didn't really checkout), which must also
> > be the reason you're asking for sponsorship (=> the package will go
> > through NEW, so you can't upload yourself).  But your upload is
> > targetting unstable.
> 
> Corrected

That means you're going to start a transition.  I won't help you with
that unless you get an ACK from the release team, which afaik you
haven't.

> > Things I want to see fixed:
> > 
> > 1/ you didn't incorporate any NMU
> 
> Change included and NMU aknowledge. This version go back before the NMU

you don't need anymore (since a decade…) to reclose the bugs if you're
including the old changelog entries.

> > 2/ the Vcs-* field, Vcs-Git is plain broken.
> 
> Done

not in git.

> > Other things that you may consider changes in future, not needed now:

Great that you did most of them, but you didn't push (at least not to
debian/6.9.5.9+dfsg-1)

> Now building will remove package from mentors and uploading a new one

no need if you push to git.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#838566: RFS: mimerender/0.6.0-1 [ITP]

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Thu, Sep 22, 2016 at 02:48:29PM +0200, Dominik George wrote:
> I am looking for a sponsor for my package "mimerender"

so, this package is in DPMT, hence I'm looking only at the git repo.

blocking things:
 * this package doesn't seem to be using git-dpm, as mandate by DPMT.

nice to have:
 * properly sorted build-depends.  `wrap-and-sort -ast` might help here
 * the last debhelper compat level is 10
 * in Debian the standard MIT license is called Expat, see DEP-5.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#838575: marked as done (RFS: flask-compress/1.3.1-1 [ITP])

[Mattia Rizzolo]

> >It went to "found a sponsor, had to change something, did not reupload 
> >because sponsor does not use mentors" ;).
> 
> 
> well, so in this case it is good to have it close, avoiding double reviews 
> since
> you already have somebody who picked up the work!

well, or put an Owner on the bug, which would be me...

anyway, nevermind, I'll handle it as soon as you poke me on IRC.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Version comparison with "+repack"

[Mattia Rizzolo]

On Fri, Oct 07, 2016 at 12:26:09PM +0200, Ole Streicher wrote:
> Santiago Vila  writes:
> > On Fri, Oct 07, 2016 at 11:00:17AM +0200, Ole Streicher wrote:
> >> dpkg --compare-versions 7.5~rc+repack  lt 7.5~rc2+repack && echo lt || 
> >> echo ge
> >> ge
> >> 
> >> What is the best way to fix this?
> >
> > The best way I don't know, but I would put the RC number at the end,
> > i.e. 7.5~rc+repack2 for RC2, 7.5~rc+repack3 for RC3 and so on.
> 
> IMO this is not a good idea since it suggests that we now have the
> second repack of the RC.

agreed.  What about
7.5~rc.2+repack
?

The full stop is ugly at my eyes, but does the work and there are worse
things in the world.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#840992: RFS: golang-github-hlandau-goutils/0.0~git20160722.0.0cdb66a-1

[Mattia Rizzolo]

Thank Gianfranco :)

The subtle ping to me from Peter rised my attention, but clearly you're
doing a very great job of taking care of RFSes! :-)

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#840992: Bug#841031: Bug#841032: RFS: golang-github-hlandau-dexlogconfig/0.0~git20160722.0.055e2e3-1 [ITP]

[Mattia Rizzolo]

jessie-backports has debhelper 10 since yesterday.

On Tue, 18 Oct 2016, 3:36 p.m. Peter Colberg,  wrote:

> Hi Gianfranco,
>
> Thank you for all the uploads.
>
> On Tue, Oct 18, 2016 at 08:20:23AM +, Gianfranco Costamagna wrote:
> > (extended description too short might be fixable in a future upload,
>
> This is indeed an issue with golang micropackages, since the upstream
> authors usually don’t provide more than a few words. For collections
> of miscellaneous functions (os, net, …), one would probably need to
> summarize each function for a meaningful description. I will take
> another look at some point at pkg-go/packages to see how this is
> handled in practice.
>
> > and please consider switching to compat 10)
>
> I was considering the possibility of backports, but this is actually
> not an issue since debhelper is up-to-date in jessie-backports. Still,
> would you say it is reasonable to postpone the switch to compat 10
> till after the freeze? Where appropriate, I have already enabled
> autoreconf and parallel builds.
>
> Regards,
> Peter
>
>

Bug#842160: RFS: python-memory-profiler/0.40-1 [RC]

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: owner -1 !

On Wed, Oct 26, 2016 at 10:41:36PM +0900, Changwoo Ryu wrote:
> I am looking for a sponsor for my package "python-memory-profiler":

sure thing!

> Or you can use the alioth git:
> 
> https://anonscm.debian.org/git/users/cwryu/python-memory-profiler.git

let's use git indeed.

> 
>   * New upstream release
>   * debian/*: Clean up the pybuild build (Closes: #804442)
>   * debian/*: lintian fixes
> - Standard-Version: 3.9.8
> - Add missing source format
> - Use new https addresses for Vcs-* fields

This is broken:

mattia@chase /tmp % git clone 
https://anonscm.debian.org/users/cwryu/python-memory-profiler.git
Cloning into 'python-memory-profiler'...
fatal: repository 
'https://anonscm.debian.org/users/cwryu/python-memory-profiler.git/' not found
128 mattia@chase /tmp % 

 :(

Furthermore be aware that you can use
https://anonscm.debian.org/git/users/cwryu/python-memory-profiler.git/
for both of Vcs-Git and Vcs-Browser.

Also, upstream has released 0.41, why not packaging that?  (annoying the
fact that seems there are no recent tags in github).

> My new gpg key is not in the keyring yet since the weak key 
> removal so I can't upload this update myself. RFS.

No problem, we're here :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Debcheck: "Package has a Depends on perl:any which cannot be satisfied"

[Mattia Rizzolo]

On Sat, Oct 29, 2016 at 12:14:45PM -0700, Paul Hardy wrote:
> Debcheck on unifont-bin reports "Package has a Depends on perl:any
> which cannot be satisfied" for several architectures; see
> https://qa.debian.org/debcheck.php?dist=testing&package=unifont:
> 
> -- begin -
> Package has a Depends on perl:any which cannot be satisfied on mipsel.
> Package has a Depends on perl:any which cannot be satisfied on s390x.
> Package has a Depends on perl:any which cannot be satisfied on armel.
> Package has a Depends on perl:any which cannot be satisfied on armhf.
> Package has a Depends on perl:any which cannot be satisfied on powerpc.
> Package has a Depends on perl:any which cannot be satisfied on i386.
> Package has a Depends on perl:any which cannot be satisfied on amd64.
> Package has a Depends on perl:any which cannot be satisfied on mips.
> Package has a Depends on perl:any which cannot be satisfied on ppc64el.
> Package has a Depends on perl:any which cannot be satisfied on arm64.
> --- end -
[...]
> Does anyone know what is causing this Debcheck message, and how can it be 
> fixed?

debcheck's broken, as it doesn't know about multi-arch stuff (like the
:any qualifier).

i.e. see #708060 (but I think the thing is more involved than that).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Non-NEW backports rejected with "ACL dm: NEW uploads are not allowed"

[Mattia Rizzolo]

On Sun, Oct 30, 2016 at 12:04:16AM -0400, Peter Colberg wrote:
> Older versions of the packages already exist in jessie-backports. My
> key has been added to the backports ACL (and has worked for similar
> updates in the past), and I have DM upload rights for the packages.
> 
> My uploads for both packages were rejected with "ACL dm: NEW uploads
> are not allowed". I tried two times each, on October 16 and today, to
> rule out temporary errors. Do you have any idea what I am missing?
> 
> I attached the (unsigned) .changes files for the attempted uploads.

from the first .changes:

| Distribution: jessie

that's wrong, you are trying to upload to the stable distribution,
instead of jessie-backports.

Am I right that you used sbuild with -D to build this package?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#842597: RFS: [RC] pythonmagick/0.9.14-1

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sun, Oct 30, 2016 at 06:11:01PM +0100, Bastien ROUCARIÈS wrote:
>   I am looking for a sponsor for my package "pythonmagick"

o/

>   Alternatively, one can download the package with dget using this command:
> 
> dget -x https://mentors.debian.net/debian/pool/main/p/pythonmagick/
> pythonmagick_0.9.14-1.dsc

given this package is in dpmt I'll stick to git instead.

>   * Switch watch to .xz and add signature check

please instead make use of uscan's @ARCHIVE_EXT@ substitution variable.

>   * Add myself as uploader.
>   * Switch to git-dpm.
>   * Bump Standards-Version no changes.
>   * New upstream release:
> - Bug fix: "FTBFS with newer experimental version of imagemagick",
>   thanks to Bastien ROUCARIES (Closes: #840428).

I find weird thanking yourself here :)
Also, the upstream bug that you linked in the debian bug is still open
with no comments, how come?

moreover:

* please bump debhelper compat level to 10
* switch to pybuild for building
* README.source is now completely useless
* I wouldn't mind seeing the build-deps sorted
* merge the UNRELEASED changelog entry into yours


Then, does this package build with python3?  If so please add a python3-
package.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: RFS: node-everything.js/1.0.3-1

[Mattia Rizzolo]

On Thu, Oct 27, 2016 at 11:59:20PM -0300, Lucas Castro wrote:
>   Package: sponsorship-requests
>   Severity: optional
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "node-everything.js"

there, followed up a little over IRC, and uploaded!

(just FYI.  I also made him notice he didn't file a proper bug report…)

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#843430: RFS: ocrmypdf/4.3-1

[Mattia Rizzolo]

control: owner -1

On Sun, Nov 06, 2016 at 09:59:01AM -0700, Sean Whitton wrote:
> I am looking for a sponsor for a new release of ocrmypdf.

o/

> I normally upload ocrmypdf with dgit, so I'd like to request sponsorship
> using dgit so that the git history on dgit-repos is not interrupted.

> If you have any trouble with this, I'd appreciate if you'd ask me about
> it rather than doing an upload that bypasses dgit, as that would break
> the history on dgit-repos.  I'm interested in making sponsorship with
> dgit a smooth and well-documented process.

I'm interested in learning some bases of dgit, so I'd like to process
this RFS and using dgit with it.

Just, I'd like to read those manpages you wrote for the latest dgit
release before (I remember a manpage exactly about sponsoring), and I
can't do it right away, mind if I'll defer this to tomorrow ot Tuesday?

Of course if you're in hurry and somebody else is available feel free to
steal it from me!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#843583: RFS: imagemagick/8:6.9.6.2+dfsg-3

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Mon, Nov 07, 2016 at 09:49:52PM +0100, Bastien ROUCARIES wrote:
>   I am looking for a sponsor for my package "imagemagick"

Hi Bastien!

Please, avoid using Cc to notify people of bugs, use x-debbugs-cc
instead...

> dget -x 
> https://mentors.debian.net/debian/pool/main/i/imagemagick/imagemagick_6.9.6.2+dfsg-3.dsc

I was doing the thing via git, but I noticed a difference.
In 0520b5304334d3da89efe5a8b2c6496603e62fd0 I can see this:

-Build-Depends: debhelper (>= 10),
+Build-Depends: debhelper (>= 9.20151219),

I can't really explain that, but I also find interesting that in the
.dsc I got from mentors the build-dep is on >= 10.

See the attached diff of your-dsc my-dsc

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for imagemagick-6.9.6.2+dfsg imagemagick-6.9.6.2+dfsg

 control|2 +-
 control.d/noquantum.in |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff -Nru imagemagick-6.9.6.2+dfsg/debian/control 
imagemagick-6.9.6.2+dfsg/debian/control
--- imagemagick-6.9.6.2+dfsg/debian/control 2016-11-06 12:51:44.0 
+
+++ imagemagick-6.9.6.2+dfsg/debian/control 2016-11-06 12:51:44.0 
+
@@ -8,7 +8,7 @@
  Vincent Fourmond 
 Standards-Version: 3.9.8
 # for dbg-sym
-Build-Depends: debhelper (>= 10),
+Build-Depends: debhelper (>= 9.20151219),
 # for improving build
  dh-exec, dh-autoreconf,
 # for linking compiling ...
diff -Nru imagemagick-6.9.6.2+dfsg/debian/control.d/noquantum.in 
imagemagick-6.9.6.2+dfsg/debian/control.d/noquantum.in
--- imagemagick-6.9.6.2+dfsg/debian/control.d/noquantum.in  2016-11-06 
12:51:44.0 +
+++ imagemagick-6.9.6.2+dfsg/debian/control.d/noquantum.in  2016-11-06 
12:51:44.0 +
@@ -8,7 +8,7 @@
  Vincent Fourmond 
 Standards-Version: 3.9.8
 # for dbg-sym
-Build-Depends: debhelper (>= 10),
+Build-Depends: debhelper (>= 9.20151219),
 # for improving build
  dh-exec, dh-autoreconf,
 # for linking compiling ...


signature.asc
Description: PGP signature

Bug#843669: RFS: eclib/20160720-3

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Tue, Nov 08, 2016 at 05:40:45PM +0100, Julien Puydt wrote:
>   I am looking for a sponsor for my package "eclib"

o/

> Vcs-Git:
> https://anonscm.debian.org/git/debian-science/packages/eclib.git

* please kill the dh-autoreconf build-dep
* d/copyright looks outdated; at least your own copyright is, but please
  look over all of it.
  + maybe stop mixing tabs and spaces so irregularly too?
* d/rules:
  + could you instead inject the -D_LARGEFILE_SOURCE by using
dpkg-buildflags' means?  (i.e. DEB_CPPFLAGS_MAINT_APPEND variable)
autotools should be able to deal with it correctly even without
passing it at configure time like that.
  + can't that thing be moved over to dh_auto_install instead of
manually calling make?

>   - I cleaned d/rules with a rusty axe.

:)

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#843430: RFS: ocrmypdf/4.3-1

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Sun, Nov 06, 2016 at 09:59:01AM -0700, Sean Whitton wrote:
> I normally upload ocrmypdf with dgit, so I'd like to request sponsorship
> using dgit so that the git history on dgit-repos is not interrupted.

As I said, I'm interested in trying out dgit and at least understanding
it more, so I'm doing this.

First, a small review:

* be aware that I'm morally opposed to --link-doc, so good thing you
  reverted that..
* policy 3.9.7 recommend to install the docs in /usr/share/doc/$mainpkg
  instead of /usr/share/doc/$mainpkg-doc/   care to move them?
* question: why don't you also sort the (build-)deps?


> % dgit sbuild || dgit gbp-build --git-pbuilder
> # ^ no source-only uploads to binNEW!

I use pbuilder, so I can't use `dgit sbuild`.
I also don't use gbp to build my package, but I usually `debuild -S`
them, then `cd ..` and `pbuilder b foo_123.dsc`, and depending on
whether I'm doing a source-only upload or a source+binary upload I
either upload that one foo_123_source.changes  that debuild generated,
or the ~/pbuilder/results/sid/amd64/foo_123_amd64.changes that pbuilder
built (note how it's in a completely different directory).

Now, I understand I shouldn't run debuild directly on this but:
% dgit build-source
wants all the build-dependencies installed => no going to happen

digging through the manpage I ended up with
% dgit -wg build-source

cool, I have a .dsc now.
I can build it!

but:
tests/test_main.py 
FFssFF.FFF.FFF..FF.F...

They are all like

tests/test_main.py:131: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

input_basename = 'ccitt.pdf', output_basename = 'test_quick.pdf'
env = {'CCACHEDIR': '/home/mattia/pbuilder/cache/ccache', 'CCACHE_DIR': 
'/home/mattia/pbuilder/cache/ccache', 'CCACHE_PATH': '/usr/bin', 
'CCACHE_UMASK': '000', ...}
args = (), input_file = '/build/ocrmypdf-4.3/tests/resources/ccitt.pdf'
output_file = '/build/ocrmypdf-4.3/tests/output/main/test_quick.pdf'

def check_ocrmypdf(input_basename, output_basename, *args, env=None):
"Run ocrmypdf and confirmed that a valid file was created"
input_file = _infile(input_basename)
output_file = _outfile(output_basename)

p, out, err = run_ocrmypdf(input_basename, output_basename, *args, 
env=env)
if p.returncode != 0:
print('stdout\n==')
print(out)
print('stderr\n==')
print(err)
>   assert p.returncode == 0
E   assert 15 == 0
E+  where 15 = .returncode

tests/test_main.py:68: AssertionError
- Captured stdout call -
stdout
==

stderr
==
  ERROR - [Errno 13] Permission denied


Is there some caveat I don't know?



Then, once I build this, should I e.g. place the built files (I suppose
I have to do a -b build, right, not -F?) in .. realtative to the
unpacked source tree and just dgit push?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Modernizing the upstream tarball without version number change

[Mattia Rizzolo]

On Sat, Nov 12, 2016 at 02:12:23PM +0100, Christoph Biedl wrote:
> disclaimer: This is a theoretical situation

pfff :)

> there is an upstream tarball foo_1.0.orig.tar.xz but, quite frankly,
> it's a mess. The creator didn't care about that process and so it
> contains a lot of cruft like a populated .git/, backup files, autotools
> debris, patches applied, you name it. Therefore I'd like to provide a
> clean and much smaller one, ideally one provided by upstream that was
> ignored in the past.
> 
> However, there might be no newer upstream version so I'd have to
> replace foo_1.0.orig.tar.xz with new content, something I consider
> unfriendly[1] and that hopefully[2] gets blocked by technical means.

It is blocked indeed.

> Ideas so far:
> 
> * Fake a new upstream version number, like foo_1.0a.orig.tar.xz.
>   Yes, it's faking. Using "+repack" is more obvious but still means
>   this gets carried into the Debian version number.

+ds is what's usually used.

> * Switch upstream tarball compression. This works, I found an upload[3]
>   where -2 switched from .gz to .xz. Still rather a hack[4], and if this
>   means going away from xz to something older, it feels wrong.

Though it works and indeed it has been used.

> Anything else I could do? It's all a bit first-world-problem-ish and, as
> I said, it's a theoretical question. In the actual cases (outside
> Debian) I could get out of this situation easily since either there was
> a new upstream version, or the source name was a misnomer and needed a
> change anyway. I don't expect to have that luck all the time.

Personally, I'd just repack, appending +ds to the upstream version.
I find switching compression scheme just for the sake of repacking, an
ugly hack; I really really prefer to be shipping whatever upstream
provided me, and if I can't/don't want to do so I want that information
to be clearly visible, in this case in the form of a modified version.

> [1] In my opinion, every file in the Debian repositories that carries a
> version number should have unique content over all the time. I found
> some history .dsc files on snapshot.d.o that violate this idea, but
> I think I should not extend that list.

you really found such things?
'cause really a file once stored in the archive really can't change.
At least, as long as that file is known to dak, it can't change, once a
distribution is archived you theoretically could upload the same
filename with different content.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: upload to mentors

[Mattia Rizzolo]

On Tue, Nov 22, 2016 at 10:32:15PM +0100, Werner Detter wrote:
> > source-only uploads works, please use them.
> 
> Is this "new" or is "something" broken? I'll give it a try with
> source-only uploads.

I've personally never done a full (with binaries) upload to mentors.
source-only uploads always worked.  The only upside of uploading
binaries too would be to have them scanned by lintian and the result
pubblished by the web app, i.e. nothing so interesting.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Package not migrating

[Mattia Rizzolo]

On Wed, Nov 30, 2016 at 04:35:34PM +0100, Ole Streicher wrote:
> I have a package (casacore-data-tai-utc), that doesn't migrate to
> testing, even if it is marked as "valid candidate":
> 
> excuses:
>  * 12 days old (needed 10 days)
>  * casacore-data-tai-utc/i386 unsatisfiable Depends: python3-casacore
>  * Valid candidate
...
> How do I get rid of this excuse?

Britney enforces the installability of arch:all packages in amd64 and
i386.  If your arch:all packages is and won't be installable in i386,
you need to contact the release team to ask for a force hint to have it
migrated (it's needed only the first time).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#845976: RFS: moc/1:2.6.0~svn-r2935-1

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: owner -1 !

On Sun, Nov 27, 2016 at 01:16:13PM +0100, Elimar Riesebieter wrote:
>   I am looking for a sponsor for my package "moc"

o/

> dget -x 
> https://mentors.debian.net/debian/pool/main/m/moc/moc_2.6.0~svn-r2935-1.dsc

One request: please bump the debhelper comapt level to 10, and simplify
d/control and d/rules appropriately.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Patch upload not showing up in deferred queue

[Mattia Rizzolo]

On Tue, Jan 10, 2017 at 06:51:56PM -0600, Taylor Kline wrote:
> So how do non-DDs help out with providing patches?

By attaching patches in the bugs.

The ability to actually upload the packages is the whole distinction
between DD and external contributors.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#850928: RFS[ITP]: minetest-mod-3d-armor/0.4.5-1

[Mattia Rizzolo]

Control: owner -1 !
Control: tag -1 moreinfo

On Wed, Jan 11, 2017 at 11:34:18AM +0100, Julien Puydt wrote:
>   I am looking for a sponsor for my package "minetest-mod-3d-armor"

o/

> Vcs-Git:
> https://anonscm.debian.org/git/pkg-games/minetest-mod-3d-armor.git


>   IMPORTANT NOTICE: d/copyright doesn't correspond to what you find in
> 0.4.5's LICENSE.md and README.md files (notice the plural) : it corresponds
> to the clarifications I obtained from upstream, which have been committed to
> their repository but haven't found their way in an official release yet:
> https://github.com/stujones11/minetest-3d_armor/issues/75

uh.

please apply that patch, and add a Comment: field somewhere in
d/copyright ; ftpmasters are not going to read this email.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Restoring old package version

[Mattia Rizzolo]

On Wed, Jan 11, 2017 at 10:48:58AM -0500, Ross Vandegrift wrote:
> terminology was affected by the RC bugs flooding issue mentioned in the
> recent email on the Strech freeze status.

terminology doesn't seem to be affected by any RC bug.  What are you
talking about?

> In [1], it says to upload the
> old version.  I'm not clear on what I need to do - should I open
> an RFS with the old version from snapshot.d.o?

That wouldn't be enough, you can't upload a version lower than what's
already in the target suite.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851367: RFS/ITP: python-scandir/1.4-1

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: owner -1 !

On Sat, Jan 14, 2017 at 01:00:42PM +0100, Julien Puydt wrote:
>   I am looking for a sponsor for my package "python-scandir"

o/

> https://anonscm.debian.org/git/python-modules/packages/python-scandir.git

d/control:

Build-Depends: debhelper (>= 10), dh-python, libpython2.7-dev, python, 
python-setuptools

please replace those python deps by using either python-all-dev or
python-dev.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]

[Mattia Rizzolo]

On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote:
> ** What I have already done for packaging openmeca **
> 
>  - open an ITP (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590).
>Andreas Tille (from debian-science) tell me that the soft fit well with
> the debian-science field.

good.

>  - open a git repository for openmeca on alioth :
> https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/
>post a first version of the openmeca package on this git repository.
>This package seems to be right on my personal computer (Ubuntu 16.04.1
> LTS and checked with "gbp buildpackage")

good.  (although you really should build it in Debian unstable, and
test it there too).

>  - post an intent on the debian science list (see
> https://lists.debian.org/debian-science/2017/01/msg00093.html)
>but I have no answer.

That's not an "intent" really, it's a forward of your ITP with "some"
added text.

> As I have no answer from the debian-science list (probably they have no
> time), I post my request on this list.

1) consider that 4 days are really little, also considering a week end
   was in the middle
2) the subject was really poor: most of use receive *a lot* of emails
   and subjects are important; I probably skipped that email thinking it
   was just a "FYI" of an ITP related to -science.

> I am not used with the Debian policy so... please tell me if I am wrong,
> impatient, or something else

The usual procedure (especially if the team have nothing else in place)
is to open a RFS bug.  I invite you to read
https://mentors.debian.net/intro-maintainers especially from point 5
onward; mentors.d.n also gives you a template for the RFS bug (see point
4). (note that even if you'll have to upload a source packages to
mentors.d.n, several of us still prefer to review using a git
repository, so please include that too in the request).
The reason to prefer an RFS bug over emails is that they don't get lost:
several of us look at https://bugs.debian.org/sponsorship-requests from
time to time and take care of pending request, whereas emails in a
mailing list are much harder to keep track of.



Now, you don't have any package already in the archive, so my personal
policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" me
to sponsoring the package, but I trust there are several other
developers willing to do so :)  I just wanted to explain better the
usual procedure ^^

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Mattia Rizzolo]

Control: owner -1 !
Control: tag -1 moreinfo

On Wed, Jan 18, 2017 at 04:46:46PM +0300, Коля Гурьев wrote:
>   I am looking for a sponsor for my package "telegram-desktop"

Hi!

I am an heavy user of telegram, and I was looking forward for this
package, despite the privacy concerns, etc.

>   Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc

I will be reviewing this package more deeply, bug few things I can tell
you already:

* changelog for the first upload should use a -1 version, and only
  contain on line "Initial upload.  (Closes: #x)" or somesuch, so
  please get rid of all the rest
* Vcs-* fields should point to a *packaging* repository, not the
  upstream git repo; that said, I'd love to see a git repository used
  for packaging this, this is the tool I prefer for this job:
  http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
* please use `wrap-and-sort -ast` (or somesuch) to make a diff-frindly
  list of build-deps
* d/rules is incredibly verbose, I can't believe such a thing is needed
  (once I'll look deeply I can tell you more, I just know I'm not happy
  to see such d/rules).
* The bug you reference is still a RFP, you should turn it into an ITP
  https://www.debian.org/devel/wnpp/#howto-rfp if you don't know the BTS
  and how to deal with it, read all of https://www.debian.org/Bugs/ and
  subpages.


Now, I usually don't sponsor NEW packages for new people without a
record of past contributions to Debian, as I don't trust them to stick
around and actually maintain the package), but I'm inclined to make an
exception to this rule of mine on the basis that I'd love to have this
package for myself (but be aware, I really expct the package to be
maintained…).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Mattia Rizzolo]

On Wed, Jan 18, 2017 at 10:07:34PM +0300, Коля Гурьев wrote:
> I've putted the current changes back to [1].
> 
> I would appreciate your advice about my debian/rules. What can I improve it?
> 
> [1] 
> https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-1.dsc

It seems this one is using a different .orig.tar.gz than the first one.
Neither of them being the .tar.gz I download from github.  bad.

Then I looked at that git repo you put in Vcs-*.  I'm not sure about the
format used there, but I'd say to get this release upload and then sync
up with whatever's there.  (or have me understand what's going on
there).


Then:

* d/compat:
  + please use 10.  Read the relevant part of debhelper(7) before.
* d/control:
  + as said below, I'd say this is good to go in main
  + Build-dep on 'gyp:all', why that architecture qualification?  I'm
not even sure what that is supposed to mean
  + you build-dep on libss1.0-dev, doesn't this work with libss1.1?  If
it doesn't please open an upstream issue, and be ready to have a
debian bug as soon as it's accepted into the debian archive
* d/manpage.1.ex:
  + this is an example empty file, get rid of it (or even better, write
a useful one)
* d/README.Debian:
  + there is a todo there.  I'm pretty sure users are not interested in
knowing you need to "Sort out dpkg-shlibdeps warnings".  Please move
that list elsewhere (this could either be a d/TODO file, or bugs in
some bug tracker (like the Debian one, once it's accpeted)
* d/shlibs.local:
  + why?
* d/telegramdesktop.desktop:
  + upstream already ships one, why duplicate?
* d/telegram-desktop.doc-base.EX:
  + this is an example file, get rid of it
* d/p/Avoid-depending-on-static-libraries.patch:
  + it links unrelated bugs, or why does it anyway?
  + can you work on a patch that does that by means of a compile flag,
and send it upstream?
* d/p/Fix-autorestart-when-new-language-is-selected.patch:
  + this definitely should be upstream already
* d/rules:
  + BUILD_MODE doesn't seem to actually change anything except for the
name of a directory.  if so I guess you can just get rid of that
  + please drop 'nostrip' handling; if you strip binaries, then dh_strip
won't have anything left to strip, and the genereted -dbgsym package
won't contain anything useful
  + also drop all of those INSTALL_* things.  Just call dh_install to
copy the binary in place (no need to create the directory with it)
and then mv(1) to rename it.  same for the icon: mkdir + cp is cool
(but feel free to keep using install(1) for this one if you like)
Personally I'd even prefer dh-exec over that, because I like a more
declarative packaging, but you're call.
  + I think you could just add a `--buildsystem cmake` in the dh call,
then the override_dh_auto_build could go, as could the "configure
with cmake" be substituted by a dh_auto_configure call.  OTOH this
requires changing other bits of how you're building the package.
  + also the parallel stuff should really be handled by dh itself,
instead of make.  besides, just doing the makes very little of the
build parallel.
* the ITP bug is named differently than the RFS and the package itself.
  please pick a name and uniform all the things.


Be aware that I don't know gyp, and really the structure of the upstream
package is very weird to me.
Also I've yet to look at the upstream package itself, and doing a
license check.

> By the way, this is my nickname in Telegram: https://t.me/mymedia

Great, I'll keep it in mind if at some point I'll need to contact you
(I'm @mattia).
That said I'd prefer if at least this one sponsorship request is done
in public.

> > Why is it in contrib?
> 
> From what I understand, there are packages with dependencies on non-free
> software in contrib section. This program does not work if Telegram server
> is stopped for any reason. But this server is proprietary, more accurately,
> it does not even distribute in public. So I thought the package has to be in
> contrib.  Correct me, please, if I am wrong.

Indeed, it should be in main.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: RFS: telegram-desktop/1.0.2-1

[Mattia Rizzolo]

sure what,
it's is pretty convoluted indeed…  Wonder what's the point of such
complicated build system.

> The third, d/p/Fix-desktop-integration-issues.patch, fixes some problems
> which began because I renamed the executable binary and don't take their
> Updater. I'll most likely prepare a pull request to upstream.

Yay.
Question: why don't you also name the icons telegram-desktop, as you
name the binary and the WMClass?

> Now I put the new package on mentors.debian.org [3] again.
> [3] 
> https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.2-1.dsc

I think you're not using the boundled minizip, but still that should be
referenced in the d/copyright.
Also, why are you using a more restrictive license for debian/* instead
of also picking the OpenSSL exception?  Theoritically this could lead to
patches that can't be upstreamed, or somthing stupid like this.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Cleaning packaging files with Lintian

[Mattia Rizzolo]

On Wed, Feb 08, 2017 at 07:56:42PM +0100, Narcis Garcia wrote:
> I have this error from Lintian output:
> E: ntfsundelete-tree: maintainer-address-malformed Narcis Garcia
> 
> 
> How can I better mask e-mail address in control file?

You don't.

And once you write to any public Debian mailing list your email
address is so public that trying to hide it anymore is just wasted time.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: RFS: telegram-desktop/1.0.6-1 [ITP]

[Mattia Rizzolo]

On Fri, Feb 03, 2017 at 01:33:40AM +0800, Boyuan Yang wrote:
> Hi,

Hi Boyuan!

I do not assume the sponsoree is subscribed to either the bug or
debian-mentors, so I suggest you always CC him.

> I just heard that someone filed an RFS for telegram-desktop. Good job! Wish 
> that you could make this package into good shape and put it into Debian.

Yeah :)

> > I can't understand how pristine-tar works. Should I manually download [...]
> 
> You should use upstream tarball when applicable. If we use the tarball which 
> is *identical* with the tarball released by upstream, we can have confidence 
> that no source code is modified in the distribution version of this software. 

Exactly.
You need not to manually commit the pristine-tar data.  If you have
'pristine-tar = True' in either your debian/gbp.conf or ~/.gbp.conf then
when you do `gbp import-orig ../bla.tar.gz` gbp will commit the data by
itself.

> Downloading manually can be unnecessary. If you carefully write debian/watch 
> file, the "uscan" tool can do it for you according to information in d/watch 
> file. If you don't really want to hack into d/watch, then manual download 
> should be needed.

IME, having a debian/Watch is important, not just because of the
download thing, but to have automatic tools detect new upstream releases
(besides, then you can do `gbp import-orig --uscan` to do everything…)


Although, the above points are moot, because you are working from the
upstream git tree, and not importing tarballs.  I have very little
experience in working with those, and indeed for them I usually do
uscan --download
git merge vXX
pristine-tar commit ../foo_XX.tar.gz vXX
And I haven't yet found a way to have gbp be nice and do the work for
me (nor I know whether there is a way to do that).
(FTR, I do that with src:dehydrated)

> A big trouble is that upstream usually bundles lots of third-party sources 
> into its release. You will need to write detailed d/copyright file for those 
> files.

Once we make sure those bundled libs are not used, they can stay there,
and just dump info in d/copyright; which I prefer over a +ds repacking.

> * I really don't recommend using "ronn" tool to generate man page. Even we 
> have ronn in Debian, ronn is already dead upstream [1] and we shouldn't use a 
> dead tool in build toolchain. Writing man pages manually won't take up too 
> much time, or at least we can consider tools other than ronn (yes, there are 
> other tools available).

like pandoc?
Then again, I agree that this manpage is very short that it is not so
hard to write it in groff from the start.
Anyhow, I don't find particularly important this point.


> * Please consider explicitly enable (full) hardening flags in d/rules and 
> test 
> if the build can pass.
> 
> * Is the hard Depends: to fcitx-frontend-qt5 necessary? Your instruction 
> would 
> make everyone who installs telegram-desktop to install fcitx, which is an 
> Input Method Framework. I recommend you downgrade it to Suggests.
> 
> * Build-depends fcitx-frontend-qt5 seems very wrong. Could you please explain 
> why you add this one?
> 
> [1] https://github.com/rtomayko/ronn/

Good point; Коля, please have a look at them.


Then:

In d/copyright, the Apache-2.0 license text should point to the thing in
/usr/share/common-license; it's not enough to point to an external
website, per Debian Policy everything should be available locally.

> According to their contributing policy [1], I put my patches into public
> domain. Is it right?

Well, it's bullshit if you ask me; I wouldn't be particularly happy to
put my work in the public domain exactly because I don't want the
"Telegram team needs to use full Telegram Desktop source code with some
different license" as they put it.  But yep, it's right.


dpkg-shlibdeps reports a lot of libraries that are linked but the binary
doesn't use any symbol: can you try to build with -Wl,--as-needed ?


lintian reports several mispelling errors, including one in the manpage
that you wrote..


You patched Telegram/gyp/Telegram.gyp but are you sure you don't have to
also patch Telegram/gyp/telegram_linux.gypi ?  At the very least I
noticed a
-L/build/foobar/out/Release/../../../Libraries/libexif-0.6.20/libexif/.libs
in the final linking that I didn't expect to see, and there is no
libexif-dev in Build-Depends.




In other news, I now also installed the package, nice work :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#849493: RFS: vc/1.3.0-1 [ITP]

[Mattia Rizzolo]

[ re-sending, as I screwed up the CC, sorry to those will receive the
duplicated ]


Note: I won't sponsor this package, as for a policy I don't sponsor NEW
packages for people without a track of previous contributions.


On Mon, Feb 13, 2017 at 10:08:31AM +0800, Boyuan Yang wrote:
> 在 2017年1月27日星期五 CST 下午1:04:26，Boyuan Yang 写道：
> > Hi all,
> >
> > This is the owner of RFP bug for vc package (#846491) and let's push
> > the process forward a little bit.

Well, RFPs have no "owner".  It's just somebody saying "pretty please
could somebody package this and upload to the archive".

> Ubuntu just released a new version of vc (https://launchpad.net/ubuntu/
> +source/vc/1.3.0-0ubuntu1). This could be reused by Debian.

Yes.
As the person who sponsored that upload to Ubuntu, I wouldn't have done
so if the RFP (that I found) was a ITP, as uploading it to Ubuntu would
have been a clear duplication of work.
Also the RFS should be marked as a blocker of the ITP, but the automated
tool doing that doesn't act on RFP packages (correctly…)

> Aleksey, are you still working towards this RFS? If yes, you may take a look
> at this Ubuntu package. If not, please disown and close this bug (#849493).

Well, I can tell you that the package in Ubuntu now is perfect to be
uploaded as it is, in particular the package at mentors is worse in the
following points:
 * Section of the binary should be libdevel, not libs
 * copyright is incomplete
 * missing watchfile
 * spurious .directory files from Dolphin (?!?)
 * the synopsis is very poor
 * dh compat 9 instead of 10

> Still I think the name "vc" and "vc-dev" should be acceptable. Changing into
> other name will cause split between Debian and all Ubuntu derivatives.

aye, they are short, but given it's already in a Ubuntu it can't really
be ignored.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: telegram-desktop/1.0.12-1

[Mattia Rizzolo]

On Mon, Feb 20, 2017 at 03:02:09PM +0300, Коля Гурьев wrote:
> New version has been released yesterday. I built the package [1] and fixed
> some your comments as you wrote.

… so many releases!

> Sorry for the delay. I had some troubles with hardware of my computer, but I
> hope now they have been solved.

nvm!

> 11.02.2017 15:41, Mattia Rizzolo wrote:
> > * Please consider explicitly enable (full) hardening flags in d/rules and 
> > test
> > if the build can pass.
> 
> Hmm... It seems to be working. But lintian sill warnings about
> hardening-no-fortify-functions.

That usually means that something doesn't respect
CFLAGS/CXXFLAGS/CPPFLAGS & friends
btw,
DPKG_EXPORT_BUILDFLAGS = 1
is not needed: if you read debhelper(7) you'll see that starting with
compat 9 those are already exported by dh.

also,
export DH_VERBOSE  # for easy debugging this script
does this work without the "=1" bits?  (personally I export that in my
environment as I always want local builds to be as verbose as possible,
so I don't see the difference.


> 11.02.2017 15:41, Mattia Rizzolo wrote:
> > dpkg-shlibdeps reports a lot of libraries that are linked but the binary
> > doesn't use any symbol: can you try to build with -Wl,--as-needed ?
> 
> Thank you for the helpful option. But I did not use it because I manually
> got rid of any spare libraries from linker options. And now dpkg-shilibdeps
> does not show any warnings.

cool, even better!
something that might be made upstreamable?
You might not think/notice it just yet, but having too many local
patches does make maintenance a burden on the long run…

> > Well, it's bullshit if you ask me; I wouldn't be particularly happy to
> > put my work in the public domain exactly because I don't want the
> > "Telegram team needs to use full Telegram Desktop source code with some
> > different license" as they put it.  But yep, it's right.
> 
> Okay, I do not get it. I believe it would be better if the package was not a
> frant. I mean, let the patches have the same license like the upstream code.
> Like any other package in Debian archive.

It's not a techinical thing, but more political, actually.  I want to
decide the license of what I write.
But what you did before was ok.

> [1] 
> https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.12-1.dsc

This still need to take care of:

* spelling-error-in-binary (please upstream the fix)
* spelling-error-in-manpage
* desktop-entry-lacks-keywords-entry (please upstream the fix)

Once you do those I'll do a last round of license/copyright check (as I
don't remember if I did that), and if it's fine I'll upload.



git check:
* pristine-tar is not pushed/updated (after some check, if you have
  pristine-tar-commit=True doing a `gbp buildpackage…` it does commit it
  by itself, in some cases.…)
* you have a lot of branch, including a "master" (which is HEAD) and a
  "debian", but it seems latter is abbandoned, and the actual
  debianization is on "master".  can you clean it up a bit?  
* you have a weird looking tag tmp-old-debian
* you might want or not to push the upstream branch in your repo, your
  call, but if you don't let me suggest you don't call the debianization
  branch "master" ("debian" is cool, but please change HEAD).
* there is not upstream tag pushed for the last upstreams

but the git repo seems to be perfectly in line with what you uploaded to
mentors, which is very nice and makes me happy.  Also because if I'm
happy with the git repo I can tell you to stop messing around with
tarballs and uploads and stuff, and in my experience everything is
smoother. :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: telegram-desktop/1.0.12-1

[Mattia Rizzolo]

nd the actual tarball.  It should always be
pretty small.  Besides, the repository is already full of binary blobs,
with all those images :P

> What the profit if I still musta download the tarball?

You must download the tarball only once, to fill it in, then never
again.
pristine-tar came handy recently to me while switching computers, where
I cloned all repositories, and I didn't have to redownload also all the
tarballs.

> [1] 
> https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.13-1.dsc

Note that this doesn't match *at all* your top commit (that you even
tagged) cfb1daea9b2ff0b4501d2e97ca979d56b5b58364 :P
Anyway, given that now we got a workable git repository, feel free to
stop uploading those, and just hand me a commit id :)


I think if you update to the new release, and merge my PR, should be
good to go.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#851756: telegram-desktop/1.0.12-1

[Mattia Rizzolo]

On Sun, Mar 12, 2017 at 10:02:02PM +0300, Коля Гурьев wrote:
> 12.03.2017 21:12, Mattia Rizzolo пишет:
> > Did you send upstream those typo fixes?
> 
> I made a pull request [1], but it related only to .desktop file and it fixes
> dependency on Updater. I didn't add Keywords entry because I don't know what
> keywords are really suitable.

Ok, I hope they will merge it.
You might want to rebase it (and catch the occasion to do a ping with
it), as github says it has conflicts.
BTW, the spec of the .desktop file is
https://specifications.freedesktop.org/desktop-entry-spec/latest/, not
what you linked in that PR.

I look forward to see the typo fixes too :)

> I'll examine this issue. Maybe there are other implementations, or I'll
> perhaps be able to build Telegram without this library.

I hope so.  I wouldn't like to propagate such badly named library :(

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#857706: RFS/ITP: minetest-mod-homedecor/0.4.15-1

[Mattia Rizzolo]

Control: owner -1 !
Control: tag -1 moreinfo

On Tue, Mar 14, 2017 at 08:33:49AM +0100, Julien Puydt wrote:
>   I am looking for a sponsor for my package "minetest-mod-homedecor"

o/

> Vcs-Git:
> https://anonscm.debian.org/git/pkg-games/minetest-mod-homedecor.git

% cat debian/minetest-mod-homedecor.lintian-overrides 
# used by upstream, not by us
minetest-mod-homedecor: script-not-executable 
usr/share/games/minetest/mods/homedecor/homedecor/listnodes.sh

Well, ok, but that's not the point.

If it needs to be execuded it should be +x.  If it does not it shouldn't
have the shebang.  If it is not need at all, it shouldn't be there.
Please send upstream a fix for one of it, and either fix the packaging,
or properly comment the override.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: What option should I now use to do source only builds

[Mattia Rizzolo]

On Sat, Mar 18, 2017 at 08:22:36AM +0100, Johannes Schauer wrote:
> So just as with sbuild I don't see why anybody would want to *only* build the
> source package inside a chroot. Since the source package is the *input* to the
> whole operation, you would just get back what you already put in.

The only gain would be in a situation where you can't run the clean
target outside of the chroot, due to missing dependencies, so
`dpkg-source -b .` will produce an "unclean" source.  After moving it
inside a throw-away chroot with the build-deps installed you can call
the clean rules, and produce the source again, which will be "cleaner"
than the one produced outside.
Personally I'd call this case quite borderline and unusual, especially
in this world of git where the working directory is easily cleaned by a
`git clean -fdx` et al.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: What option should I now use to do source only builds

[Mattia Rizzolo]

On Sat, Mar 18, 2017 at 03:45:30PM +0100, Johannes Schauer wrote:
> how would the unpacked source directory become unclean if I'm using pbuilder 
> or
> sbuild to build my packages?

The developer might drop in debian/ (or in ./ in the case of a native
package) any kind of file and that would be packed up by dpkg-source -b.

Very simply those files could be .orig and .reject from patch(1).  Or
debian/files :P  (I think that would be generated by
`dpkg-buildpackage -S -nc -d` (and -d is implied by the combination of
-nc and -d)).

You can find a very simple example in pbuilder itself, look at the
source package before I start maintaining it, you'll find very weird
test files left there by dancer that were not part of the git
repository and didn't really had any role within the package.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: After upgrading pbuilder jessie-backports pbuilder stopped working

[Mattia Rizzolo]

On Tue, Mar 28, 2017 at 03:23:46PM +0200, Andreas Tille wrote:
> yesterday I upgraded pbuilder from jessie-backports on a Jessie machine:

Yes, we have a regression.

I've been told one "solution" is to recreate the chroot using the
jessie-bpo debootstrap.  otherwise please downgrade pbuilder for the
time being, while we work on it.

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Mattia Rizzolo]

Control: owner -1 !
Control: tag -1 moreinfo

On Sat, Apr 01, 2017 at 01:07:18AM +0300, Коля Гурьев wrote:
> I am looking for a sponsor for my package "microsoft-gsl"

Hi!

>  Package name: microsoft-gsl

As others said already, 'microsoft' in the package name is a sad
situation.  Personally, is just a can of worms I do not want to open for
so little, so please rename it to something else (I like 'ms-gsl').

>  Version : 0.1~2017.03.20~git16a6a41-1

I recommend using 0 instead of 0.1 as base version.

>   dget -x 
> https://mentors.debian.net/debian/pool/main/m/microsoft-gsl/microsoft-gsl_0.1~2017.03.20~git16a6a41-1.dsc

As I said privately, I'd enjoy having a git repository for this :)
Here I feel you could enjoy even more baing the repo out of upstream
git (see an example in the dehydrated package); or you can see my
pencil2d package for an example of a thing building tarball out of
upstream git, ready to be committed; as you prefer.

* test building, I noticed it didn't take advantage of my quad-core
  system; why didn't you use compat level 10?
* please send that UnitTest.patch upstream; that's clearly one of those
  cases their stupid system with a case-insensitive file system tricked
  them…
* that empty directory tests/unittest-cpp, why didn't you remove it?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Mattia Rizzolo]

Control: retitle 859221 ITP: ms-gsl -- Microsoft Guidelines Support Library
Control: reitle -1 RFS: ms-gsl/0~git20170403.ebab8ca-1

On Sat, Apr 08, 2017 at 05:33:35PM +0300, Коля Гурьев wrote:
> 04.04.2017 03:22, Mattia Rizzolo пишет:
> > As I said privately, I'd enjoy having a git repository for this :)
> > Here I feel you could enjoy even more baing the repo out of upstream
> > git (see an example in the dehydrated package); or you can see my
> > pencil2d package for an example of a thing building tarball out of
> > upstream git, ready to be committed; as you prefer.
> 
> I temporally uploaded my repo to GitHub [1]

Nice, would you also please push upstream and prisitine-tar branches?
(you may name upstream and debian branches as you see fit, just be sure
HEAD points to the packaging branch and debian/gbp.conf reflects the
reality if it's not the default)

> I believe alioth.debian.org
> will be a better location. I've registered there (my username is
> mymedia-guest) just now.

As you saw, I made a request for you to access collab-maint.

> I also made get-orig-source target in d/rules. It clones the upstream
> repository and pack it in a tar archive. I made it because I hadn't found
> any tarball on upstream GitHub.

Cool.

> > * test building, I noticed it didn't take advantage of my quad-core
> >   system; why didn't you use compat level 10?
> 
> I'm Ubuntu user, but there is only debhelper of version 9 in ubuntu
> repositories. So I added --parallel option into d/rules file as an interim
> solution.

Look better, debhelper >= 10 is available in xenial, yakkety and zesty.
Besides, in theory you are supposed to test your packages in Debian too
:P

Also, it shouldn't matter much, as you should be building your packages
in the current development version, using a chroot (see tools like
pbuilder or sbuild).


BTW, being an ubuntu user you might also consider to subscribe to the
launchpad package.  An Ubuntu developer (it wasn't me!) synced the
package in Ubuntu zesty already, and there is already a bug open there
too https://launchpad.net/ubuntu/+source/telegram-desktop (same for
ms-gsl once it will be there).
Just so you know, I have upload rights to Ubuntu's universe too (i.e. I
am a MOTU).

> > * please send that UnitTest.patch upstream; that's clearly one of those
> >   cases their stupid system with a case-insensitive file system tricked
> >   them…
> 
> It seems the upstream doesn't need this patch because they use a last
> version of UnitTeset++ framework where the header has capital letters.

| + In libunittest++ debian package others paths are.

The grammar of this sentence is off :)
I suggest "In the libunittest++ debian package the paths are different".
But is it really just a debian thing? :O  Or upstream changed something?

> [1] https://github.com/mymedia2/ms-gsl



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#857131: RFS: fgrun/2016.4.0-0.1 [RC, NMU]

[Mattia Rizzolo]

control: tag -1 moreinfo

On Fri, Mar 10, 2017 at 07:58:52AM -0700, Sean Whitton wrote:
> Since Markus has got involved in this thread, perhaps you can organise a
> team upload, and/or add Boyuan to the Uploaders: field.

Indeed.
Markus: would you please take this RFS to its end?

> > * This package has a longstanding unfixed RC bug (FTBFS) and fell out of
> > Stretch release. With absolutely zero reverse dependency and migration 
> > blocking, I believe fgrun should be able to enter unstable even though we 
> > are 
> > in freeze now (because it wouldn't affect other packages or Stretch release 
> > at 
> > all).
> 
> Note that the release team's freeze policy does not allow this.

I'm quite positive that the release team doesn't particularly care about
what happens to sid-only packages unless as long as they don't correlate
to anything that is in stretch (i.e. a package in stretch starting to
depending on a sid-only package).


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: someone knows about https://archive.debian.net/

[Mattia Rizzolo]

have you also read that page?..

more info: the person who was nominally maintaining it was not maintaining
it, as he let the SSL certificate expire, and so DSA took repointed the DNS
to an error page.

On Fri, Apr 21, 2017 at 4:04 PM PICCORO McKAY Lenz 
wrote:

> some one noted or using any time the https://archive.debian.net/ service..
>
> was usefully for packagin notes and test over other versions..
> archived of course.. was usefully for my lives due most old hardware
> like framegrabber capture devices does not have support today in
> current klernels...
>
> today this service are changed and now only put a static page in
> frontend.. anybocy knows about related?
>
> --
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
>

Bug#748019: RFS: scribus/1.4.2.dfsg.1+r18267-0.1 [RC, NMU]

[Mattia Rizzolo]

X-Debbugs-CC: Andrea Colangelo 
Package: sponsorship-requests
Severity: important
Control: block 741666 by -1


Dear mentors,

I am looking for a sponsor for the package "scribus".
My usual sponsor (CC'ed) is busy right now, and this is a NMU for a RC bug
(#741666).

 * Package name: scribus
   Version : 1.4.2.dfsg.1+r18267-0.1
   Section : graphics

It builds those binary packages:

  scribus- Open Source Desktop Page Layout - stable branch

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

  http://mentors.debian.net/package/scribus

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

  dget -x 
http://mentors.debian.net/debian/pool/main/s/scribus/scribus_1.4.2.dfsg.1+r18267-0.1.dsc

Changes since the last upload:

  scribus (1.4.2.dfsg.1+r18267-0.1) unstable; urgency=medium

* Non-maintainer upload.
* Repack the source to remove some non-free contents. (Closes: #741666)
* debian/README.source: update to reflect the above changes.


--
regards,
        Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Bug#749213: RFS: qtop/2.2.3-2 [ITP]

[Mattia Rizzolo]

On Sun, May 25, 2014 at 10:16 AM, Hugo Lefeuvre  wrote:
>  I've already asked for a sponsorship, but the name of the package was
>  buggy. I've also made a patch to change the name of the software from
>  'Top' to 'qtop'.
>
> qtop (2.2.3-2) unstable; urgency=low
>
>   * debian/patches/name.patch:
> - Changes the name of the binary from Top to qtop.
>
>  -- Hugo Lefeuvre   Sun, 25 May 2014 00:42:12 +0200
>
> qtop (2.2.3-1) unstable; urgency=low
>
>   * Initial release (Closes: #731881)
>
>  -- Hugo Lefeuvre   Sun, 18 May 2014 17:23:10 +0200

Since the package has been never released, please remove the changelog
entry for 2.2.3-2 and keep only the first with "Initial release".


-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymet3gjkva+vpyfnnfaybhhualctwn+qtdvgcmfnb0cv...@mail.gmail.com

missing LDFLAGS

[Mattia Rizzolo]

/moc_pentool.o .obj/moc_penciltool.o 
.obj/moc_brushtool.o .obj/moc_erasertool.o .obj/moc_selecttool.o 
.obj/moc_movetool.o .obj/moc_handtool.o .obj/moc_smudgetool.o 
.obj/moc_polylinetool.o .obj/moc_buckettool.o .obj/moc_eyedroppertool.o 
.obj/moc_shortcutspage.o .obj/moc_mainwindow2.o .obj/moc_timelinecells.o 
.obj/moc_keycapturelineedit.o .obj/moc_objectsaveloader.o .obj/moc_stroketool.o 
.obj/moc_colorwheel.o .obj/moc_colorinspector.o .obj/moc_colorgriditem.o 
.obj/moc_colorgrid.o .obj/moc_colorbox.o .obj/moc_recentfilemenu.o 
.obj/moc_colormanager.o .obj/moc_toolmanager.o .obj/moc_layermanager.o 
.obj/moc_basemanager.o .obj/moc_quazipfile.o   -L/usr/X11R6/lib64 -Lliblinux 
-lming -lpng -lz -L/usr/local/zlib/lib -lQt5Svg -L/usr/lib/x86_64-linux-gnu 
-lQt5Multimedia -lQt5XmlPatterns -lQt5Widgets -lQt5Network -lQt5Xml -lQt5Gui 
-lQt5Core -lGL -lpthread 



So I suppose that -fPIE and -pie are missing from LDFLAGS. This is strange,
given that I don't override dh_auto_build and I use dh9.
I also try (locally) to add "LDFLAGS += -fPIE -pie" at the top of the rules
file, but without success.

Does somebody have any hint on what to look for/to?


[0] http://packages.qa.debian.org/p/pencil2d.html
[1] http://qa.debian.org/bls/packages/p/pencil2d.html

-- 
regards,
        Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Re: missing LDFLAGS

[Mattia Rizzolo]

On Mon, Jun 9, 2014 at 4:05 PM, Paul Wise  wrote:
> This package uses qmake. It appears debhelper has support for qmake
> and passes LDFLAGS on to the qmake generated Makefile using
> QMAKE_LFLAGS_RELEASE and QMAKE_LFLAGS_DEBUG. It might be that the
> generated Makefile in this case uses a different variable for passing
> flags to the linker. I suggest you look at the generated Makefile for
> some hints.

This is not the case: the others flage (i.e. -Wl,-z,relro) are passed
to the liker.
Looks like -fPIE and -pie are not passed:

% dpkg-buildflags --get LDFLAGS
-Wl,-z,relro

I'm now wondering why bls complains...

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymetgdiypcalvc_hgc5jbiqaw9okxfxfitpd3rg3tsht...@mail.gmail.com

Re: missing LDFLAGS

[Mattia Rizzolo]

On Mon, Jun 9, 2014 at 5:35 PM, Paul Wise  wrote:
> Aha, you want this in debian/rules to get the extra flags:
>
> export DEB_BUILD_MAINT_OPTIONS=hardening=+all

Oh, that's new to me, thanks, it worked! :)

> BTW: you can run blhc locally to check build logs for hardening flags.

this is what I did.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymeu6qss1nwgkgbgcyxsr0m86kc+fnkmyxnxsr3ytbbf...@mail.gmail.com

Re: Bug#760065: RFS: kildclient/3.0.0-1 [new upstream version of package already in Debian]

[Mattia Rizzolo]

[removing the RFS bug from the CC list and putting d-mentors@ldo]

On Tue, Sep 2, 2014 at 8:42 PM, Eriberto  wrote:
> 2014-09-02 15:16 GMT-03:00 Eduardo M KALINOWSKI :
>> On Seg, 01 Set 2014, Eriberto Mota wrote:
>>> 1. d/changelog: add ACK for NMU. See details here[1].
>> I included the NMU changelog entry in debian/changelog (after my changes),
>> is something else necessary?
> See an example here:
> http://metadata.ftp-master.debian.org/changelogs/main/g/gconjugue/unstable_changelog
>

I'm not sure this needed (anymore?)
The devref reads:
"To acknowledge an NMU, include its changes and changelog entry in
your next maintainer upload. If you do not acknowledge the NMU by
including the NMU changelog entry in your changelog, the bugs will
remain closed in the BTS but will be listed as affecting your
maintainer version of the package."

I totally don't understand what's the meaning of "the maintainer
version of the package". Based of the BTS behaviour I saw, I'd say it
collects the package's versions (so the package's history) from
http://metadata.ftp-master.debian.org/changelogs/main/$letter/$package/unstable_changelog.
If you retain the entry for the NMU (you should) in the changelog, the
BTS will contain to consider your package as fixed, even if you don't
ack the NMU.

Please enlighten me if I got this wrong :)

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymes777-7wr60rvj01jd2qqwwug2hrvtj7f8rvljvz1a...@mail.gmail.com

Re: How to resolve circular build dependency?

[Mattia Rizzolo]

On Sep 13, 2014 3:01 PM, "Ole Streicher"  wrote:
>
> Dear mentors,
>
> in debian-astro, we have a problem with a circular dependency on two
> packages that are currently prepared [1], [2]:
>
> - the "casacore" needs the "casacore-data" package for unit tests
>
> - the "casacore-data" needs "casacore" to be build from the source data.
>
> The source data of casacore-data are actually independent of casacore,
> so it does not make sense to put both into one common package.
>
> How can this problem be solved?
>

What's about upload casacore with the tests disabled, then upload
casacore-data, then re-upload casacore with the tests re-enabled?

Re: How to resolve circular build dependency?

[Mattia Rizzolo]

On Sep 13, 2014 3:20 PM, "Ole Streicher"  wrote:
> Still, the packages would have a circular build dependency, which I think
should be avoided, right?
>

Well, compilers often build-depend on them own, which is even worse.
If a circular dependency could be avoided, better, but I don't care that
much.

I also guess the -data package is arch: all, so it wouldn't cause any issue
during bootstraps and the like (yet it would cause a issue to some
derivatives (guess which one) that rebuild all packages, but I wouldn't
care that much, a 5 minutes work on the package and then a manual sync it's
enough)

Re: uscan/watch and savannah

[Mattia Rizzolo]

On Tue, Sep 30, 2014 at 6:10 PM, Andreas Rönnquist
 wrote:
> Hi
>
> Does anybody maintain a package which uses Savannah as host for the
> upstream, and uses the savannah file area for its file releases?

/me rise his hand

http://sources.debian.net/src/licenseutils/0.0.7-3/debian/watch/

>
> My problem is that while uscan --report-status reports that an upstream
> is available, since it checks the
>
> http://download.savannah.gnu.org/
>
> folder, but when it is time to download, savannah redirects to the
> nearest mirror site and tries to download from there. (In my case
> http://nongnu.uib.no/ ) where the file hasn't had the time to
> replicate, which causes problems, and the download isn't possible.
>
> What is the best way to come around this problem where uscan
> --report-status reports that a release is available, while it hasn't
> had time to replicate to the site where download happens from?
>
> Do you people simply use download-mirror.savannah.gnu.org in watch
> instead, or is there a better solution?

do you mind link your watch file (and maybe tell us the which package is this)
-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymes+zctyc9kxbfcl3h_3rgik7l6nt2ql-cihcfzfwpn...@mail.gmail.com

Re: Minimized Javascript

[Mattia Rizzolo]

On Nov 6, 2014 10:30 AM, "Maxime Chatelle"  wrote:
>
> Hi,
>
> I'm doing the packaging for a documentation package. The content is
> HTML, CSS, some images, one "source" javascript library, and 2 minimized
> javascript libraries. The minimized libraries is a problem.
>
> I think about these solutions:
>
> 1) Remove minimized libraries from the source package (dfsg), create two
> new Debian packages for the libraries and do the required linking.

This should be done if the libraries are generic (e.g. jquery), but not
strictly required.

> 2) Remove minimized libraries from the source package (dfsg) and add
> quilt patches to include "source" version of the libraries.

Good enough

> 3) Remove minimized libraries from the source package (dfsg) and trying
> to patch HTML files to get rid of the libraries.

Not sure where is the differences from 2.

> 4) (Not sure if I can do that) Remove minimized versions and replace
> these by the "source" versions directly in the DFSG source package.

Do not edit upstream source without using patches at build time (e.g. using
quilt).

5) remove the minimized libraries from the source package (dfsg), and
reminimize them at build time

Re: Facilitating contributions by newcomers

[Mattia Rizzolo]

On Wed, Nov 12, 2014 at 9:50 AM, Christian Kastner  wrote:
> I'd argue it's good enough for the task itself, but searching for areas
> to contribute to could still be improved significantly.

I agree.

> For example,
> given the following list of motivations a new contributor might have
>
>"I want to help fix simple bugs in C programs."
>"I want to help fix difficult bugs in Java programs."
>"I want to help with translations."
>"I want to help multiarchify packages."

I think you all may be interested on http://harvest.ubuntu.com/opportunities/
Not sure on how it works, but it collects data from different services
(e.g., merges.u.c) other than the bug tracker, and it's able to
present opportunities in various fields, sorting them by different
criteria.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymeulmwsj10vsker-lgckbfm21wn_pzl0natndkagrtf...@mail.gmail.com

Re: Qemubuilder for arm64?

[Mattia Rizzolo]

On Wed, Nov 19, 2014 at 09:41:46PM +0100, Daniel Stender wrote:
> Hi,
> 
> I'm trying to get Qemubuilder run for arm64 package building, but fails
> so far. I've got a proper kernel and initrd, but breaks with:
> "Your architecture arm64 does not seem to be supported". Maybe that's
> exactly how it is, is it?
> 
> Does anybody has got Qemubuilder run for arm64, or have any pointers
> to other cross-package-building solutions other than building in
> a Qemu box itself?

qemu-user-static is enough (more or less, I'm not an expert of qemu and
virtualization in general).
I use this to create an arm64 chroot (and then build and do stuff:

sudo -E eatmydata pbuilder --create --override-config \
 --architecture arm64 \
 --distribution sid --components main \
 --aptcache /home/mattia/pbuilder/cache/apt/sid/arm64 \
 --buildresult /home/mattia/pbuilder/result/sid/arm64/ \
 --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg \
 --mirror http://http.debian.net/debian \
 --basetgz /home/mattia/pbuilder/sid-arm64-base.tgz \
 --debootstrap qemu-debootstrap

Obviously I scripted it (with a script that handle much more...) and I use other
arguments, but still, this is the base.

I noted that this packages are needed:
qemu-system-arm libc6:arm64 libeatmydata1:arm64 libselinux1:arm64
you have to install libeatmydata on the chroot (e.g. by
EXTRAPACKAGES+="libeatmydata1" on .pbuilderrc) and load it (there are pleany of
guides to do so on the internet). I suggest you to use it, because without it
it's going to take forever (and it teake a huge amount of time anyway, due to
the qemu thingy).

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Re: Bug#771245: RFS: wmanager/0.2.1-12 (fix an important bug in jessie)

[Mattia Rizzolo]

On Fri, Nov 28, 2014, 10:41 PM Peter Pentchev  wrote:


 Hmm, but is there some problem with the buildds?  It looks like you
tried to use a long-awaited brand-new feature of the buildd network -
a real source-only upload - and all the buildds successfully built
the package, but none of them has tried to upload it yet.

https

://

buildd.debian.org

/status/

logs.php

?pkg=

wmanager

&

ver

=0.2.1-12&suite=

sid


Should we get in touch with debian-wb-team?



 Not sure about what you are talking about...
The 0.2.1-12 binaries are in the archive...
http://ftp.debian.org/debian/pool/main/w/wmanager/

Re: Big data is needed for unit test

[Mattia Rizzolo]

On Tue, Dec 02, 2014 at 11:12:35AM +0100, Corentin Desfarges wrote:
> >What license is the file under?
> 
> It hasn't any license.

Then it's license is the default "all rights reserved", you can't redistribute
it, you can't change it, you can't do anything, and you can't use it without
explicit permission from it's copyright holder.
Of course you can't upload it to the debian archive (see DFSG).

Please check better, given that it is the test case of a free software maybe
also the data are free.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Re: Re: Re: Re: Big data is needed for unit test

[Mattia Rizzolo]

On Fri, Dec 05, 2014 at 10:37:39AM +0800, Paul Wise wrote:
> On Thu, Dec 4, 2014 at 11:16 PM, Corentin Desfarges wrote:
> 
> > The file is just used by one of the unit tests. But there are more than 20
> > unit tests which need their own specific data to work.
> 
> Personally I'm now leaning towards you doing the unit tests on your
> own hardware against the installed package, rather than doing the unit
> tests at build time on Debian hosts. You could also place the test
> files on your website and have a README file or test-me script that
> people could use to download the test files and run the tests against
> the installed package.

This, and write a DEP8 test to be run on ci.debian.net.
See http://ci.debian.net/doc/ for more info.

-- 
regards,
        Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Re: launchpad for debian and autobuilders

[Mattia Rizzolo]

On Fri, Dec 12, 2014 at 09:52:37AM +0100, Leopold Palomo-Avellaneda wrote:
> A Divendres, 12 de desembre de 2014, Paul Wise va escriure:
> > On Fri, Dec 12, 2014 at 4:26 PM, Leopold Palomo-Avellaneda wrote:
> > The Debian autobuild service is here:
> > https://buildd.debian.org/
> Yes, but _only_ the debian developers could access there. If I want to test a 
> package, you need an sponsor, and so on. I know the path.

ftp masters are also working to have PPA in debian (for DD and DM, if IIUC), but
this is a long dream.

> The question is that sometimes one wants to build or test, or whatever and
> launchpad offers that service for ubuntu. And the people, like me, that would 
> like to have own packages to test previous search an sponsor, have to create
> all this infrastructure. That's all.
> 
> I would love to have a public service to build with clean autobuilders
> packages for the people. Not, like now that you have to build your own
> environtment.

To solve this issue (in fact, not everyone has a powerful enough computer to
locally build everything) some people write some tools.
I know about Deb-o-Matic: https://packages.debian.org/sid/debomatic

The developer run an instance here: http://debomatic-amd64.debian.net/ (also
with a really nice web interface see github for the source).
(if you are going to ask, the packages are currently keep for 15 days)

-- 
regards,
    Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me:  http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page:   https://wiki.ubuntu.com/MattiaRizzolo


signature.asc
Description: Digital signature

Re: pbuilder questions

[Mattia Rizzolo]

On Tue, Mar 17, 2015 at 07:31:18PM +0100, Felix Natter wrote:
> hi,
> 
> I tried to follow this hint:
>   
> https://wiki.debian.org/PbuilderTricks#How_to_include_local_packages_in_the_build
> but I have some questions along the way (and will improve the
> documentation with your replies).

fine & good

> I am using this configuration (currently in /etc/pbuilderrc [1]):
> [1] I couldn't get it to work by putting the config in
> /home/felix/.pbuilderrc (possibly because I didn't run "pbuilder create"
> after configuring).

I somehow feel this is because you have to use `sudo -E` to preserve $HOME, or
otherwise put the file in /root/.pbuilderrc (imho bad)

> --
> #AUTO_DEBSIGN=${AUTO_DEBSIGN:-yes}
> #HOOKDIR=/var/cache/pbuilder/hooks
> 
> # Location of the dir where you keep pbuilder hook scripts.
> HOOKDIR="/home/felix/.pbuilder-hooks"
> 
> # Path to your local repo to be used as a mirror written as apt source line.
> OTHERMIRROR="deb [trusted=yes] file:///home/felix/pbuilder/local_repo ./"
> 
> # Path to your local repo. This tells pbuilder to mount this directory so it 
> is available in the chroot.
> BINDMOUNTS="/home/felix/pbuilder/local_repo"
> 
> # As we need to have the apt-ftparchive command, we need to insure this 
> package is installed.
> EXTRAPACKAGES="apt-utils"
> --
> 
> -- /home/felix/.pbuilder-hooks/D05update-local-repo --
> #!/bin/bash
> 
> # Path to the local repo.
> LOCAL_REPO="/home/felix/pbuilder/local_repo"
> 
> # Generate a Packages file.
> (cd $LOCAL_REPO ; apt-ftparchive packages . > Packages)
> 
> # Update to include any new packages in the local repo.
> apt-get update
> --
> 
> => my questions are:
> 
> - It seems I need to run "pbuilder create" to honor the changes to
>   /etc/pbuilderrc. Is that true? Does "pbuilder --update" suffice?

recreate the chroot or use --override-config while --update
see pbuilder(8)

> - I think I can put the above variables into ~/.pbuilderrc
>   (/home/felix/.pbuilderrc).  But how is this honored when running "sudo
>   pbuilder create"?  (runs as root, "pbuilder" knows nothing about user
>   'felix'...)

as I said, `sudo -E pbuilder...`.
I use a (rather large and bloated) wrapper similar to pbuilder-dist, but maybe
if plain pbuilder is fine for you maybe you can alias it:
alias pbuilder="sudo -E pbuilder"

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540 .''`.
more about me:  http://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-


signature.asc
Description: Digital signature

Re: how to migrate from experimental to unstable

[Mattia Rizzolo]

On Mon, Apr 27, 2015 at 7:18 PM, Jerome BENOIT  wrote:
> Hello List,
>
> it sounds as a trivial question, but I cannot figure out any answer from 
> Google:
> how can we push package in experimental to unstable ?

upload them again to unstable with a greater version number than experimental's.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymet8_7lnww1xmnazaocvhva0u1nddpxrdhxzuty2w8m...@mail.gmail.com

Re: why dpkg-buildpackage doesn't care my build targets in debian/rule

[Mattia Rizzolo]

On Fri, May 22, 2015 at 6:31 AM, lumin  wrote:
> override_dh_auto_build:
> # well. let's copy config back again.
> cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
> debian/my/00-fix-caffe-include-path-debian.sh
> $(MAKE) all
> $(MAKE) test
> $(MAKE) runtest

also, that test things should go in a override_dh_auto_test target,
not in the build one.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymes4s6pn8b4fhqnlwxdc2ezfe3rek4srajdh+f4ga9e...@mail.gmail.com

Re: Pbuilder requests Build-Depends on local machine - why this?

[Mattia Rizzolo]

Hi *,

On Thu, Jun 25, 2015 at 10:02:32PM +0200, Andreas Tille wrote:
> On Thu, Jun 25, 2015 at 10:35:49PM +0900, Hideki Yamane wrote:
> > 
> >  I've changed local pdebuild as
> > 
> > -echo "dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD} 
> > $DEBBUILDOPTS" | \ 
> > +echo "dpkg-buildpackage -S -d -us -uc -r${BUILDSOURCEROOTCMD} 
> > $DEBBUILDOPTS" | \
> 
> Cool.  Do you intend to upload soonish or should rather I use a local
> build incorporating this meanwhile?

just FTR, I plan (and working towards) to adopt pbuilder, which is unmaintained
since some time.

I incorporated this particular change in my git clone, but another upload (NMU)
is already in deferred and will lend in 6 days in unstable.

I scheduled my upload as a maintainer with this somewhere mid/late july.
If that bugs you too much and you're willing to do un upload before please get
in touch with me and NMU pbuilder after the pending upload hits unstable.


(btw it's not needed "a local build", `vim /usr/bin/pdebuild` is enough :P)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540 .''`.
more about me:  http://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-


signature.asc
Description: Digital signature

Bug#790771: why closed ?

[Mattia Rizzolo]

On Wed, Jul 01, 2015 at 05:54:01PM +0100, Ghislain Vaillant wrote:

Please, avoid sending email in HTML.

> On 01/07/15 17:51, PICCA Frederic-Emmanuel wrote:
> >look at the title ;)
> >RFS for the 2.4-1 version :)
> >
> >no worry upload to mentors en I will take care of the sponsoring.
> >
> >Cheers
> >
> >Fred
> >
> >>#790771: RFS: clblas/2.4-1 -- OpenCL BLAS library
> 
> Sure, because:
> 
> *Changed Bug title to 'RFS: clblas/2.4-1 -- OpenCL BLAS library' from 'RFS:
> clblas/2.4-2 -- OpenCL BLAS library'*Request was from |Bart Martens
> |to |cont...@bugs.debian.org|. (Wed, 01 Jul 2015
> 16:27:14 GMT) Full text
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=790771>and rfc822
> format 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=790771;mbox=yes>available.
> 
> Which still leaves my original question: why ?

Try opening one of the link you posted ↑
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790771;msg=12

I see that the package at mentors has version 2.4-1
so I retitle the RFS to match that version.

And indeed 2.4-2 was uploaded only today, after this change.


Btw, of course that's an automated email, by a service run by bartm to help
keeping the RFS queue acceptable.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540 .''`.
more about me:  http://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-


signature.asc
Description: Digital signature

Re: Granting DM rights as a sponsor

[Mattia Rizzolo]

On Tue, Jul 14, 2015 at 06:11:14PM -0700, Vincent Cheng wrote:
> actually switched to using dput-ng myself (mostly due to inertia, and
> also IIRC it involves dput config file changes).

It does not.
dput-ng is entirely compatible with dput config files, it just adds a new
format (json-based) if you want to, but you are not required to use it.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540 .''`.
more about me:  http://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-


signature.asc
Description: Digital signature

Bug#861072: RFS: golang-github-pkg-xattr/0.2.0+git20170313.4.2c7218a-1

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: owner -1 !

On Mon, Apr 24, 2017 at 01:36:46PM +0200, Félix Sipma wrote:
> I am looking for a sponsor for "golang-github-pkg-xattr":

hi there!

> gbp clone --pristine-tar 
> https://anonscm.debian.org/git/pkg-go/packages/golang-github-pkg-xattr.git


You are doing some really bad, actually, namely defining
DEB_BUILD_OPTIONS in d/rules.  I thought lintian had a check for this.
Please don't do this: either use DEB_BUILD_MAINT_OPTIONS, or add an
empty dh_auto_test override.  In both cases, I would appreciate if you
could add that comment you added in the git commit message directly as a
comment to d/rules, so people can wonder less on why you disabled the
tests.

Besides, why not just exporting the variable, instead of doing the way
you did it?

Also, can you write a tad longer description?  (lintian does complain
about this).


I am not sure of the general rules within the go team, but usually I
prefer when people don't do debian/ tag unless they are 100% sure that's
what is going to be uploaded.  In this case you are now forced to either
remove that tag (and then I have to manually remove it locally too…, and
so are all the people who have already cloned that repo), or bump the
version which is probably even uglier…

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: request for maintaining my packages

[Mattia Rizzolo]

On Fri, May 05, 2017 at 01:08:41PM +0200, erana wrote:
> To help out debian I would like to maintain 2 packages : koboldsquest and
> isle-of-evermeet. These have been uploaded and packaged to the anonymous
> debian upload ftp server and are also available at 
> http://erana.yellowcouch.org/debian/

...
https://lists.debian.org/package-sponsorship-requests/2017/package-sponsorship-requests-201705/msg00052.html
https://lists.debian.org/package-sponsorship-requests/2017/package-sponsorship-requests-201705/msg00053.html

And please don't cross post that way.

(this — debian-mentors — would be the correct list, btw)

-- 
regards,
            Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: owner -1 !

On Mon, May 15, 2017 at 10:57:36PM +0300, Коля Гурьев wrote:
> I am looking for a sponsor for my package "libtgvoip"

o/

> dget -x 
> https://mentors.debian.net/debian/pool/main/libt/libtgvoip/libtgvoip_0.4.1~git20170514.73bf810-1.dsc

Using git as you know I prefer it :)

I fixed the HEAD on alioth to point to the debian branch (as otherwise
cloning would checkout master causing
warning: remote HEAD refers to nonexistent ref, unable to checkout.
), also could you please push some upstream tags and add an appropriate
d/gbp.conf?


Review:
* d/control:
  + Vcs-Git is wrong
  + I appreciate when Vcs-Browser is the same as Vcs-Git, given they can
be now (hint: use /git/ in both)
* d/rules:
  + why are you calling dh_install manually at the end of
dh_auto_install? it's called by dh anyway


It also fails to build for me on i386 with an error that looks like SSE2
related (but I'll let you look at it).

Otherwise it looks cool to me, but I'd like to have a correct Vcs-Git
and a working i386 build at the first upload…

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Mattia Rizzolo]

On Wed, May 17, 2017 at 12:46:46PM +0300, Коля Гурьев wrote:
> 16.05.2017 13:01, Mattia Rizzolo пишет:
> > ), also could you please push some upstream tags and add an appropriate
> > d/gbp.conf?
> 
> What kind of tags you're interested in? Unfortunately, there are no any tags
> in the upstream repository.

Well, I guess at least gbp's upstream/ tags at least, in this
case I'd expect a debian/0.4.1~git20170514.73bf810 at the commit
afa9bd2ea3c81a3f74b740946186a94e2112c957.
I think there should be a flag in some gbp command to do that in some
cases (but I don't have enough experience in using gbp on top of the
upstream git repo)

> I also renamed debian branch to master, so gbp seems to be working.

ok.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Mattia Rizzolo]

On Wed, May 17, 2017 at 12:50:52PM +0300, Коля Гурьев wrote:
> In addition, I added a patch for fix deadlock when an incoming call is
> complete. It works for me, but it may cause some other problems.

I'm fine uploading it with that rejected patch if you want.

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Mattia Rizzolo]

On Wed, May 17, 2017 at 02:21:42PM +0200, Mattia Rizzolo wrote:
> On Wed, May 17, 2017 at 12:50:52PM +0300, Коля Гурьев wrote:
> > In addition, I added a patch for fix deadlock when an incoming call is
> > complete. It works for me, but it may cause some other problems.
> 
> I'm fine uploading it with that rejected patch if you want.

Although, I now see upstream did a commit "hopefully" fixing it, so try
that out instead of your "solution"?
https://github.com/grishka/libtgvoip/commit/937a85788630f3d57b5cc5d30f764db3ecce7e0b


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#862691: RFS: telegram-desktop/1.1.0-1 - official telegram messaging application

[Mattia Rizzolo]

On Thu, May 18, 2017 at 12:36:04AM +0300, Коля Гурьев wrote:
> Great, but... The upstream has released a new "stable" version v1.1.2 right
> now. A changelog is the next:

wow, that was fast ^^

> What do you think I should prepare a new version of the package
> immediately? Or may I do it by later, maybe tomorrow?

I don't mind either way (I wouldn't be doing it right not anyway).

-- 
regards,
    Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Droping v5 extension to library names

[Mattia Rizzolo]

On Mon, Jun 12, 2017 at 08:14:35PM +0200, Andreas Tille wrote:
> For instance for the package libbpp-core2v5 which has
> now soversion=3.  Should the new package be named
> 
> libbpp-core3v5

This no.

> or
> libbpp-core3
> ?

This one is right.



I think this was part of the announcement done back when the v5 suffix
where annouced by Matthias.

-- 
regards,
            Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Exclude files after gpb import-orig

[Mattia Rizzolo]

On Mon, Jun 19, 2017 at 06:43:43PM +0500, Andrey Rahmatullin wrote:
> On Mon, Jun 19, 2017 at 03:38:24PM +0200, Muri Nicanor wrote:
> > I've imported a source package into git using gbp import-orig --uscan,
> > then updated the changelog with gbp dch and then made a lot of changes
> > (and commited them). Now I added a file to Files-Excluded: in
> > debian/copyright- but when I run gbp buildpackage, it still generates a
> > source-package with the file included. I guess i have to somehow run
> > uscan again, and redo the import-orig?
> Yes, Files-Excluded: is only used by uscan when generating the orig.tar.
> Don't forget to change the upstream version when regenerating the tarball.

Also, you don't really need to run uscan (which can be a very annoying
task if you are on slow network and the tarball is big), you only need
mk-origtargz(1), which is the tool uscan calls to repack the tarball,
and you can use the tarball you already have.
If you haven't pushed anything around, you might be able to roll back
you changes to were you were before, but it can be difficult and
"dangerous" (for you safety of the data in the git repo) if you are not
keen to use git.  I recommend just rebuilding the tarball versioning it
+dfsg1 (assuming the previous one was "+dgsg" only) and import it again.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Exclude files after gpb import-orig

[Mattia Rizzolo]

On Mon, Jun 19, 2017 at 10:34:42PM +0200, Muri Nicanor wrote:
> Thank you Andrey and Mattia, that worked. For the record, I've added the
> files to Files-Excluded, ran mk-origtargz -S +ds1
> ../usbguard_0.7.0.orig.tar.gz and then ran gbp import-orig
> ../usbguard_0.7.0+ds1.orig.tar.gz and used 0.7.0+ds1 as upstream-version
> (and then updated the d/changelog files accordingly).

Nice.

Also take note that most probably you're going to need to update
debian/watch to properly mangle that in its dversionmangle rule.  I
recommend something like this, that is always good:
dversionmangle=s/\+(debian|dfsg|ds|deb)(\d+)?$//

-- 
regards,
        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature