Re: How to package a library only used with LD_PRELOAD?

[Stephen Kitt]

Hi Linus,

On Mon, 11 Jan 2021 15:24:44 +0200, Linus Vanas  wrote:
> I've been working on packaging libstrangle:
> https://salsa.debian.org/Huitsi/libstrangle
> 
> The library is only meant to be used with LD_PRELOAD and not linked with 
> at build-time, but an upstream script assumes the lib is in the ld 
> search path. To my understanding of the policy, this would mean having 
> to comply with "8. Shared libraries" despite the library really not 
> being suited for it. I'd rather patch the script than make the library 
> comply with shared library policy but I'm unsure how to do that in a 
> multiarch-compatible way.
> 
> Am I reading the situation correctly and if so, how should I solve it?

I agree it would be better to patch the script. However you don’t have to
make the package multiarch-compliant; you can install your library in a
package-private directory, the same on all architectures, and leave it at
that. That said, given that i386 libstrangle would be useful on amd64,
alongside amd64 libstrangle, it might be better to look into the Rpath token
expansions which are supported by ld.so in LD_PRELOAD, e.g. $PLATFORM —
although it doesn’t fully match the multiarch requirements. (See man ld.so
for details.)

See olla for an example of a non-multiarch LD_PRELOAD library; it installs

/etc/bash_completion.d/olla
/etc/olla.conf
/usr/lib/olla/libolla.so
/usr/lib/olla/libolla.so.1
/usr/lib/olla/libolla.so.1.0
/usr/share/doc/olla/README.markdown
/usr/share/doc/olla/changelog.gz
/usr/share/doc/olla/copyright

Regards,

Stephen


pgpxYRo8Q3kBL.pgp
Description: OpenPGP digital signature

Bug#944323: RFS: piper/0.3-1 [ITP] -- graphical frontend for libratbag

[Stephen Kitt]

On Fri, 08 Nov 2019 14:47:41 +, Stephan Lachnit
 wrote:
> > you need python3-dev in the build-dependencies instead of python3
> > (as-is, the package doesn’t build in a clean build chroot)  
> This give me the following lintian warning:
> build-depends-on-python-dev-with-no-arch-any
> 
> However I don't really get what the difference between python3-dev and
> python3 is, the lintian tag entry doesn't really help.

Right, python3 is the interpreter only, python3-dev adds a number of files
which are necessary to build Python modules. I suspect that Piper doesn’t
need python3-dev, and its meson.build could be changed to avoid that
build dependency...

> > the ratbagd dependency should be (>= 0.10-1), greater than rather
> > than equal, otherwise the piper package ends up too closely tied to
> > libratbag (0.10-2 would break the dependency, as would the
> > forthcoming 0.11-1); in fact switching to >= means you can even drop
> > the package revision, and write (>= 0.10)  
> 
> What I tried to do with my initial (=0.10) was to let every 0.10 version
> work, so 0.10-1 and 0.10-2, however this doesn't work. I tried to bind
> piper to a specific ratbagd version because the Wiki states that ratbagd
> API is not stable.

OK, to do something like that you’d depend on “ratbatgd (>= 0.10), ratbagd
(<< 0.11)”. I’m not sure that’s the best approach: you’d end up having to
upload a new version of Piper every time a new upstream version of ratbagd
was released (e.g. 0.11 which is now in the archive).

I’d go for a different approach: if ratbagd changes in an incompatible way,
since it doesn’t provide API guarantees, then it should be in charge of
keeping track of that. Technically, that would mean that an incompatible
version of ratbagd would declare that it breaks the relevant versions of
Piper, which would ensure that users wouldn’t upgrade if they have an
incompatible version of Piper.

With the latter approach, non-breaking versions of ratbagd can be uploaded
without requiring a new upload of Piper. If ratbagd breaks Piper, upstream
will release a new version of Piper anyway, which would require an upload.

> I uploaded a new version with the right debian version and your suggestions.
> I know I have to update the git workflow, will do that in the future.

OK, thanks!

If you don’t have anything left to do on the package, I can upload it for
you, and create the repository on Salsa in the debian namespace.

Regards,

Stephen


pgpXPDUXwOHC6.pgp
Description: OpenPGP digital signature

Bug#944323: RFS: piper/0.3-1 [ITP] -- graphical frontend for libratbag

[Stephen Kitt]

Hi Stephan,

On Thu, Nov 07, 2019 at 10:32:25PM +0100, Stephan Lachnit wrote:
> I am looking for a sponsor for my package "piper"

I noticed a few of problems which need to be fixed:

* you need python3-dev in the build-dependencies instead of python3
  (as-is, the package doesn’t build in a clean build chroot)
* your changes in -2 shouldn’t increment the package version, since
  there hasn’t been an upload to the archive yet — you’re still in the
  process of getting -1 ready, effectively (and it’s all still the
  “initial packaging”)
* the ratbagd dependency should be (>= 0.10-1), greater than rather
  than equal, otherwise the piper package ends up too closely tied to
  libratbag (0.10-2 would break the dependency, as would the
  forthcoming 0.11-1); in fact switching to >= means you can even drop
  the package revision, and write (>= 0.10)

I noticed that your git repo only has a single branch. I find it
better in the long run to maintain an upstream branch with the
upstream code (which can effectively be the upstream master branch,
directly), and the Debian packaging in a separate branch. Check out
https://dep-team.pages.debian.net/deps/dep14/ for one possible
layout.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#943730: marked as done (RFS: cowsay/3.03+dfsg2-7 [ITA] -- configurable talking cow)

[Stephen Kitt]

On Wed, 30 Oct 2019 11:03:33 +0800, Paul Wise  wrote:
> On Wed, Oct 30, 2019 at 5:03 AM Stephen Kitt wrote:
> > I’ve pushed that to the games-team repository, and tagged the release.
> > Please register a guest account on Salsa if you don’t already have one:
> > https://signup.salsa.debian.org/
> > Then you’ll be able to request access to the cowsay repository and/or the
> > games team on https://salsa.debian.org/games-team  
> 
> Why not use the existing cowsay repository?
> 
> https://salsa.debian.org/debian/cowsay

Oops, sorry, yes, that’s the repo I used.

Regards,

Stephen


pgpXpikHyN6wZ.pgp
Description: OpenPGP digital signature

Bug#943730: RFS: cowsay/3.03+dfsg2-7 [ITA] -- configurable talking cow

[Stephen Kitt]

Hi James,

On Mon, Oct 28, 2019 at 07:18:45PM +0100, James McDonald wrote:
> Changes since the last upload:
>   * New maintainer (closes: #910035)
>   * Fix lintian warning about spelling of 'balloons' in patch
>   * Add fox cow (closes: #888229)
>   * Bump Standards-Version to 4.4.1
>   * Bump debhelper compat to 12

Thanks for preparing this! I’ll gladly help you get your package into
the archive.

I’ve reviewed the changes, and they look good to me, apart from the
debhelper 12 bump: could you follow the manpage’s recommendation, and
use debhelper-compat instead of debian/compat?

Also, do you have access to the repository on Salsa?

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#882392: RFS: dmg2img/1.6.7-1 [ITA]

[Stephen Kitt]

Hi Denys,

On Wed, Nov 22, 2017 at 04:08:05AM +, Denys Berkovskyy wrote:
> I am looking for a sponsor for my package "dmg2img"

Excellent, thanks for taking care of this!

> Changes since the last upload:
>  * New upstream version 1.6.6 (Closes: #778827)
>  * New upstream version 1.6.7
>  * Fix FTCBFS: Let cdbs' makefile.mk pass cross compilers. (Closes: #864511)
>  * Update patches
>  * Update debhelper compatibility level to v10
>  * Bump standards version to 4.1.1 (No changes required)
>  * Fix homepage URL, remove obsolete URLs
>  * Update debian/copyright file
>  * Fix typo in packet description
>  * New maintainer (Closes: #881838)

I have a few review comments...

In the changelog, I don’t think there’s much point in repeating “New
upstream version”. I also prefer distinguishing close reasons in
detail: so “New upstream version” would close a bug requesting a new
upstream version, but not bugs which happen to be fixed in the
upstream release. This would result in something like

  * New upstream release:
- fixes a crash on invalid block signatures (Closes: #778827)

While you’re at it, could you check to see whether the other crashing
bugs are fixed? I think some of them might be...

It would be nice too to see whether bindnow and fortify can be enabled
(unless those are false positives in Lintian’s output).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#864208: RFS: libunistring/0.9.7-1 ITA

[Stephen Kitt]

Hi Jörg,

On Mon, 05 Jun 2017 12:00:41 +0200, Jörg Frings-Fürst
 wrote:
> Alternatively, one can download the package with dget using this
> command:
> 
> dget -x
> https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_0.9.7-1.dsc

Thanks for taking care of this. Here are my review notes.

* I noticed you’ve added symbols files specifically for amd64 and i386; they
  are identical and there’s nothing there which should vary across
  architectures, is there any reason not to have a generic symbols file?

* The contents of DEVELOP.Debian would fit nicely in a README.source instead,
  IMO
  (https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource).

* Since you’re no longer using cdbs, the relevant lines in debian/rules could
  be entirely removed rather than commented.

Regards,

Stephen


pgpkpMPJgtrWg.pgp
Description: OpenPGP digital signature

Bug#804947: RFS: inform/6.31.1+dfsg-2

[Stephen Kitt]

Hi Ben,

On Sun, 15 Nov 2015 07:13:04 +1100, Ben Finney <ben+deb...@benfinney.id.au>
wrote:
> On 14-Nov-2015, Stephen Kitt wrote:
> > On Sat, 14 Nov 2015 13:48:19 +1100, Ben Finney
> > <ben+deb...@benfinney.id.au> wrote:  
> > > Now the package builds without error using any of:
> > > 
> > > * The Pbuilder chroot I'm doing most of my testing with.
> > > * A ‘dpkg-buildpackage -B’ invocation.
> > > * A ‘dpkg-buildpackage -A’ invocation.  
> > 
> > The latter still fails for me, see above.  
> 
> Okay, I have now added the appropriate sequence of actions to the
> ‘build-indep’ target.
> 
> It goes through the binary build process (I think because of
> ‘dh_install’), though the result is 

I'm guessing something got lost there ;-). But the build works for me now,
thanks!

> This will be cleaner in the next release, once I re-write all those
> targets to just use ‘dh’.

Yup, it handles all that for you.

> > > These changes are committed to the VCS repository for the Debian
> > > packaging, as the work-in-progress “6.31.1+dfsg-3”.  
> > 
> > Thanks; since -2 never got uploaded to the archive, I'd rather you
> > modified that release instead of creating a new one, if you don't
> > mind...  
> 
> That changes published VCS history (I had to delete the tag for the
> release), I think that's a problem. I've done it this time, let me
> know if that's okay.

I tend to treat tags as informative (since they can be moved), so that
doesn't bother me; or at least it bothers me less than adding a new version
in the changelog when nothing goes to the Debian archive.

> While the release remains not yet finalised, temporarily finalise it
> in ‘debian/changelog’ for the package build.

It all looks OK to me now, so if you don't mind I'll let you finalise the
changelog the way you want it and I'll upload the result. I'm not familiar
with the typical bzr-buildpackage workflow, but if you can, just finalise the
changelog for now, and wait for the upload to tag it (so we're sure the final
tag accurately matches the upload).

lintian complains about the duplicated non-free/devel section in
debian/control, but it's just an info-level item so it can remain as-is for
now as far as I'm concerned...

Regards,

Stephen


pgpOz096t37cJ.pgp
Description: OpenPGP digital signature

Bug#804947: RFS: inform/6.31.1+dfsg-2

[Stephen Kitt]

On Sat, 14 Nov 2015 10:55:27 +1100, Ben Finney <ben+deb...@benfinney.id.au>
wrote:
> On 13-Nov-2015, James Cowgill wrote:
> > The package FTBFS when build with dpkg-buildpackage -B:  
> […]
> > > cd inform-6.31.1/ && ./configure --prefix=/usr  
> […]
> > > configure: error: cannot run /bin/bash config/config.sub
> > > debian/rules:49: recipe for target 'build.stamp' failed
> > > make: *** [build.stamp] Error 1  
> 
> That's because the ‘config/config.*’ files, supplied in the upstream
> source, are removed in the “clean” target. I did that in order to not
> have unwarranted changes in the source files.
> 
> Maybe I should be using ‘dh_autoreconf’:
> 
> >  Why not use dh_autoreconf?  
> 
> Because I'm not very experienced with GNU Autotools, and wasn't aware
> of that command. Would that address the above problem as well, do you
> think?

As you found out, it does avoid failing the build because of missing files.

[...]
> > debian/rules:
> >  Why not use dh?  
> 
> I'd like to understand the rationales for the current ‘debian/rules’,
> before replacing it so completely. Certainly migrating to the ‘dh’
> command is a medium-term goal.

OK, that seems sensible to me.

> On 13-Nov-2015, Stephen Kitt wrote:
> > and with dpkg-buildpackage -A (which would be nice to have since the
> > source package produces an arch-independent binary package alongside
> > the arch-dependent one).  
> 
> I suspect this is also to be addressed by using ‘dh-autoreconf’, would
> you agree?

Not entirely, since your binary-indep target does nothing. I exported a
source package from the updated bzr repo, and “dpkg-buildpackage -A” fails
with

touch "build.stamp"
 fakeroot debian/rules binary-indep
make: Nothing to be done for 'binary-indep'.
 dpkg-genchanges -A >../inform_6.31.1+dfsg-3_all.changes
[Ignoring the dpkg-genchanges warnings...]
dpkg-genchanges: error: binary build with no binary artifacts found; cannot
distribute
dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2

> > README.Debian-source should be README.source (policy 4.14,
> > https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource).  
> 
> Done now.

Thanks.

> > debian/rules isn't really the place to comment on policy, I'd
> > suggest filing a bug against policy... You could also just use uscan
> > and drop the various get-orig-source targets entirely.  
> 
> My intention with those targets is to conform to policy and explain to
> the reader, not to comment on policy or change it.

OK, I read “This target is an anomaly” as comment!

On Sat, 14 Nov 2015 13:48:19 +1100, Ben Finney <ben+deb...@benfinney.id.au>
wrote:
> Now the package builds without error using any of:
> 
> * The Pbuilder chroot I'm doing most of my testing with.
> * A ‘dpkg-buildpackage -B’ invocation.
> * A ‘dpkg-buildpackage -A’ invocation.

The latter still fails for me, see above.

> These changes are committed to the VCS repository for the Debian
> packaging, as the work-in-progress “6.31.1+dfsg-3”.

Thanks; since -2 never got uploaded to the archive, I'd rather you modified
that release instead of creating a new one, if you don't mind...

Regards,

Stephen


pgpha_l_m4xVu.pgp
Description: OpenPGP digital signature

Bug#804947: RFS: inform/6.31.1+dfsg-2

[Stephen Kitt]

Control: owner -1 !

Hi,

On Fri, 13 Nov 2015 20:44:40 +, James Cowgill 
wrote:
> On Fri, 2015-11-13 at 16:36 +1100, Ben Finney wrote:
> > Package: sponsorship-requests
> > Severity: wishlist
> > Control: tags 698980 + pending
> > Control: block 698980 by -1
> > 
> > I am looking for a sponsor for my package ‘inform’:  
> 
> Since I've used inform before, I had a small look at the package.
> However, I'm not a DD so I can't upload it for you.

Thanks for the review, James!

Ben, I am a DD so I can upload it for you (once you fix the issues,
including those James points out).

[...]
> The package FTBFS when build with dpkg-buildpackage -B:

and with dpkg-buildpackage -A (which would be nice to have since the source
package produces an arch-independent binary package alongside the
arch-dependent one).

> debian/rules:
>  Why not use dh?
>  Why not use dh_autoreconf?

+1 from me for both these recommendations, especially since you've done a
fair bit of the work already by splitting up the installation files.

README.Debian-source should be README.source (policy 4.14,
https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource).

debian/rules isn't really the place to comment on policy, I'd suggest filing
a bug against policy... You could also just use uscan and drop the various
get-orig-source targets entirely.

Thanks for taking the time to work on this!

Regards,

Stephen


pgpRaczRjCbiY.pgp
Description: OpenPGP digital signature

Bug#799813: RFS: snes9x [ITP] -- Cross-platform SNES emulator

[Stephen Kitt]

Hi Sérgio,

On Tue, 22 Sep 2015 18:44:23 -0300, Sérgio Benjamim 
wrote:
> Looking for a sponsor for this package:
> 
> * Package name : snes9x
[...]
> * License  : non-free/non-commercial
[...]
> 
> It's worth to mention that Snes9x is more accurate than ZSNES and use less
> hardware resources than bsnes.

How does it compare with Mednafen's SNES support?

Regards,

Stephen


pgpX9xHtT_51t.pgp
Description: OpenPGP digital signature

Bug#798057: ITP RFS: node-sprintf-js/1.0.3-1

[Stephen Kitt]

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

Salut Bastien,

On Sat, 5 Sep 2015 00:17:01 +0200, Bastien ROUCARIES
 wrote:
>   I am looking for a sponsor for my package "node-sprintf-js"
> 
>  * Package name: node-sprintf-js
>Version : 1.0.3-1
>Upstream Author :Alexandru Marasteanu
>  * URL : https://github.com/alexei/sprintf.js/issues
>  * License : BSD-3-Clause
>Section : web
> 
>   It builds those binary packages:
> 
> node-sprintf-js - JavaScript sprintf implementation
> 
>   To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/node-sprintf-js

Thanks for packaging this!

Just a few comments:
* debian/README.Source should be README.source (policy 4.14)
* debian/changelog still has UNRELEASED
* I'd rather have "Priority: optional" but I didn't check the other
  dependencies
* is there any point in symlinking the source code contained in the upstream
  package in missing-sources (other than fixing a Lintian warning)?
* debian/copyright should reproduce the license grant given by upstream
  verbatim (OK, this is really "couper les cheveux en quatre")

Regards,

Stephen


pgpoHD2DIm_uU.pgp
Description: OpenPGP digital signature

Re: dpkg-source: info: local changes detected and gbp:error: Cannot parse archive name

[Stephen Kitt]

On Sun, 31 May 2015 22:54:58 +0500, Andrey Rahmatullin w...@debian.org
wrote:
 On Sun, May 31, 2015 at 05:03:29PM +0200, Marcin Dulak wrote:
  $ debuild -us -uc
  ...
  dpkg-source: info: building gpaw using existing
  ./gpaw_0.10.0.11364.orig.tar.gz
  dpkg-source: info: local changes detected, the modified files are:
   gpaw-0.10.0.11364/configuration.log
  ...
  
  It looks to me like the configuration.log file, which is written during
  compilation of gpaw
  is treated as a source modification. How should I handle this?
 You need to removed it in the clean step. With dh(1) it can be done by
 overriding dh_auto_clean.

Or by adding the file's name to debian/clean.

Regards,

Stephen


pgpZhAzDU3Iyo.pgp
Description: OpenPGP digital signature

Bug#783277: RFS: gnome-exe-thumbnailer/0.9.3 [ITP]

[Stephen Kitt]

Hi James,

On Mon, 27 Apr 2015 11:52:13 -0700, James Lu glol...@hotmail.com wrote:
 Thanks for the response! I've uploaded a new version (0.9.3-1) via dput 
 mentors, which fixes most of the problems you've mentioned. The site, 
 however, doesn't seem to have updated the package page, so I'm not sure 
 if the changes have stuck. I've mirrored the .dsc file elsewhere 
 http://packages.overdrive.pw/pool/main/g/gnome-exe-thumbnailer/gnome-exe-thumbnailer_0.9.3-1.dsc
  
 just in case, though aptly (repo management) doesn't handle .changes 
 files yet.

I couldn't find your updated package on mentors, but the other .dsc is OK (I
don't need the .changes file to review or even to sponsor an upload).

 The only warning left is binary-without-manpage, as the source doesn't 
 seem to provide one at all. The script, gnome-exe-thumbnailer, doesn't 
 handle --help either, and spits out errors instead. I'm not sure what to 
 do in this case, other than file a separate issue?

You'd need to write a manpage :-). Given that thumbnailers aren't run by
end-users generally, the manpage doesn't need to be very detailed; have a
look at
https://sources.debian.net/src/evince/3.14.1-2/debian/evince-thumbnailer.1/
for an example. If you've never done this before, try adapting
evince-thumbnailer.1; I can help if necessary.

Apart from that I'd prefer it if you could merge all your changes into a
single changelog entry, so there's only an entry for 0.9.3-1, then the
pre-existing entry for 0.9.3-0ubuntu1.

  Finally, it might be worth packaging this within the Wine packaging team,
  if you'd care to join us...
 
 I'm not too familiar with packaging teams, but that sounds good to me! 
 I'm open to collaborative maintenance. :)

OK, great! You need to create an Alioth account if you don't have one yet
(https://alioth.debian.org/account/register.php), then go to the Wine
packaging team page and ask to join
(https://alioth.debian.org/projects/pkg-wine/ and look for the Request to
join link in the right-hand column).

To mark the package as team-maintained, you'd set

Maintainer: Debian Wine Party pkg-wine-pa...@lists.alioth.debian.org

in debian/control and add yourself in an Uploaders: entry. Once you're in the
team you'll be able to create a git repository there for your package too.
(But you can worry about that later if it's unfamiliar to you.)

Regards,

Stephen


pgpqaoc22VtCn.pgp
Description: OpenPGP digital signature

Bug#783277: RFS: gnome-exe-thumbnailer/0.9.3 [ITP]

[Stephen Kitt]

Hi again,

Before I forget, it would be nice to get in touch with Scott Ritchie to let
him know you're packaging this for Debian! You could ask him if there's an
official upstream repo (the version of gnome-exe-thumbnailer in winezeug is
very old).

Regards,

Stephen


pgpdmolQ1r43B.pgp
Description: OpenPGP digital signature

Bug#783277: RFS: gnome-exe-thumbnailer/0.9.3 [ITP]

[Stephen Kitt]

Control: owner 783277 !

Hi James,

On Fri, 24 Apr 2015 17:52:29 -0700, James Lu glol...@hotmail.com wrote:
 I am looking for a sponsor for my package gnome-exe-thumbnailer
 
   * Package name: gnome-exe-thumbnailer
 Version : 0.9.3
 Upstream Author : 2010-2012 Jan Nekvasil jan.nekva...@ryant.cz
   2009-2010 Christian Dannie Storgaard
 cybo...@gmail.com 2009-2012 Scott Ritchie scottritc...@ubuntu.com
   * URL : http://wiki.winehq.org/exe-thumbnailer
   * License : LGPL-2.1+
 Section : gnome
 
 Changes since the last upload:
 
 gnome-exe-thumbnailer (0.9.3) unstable; urgency=medium
 
* Initial Debian release, forked from Ubuntu. (Closes: #767376)

Note that the version uploaded to Debian might end up replacing that in
Ubuntu.

* Update debian/ files:
   - Set myself as maintainer.
   - Bump to debhelper 9.

You need to change the value in debian/compat as well as the version in the
build-dependency.

   - Remove outdated gconf2 build-dependency, depend on libglib2.0-bin
 instead (for theme fetching).
   - Remove unnecessary dependency on python.
   - Update Standards Version to 3.9.6.
   - Set priority to optional from extra.
   - Include my changes in debian/copyright.

The declarations aren't quite right; you don't need the years after
Copyright:, so simply

Files: *
Copyright:
 2010-2012 Jan Nekvasil ...

Also, did you receive the source by email, or did you download it from
Ubuntu? The Source: states the former but it's the same in Ubuntu, so I'm
guessing you need to change that ;-).

   - Remove /usr/share/gconf/schemas from dirs file.
   - Explicitly set source/format to 3.0 native. This is what the Ubuntu
 packaging seems to suggest, as there is only one .tar.gz
 file available for download.

The Ubuntu packaging is indeed native, as indicated by debian/source/format;
but this isn't a native package (a native package is a package which contains
software written specifically for Debian). I'd rather you changed
debian/source/format to 3.0 (quilt) and used 0.9.3-1 as package version;
that would also avoid issues upgrading from the Ubuntu version of the
package. (Copy Ubuntu's .tar.gz to gnome-exe-thumbnailer_0.9.3.orig.tar.gz.)

Could you also fix the following lintian issues?

* P: gnome-exe-thumbnailer source: unversioned-copyright-format-uri
  http://dep.debian.net/deps/dep5

(The URI should be
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
currently.)

* I: gnome-exe-thumbnailer: capitalization-error-in-description-synopsis
  Gnome GNOME
* I: gnome-exe-thumbnailer: capitalization-error-in-description Gnome GNOME
* W: gnome-exe-thumbnailer: binary-without-manpage
  usr/bin/gnome-exe-thumbnailer

Finally, it might be worth packaging this within the Wine packaging team, if
you'd care to join us...

Regards,

Stephen


pgpQM9JuFeDY5.pgp
Description: OpenPGP digital signature

Bug#778729: Try 2: Bug#778729: RFS: git-tools/1.0.0-1 [ITP]

[Stephen Kitt]

On Mon, 9 Mar 2015 10:57:02 +0100, Adam Borowski kilob...@angband.pl wrote:
 On Sun, Mar 08, 2015 at 04:20:08PM +0100, Stephen Kitt wrote:
  Could you fix up debian/patches/debian-changes? It's just got
  auto-generated template headers... Or is that because you're using
  single-debian-patch in debian/source/options?
 
 The latter.  I guess, dpkg-source shouldn't insert that template if
 single-debian-patch is set.  It's pointless to duplicate the work if all
 changes are already tracked and documented in a proper VCS.

OK, that's fine by me. (I guess you could file a bug if one isn't already
filed!)

  Also, I know this has been debated before, but it seems rather
  restrictive to call the binary package git-restore-mtime, given that
  there are other useful git tools in the package.
 
 Actually, it was the source name that was discussed.
 
 As for binary, my reason is that git restore-mtime is the main point of
 interest here, the other tools being just thrown in.  Their usefulness is
 quite marginal.  In fact, I dropped two altogether: git-branches-rename and
 git-rebase-theirs as both can be reproduced by an one-liner.
 
 As for three tools that I left in, git-find-uncommited-repos probably should
 be axed too -- it's just find -name .git -execdir 'git status' with some
 output massaging.  git-strip-merge is both situational and trivial to
 reproduce.  The only other tool with some real use is git-clone-subset.
 
 Thus, it would feel odd to have a package named git-tools that contains
 only two tools of some note.

OK, stick with git-restore-mtime as the binary package then. I'm wondering if
it would be better to call the source package git-mestrelion-tools...

  While I'm at it, given that you're shipping extra manpages, wouldn't it be
  worth it to ship the help2man-generated manpage as well, instead of
  rebuilding it every time?
 
 I build it from source to make sure new upstream changes are incorporated.

That's what I reckoned, although you'd still need to tweak the version number
in debian/rules every time.

 On the other hand, this makes it near impossible to adjust the output, and
 is inconsistent with the other three manpages, all of which are
 hand-crafted.  Thus, you're probably right, it would be better to ship
 the manpage instead of building it from source.

Shall I wait for that then before uploading?

Regards,

Stephen


pgpzn8mBPsGMX.pgp
Description: OpenPGP digital signature

Bug#778729: Try 2: Bug#778729: RFS: git-tools/1.0.0-1 [ITP]

[Stephen Kitt]

On Tue, 10 Mar 2015 00:38:29 +0100, Adam Borowski kilob...@angband.pl wrote:
 Should be ready now.  However, mentors.d.n seems to not allow uploading the
 same binary package with a different source more than once per day (there's
 some cronjob AFAIK), so I had to use my own repository:
 
 http://angband.pl/debian/pool/main/g/git-mestrelion-tools/git-mestrelion-tools_1.0.0-1.dsc

Thanks, I've uploaded that to the archive. For your next upload you might
want to add a watch file ;-).

Regards,

Stephen


pgp5NpVXMQiHR.pgp
Description: OpenPGP digital signature

Bug#778729: Try 2: Bug#778729: RFS: git-tools/1.0.0-1 [ITP]

[Stephen Kitt]

Hi Adam,

On Tue, 3 Mar 2015 23:52:15 +0100, Adam Borowski kilob...@angband.pl wrote:
 On Thu, Feb 19, 2015 at 02:53:52AM +0100, Adam Borowski wrote:
  * Package name: git-tools
  * URL : https://github.com/MestreLion/git-tools
  
  It builds those binary packages:
git-restore-mtime - set timestamps to the date of a file's last commit
 
 Hi guys again!  Lemme ping you, as sadly no one offered to sponsor this
 package yet...  I made a few changes:
 * fixed a reference to GPL2 (should be GPL3)
 * moved my hand-crafted manpages to debian/ (so they don't require a patch)
 * actually installed them (only the help2manned one was there[¹])
 * renamed the source to git-tools, per Chris Lamb's suggestion.
 * picked a fix from upstream

Thanks for packaging this!

Could you fix up debian/patches/debian-changes? It's just got auto-generated
template headers... Or is that because you're using single-debian-patch in
debian/source/options?

Also, I know this has been debated before, but it seems rather restrictive to
call the binary package git-restore-mtime, given that there are other useful
git tools in the package.

While I'm at it, given that you're shipping extra manpages, wouldn't it be
worth it to ship the help2man-generated manpage as well, instead of
rebuilding it every time?

Regards,

Stephen


pgpSQAUzBI4Id.pgp
Description: OpenPGP digital signature

Bug#771930: RFS: sane-frontends/1.0.14-10 [ITA]

[Stephen Kitt]

Hi Jörg,

On Thu, 04 Dec 2014 14:41:25 +0100, Jörg Frings-Fürst
deb...@jff-webhosting.net wrote:
 first thanks for your review.

You're welcome!

[...]

 Packeage is uploaded to mentors[1] again.

Thanks for all the fixes. I just noticed something else: version -9
installed /usr/share/sane/sane-style.rc, but version -10 doesn't; this file
is used by xscanimage according to the latter's manpage. Could you check why
it's no longer being installed?

Regards,

Stephen


pgp5GlcBk2x0D.pgp
Description: OpenPGP digital signature

Bug#771930: RFS: sane-frontends/1.0.14-10 [ITA]

[Stephen Kitt]

Control: owner -1 !

Hi Jörg,

On Wed, 03 Dec 2014 17:20:22 +0100, Jörg Frings-Fürst
deb...@jff-webhosting.net wrote:
   I am looking for a sponsor for my package sane-frontends

Excellent, thanks for taking care of this.

Your packaging updates look good, in particular the debian/copyright
overhaul! Regarding the latter, you've listed src/preferences.c twice ;-).

Is the dh_builddeb override in debian/rules necessary?

Since you're adding a bunch of .install files, it should be possible to
install the XPM using them too, thereby simplifying debian/rules even
further.

debian/watch mentions sane-backends which I guess is a copy-and-paste error!

Regards,

Stephen


pgpi7nf9urTp9.pgp
Description: OpenPGP digital signature

Re: Fixing the warning of Depends field unknown substitution variable ${perl:Depends}

[Stephen Kitt]

Hi,

On Sat, 29 Nov 2014 19:24:59 + (UTC), T o n g mlist4sunt...@yahoo.com
wrote:
 My packages gives this warning:
 
   dpkg-gencontrol: warning: Depends field of package dbab: unknown 
 substitution variable ${perl:Depends}
 
 I am packaging Perl stuff, and I do use IO::Socket::INET in my code:
 
 https://github.com/suntong001/dbab/blob/master/src/bin/dbab-svr
 
 In https://lists.debian.org/debian-mentors/2013/12/msg00060.html
 Russ Allbery pointed out that, 
 
 ,-
 | unknown means you tried to use it and nothing set it... dh_perl found
 | some Perl script or library in the package and tried to write out the
 | substitution variable.
 `-

Russ is highlighting the difference between unused and unknown; the
latter part you're quoting refers to unused, not unknown. unknown means
the exact opposite: your control file refers to a substitution variable which
has no value.

 However, I do have that ${perl:Depends} in my control file:
 
 $ grep '^Depends: ' debian/control 
 Depends: ${misc:Depends}, ${perl:Depends}, dnsmasq, curl 
 
 File: https://github.com/suntong001/dbab/blob/master/debian/control
 
 So how exactly should I fix it? 

If you want to fix the warning you should remove ${perl:Depends}. If you
think ${perl:Depends} should have a value then there may be something else
going on; what does dbab end up depending on once it's built? (dpkg-deb -I
dbab*deb will tell you.)

(Note that IO::Socket::INET is part of perl, so you don't need to depend on
anything beyond that as far as I can see.)

Regards,

Stephen


pgp2qaUYD24Ke.pgp
Description: OpenPGP digital signature

Bug#766833: RFS: fuzzylite/5.0+dfsg-1 [ITP]

[Stephen Kitt]

Hi Johannes,

On Sun, 26 Oct 2014 13:21:48 +0100, Johannes Schauer j.scha...@email.de
wrote:
 Quoting Johannes Schauer (2014-10-26 09:01:55)
  Luckily, Juan Rada-Vilela, the author of fuzzylite volunteered to do this
  porting task because he is interested in getting fuzzylite into Debian
  and he wishes to see more users of his library. I now forwarded his work
  to vcmi upstream and they say they will try to get fuzzylite 5.0 support
  into their next release.
 
 I should've waited a couple of hours with my last email because upstream
 just now integrated fuzzylite 5.0 support into their development branch.
 Thus, the next vcmi version will support fuzzylite 5.0 and if somebody
 could sponsor my fuzzylite package, then we could also see the next vcmi
 release in Debian contrib :)
 
 http://mentors.debian.net/debian/pool/main/f/fuzzylite/fuzzylite_5.0+dfsg-1.dsc

I've taken a look at the package and it seems fine, apart from the two points
remaining from your exchanges with Jakub:

* the hard-coded paths in src/Console.cpp
* the spelling/grammar errors

Regarding the latter, I prefer ... method `static bar` was made `virtual
foo::bar`, which allows it to be overridden.

Do you have any idea what should be done about the former?

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#759796: RFS: gemrb/0.8.1-1

[Stephen Kitt]

Control: owner -1 !

Hi Beren,

On Thu, 25 Sep 2014 23:21:20 +0200, Beren Minor
beren.minor+deb...@gmail.com wrote:
 I am still looking for a sponsor for my GemRB package.
 The details are in the OP of this bug report (#759796
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%20759796).

I've taken a look at this, and the only issue I can see is that the copyright
years need to be updated to 2003-2014 (see gemrb/core/VEFObject.cpp and
gemrb/GUIScripts/CreateControlDecorators.py amongst others).

If you fix this I'll sponsor the package!

It might also be worth pointing out in README.Debian that filenames should be
converted to lower-case after extraction, in particular for the GoG releases,
as documented in http://www.gemrb.org/wiki/doku.php?id=install:unshield-bg1 -
for me the game segfaults after the intro movies if this isn't done.

Have you considered implementing support for the game files in
game-data-packager?

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#761482: RFS: argyll/1.6.3-1 [ITA]

[Stephen Kitt]

Hi Jörg,

On Wed, 17 Sep 2014 09:15:34 +0200, Jörg Frings-Fürst
deb...@jff-webhosting.net wrote:
 Am Dienstag, den 16.09.2014, 20:06 +0200 schrieb Stephen Kitt:
  Hi Jörg,
  
  On Tue, 16 Sep 2014 09:26:04 +0200, Jörg Frings-Fürst
  deb...@jff-webhosting.net wrote:
 
 [...]
  
  I've got the package removed from the new queue, but I noticed a couple
  more changes I'd like to see in the package:
  * rm_conffile should be replaced with dpkg-maintscript-helper too (and the
latter added in the required scripts)
 I have removed the function rm_conffile(). In Debian the first
 version[1] was 1.1.1-1, in oldstable too and the function was for
 versions le 1.1.0-3.

Yes, that makes sense.

  * icc/*.icm and ref/*.icm are public domain and should be listed as such
  in debian/copyright (see ref/ReadMe.txt and the ICM metadata)
 Done. Please take a look on the license text. From[2] for
 public-domain: 
 
 No license required for any purpose; ...
 
 But without the license text I get a lintian warning.

You don't have to include a separate license block; I'm uploading the package
with the following file block instead:

Files: ref/*.icm
   icc/*.icm
Copyright: Public domain
License: public-domain
 Public Domain. No Warranty, Use at own risk.

That's the text which appears in the ICM files themselves. I replaced your
Copyright line too, since asserting copyright isn't compatible with a public
domain assertion (if that is at all possible in any case...).

Regards, and thanks again for your work,

Stephen


signature.asc
Description: PGP signature

Bug#761482: RFS: argyll/1.6.3-1 [ITA]

[Stephen Kitt]

Hi Jörg,

On Tue, 16 Sep 2014 09:26:04 +0200, Jörg Frings-Fürst
deb...@jff-webhosting.net wrote:
 Am Montag, den 15.09.2014, 22:59 +0200 schrieb Stephen Kitt:
  Ah right, thanks, the last time I checked dpkg-maintscript-helper didn't
  handle this case.
  
  Jörg, it's dpkg-maintscript-helper dir_to_symlink...
 
 I have create / added the dpkg-maintscript-helper calls to 
 *.(postinst|preinst|postrm)
 
 The package is uploaded to mentors[1]. 
 
 Stephen can you remove it from the new queue and upload again?

I've got the package removed from the new queue, but I noticed a couple more
changes I'd like to see in the package:
* rm_conffile should be replaced with dpkg-maintscript-helper too (and the
  latter added in the required scripts)
* icc/*.icm and ref/*.icm are public domain and should be listed as such in
  debian/copyright (see ref/ReadMe.txt and the ICM metadata)

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#761482: RFS: argyll/1.6.3-1 [ITA]

[Stephen Kitt]

Hi Bastien,

On Mon, 15 Sep 2014 20:28:54 +0200, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
 Le 14 sept. 2014 16:21, Stephen Kitt sk...@debian.org a écrit :
  Upgrading argyll does reveal a real problem though... Given that you're
  shipping all the documentation in argyll-doc, and symlinking from the
 other
  two packages, you need to replace the old directories with symlinks, using
  something like this in argyll's postinst:
 
 Ar please use dpkg-maintainer-script-helper

Ah right, thanks, the last time I checked dpkg-maintscript-helper didn't
handle this case.

Jörg, it's dpkg-maintscript-helper dir_to_symlink...

  # Replace documentation directory with symlink
  if [ -d /usr/share/doc/argyll ]  [ ! -L /usr/share/doc/argyll ]; then
  if rmdir /usr/share/doc/argyll 2/dev/null; then
  ln -sf argyll-doc /usr/share/doc/argyll
  fi
  fi
 
 You forget some case... buggy

Did you check what Jörg actually implemented? Not that it matters really,
d-m-h is the right way to do this.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#761482: RFS: argyll/1.6.3-1 [ITA]

[Stephen Kitt]

Hi,

Thanks for taking care of ArgyllCMS! Here's a quick review.

On Sun, 14 Sep 2014 11:11:43 +0200, Jörg Frings-Fürst
deb...@jff-webhosting.net wrote:
   * New Maintainer (Closes: #720178).
   * New upstream release (Closes: #742658).
   * debian/rules:
 - Add get-orig-source.
 - Remove useless --with quilt from dh $@
 - Enable hardening=+all

But the line is commented out in debian/rules!

 - Remove section for not included spyder2 firmware.
 - Rewrite for use of upstream build system.
   * debian/control:
 - Set myself as maintainer.
 - Update Build-Depends:
   + Remove automake | automaken
 - For previously not existing Vcs
   + Create a new git repository on alioth.
   + Add the fields Vcs-Browser and Vcs-Git.
 - Change Priority from optional to extra.
 - Remove useless packages:
   + icc-utils
 Now in argyll. Now only dummy package.

Please mention (transitional package) in the package's short description,
and perhaps also in the long description (This package is a transitional
dummy package. instead of This package is a dummy package.)

   + libicc2  libicc-dev
 Useless. Only linked to argyll  icc-utils.
   + libimdi0  libimdi-dev
 Useless. Only linked to argyll  icc-utils.
   * Add debian/source/options:
 - Set compression to xz  compression-level to 9 to save space.

xz is now the default, and 9 is too expensive at decompression-time for some
of the smaller devices where argyll can be useful (think of small ARM boards
driving televisions). It might be better just to remove debian/source/options
entirely...

   * debian/copyright:
 - Rewrite into DEP-5 format.
 - Add myself to the list of authors for debian/*.
 - Add missing licenses and authors.

A few comments on debian/copyright:
* Aladdin Enterprices should be Aladdin Enterprises
* usb/driver/* should be License: GPL-2 or LGPL-2 since the licenses aren't
  cumulative
* Richaerd Hughes should be Richard Hughes
* you could say License: libjpeg instead of License: other for jpg/*

   * debian/*.1
 - Move to debian/man/*.1.
   * debian/man/*
 - Rewrite the help2man generated man pages (Closes: #670857)
   * debian/patches/
 - New 110_dispwin_segfault.patch to prevent segfault by
   wrong parameter (Closes: #700253)

I see other patches as well... 15_jam.patch.org should be removed, along
with the various patches which are no longer used in the series file (and
you should clean up the series file too). In 110_dispwin_segfault.patch, is
there a link to the mailing list archives you could copy in the Forwarded
item?

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#761482: RFS: argyll/1.6.3-1 [ITA]

[Stephen Kitt]

Hi Jörg,

On Sun, 14 Sep 2014 14:29:18 +0200, Jörg Frings-Fürst
deb...@jff-webhosting.net wrote:
 Am Sonntag, den 14.09.2014, 12:35 +0200 schrieb Stephen Kitt:
 Line in d/changelog and comments in d/rules removed.
 I think that hardening=+all is not necessary for argyll.

OK.

 [...]
 * debian/patches/
   - New 110_dispwin_segfault.patch to prevent segfault by
 wrong parameter (Closes: #700253)
  
  I see other patches as well... 15_jam.patch.org should be removed, along
  with the various patches which are no longer used in the series file (and
  you should clean up the series file too). In 110_dispwin_segfault.patch,
  is there a link to the mailing list archives you could copy in the
  Forwarded item?
 
 Link is included. Useless patches deleted and from d/p/series removed.

I see a link in 15_jam.patch, but not in 110_dispwin_segfault.patch.

Lintian doesn't reveal anything nasty about the package; there are a few
pre-built Windows binaries, but the source is also included so there's no
need to repack the source. The warning about the short license names is a
false-positive which is fixed in lintian 2.5.27.

Upgrading argyll does reveal a real problem though... Given that you're
shipping all the documentation in argyll-doc, and symlinking from the other
two packages, you need to replace the old directories with symlinks, using
something like this in argyll's postinst:

# Replace documentation directory with symlink
if [ -d /usr/share/doc/argyll ]  [ ! -L /usr/share/doc/argyll ]; then
if rmdir /usr/share/doc/argyll 2/dev/null; then
ln -sf argyll-doc /usr/share/doc/argyll
fi
fi

Otherwise /usr/share/doc/argyll ends up being an empty directory.

Incidentally, doing this means that argyll depends on argyll-doc; was that
intentional?

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Help needed about deprecated dependency

[Stephen Kitt]

Hi,

On Thu, 5 Jun 2014 18:20:13 +0200, bilibop project quid...@safe-mail.net
wrote:
 a bug has been reported[1] against a package I maintain in Debian. It is
 said that one of the binary packages recommends Udisks, which is deprecated
 for a while now, and I should move to Udisks2. The problem is that:

The bug was filed by one of the udisks maintainers, so you could always ask
him directly ;-).

 1. bilibop-rules already works fine with udisks2; in fact it works fine
 with both udisks and udisks2 (which do not conflict and can be installed on
 the same system as documented in udisks package itself)
 
 2. udisks (version 1.x) is still present in sid and jessie, so it seems to
 not be so much deprecated

It's possible the udisks maintainers are hoping to remove udisks from sid and
jessie, which they can't do as long as anything depends on it. So bugs such
as the one you're referring to would be the first step in the process.

 3. the Recommends: field already says 'udisks | udisks2': how to do
 better ? Is there a difference if I replace it by 'udisks2 | udisks' ?

If you simply Recommends: udisks2, then you can close the bug. Users who
still use udisks won't be affected, your package will still work with it as
long as they keep it installed.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Access to mips64el system wanted to fix a bug in the capnproto package

[Stephen Kitt]

On Sat, 19 Apr 2014 17:36:31 -0700, Tom Lee deb...@tomlee.co wrote:
 Thanks for the detailed response Stephen, all great stuff to know. Yunqiang
 Su has already been kind enough to offer up a porterbox since I sent my
 earlier email. :)
 
 Am I right in understanding a porterbox is basically just a chrooted
 environment available for remote access on a temporary basis?

Pretty much, you can drop the chrooted since there's no definition of the
kind of environment you end up in: it can be a physical machine, a VM, ...
Within the environment you get access to initially you can generally create
your own chroots where you can install packages etc. See
https://dsa.debian.org/doc/schroot/ for details.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Access to mips64el system wanted to fix a bug in the capnproto package

[Stephen Kitt]

Hi Tom,

On Sat, 19 Apr 2014 13:29:48 -0700, Tom Lee deb...@tomlee.co wrote:
 Does the Debian project have hardware/VMs set aside to help
 packagers/upstream maintainers diagnose this sort of thing? I don't think
 it's appropriate for me to simply skip the test on the packaging side
 because the test is indicating pretty clearly things may not work as
 expected on the affected architecture.

Generally speaking, yes, for official Debian architectures; see
https://db.debian.org/machines.cgi for the available machines (look for
public in the right-hand column) and
https://dsa.debian.org/doc/guest-account/ for the procedure to gain access.

This won't help with mips64el, but you could just ask your bug reporter ;-).
See the thread starting at
https://lists.debian.org/debian-devel/2013/10/msg00704.html for details of
the mips64el machine which is available via YunQiang Su.

For this kind of problem another possibility is the GNU Compile Farm, which
also includes a mips64el system; see http://gcc.gnu.org/wiki/CompileFarm for
details.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

Hi Andreas,

On Thu, 27 Mar 2014 15:33:06 +0100, Andreas Tille andr...@an3as.eu wrote:
 On Tue, Mar 25, 2014 at 12:47:45AM +0100, Stephen Kitt wrote:
  On Thu, 20 Mar 2014 08:35:33 +0100, Andreas Tille andr...@an3as.eu
  wrote:
   In other words what we can see in the log above conflicts with the
   documentation if make is not found and should be reported as bug in
   autopkgtest ?
  
  As far as I can see from the logs, there was no declared dependency on
  make or @builddeps@, so make's absence is correct as per the
  documentation.
 
 For sure make is not in @builddeps@ since it is build-essential ... which is
 actually my point.

See the documentation:

`@builddeps@' will be replaced by the package's Build-Depends:,
Build-Depends-Indep:, and make. This is useful if you have many build
dependencies which are only necessary for running the test suite and
you don't want to replicate them in the test Depends:. However, please
use this sparingly, as this can easily lead to missing binary package
dependencies being overlooked if they get pulled in via build
dependencies.

@builddeps@ does include make.

But autopkgtests don't get build-essential installed by default, which is
indeed somewhat surprising! (Although somehow in my tests gcc is available.)

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

On Thu, 20 Mar 2014 08:24:15 +0100, Martin Pitt mp...@debian.org wrote:
 Stephen Kitt [2014-03-19 23:54 +0100]:
 Well, it depends what you want to do. In CI we *always* want to test
 the packages from the actual archive of course. But as a package
 maintainer you may want to (and should) run your autopkgtest for an
 updated package *before* you upload it to the archive, and you want to
 test them with locally built binaries instead.

Of course, and ideally with the same setup as is used on the CI platforms in
Debian and Ubuntu.

  Likewise for me. I find it particularly complicated to imagine what
  variants of adt-run should be used to make sure a particular test-suite
  is suitable for the CI platforms (ci.debian.net and Ubuntu's), which
  basically means having to look up the source code of the platforms to
  figure out what's going to happen, or uploading a package and waiting for
  the results...
 
 Recent versions of autopkgtest now ship the new
 /usr/share/doc/autopkgtest/README.running-tests.gz which I hope
 explains the use cases and how to run them.

It does explain the various use cases, but I found auto-package-testing more
helpful in that it contains the actual launcher scripts (prepare-testbed and
run-adt-test) used on the CI platforms.

  To me, autopkgtest test-suites are nice for two things:
  * tests which can't be run within a build (I started looking into all this
for libevdev, which includes a test-suite that must be run as root);
  * integration tests which combine multiple binary packages (e.g. Martin's
example with the toolchain; I'm also working on a toolchain test-suite
  for mingw-w64, which would combine the mingw-w64 toolchain and wine to
  make sure the toolchain is working correctly).
 
 Yes, for these. But also, you can do reverse dependencies testing and
 thus ensure that package A still works if one of its dependencies (say
 libfoo) gets updated, to prevent libfoo from landing if it breaks API.
 Uploading libfoo won't usually cause an upload/build of A otherwise,
 so running tests during build won't catch this.

Yup, that came under combine multiple binary packages from my point of
view :-).

 Also, autopkgtests test *packages* as they will appear on an actual
 system, unlike tests during build. The latter won't tell you if you
 forgot to install some files or put them into the wrong place, or your
 package has a missing Depends.

Ahah, that's an excellent point.

  I'm wondering how all this meshes with Ubuntu's fast migration approach:
  I'm guessing it doesn't see build-time tests which are run as part of the
  build... 
 
 It kind of does by rejecting packages which don't build on all
 platforms, i. e. if tests during build fail on a particular arch.

Right, I was thinking of the positive side; as I understood it there is some
sort of bonus in the proposed migration in Ubuntu for packages with working
autopkgtests. If that is correct then it would be better to use tests during
the build and also as autopkgtests, wouldn't it?

  Would it be worth running them as autopkgtest tests *as well* for
  this use case?
 
 If you can, sure. Otherwise a quick smoke test is usually enough. Let
 the upstream tests during package build cover the fine details, and
 just let autopkgtest check that your package works in general (i. e.
 you can start a program, import a Python module, build a simple
 5-liner against libfoo-dev, and so on).

That's what I liked about DEP8 at first — it helps avoid brown-bag errors ;-).

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

Hi Andreas,

On Thu, 20 Mar 2014 08:35:33 +0100, Andreas Tille andr...@an3as.eu wrote:
 On Wed, Mar 19, 2014 at 11:54:03PM +0100, Stephen Kitt wrote:
   Moreover I observed another issue with autopkgtest which is quite
   astonishing to me:  In bug #741274 it was reported that the autopkgtest
   would fail and the according log is here:
   
  
   http://ci.debian.net/data/unstable-amd64/packages/p/python-pysam/2014-03-12.log
   
   The problem is that `make` was not available in the chroot (obviosly)
   which does not sound very reasonable to me.  While I added it to the
   Depends in debian/tests/control I think it is not sensible to assume
   that make exists in a build chroot (it is not in the Build-Depends) but
   trying to build the package somehow and than notice that it is missing.
   I admit that I'm really confused how autopkgtests are working.
  
  This is actually documented, sort of: the documentation for @builddeps@
  mentions make as one of the packages which gets pulled in. (Why not
  build-essential? Yet somehow gcc is available...)
 
 In other words what we can see in the log above conflicts with the
 documentation if make is not found and should be reported as bug in
 autopkgtest ?

As far as I can see from the logs, there was no declared dependency on make
or @builddeps@, so make's absence is correct as per the documentation.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

Hi,

On Thu, 20 Mar 2014 15:10:23 +, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
 Stephen Kitt writes (Re: DEP8 tests using the built package source):
  (Hi Ian, I'm adding you to the discussion since I'm talking about changes
  to DEP8. I've snipped the exchanges but I hope you can get the gist of it
  without needing to spend time looking anything else up!)
 
 Hi.  Sorry about the delay replying.

No problem!

  What bothers me is that the current DEP8 spec says that packages can rely
  on having their source tree in the built state by stating Restrictions:
  build-needed, but effectively that imposes too much of a burden on the
  testing infrastructure. (That's not a complaint, I don't think we should
  require another buildd network to run tests, at least not until we've got
  as much test code as binary-targeted source code.) It's the kind of
  expectation that makes sense in a traditional CI setting (e.g. Jenkins
  with Maven for Java projects, where the project is built and its tests
  run in the same environment), but with DEP8's aim of testing the
  installed binaries it seems less useful to me. Wouldn't it make sense to
  change DEP8 to encourage building whatever is strictly required for the
  tests, and perhaps drop build-needed altogether?
 
 I have no objection to wording pointing out that some test runners
 might skip tests which specify build-needed.  I don't think removing
 the tag entirely is a good idea.

Martin convinced me of that with his replies, and added a clarification to
the documentation.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

On Tue, 18 Mar 2014 12:01:18 +0100, Martin Pitt mp...@debian.org wrote:
 Antonio Terceiro [2014-03-17  9:59 -0300]:
  On Sun, Mar 16, 2014 at 11:27:06PM +0100, Stephen Kitt wrote:
 FTR, we explicitly make use of that for our toolchain packages: gcc,
 binutils, linux, and eglibc have a bin/true test with needs build
 to ensure that whenever we update one piece, the others are still
 buildable and their tests succeed (which run at build time). I know
 that this is somewhat of an abuse of autopkgtest, but it does work :-)

So effectively it becomes a rebuild reverse-dependencies tool as well,
nice! (Although I do agree with the abuse part.)

   Wouldn't it make sense to change DEP8 to encourage building
   whatever is strictly required for the tests, and perhaps drop
   build-needed altogether?
 
 I wouldn't want to drop build-needed, as it only complicates things
 for the cases where people want it. But I'm happy to add a stanza to
 its documentation to avoid it for packages which take a nontrivial
 amount of time to build; does that sound like an acceptable
 compromise?

It does indeed, with Jakub's idea of copying only the required code to
$ADTTMP too.

Thanks,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

Hi Andreas,

On Wed, 19 Mar 2014 13:49:52 +0100, Andreas Tille andr...@an3as.eu wrote:
 On Wed, Mar 19, 2014 at 11:47:02AM +0100, Jakub Wilk wrote:
  Long answer:
  
  You can declare that a test needs to be run from a built source
  tree. Then the test runner will build the package. But that doesn't
  necessarily mean that the built binaries will be used for anything.
  
  Now, adt-run(1) has multiple modes of operation. In some of them the
  built binaries are used to satisfy tests' dependencies, in others
  packages from the archive are used. (This is super confusing. :/)
 
 +1 for confusion.

Likewise for me. I find it particularly complicated to imagine what variants
of adt-run should be used to make sure a particular test-suite is suitable
for the CI platforms (ci.debian.net and Ubuntu's), which basically means
having to look up the source code of the platforms to figure out what's
going to happen, or uploading a package and waiting for the results...

  I hope that ci.debian.net is configured in such a way it uses binary
  packages from the archive.
 
 I also hope so.  We recently had a discussion about biopython[1] whether
 to run dh_auto_test or not if autopkgtest exists.  I'm in clear favour
 of running dh_auto_test and based my arguing on the assumption that
 autopkgtest is testing the binary packages.  I'd be happy to hear the
 opinion of the autopkgtest experts about this.

I'm not an expert, but I do agree with you. If a package includes a
test-suite which can run during the build, then it might as well be run then,
since that should avoid uploading broken packages (or flag them very early).

To me, autopkgtest test-suites are nice for two things:
* tests which can't be run within a build (I started looking into all this
  for libevdev, which includes a test-suite that must be run as root);
* integration tests which combine multiple binary packages (e.g. Martin's
  example with the toolchain; I'm also working on a toolchain test-suite for
  mingw-w64, which would combine the mingw-w64 toolchain and wine to make
  sure the toolchain is working correctly).

I'm wondering how all this meshes with Ubuntu's fast migration approach:
I'm guessing it doesn't see build-time tests which are run as part of the
build... Would it be worth running them as autopkgtest tests *as well* for
this use case? Then again, if packages without tests aren't treated
differently, there would be no advantage to making tests' existence explicit
in all cases.

 Moreover I observed another issue with autopkgtest which is quite
 astonishing to me:  In bug #741274 it was reported that the autopkgtest
 would fail and the according log is here:
 

 http://ci.debian.net/data/unstable-amd64/packages/p/python-pysam/2014-03-12.log
 
 The problem is that `make` was not available in the chroot (obviosly)
 which does not sound very reasonable to me.  While I added it to the
 Depends in debian/tests/control I think it is not sensible to assume
 that make exists in a build chroot (it is not in the Build-Depends) but
 trying to build the package somehow and than notice that it is missing.
 I admit that I'm really confused how autopkgtests are working.

This is actually documented, sort of: the documentation for @builddeps@
mentions make as one of the packages which gets pulled in. (Why not
build-essential? Yet somehow gcc is available...)

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

On Sun, 16 Mar 2014 15:41:15 -0300, Antonio Terceiro terce...@debian.org
wrote:
 not subscribed to debian-mentors, please Cc: me explicitly if you still
 need my input.

Noted, thanks for noticing :-).

  Stephen Kitt sk...@debian.org, 2014-03-15, 14:53:
  A local adt-run using an unstable chroot or qemu works, whether run from
  the built or unbuilt source tree. But the tests fail on ci.debian.net; as
  far as I can tell it doesn't try to build the source package before
  running the tests, so they fail (see
  http://ci.debian.net/data/unstable-amd64/packages/libe/libevdev/2014-03-14.log
  for the last run).
 
 This is related to the way that the version of debci on ci.debian.net
 invokes adt-run. I am about to deploy a new version that does The Right
 Thing (TM) and should probably fix the issue you are seeing.

Excellent!

  Jakub Wilk
  == debian/tests/control ==
  Tests: check
  Restrictions: needs-root build-needed rw-build-tree
  Depends: @builddeps@
 
  It's probably unrelated to the problem you're observing, but this
  Depends is certainly incorrect. The specification says that “tests
  must test the INSTALLED version of the program”, but there is nothing
  in Depends to ensure that the program is in fact installed.
 
 ... this is an important point. You have to make sure that the any tests
 will run against the code that is _installed_ and not against the code
 that was just built. Also, it would be really nice on the test
 infrastructure if you could build strictly the bits you need to the
 tests instead of building everything. e.g. the ideal would be build
 _only_ the unit test files (assuming they need to be built) and not all
 the other code (since you are supposed to run the tests against the
 installed version of the package)

Indeed, thanks to Jakub for pointing that out. I've reworked the upstream
tests to build using the installed package.

Your point concerning building only the required bits effectively means that
we shouldn't use build-needed in the tests/control Restrictions field,
but manually control the build only for the purposes of running the tests, am
I right?

Regards,

Stephen


signature.asc
Description: PGP signature

Re: DEP8 tests using the built package source

[Stephen Kitt]

(Hi Ian, I'm adding you to the discussion since I'm talking about changes to
DEP8. I've snipped the exchanges but I hope you can get the gist of it
without needing to spend time looking anything else up!)

On Sun, 16 Mar 2014 17:39:20 -0300, Antonio Terceiro terce...@debian.org
wrote:
 On Sun, Mar 16, 2014 at 08:39:38PM +0100, Stephen Kitt wrote:
  On Sun, 16 Mar 2014 15:41:15 -0300, Antonio Terceiro terce...@debian.org
  wrote:
   ... this is an important point. You have to make sure that the any
   tests will run against the code that is _installed_ and not against
   the code that was just built. Also, it would be really nice on the
   test infrastructure if you could build strictly the bits you need to
   the tests instead of building everything. e.g. the ideal would be
   build _only_ the unit test files (assuming they need to be built)
   and not all the other code (since you are supposed to run the tests
   against the installed version of the package)
  
  Indeed, thanks to Jakub for pointing that out. I've reworked the
  upstream tests to build using the installed package.
  
  Your point concerning building only the required bits effectively
  means that we shouldn't use build-needed in the tests/control
  Restrictions field, but manually control the build only for the
  purposes of running the tests, am I right?
 
 most probably, yes.
 
 It's always a compromise.  Sometimes it's reasonably easy to patch the
 upstream test suite to make it not expect locally-built binaries, not
 use local includes etc. Sometimes it may be a lot harder, so YMMV.

Right, and in this particular instance it's not particularly difficult.

What bothers me is that the current DEP8 spec says that packages can rely on
having their source tree in the built state by stating Restrictions:
build-needed, but effectively that imposes too much of a burden on the
testing infrastructure. (That's not a complaint, I don't think we should
require another buildd network to run tests, at least not until we've got as
much test code as binary-targeted source code.) It's the kind of expectation
that makes sense in a traditional CI setting (e.g. Jenkins with Maven for
Java projects, where the project is built and its tests run in the same
environment), but with DEP8's aim of testing the installed binaries it seems
less useful to me. Wouldn't it make sense to change DEP8 to encourage
building whatever is strictly required for the tests, and perhaps drop
build-needed altogether?

Regards,

Stephen


signature.asc
Description: PGP signature

DEP8 tests using the built package source

[Stephen Kitt]

Hi,

I maintain libevdev, which includes tests which need to be run as root in the
built source tree:

./configure
sudo make check

Obviously this means I can't run the tests during the standard build, but
Michael Terry from Canonical pointed out that DEP8 tests would be appropriate
(https://bugs.launchpad.net/ubuntu/+source/libevdev/+bug/1287128).

I tried the following:

== debian/tests/control ==
Tests: check
Restrictions: needs-root build-needed rw-build-tree
Depends: @builddeps@

== debian/tests/check ==
#!/bin/sh

make -C ${0%/*}/../.. check


A local adt-run using an unstable chroot or qemu works, whether run from the
built or unbuilt source tree. But the tests fail on ci.debian.net; as far as
I can tell it doesn't try to build the source package before running the
tests, so they fail (see
http://ci.debian.net/data/unstable-amd64/packages/libe/libevdev/2014-03-14.log
for the last run).

Has anyone else come across this situation? Should I just rebuild the source
myself in the test, in ADTTMP?

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#739585: RFS: qjoypad/4.1.0-1 ITP

[Stephen Kitt]

Hi Jordan,

On Wed, 26 Feb 2014 00:12:40 -0600, Jordan Metzmeier jmetzmeie...@gmail.com
wrote:
 The package has been updated. I uploaded the new version to mentors
 and pushed my changes to git under pkg-games. The following has been
 updated:
 
 * Add xpm file for desktop and menu icon
 * Update description and keywords for .desktop file
 * Move .desktop file installation to debian/install
 * Move cleanup of src/*.png to debian/clean
 * Add Vcs* fields to debian/control

Excellent, thanks!

Could you push your tags to the Alioth repository too? (git push --tags.)
It doesn't get done automatically unfortunately and without the tags
git-buildpackage can't do its stuff.

Also, I realised I wasn't clear enough; when I said Don't bother with the
generic name though, I meant the GenericName entry in the Ubuntu file; yours
was fine and the .desktop file would be better with it back in! Sorry...

Finally, if you'd like to maintain this in the Games team, you should change
the maintainer as follows:

Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org

and add yourself as an uploader:

Uploaders: Jordan Metzmeier jmetzmeie...@gmail.com

But that's really up to you.

If you don't mind pushing the tags, adding GenericName=Joypad mapping back
to the .desktop file, and (if necessary) updating the control file, I'll sign
and upload the package.

Thanks for your work,

Stephen


signature.asc
Description: PGP signature

Bug#739585: RFS: qjoypad/4.1.0-1 ITP

[Stephen Kitt]

Control: tag -1 moreinfo

Hi Jordan,

On Thu, 20 Feb 2014 01:33:48 -0600, Jordan Metzmeier jmetzmeie...@gmail.com
wrote:
 I am looking for a sponsor for my package qjoypad

[...]
 
 The package contains two lintian info warnings:
 desktop-entry-lacks-keywords-entry
 no-upstream-changelog
 
 For the desktop lacking keywords entry, I really didn't have any ideas
 on what a user would type in other than the name and expect to find
 qjoypad. I would be happy to include any suggestions here.

no-upstream-changelog is now pedantic, so I wouldn't worry about it. As far
as keywords go, I'd add joystick, joypad, and perhaps joykeys and joyemu (the
names of two similar programs for Windows or DOS which users may know).

Did you look at the Ubuntu packaging? I like the desktop file:

[Desktop Entry]
Name=QJoyPad
GenericName=Simulated Keystrokes
GenericName[de]=Simulierte Tastendrücke
Comment=Trigger keystrokes and mouse actions with gamepads/joysticks
Comment[de]=Löse mit dem Gamepad/Joystick Tastendrücke und Mausbewegungen aus
Icon=qjoypad
Exec=qjoypad
Terminal=false
Type=Application
Categories=Utility;Game;
StartupNotify=false
Encoding=UTF-8

I think the comment is better than that in your version, and the Utility
and Games categories seems more appropriate to me than KDE and Qt.
Don't bother with the generic name though...

Given that you have a debian/install file, you could use that to replace your
install line for qjoypad.desktop in debian/rules.

Could you also convert the icon to xpm and add it to the menu file? See
https://wiki.debian.org/Games/JessieReleaseGoal for details.

I noticed in your ITP that you mention a possible Games team maintainership;
what are your thoughts on that now? (I'm a member of the Games team).

Thanks for your work! It's nice to see you know your way around qmake ;-).

Regards,

Stephen


signature.asc
Description: PGP signature

Re: What to do when autobuilders might run out of memory when building a package

[Stephen Kitt]

Hi,

On Wed, 5 Feb 2014 14:03:00 +0100, Andreas Tille andr...@an3as.eu wrote:
  One solution is to build with no optimisations (-O0 instead of -O2,
  perhaps using noopt); that allows seqan to build on my i386 buildd. I
  didn't try with -O1.
 
 Any volunteer to test
 
 $ svn diff
 Index: rules
 ===
 --- rules   (Revision 15979)
 +++ rules   (Arbeitskopie)
 @@ -7,6 +7,11 @@
  export CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS | sed
 's/-fstack-protector *//') 
  DEB_HOST_ARCH   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 +DEB_BUILD_ARCH_BITS := $(shell dpkg-architecture -qDEB_BUILD_ARCH_BITS)
 +ifeq ($(DEB_BUILD_ARCH_BITS),32)
 +CFLAGS=$(shell dpkg-buildflags --get CFLAGS | sed 's/-O[2-9]/-O1/')
 +CXXFLAGS=$(shell dpkg-buildflags --get CXXFLAGS | sed 's/-O[2-9]/-O1/')
 +endif
  
  %:
 dh $@
 
 
 I do not have any properly sized i386 at hand and I would like to avoid
 hammering the porter machines hard with this build which takes 2h on my
 amd64 where I made sure no other process will consume some memory.

With -O1 the build requires 2.5GB of memory on i386. It builds fine but
obviously might take a (very) long time on buildds with less RAM. -O0 only
needs 1GB.

If you can target the change more specifically, only pair_align.cpp needs the
work-around - everything else builds with far less memory.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: What to do when autobuilders might run out of memory when building a package

[Stephen Kitt]

Hi Andreas,

On Tue, 4 Feb 2014 21:15:41 +0100, Andreas Tille andr...@an3as.eu wrote:
 recently I uploaded seqan and I admit I fail to build the package on two
 of three machines I control and use to build.  Only one of these three
 amd64 machines has a big enough memory and does not die from swapping.
 When looking at the build log of i386:
 
 https://buildd.debian.org/status/fetch.php?pkg=seqanarch=i386ver=1.4.1-3stamp=1390975155
 
 I see
[...]
 cc1plus: out of memory allocating 7372636 bytes after a total of 45391872
 
 When looking at
 
https://buildd.debian.org/status/package.php?p=seqan
 
 it seems that only the more powerful architectures are able to build
 this package but also kfreebsd-amd64 fails (with a different error but I
 suspect the same problem).  I would consider excluding some
 architectures but the package is really used on i386 and I wonder whether
 there are some options to get it builded at least for this architecture.

The memory allocation isn't caused by memory exhaustion but by address space
exhaustion - pair_align.cpp needs 5GB of RAM to build with the current
CXXFLAGS. All the failed architectures apart from kfreebsd-amd64 are 32-bit
architectures.

One solution is to build with no optimisations (-O0 instead of -O2, perhaps
using noopt); that allows seqan to build on my i386 buildd. I didn't try with
-O1.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#732613: RFS: xye/0.12.2+dfsg-1 [ITA]

[Stephen Kitt]

Hi Andreas,

On Thu, Dec 19, 2013 at 12:00:25PM +0100, Andreas Rönnquist wrote:
 I am looking for a sponsor for my package xye

I like Xye, so I thought I'd give your package a look, with the intent
of sponsoring it eventually. I've just got a couple of comments:
* debian/repack is nice but seems like an awful lot of effort to
  remove two files; have you noticed the new Files-Excluded header in
  debian/copyright which uscan now supports?
* The manpage doesn't follow the typical Unix manpage style, although
  if there are no command-line options then the text you've written is
  good enough. You might get bug reports requesting the manpage to
  document how to play but until then...
* You should update debian/copyright to include yourself.

Incidentally while trying to determine whether xye takes any
command-line parameters, I discovered that specifying any parameter
causes xye to crash! (I'll file a bug...)

Regards,

Stephen


signature.asc
Description: Digital signature

Bug#732613: RFS: xye/0.12.2+dfsg-1 [ITA]

[Stephen Kitt]

On Sat, 21 Dec 2013 21:30:28 +0100, Andreas Rönnquist gus...@gusnan.se
wrote:
  I've just got a couple of comments:
  * debian/repack is nice but seems like an awful lot of effort to
remove two files; have you noticed the new Files-Excluded header in
debian/copyright which uscan now supports?
 
 Ah, I hadn't - thanks! Well, I am kind of irritated on that bug I
 mentioned in README.source (##635920) which makes it impossible to use
 git-import-orig --uscan in combination with a debian/repack script... I
 guess using the mentioned Files-Excluded would solve this?

I haven't actually got round to using it myself yet, so I can't say for
sure... But I get the impression that uscan repacks the original tarball
itself with the same name when removing excluded files, so it should work
transparently with git-import-orig --uscan.

I'll leave it to you to decide what you want to do for this version of the xye
package, since it's too late for the 0.12.2 import anyway, and it would
require rewriting debian/copyright in machine-readable format.

  * The manpage doesn't follow the typical Unix manpage style, although
if there are no command-line options then the text you've written is
good enough. You might get bug reports requesting the manpage to
document how to play but until then...
 
 I'll think I'll wait for those bug reports... ;)

That's fine by me!

  Incidentally while trying to determine whether xye takes any
  command-line parameters, I discovered that specifying any parameter
  causes xye to crash! (I'll file a bug...)
 
 Oh! I have managed to include a patch that fixes this problem, but when
 doing so I found more related problems - if running with a folder which
 doesn't contain any data files it still segfaults (but later). I
 will try to put together a patch for this problem too.
 
 (I have pushed my current changes to alioth).
 
 Would you like me to put together a new package on mentors, or do you
 simply get the gbp packaging from alioth?

I'm pulling your packaging from alioth, so no need to update mentors.

BTW I noticed in your email to debian-devel-games that you mentioned the
newer-standards-version lintian warning; this is fixed in the latest
version of lintian, currently available in unstable only. I recommend that
for Debian development work you always use the unstable version of lintian; I
use the following apt pinning (in /etc/apt/preferences):

Package: lintian
Pin: release a=unstable
Pin-Priority: 500

Package: debian-policy
Pin: release a=unstable
Pin-Priority: 500

Let me know when you reckon you've finished preparing the package, whether
or not you fix the second segfault you mention (I can't reproduce it, but I
may not be testing the right thing).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#715172: RFS: solaar/0.8.99.10-3 ITP

[Stephen Kitt]

Hi Daniel,

On Sat, 13 Jul 2013 18:59:34 +0200, Daniel Augustin Pavel
daniel.pa...@gmail.com wrote:
 On 13 July 2013 18:26, Stephen Kitt sk...@debian.org wrote:
  Here is my review of the package so far:
  * great job on the ConsoleKit / systemd support, with minimal debconf
prompting, nice!
 
 Thank you! I'm also packaging Solaar for Ubuntu, and I'm trying to
 have it integrate nicely with modern destktop environments. At the
 same time, some users might have a lightweight DE, and I don't want to
 force on them such heavy dependencies.
 
 I fear the notification about using the plugdev group may be a bit too
 much, but I don't know how to handle this situation better.

Neither do I, and in most cases users won't see it anyway.

  * personally I'd drop substvars.extra (and define the substvars in
debian/rules, with a solaar: prefix) and rules.extra, but that's really
  a question of preference rather than best practice as far as I'm concerned
 
 I'm using the substvars because the Ubuntu package needs
 gnome-icon-theme-full (or equivalent).
 By defining them in debian/rules, you mean something like
 dh_gencontrol -- -Vsolaar:VAR=VALUE ?

Yes. To handle the differences between Ubuntu and Debian, you could use the
approach used in gcc's packaging for example:
* build-depend on lsb-release
* add something like this to debian/rules:
distribution := $(shell lsb_release -is)
...
ifeq ($(distribution),Ubuntu)
...
else
...
endif

 The rules.extra was actually needed by some silliness I was doing with
 the Ubuntu package; I've gotten rid of it but forgot to remove
 rules.extra.

OK.

  * why not use dh compat level 9?
 
 I have no idea what that is :). Most likely compat 8 is what I found
 in the samples I used when I started packaging. What's the
 difference/impact?

Have a look at the COMPATIBILITY LEVELS section in debhelper's man page for
all the details; in your case, compat 9 avoids having --with=python-support
by default.

  * since this is a new package, you should file a separate ITP (alongside
  this RFS), indicate that the RFS blocks the ITP, and close the ITP in
debian/changelog (not the RFS, I'll do that when I sponsor the package)
 
 Okaaay... I'll do this slowly so I don't get confused :). Sorry, I'm
 still learning the maintaining/sponsorship process.

No problem! Filing an ITP means I'm working on packaging this, and
hopefully avoids duplication of effort. The Debian package effectively fixes
the bug, so the changelog indicates that with the appropriate bug number.
Filing an RFS mean I need help getting this uploaded; the package can't fix
that bug, so it's not mentioned in the changelog.

  * in debian/copyright, you need to give the license paragraphs for the SVG
and PNG files, in the same way as your GPL-2 license paragraph; These
files were copied from the Oxygen icon theme should go in a Comment:
stanza
  * still in debian/copyright, you don't need Copyright (C) in your
Copyright: stanzas (so just Copyright: 2012-2013 Daniel Pavel)
 
 Okay.
 
  Outwith the Debian-specific packaging, you should add appropriate headers
  to your source files in bin and lib, as described in the How to Apply
  These Terms to Your New Programs at the end
  of /usr/share/common-licenses/GPL-2.
 
 Okay. I've seen some software including the copyright template at the
 beginning of source files, but I'm lazy and hoped the COPYING file in
 the sources would cover it :). Is it necessary to include it in _all_
 sources, or just the bin/ and lib/ root?

Ideally it should be in all the sources. It may seem unnecessary when you
think of your piece of software as a whole, but it means that if someone else
picks one or two files from Solaar for use elsewhere, the licensing terms for
those files stay with them. It avoids future packagers tearing their hair out
trying to determine the correct licensing information for packages with
sources pulled from a variety of different projects...

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#715172: RFS: solaar/0.8.99.10-3 ITP

[Stephen Kitt]

owner 715172 !
tag 715172 + pending
tag 715172 + moreinfo
thanks

Hi Daniel,

On Sat, 6 Jul 2013 18:21:08 +0200, Daniel Augustin Pavel
daniel.pa...@gmail.com wrote:
 I am looking for a sponsor for my package solaar
 
 * Package name: solaar
   Version : 0.8.99.10-3
   Upstream Author : Daniel Pavel daniel.pa...@gmail.com
 * URL : http://pwr.github.io/Solaar
 * License : GPLv2
   Section : misc
 
 It builds those binary packages:
   solaar - Logitech Unifying Receiver peripherals manager for Linux
   solaar-gnome3 - gnome-shell/Unity integration for Solaar

I was quite pleased to see this RFS! I'd love to help you get the package
ready and sponsor it for you.

Here is my review of the package so far:
* great job on the ConsoleKit / systemd support, with minimal debconf
  prompting, nice!
* personally I'd drop substvars.extra (and define the substvars in
  debian/rules, with a solaar: prefix) and rules.extra, but that's really a
  question of preference rather than best practice as far as I'm concerned
* why not use dh compat level 9?
* since this is a new package, you should file a separate ITP (alongside this
  RFS), indicate that the RFS blocks the ITP, and close the ITP in
  debian/changelog (not the RFS, I'll do that when I sponsor the package)
* in debian/copyright, you need to give the license paragraphs for the SVG
  and PNG files, in the same way as your GPL-2 license paragraph; These
  files were copied from the Oxygen icon theme should go in a Comment:
  stanza
* still in debian/copyright, you don't need Copyright (C) in your
  Copyright: stanzas (so just Copyright: 2012-2013 Daniel Pavel)

Outwith the Debian-specific packaging, you should add appropriate headers to
your source files in bin and lib, as described in the How to Apply These
Terms to Your New Programs at the end of /usr/share/common-licenses/GPL-2.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Package version numbers

[Stephen Kitt]

On Wed, 16 Jan 2013 19:16:26 +0100, Christian PERRIER bubu...@debian.org
wrote:
 Quoting Raphael Hertzog (hert...@debian.org):
  On Wed, 16 Jan 2013, Christian PERRIER wrote:
   Quoting Jakub Wilk (jw...@debian.org):
I would paint the bikeshed the following color:
0.8.51+dfsg1-0.1
   
   Isn't that missing the fact that this is a t-p-u upload, which is
   indeed the start of a wheezy branch?
   
   So something we were naming +wheezyfoo in the past and which we
   now name +deb70u1.
  
  It's not really relevant because sid has already diverged and has a higher
  (upstream) version.
  
  So 0.8.51+dfsg1-0.1 is acceptable IMO.
 
 Indeed.
 
 And the theoretical question of what if sid hadn't diverged wrt
 upstream is silly as this is a native package.
 
 Steve, problem solved, then..:). We were bikeshedding a bit too much.

Yup, thanks! A case of “Pourquoi faire simple quand on peut faire
compliqué ?” ;-) (“Why make things simple when they can be complicated?”)

An updated package is coming up shortly...

Regards,

Stephen


signature.asc
Description: PGP signature

Package version numbers

[Stephen Kitt]

Hi,

Neither my AM (Christian Perrier) nor myself are sure about the answer to this
one, so he suggested I ask -devel for advice (and I'm throwing -mentors into
the mix too).

I've prepared an update for calibre, to fix a few issues in the package which
is currently in Wheezy (see #686547 for details). The update involves
repacking the original tarball, which was already repacked, and is an NMU.

The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the update's
version be? I'm purposefully not mentioning our ideas (one of them is
obvious from the exchanges in the bug report, but is in all likelihood
incorrect).

Thanks in advance,

Stephen


signature.asc
Description: PGP signature

Re: Architecture-independent packages with missing build-dependencies on some architectures

[Stephen Kitt]

On Sat, 22 Sep 2012 18:18:06 -0400, Michael Gilbert mgilb...@debian.org
wrote:
 I think it would be more appropriate to just close the bug with a
 message indicating that the package should be built on a system with
 multiarch enabled; where the wine-bin dependency would be satisfied
 via wine-bin:i386.  Lucas's automated builds don't take that into
 account.

Right, I'll do just that!

Thanks,

Stephen


signature.asc
Description: PGP signature

Architecture-independent packages with missing build-dependencies on some architectures

[Stephen Kitt]

Dear mentors,

I maintain the wine-gecko package (wine-gecko-1.4), which is in an
interesting situation because its build-dependencies can't be satisfied on all
architectures, but it builds an Architecture: all package. Something
similar was discussed in March, and as I understand it the consensus was that
this isn't a problem, and when the buildds start rebuilding
architecture-independent packages the Build-Architecture control field will
allow us to specify where packages should be built.

I'm wondering what to do about http://bugs.debian.org/684844 - an RC bug
filed because wine-gecko FTBFS on amd64 (which is missing one of the
build-dependencies, wine-bin). I've uploaded a fix to experimental, but it
seems ugly to me: I made the package Architecture: any, so it only builds
on architectures with the full build-dependency set. This still meets the
requirements on the package, but means multiple buildds spend time building
the same thing...

Should I just mark the bug wontfix with an explanation? Or should I keep my
fix?

Incidentally, the Build-Architecture field doesn't seem to me to really
solve this issue either; using it in this instance would mean I'd have to do
sourceful uploads of wine-gecko whevener the availability of wine-bin changed!

Thanks in advance,

Stephen


signature.asc
Description: PGP signature

Bug#678087: [UPLOADED] Re: Bug#678087: RFS: mail-notification/5.4.dfsg.1-6 (Evolution 3.4 transition)

[Stephen Kitt]

On Tue, 19 Jun 2012 16:55:41 +0200, Michael Biebl bi...@debian.org wrote:
 On 19.06.2012 07:27, Stephen Kitt wrote:
  Package: sponsorship-requests
  Severity: normal
  X-Debbugs-Cc: Michael Biebl bi...@debian.org
  
  Dear mentors,
  
  I am looking for a sponsor for my package mail-notification.
 
 Uploaded.

Thanks!

Stephen


signature.asc
Description: PGP signature

Bug#678087: RFS: mail-notification/5.4.dfsg.1-6 (Evolution 3.4 transition)

[Stephen Kitt]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: Michael Biebl bi...@debian.org

Dear mentors,

I am looking for a sponsor for my package mail-notification.

It builds those binary packages:

  mail-notification - mail notification in system tray
  mail-notification-evolution - evolution support for mail notification

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

  http://mentors.debian.net/package/mail-notification

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

  dget -x 
http://mentors.debian.net/debian/pool/main/m/mail-notification/mail-notification_5.4.dfsg.1-6.dsc

Changes since the last upload:

mail-notification (5.4.dfsg.1-6) unstable; urgency=low

  * Allow linking with --as-needed (thanks to Michael Bienia for the
patch).
  * Support building with Evolution 3.4 (thanks to Michael Biebl and
Mathieu Trudel-Lapierre for the patch; closes: #677455).

 -- Stephen Kitt st...@sk2.org  Tue, 19 Jun 2012 00:03:39 +0200


Regards,
 Stephen Kitt


signature.asc
Description: PGP signature

Bug#674959: RFS: jstest-gtk/0.1.1~git20090722-2 - joystick testing and configuration tool

[Stephen Kitt]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-games-de...@lists.alioth.debian.org

Dear mentors,

I am looking for a sponsor for my package jstest-gtk

 * Package name: jstest-gtk
   Version : 0.1.1~git20090722-2
   Upstream Author : Ingo Ruhnke grum...@gmx.de
 * URL : http://pingus.seul.org/~grumbel/jstest-gtk/
 * License : GPL-3+
   Section : utils

It builds those binary packages:

 jstest-gtk - joystick testing and configuration tool
 jstest-gtk-dbg - joystick testing and configuration tool - debug

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

 http://mentors.debian.net/package/jstest-gtk

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

 dget -x
  
http://mentors.debian.net/debian/pool/main/j/jstest-gtk/jstest-gtk_0.1.1~git20090722-2.dsc

or access the subversion repository

 svn://svn.debian.org/svn/pkg-games/packages/trunk/jstest-gtk/
 http://anonscm.debian.org/viewvc/pkg-games/packages/trunk/jstest-gtk/

Changes since the last upload:

jstest-gtk (0.1.1~git20090722-2) unstable; urgency=low

  * Acknowledge NMU (thanks Gregor!).
  * Limit architectures to those using Linux kernels.
  * Add build-arch/build-indep targets and clean up debian/rules (in
particular, avoid touching build-stamp from the binary target).
  * Correct Vcs-Browser URL.
  * Restore watch file.
  * Remove obsolete Encoding key from the desktop file.
  * Drop build-dependency on quilt, and correct debian/rules
appropriately.
  * Add headers to all the patches.
  * Ship NEWS as the upstream changelog.
  * Re-enable typos.patch to fix another typo.
  * Update copyright years and format URL.
  * Rework libraries.patch to use pkg-config for all libraries.
  * Rework flag management to allow hardened builds.
  * Standards-Version 3.9.3, no further change required.

 -- Stephen Kitt st...@sk2.org  Mon, 28 May 2012 23:49:12 +0200


Regards,
 Stephen Kitt


signature.asc
Description: PGP signature

Bug#659083: RFS: xmoto -- 2D motocross platform game

[Stephen Kitt]

Hi Mike,

On Mon, 7 May 2012 01:01:37 +0200, Stephen Kitt st...@sk2.org wrote:
 On Sun, May 06, 2012 at 06:04:17PM -0400, Michael Gilbert wrote:
  I just reviewed this package.  It looks good except for a couple issues:
 
 Thanks for taking a look at this.
 
  1.  bin/credits.rpl seems to be a binary file in the repacked upstream
  source (there may be others, but I stopped at that one)
 
 Apart from the various .ogg files and the .ttf files for DejaVu,
 that's the only binary left. It's a replay of a level in the game, so
 there is no appropriate form for modification - it was recorded using
 the game and is not generated...
 
  2.  I'm not sure that it's good practice to apply the patch directly
  within the upstream orig file.  It would be better to do that via
  quilt.  You probably did that to make sure that the orig would be
  buildable by itself, but that isn't necessary.
 
 That is indeed why I did it. I'll fix it once I get wine-gecko done!

I've uploaded a fixed package to http://mentors.debian.net/package/xmoto and
pushed the changes to the svn repository:
* I've repacked the tarball, the only change now is the removal of glext.h; I
  left the added files in the bin folder out since they can be reconstructed
  byte-for-byte using xmoto --unpack (and I've added a README.source
  explaining this);
* the patch required to build as a result of removing glext.h is now applied
  as a Debian patch;
* I added DMUA as you suggested.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#659082: RFS: nestopia/1.40g+dfsg-1 [NEW] -- accurate emulator of the Nintendo Entertainment System

[Stephen Kitt]

Hi Bart,

On Tue, May 22, 2012 at 05:21:54AM +, Bart Martens wrote:
 I don't see the package at mentors.  What happened ?

It must have expired - I'm re-uploading it just now.

Regards,

Stephen



-- 
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/20120522060948.gm12...@sk2.org

Re: Bug#659082: RFS: nestopia/1.40g+dfsg-1 [NEW] -- accurate emulator of the Nintendo Entertainment System

[Stephen Kitt]

Hi Boris,

On Tue, May 22, 2012 at 10:40:51AM +0300, Boris Pek wrote:
   I don't see the package at mentors.  What happened ?
 
  It must have expired - I'm re-uploading it just now.
 
 Have you received the mail with note that your package was deleted from 
 m.d.n.?
 If no it could be an imperfection of m.d.n., and it affects all of us.

It was a while ago, but I do believe I did get the email. (So I should
have re-uploaded the package sooner, or dropped the RFS, or ...)

Regards,

Stephen


-- 
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/20120523044919.go12...@sk2.org

Bug#673277: RFS: evtest/1:1.30-1 -- utility to monitor Linux input device events

[Stephen Kitt]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package evtest

 * Package name: evtest
   Version : 1:1.30-1
   Upstream Author : Peter Hutterer peter.hutte...@who-t.net
 * URL : http://cgit.freedesktop.org/evtest/
 * License : GPL-2+
   Section : utils

It builds those binary packages:

evtest - utility to monitor Linux input device events

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

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

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

  dget -x
http://mentors.debian.net/debian/pool/main/e/evtest/evtest_1.30-1.dsc

The package is maintained on collab-maint:
Vcs-Git: git://git.debian.org/collab-maint/evtest.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/evtest.git;a=summary

Changes since the last upload:

evtest (1:1.30-1) unstable; urgency=low

  * New upstream version.
  * Update debian/watch to track all tarballs.
  * Update debian/copyright format URL.
  * Switch to debhelper compat 9 (notably to automatically enable
hardened builds).
  * Standards-Version 3.9.3, no change required.

 -- Stephen Kitt st...@sk2.org  Wed, 16 May 2012 22:17:49 +0200


Regards,
 Stephen Kitt


signature.asc
Description: PGP signature

Bug#659083: RFS: xmoto -- 2D motocross platform game

[Stephen Kitt]

Hi Mike,

On Sun, May 06, 2012 at 06:04:17PM -0400, Michael Gilbert wrote:
 I just reviewed this package.  It looks good except for a couple issues:

Thanks for taking a look at this.

 1.  bin/credits.rpl seems to be a binary file in the repacked upstream
 source (there may be others, but I stopped at that one)

Apart from the various .ogg files and the .ttf files for DejaVu,
that's the only binary left. It's a replay of a level in the game, so
there is no appropriate form for modification - it was recorded using
the game and is not generated...

 2.  I'm not sure that it's good practice to apply the patch directly
 within the upstream orig file.  It would be better to do that via
 quilt.  You probably did that to make sure that the orig would be
 buildable by itself, but that isn't necessary.

That is indeed why I did it. I'll fix it once I get wine-gecko done!

Regards,

Stephen



-- 
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/20120506230136.gc11...@sk2.org

Bug#659083: RFS: xmoto -- 2D motocross platform game

[Stephen Kitt]

tag 659083 - moreinfo
thanks

Hi Ansgar,

It's been ages, but I've finally finished getting everything ready.

On Sun, 26 Feb 2012 15:52:56 +0100, Ansgar Burchardt ans...@debian.org
wrote:
 Stephen Kitt st...@sk2.org writes:
dget -x
  http://mentors.debian.net/debian/pool/main/x/xmoto/xmoto_0.5.9-1.dsc
 
 You do not include the full license text for src/glext.h in the
 copyright information.

I should have noticed that... It was actually not DFSG-free, but it's easy
enough to patch out so I've repacked the upstream tarball without it (and
with the small, necessary patch; I added a README.dfsg file to explain
everything). I filed a bug upstream too.

 Have the patches been forwarded upstream?

They have now, see the updated patch headers for details.

 You use debhelper compat level 9, so why don't you build-depend on
 debhelper (= 9)?

When I initially switched to compat level 9, debhelper 9 wasn't available
yet. I changed the build-dependency to (= 9).

 Please update at least config.{guess,sub}, see [1] for details, or just
 use dh-autoreconf (my personal preference).

I like dh-autoreconf too, that's what I went for.

 The source for bin/xmoto.bin seems to be missing, compare with
 upstream's SVN repository[2].  I have filed a bug[3] as it is also
 the case for the version currently inthe archive.  Please ask upstream
 to include the source and ideally built xmoto.bin instead of including
 it, see also [4] for more details.

Indeed; I took the opportunity of repacking the upstream tarball to add the
missing files and remove xmoto.bin. (The resulting build still produces an
identical xmoto.bin.) I also forwarded your bug upstream.

All this (and more) is available in the subversion repository and at
http://mentors.debian.net/debian/pool/main/x/xmoto/xmoto_0.5.9+dfsg-1.dsc

The changelog is as follows:

xmoto (0.5.9+dfsg-1) unstable; urgency=low

  * New upstream release (closes: #644234):
+ builds with libpng 1.5 (closes: #649797);
+ uses libxml2;
+ uses DejaVuSansMono (add link and make ttf-dejavu-core a dependency
  of xmoto-data).
  * Repacked to avoid licensing problems:
+ remove src/glext.h, licensed under SGI License B version 1.1;
+ add the missing contents in bin (closes: #661340).
(I'm hoping that both issues will be fixed upstream, so I haven't
added a get-orig-source target to debian/rules. README.dfsg in the
repacked source explains the changes.)
  * Update debian/watch accordingly.
  * Update patches:
+ fix_segfault.patch: refresh, add DEP-3 header, forward upstream;
+ desktop.patch: re-apply, add German translation (closes: #641822),
  forward upstream;
+ spelling.patch: refresh, forward upstream;
+ manpage.patch: forward upstream;
+ gcc44-ftbfs.patch: no longer used, delete.
  * Switch to dh 9 with simple rules.
  * Use source format 3.0 (quilt).
  * Add ${misc:Depends} where appropriate.
  * Patch the manpage to fix hyphens and a few spelling mistakes.
  * Add myself to uploaders.
  * Update debian/copyright.
  * Standards-Version 3.9.3 (no further change required).
  * Fix spelling mistakes spotted by Lintian.
  * Use dh-autoreconf to update config.{guess,sub} (thanks to Ansgar
Burchardt for the hint).
  * wrap-and-sort control files.
  * Build-depend on libpng-dev only, dropping the libpng12-dev alternative
(closes: #662565).
  * Fix ftbfs with GCC-4.7 by including unistd.h where appropriate
(closes: #667422; thanks to Cyril Brulebois for his patch for another
gcc-4.7-related issue, which was already included upstream).
  * Fix the Vcs-Browser URL.

 -- Stephen Kitt st...@sk2.org  Mon, 23 Apr 2012 00:19:42 +0200

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#665926: RFS: mail-notification/5.4.dfsg.1-4 -- mail notification in system tray

[Stephen Kitt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my updated package
mail-notification. This is still just a bug-fix update, I haven't
finished the various changes I'm working on upstream.

  The source builds those binary packages:

mail-notification - mail notification in system tray
 mail-notification-evolution - evolution support for mail notification

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

  http://mentors.debian.net/package/mail-notification


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

dget -x 
http://mentors.debian.net/debian/pool/main/m/mail-notification/mail-notification_5.4.dfsg.1-4.dsc

  More information about hello can be obtained from http://www.example.com.

  Changes since the last upload:

mail-notification (5.4.dfsg.1-4) unstable; urgency=low

  * Build with gmime 2.6 rather than gmime 2.4 (patch provided by Michael
Biebl; closes: #664000).
  * Refresh patch providing Evolution 3.0 (from upstream, based on work by
Erik van Pienbroek for Fedora; closes: #657558).
  * Depend on gstreamer0.10-tools which is required to play sounds
(thanks to Sergio Cipolla for pointing this out; closes: #658607).
  * Ignore default values which can no longer be found (patch provided by
Gunnar Hjalmarsson; closes: #641937).
  * Standards-Version 3.9.3, no change required.

 -- Stephen Kitt st...@sk2.org  Tue, 27 Mar 2012 00:06:19 +0200


Regards,
 Stephen Kitt



-- 
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/20120327052207.10036.75570.report...@heffalump.sk2.org

Bug#659083: RFS: xmoto -- 2D motocross platform game

[Stephen Kitt]

Hi Ansgar,

On Sun, 26 Feb 2012 15:52:56 +0100, Ansgar Burchardt ans...@debian.org
wrote:
 You do not include the full license text for src/glext.h in the
 copyright information.
 
 Have the patches been forwarded upstream?
 
 You use debhelper compat level 9, so why don't you build-depend on
 debhelper (= 9)?
 
 Please update at least config.{guess,sub}, see [1] for details, or just
 use dh-autoreconf (my personal preference).
 
 The source for bin/xmoto.bin seems to be missing, compare with
 upstream's SVN repository[2].  I have filed a bug[3] as it is also
 the case for the version currently inthe archive.  Please ask upstream
 to include the source and ideally built xmoto.bin instead of including
 it, see also [4] for more details.

Thanks for the review, I'll update the package as appropriate once I have a
little more time (in a couple of weeks).

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#659082: RFS: nestopia/1.40g+dfsg-1 [ITA] -- accurate emulator of the Nintendo Entertainment System

[Stephen Kitt]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package nestopia.

 * Package name: nestopia
   Version : 1.40h+dfsg-1
   Upstream Author : Martin Freij and R. Belmont
 * URL : http://rbelmont.mameworld.info/?page_id=200
 * License : GPL-2.0+
   Section : games

This is an alternative to FCEU and Mednafen which are already in Debian; its
emulation is more faithful than that provided by either of those emulators.
I am also the maintainer of the mednafen package in Debian, within the
Debian Games Team (which I've also specified as the maintainer for the
nestopia package).

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/n/nestopia/nestopia_1.40h+dfsg-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards,

Stephen Kitt


signature.asc
Description: PGP signature

Re: RFS: oss-compat (RC bug fix)

[Stephen Kitt]

On Tue, 17 Jan 2012 08:41:35 +0800, Paul Wise p...@debian.org wrote:
 On Tue, Jan 17, 2012 at 8:05 AM, Paul Wise wrote:
  I note that the package is installable on hurd-*. AFAICT Hurd doesn't
  support sound or Alsa so maybe it should not depend on 'hurd' or
  should switch to architecture linux-any (or linux-all if that
  existed)?
 
 The kind folks on #debian-hurd pointed out that kldutils provides
 module-init-tools on kFreeBSD and that it is useful for oss-compat to
 be installable on hurd since other things depend on it (that don't
 nessecarily need OSS at runtime).
 
 I took the liberty of adding (LP: #340873) to the changelog.

LP#340873 actually corresponds to #518149, which was fixed in 0.0.4+nmu3. I
did notice though that it was still open against Lucid, which already has
0.0.4+nmu3, so I closed it manually there. Thanks for triaging the other
launchpad bugs!

 Uploaded.

Thanks!

Stephen


signature.asc
Description: PGP signature

RFS: oss-compat (RC bug fix)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for my package oss-compat. The updated package
adds a Multi-Arch declaration (#651335) and handles its configuration file
according to policy (#649507, which is RC).

The dsc is available at
http://mentors.debian.net/debian/pool/main/o/oss-compat/oss-compat_1.dsc and
the package's page on m.d.n is http://mentors.debian.net/package/oss-compat

I would be glad if someone uploaded this package for me.

Kind regards,

Stephen


signature.asc
Description: PGP signature

Re: RFS: mail-notification (updated package; NMU for RC bugs among others)

[Stephen Kitt]

On Wed, 14 Sep 2011 23:14:37 +0200, Sven Hoexter s...@timegate.de wrote:
 On Tue, Sep 13, 2011 at 12:31:56AM +0200, Stephen Kitt wrote:
  I've reuploaded it to m.d.n, and placed it on
  http://www.sk2.org/mail-notification/ too
  (http://www.sk2.org/mail-notification/mail-notification_5.4.dfsg.1-2.5.dsc).
 
 Uploaded. I already wrote you last time that I think, that you should
 work with the people from Fedora etc. to fold all the patches into
 a new upstream release. Please, for the sake of sanity try to get
 something going. The patch stack is insane.

Thanks!

I've started the ball rolling:
https://lists.gnu.org/archive/html/savannah-users/2011-09/msg00010.html

I'm marshalling all the various patches to get a new upstream release ready,
regardless of where it actually ends up.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: RFS: mail-notification (updated package; NMU for RC bugs among others)

[Stephen Kitt]

Hi Sven,

On Mon, 12 Sep 2011 22:26:59 +0200, Sven Hoexter s...@timegate.de wrote:
 On Thu, Sep 08, 2011 at 12:16:40AM +0200, Stephen Kitt wrote:
  In the meantime though, would any one like to sponsor the NMU?
 
 I wanted to take a look at it over the weekend but parts of the
 package went missing from mentors.d.n. I made Arno aware of it
 in #debian-metors.
 
 Maybe you can reupload it or upload it somewhere else.

I've reuploaded it to m.d.n, and placed it on
http://www.sk2.org/mail-notification/ too
(http://www.sk2.org/mail-notification/mail-notification_5.4.dfsg.1-2.5.dsc).

Regards,

Stephen


signature.asc
Description: PGP signature

Re: RFS: mail-notification (updated package; NMU for RC bugs among others)

[Stephen Kitt]

Hi Michael,

On Wed, 07 Sep 2011 02:43:37 +0200, Michael Biebl bi...@debian.org wrote:
 Am 07.09.2011 00:57, schrieb Stephen Kitt:
  I am looking for a sponsor for the package mail-notification. This
  update would fix a couple of RC bugs (the usual Evolution updates,
  which also require a switch to GTK+ 3);
 
 Hm, the package still build-depends on libgtk2.0-dev, is that an oversight?

It's only needed for gtk-builder-convert; I suppose I could just provide
the .ui files in a patch, but I'd rather build everything from the original
sources as far as possible.

 Also, the package seem to still use a lot of deprecated GNOME 2 libs, 
 like libgnomeprintui2.2-dev, libgnomevfs2-dev and libgnome2-dev.
 Are they still required? If so, you should consider porting them to the 
 newer interfaces, like GVFS.

OK - do you have any pointers to migration documentation? The main intent of
the NMU was to fix the FTBFS, not really overhaul the whole package, but it
would indeed be better to avoid leaving predictable future FTBFSes...

Thanks for looking at the package,

Stephen


-- 
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/20110907081243.098fc...@sk2.org

Re: RFS: mail-notification (updated package; NMU for RC bugs among others)

[Stephen Kitt]

On Wed, 7 Sep 2011 12:08:57 +0200, Sven Hoexter s...@timegate.de wrote:
 On Wed, Sep 07, 2011 at 10:34:11AM +0200, Adam Borowski wrote:
   OK - do you have any pointers to migration documentation? The main
   intent of the NMU was to fix the FTBFS, not really overhaul the whole
   package, but it would indeed be better to avoid leaving predictable
   future FTBFSes...
  
  It seems strange to me to have changes of this scale in a NMU.  Wouldn't
  you rather either hijack the package or talk to Liu Qi about adding
  yourself as a co-maintainer?  Especially since it's your 5th NMU of this
  package in a row, you're kind of its official non-maintainer :p
 
 I've uploaded one the NMUs in the past and last time Liu ACK'ed the NMU
 because he had not enough time to care at the time. I think I already
 proposed to Steve to take over the whole thing upstream because it's dead
 otherwise. Steve and some other people from other distros currently pass
 around patches and the mess is getting bigger every other month. :-/

I went for a large-scale NMU mainly because, compared to the work involved
fixing the FTBFS bug (the patches adding support for Evolution 3 and
switching to GTK+ 3), the rest was rather simple and addressed either nasty
bugs (the eggtrayicon segfault and Polish crash), important missing
functionality people have been waiting for for years (SSL) or a trivial
text-formatting fix (b instead of span). Then I fixed some lintian
warnings because I know some sponsors prefer a reasonably lintian-clean
package!

I have indeed ended up being the de facto maintainer, and Qi agreed in
March that we should probably co-maintain it (well, strictly speaking the
agreement was that I should have access to a repository used to maintain
mail-notification). Since then though I haven't heard anything.

I also attempted to get in touch with Jean-Yves Lefort but haven't heard
anything from him either.

In any case I don't mind either taking over upstream or taking over the
Debian package (or both). I don't know if it's possible to take over a dead
project on Savannah and Launchpad (where mail-notification are hosted), as
used to be the case on SourceForge...

In the meantime though, would any one like to sponsor the NMU?

Regards,

Stephen


signature.asc
Description: PGP signature

RFS: mail-notification (updated package; NMU for RC bugs among others)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the package mail-notification. This
update would fix a couple of RC bugs (the usual Evolution updates,
which also require a switch to GTK+ 3); I've also included a number of
fixes for bugs with patches in the BTS, and activated SSL
support. (See the m.d.n link below for the list of bugs fixed.)

Note that this is an NMU, so far with no reaction from Qi (I mentioned
the patches for the RC bugs only yesterday, but the bugs involved have
had no reaction at all).

It builds these binary packages:

 mail-notification - mail notification in system tray
 mail-notification-evolution - evolution support for mail notification

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

  http://mentors.debian.net/package/mail-notification

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

  dget -x 
http://mentors.debian.net/debian/pool/main/m/mail-notification/mail-notification_5.4.dfsg.1-2.5.dsc

I would be glad if someone uploaded this package for me.

Kind regards,

Stephen Kitt


-- 
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/20110906225703.gh28...@sk2.org

RFS: nestopia -- accurate emulator of the Nintendo Entertainment System

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for my package nestopia.

 * Package name: nestopia
   Version : 1.40h+dfsg-1
   Upstream Author : Martin Freij and R. Belmont
 * URL : http://rbelmont.mameworld.info/?page_id=200
 * License : GPL-2.0+
   Section : games

This is an alternative to FCEU and Mednafen which are already in Debian; its
emulation is more faithful than that provided by either of those emulators.
I am also the maintainer of the mednafen package in Debian, within the
Debian Games Team (which I've also specified as the maintainer for the
nestopia package).

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

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

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

  dget -x
  
http://mentors.debian.net/debian/pool/main/n/nestopia/nestopia_1.40h+dfsg-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards,

Stephen Kitt


signature.asc
Description: PGP signature

Re: [done] RFS: libbs2b

[Stephen Kitt]

On Tue, 26 Jul 2011 15:35:40 +0300, Eugene V. Lyubimkin jac...@debian.org
wrote:
 One minor detail (for the next upload) I didn't notice before: there is
 no substitution variable '{misc:Pre-Depends}', so you can remove that
 Pre-Depends line of libbs2b0 altogether.

Actually there is, in particular for multiarch support...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: RFS: oss-compat (adoption, updated package)

[Stephen Kitt]

Hi,

On Wed, Jun 08, 2011 at 12:03:24PM +0200, Bruno Kleinert wrote:
 I uploaded the package.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: RFS: oss-compat (adoption, updated package)

[Stephen Kitt]

Hi Sven,

On Wed, Jun 08, 2011 at 12:10:48PM +0200, Sven Hoexter wrote:
 On Wed, Jun 08, 2011 at 01:06:59AM +0200, Stephen Kitt wrote:
  I am looking for a sponsor for the new version 0.0.5 of the package
  oss-compat, which I am adopting within the games team. (I believe this
  makes sense since the main users of the Open Sound System nowadays are old
  Linux games.)
 
 Looks like we've another case of duplicated work here:
 http://packages.qa.debian.org/o/oss-compat/news/20110608T100624Z.html

Not quite, that's my package but with a mixed-up Changed-By (which
should be me) and Maintainer (which should be the games team). See
http://anonscm.debian.org/gitweb/?p=pkg-games/oss-compat.git;a=blob;f=debian/changelog;h=d8b7ea6d6b79bf5125ade0d8f775856d535b40ee;hb=f937da6d054dc2cc29a6605f2abba7ad22a03ae6
for the original changelog!

Regards,

Stephen


-- 
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/20110608115127.gz31...@sk2.org

Re: RFS: oss-compat (adoption, updated package)

[Stephen Kitt]

On Wed, Jun 08, 2011 at 04:22:13PM +0200, Bruno Kleinert wrote:
 What's the best practice to fix things up? Should I bump the debian
 revision of the package and re-upload it? I don't want to be blamed for
 hijacking packages by accident ;)

No hard feelings ;-)

It's a native package, so I suppose either incrementing it to 0.0.6 or
something like 0.0.5+fix would work...

Regards,

Stephen


signature.asc
Description: Digital signature

RFS: oss-compat (adoption, updated package)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the new version 0.0.5 of the package
oss-compat, which I am adopting within the games team. (I believe this
makes sense since the main users of the Open Sound System nowadays are old
Linux games.)

It builds these binary packages:
oss-compat - Open Sound System (OSS) compatibility package

The package appears to be lintian clean.

The upload would fix these bugs: 390747, 594376

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/o/oss-compat
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/o/oss-compat/oss-compat_0.0.5.dsc

It also has a VCS at http://git.debian.org/?p=pkg-games/oss-compat.git

I would be glad if someone uploaded this package for me.

Kind regards
 Stephen Kitt


signature.asc
Description: PGP signature

Re: How are directories managed.

[Stephen Kitt]

On Tue, 12 Apr 2011 17:43:10 +0530, harish badrinath
harishbadrin...@gmail.com wrote:
 On Tue, Apr 12, 2011 at 7:26 AM, Paul Elliott
 pelli...@blackpatchpanel.com wrote:
  This may be a FAQ but I could not find the answer in the documentation:
 
  How are directories managed? When does a directory get deleted? What is
  the lifetime of a directory? Is a directory owned by a specific package?
 
 In case of apache2, config files present in /etc/apache2/ are in
 apache2.2-common package. Removing this package deletes /etc/apache2/
 and all files under it.

Not quite; for instance on this system:
% dlocate -S /etc/apache2 | cut -d: -f1 | sort | uniq
apache2.2-common
dhelp
libapache2-mod-dnssd
libapache2-mod-php5

All four of these packages provide files under /etc/apache2; in addition I've
also added files there (in /etc/apache2/sites-available). /etc/apache2 would
only be automatically removed if, at the time one of the above packages is
removed, the directory is empty.

  Which packages are alowed to deposit files in a specific directory? What
  exactly are the rules?
 
 That is specified in the debian policy.

Right, and as far as I can see pretty much all that says is to follow the FHS,
and avoid attempting to create a directory with the same name as another
package's file or link.

  If a package wants to put files in a directory, how does the package
  know that the directory will live longer than the file?
 
 You cant put files in a directory that does not exist. touch
 /etc/foo/bar would fail if foo does not exist. Also you cant delete a
 non empty directory, so a package can assume that directory will live
 longer than the file(s) that it contain.

Exactly. If a package declares a directory in its contents (as displayed by
dpkg -L for instance), dpkg will create that directory on installation and
remove it if it's empty (after deleting the package's files) on removal. If a
package creates a directory and/or files separately, for example in its
maintainer scripts, then removal has to be handled explicitly in the
maintainer scripts too.

More simply put, the answer to Paul's question is that if the package
declares that it contains the directory, then it can use it - if the package
needs to do something then by definition it's installed and the directory
will exist. (Notwithstanding manual intervention by the system administrator
or dpkg filters.)

Regards,

Stephen


-- 
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/20110412204619.5bd5a...@sk2.org

RFS: joystick (updated package), evtest (new package, split off from joystick)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the new version 1:1.4~rc1-1
of my package joystick, and the new version 1:1.27-1 of my package
evtest (which used to be part of the joystick source but is now maintained
separately upstream).

joystick builds these binary packages:
inputattach - utility to connect serial-attached peripherals to the input
subsystem
joystick   - set of testing and calibration tools for joysticks

evtest builds these binary packages:
evtest - utility to monitor Linux input device events

Both packages appear to be lintian clean (mentors.debian.net issues a
warning about evtest's linux-any architecture but current versions of
lintian accept that).

The upload would fix these bugs: 607009, 616443 (in joystick), 619932, 620943
(in evtest).

The packages can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/j/joystick
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/j/joystick/joystick_1.4~rc1-1.dsc
- URL: http://mentors.debian.net/debian/pool/main/e/evtest
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/e/evtest/evtest_1.27-1.dsc

I would be glad if someone uploaded these packages for me.

Kind regards
 Stephen Kitt


signature.asc
Description: PGP signature

Re: RFS: gdmap (adopting, updated package)

[Stephen Kitt]

Dear mentors,

On Sun, 13 Mar 2011 21:43:39 +0100, Stephen Kitt st...@sk2.org wrote:
 I am looking for a sponsor for the new version 0.8.1-2
 of my package gdmap.
 
 It builds these binary packages:
 gdmap  - Tool to visualize diskspace
 
 The package appears to be lintian clean.
 
 The upload would fix these bugs: 579043, 594406
 
 The package can be found on mentors.debian.net:
 - URL: http://mentors.debian.net/debian/pool/main/g/gdmap
 - Source repository: deb-src http://mentors.debian.net/debian unstable main
 contrib non-free
 - dget http://mentors.debian.net/debian/pool/main/g/gdmap/gdmap_0.8.1-2.dsc
 
 I would be glad if someone uploaded this package for me.
 
 Kind regards
  Stephen Kitt

I'm still looking for a sponsor, I would grately appreciate it if someone
could take a look at this package.

Best regards,

Stephen


signature.asc
Description: PGP signature

Re: RFS: the mingw-w64 toolchain

[Stephen Kitt]

On Sat, 02 Apr 2011 19:18:26 +0200, Ove Kåven o...@arcticnet.no wrote:
 Den 29. mars 2011 01:08, skrev Stephen Kitt:
  In order to upload to Debian, it would theoretically be
  possible to upload mingw-w64 since it's Arch: all, then upload the full
  gcc-mingw-w64 without bootstrapping. Alternatively, bootstrapping the
  toolchain would only require two steps (but with two passages through
  NEW): binutils-mingw-w64, gcc-mingw-w64 in bootstrap mode, mingw-w64 as a
  first step; then gcc-mingw-w64 in full mode (with an incremented version
  number) and wine-gecko-1.0.0.
 
 Well, doesn't look like anybody else has offered to sponsor this yet, so
 I guess I could go for it.

Thanks!

 Which bootstrap strategy would be recommended here?

The first strategy would allow the packages to make their way into the
archive sooner, but I'm not sure what the FTP Masters' reaction would be to a
NEW package relying on an Arch: all package to avoid bootstrapping itself.
In addition to that, given the delays in the NEW queue just now, the second
strategy would probably have the interesting side effect that the bootstrap
packages would make it into the archive around the time Ubuntu unfreezes;
having the bootstrap package at that point would allow the toolchain to be
synced with Ubuntu. (Using the Arch: all shortcut would prevent that since
Ubuntu packages are always rebuilt from source.)

Thus I'd recommend the second strategy.

If the packaging meets your requirements, would it be possible for me to
join the wine party on Alioth and push my package to a git repository there?

Regards,

Stephen


signature.asc
Description: PGP signature

RFS: gcc-mingw32 (NMU, RC bug fix)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the new version 4.4.4-0.2
of the orphaned package gcc-mingw32.

It builds these binary packages:
gcc-mingw32 - The GNU Compiler Collection (cross compiler for MingW32 / MingW64)

The upload would fix these bugs: 618242 (RC, FTBFS).

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gcc-mingw32
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/g/gcc-mingw32/gcc-mingw32_4.4.4-0.2.dsc

I would be glad if someone uploaded this package for me.

Before anyone asks, I don't intend to adopt this package since it's
superseded by mingw-w64 (which is also in need of a sponsor, see my previous
message to debian-mentors). It does need an update though since it's a
build-dependency of a bunch of packages.

Kind regards
 Stephen Kitt


signature.asc
Description: PGP signature

Re: RFS: gcc-mingw32 (NMU, RC bug fix)

[Stephen Kitt]

notfound 618242 4.4.4-0.1
thanks

On Wed, 30 Mar 2011 13:01:51 +0200, Jakub Wilk jw...@debian.org wrote:
 * Stephen Kitt st...@sk2.org, 2011-03-30, 09:49:
 The upload would fix these bugs: 618242 (RC, FTBFS).
 
 Did you check if it still FTBFS? AFAICS the failure what caused by the 
 fact that libgmp3-dev was a virtual package for a while; but it isn't 
 anymore, so gcc-mingw32 should now build fine.

Indeed it no longer FTBFS; the fix was so simple I forgot to check whether it
was actually required...

I'm closing the bug and removing my package from mentors.debian.net.

Regards,

Stephen


signature.asc
Description: PGP signature

RFS: the mingw-w64 toolchain

[Stephen Kitt]

Hi,

It's been a while, but now that gcc-4.5 is in unstable and I've had the
chance to fix various things, I believe the mingw-w64 toolchain is ready for
an initial upload.

As mentioned previously, the initial aim of these packages is to package
wine-gecko and get wine development started up again. Ultimately though I'd
like to be able to replace the various MinGW and MinGW-w64 packages in Debian
(I've discussed this with Ron in the past); I'll be working on getting the
packages which currently build with mingw32 building with mingw-w64 (which,
despite its name, supports 32- as well as 64-bit Windows targets), and
hopefully get an Alioth project going eventually so I can coordinate with
other people (notably Dmitrijs Ledkovs who's been working on the Ubuntu
mingw-w64 all-in-one packages).

I've uploaded all the packages to mentors.debian.net, along with a wine-gecko
package to make sure the result is correct. The DSCs are:
* 
http://mentors.debian.net/debian/pool/main/b/binutils-mingw-w64/binutils-mingw-w64_0.1.dsc
* 
http://mentors.debian.net/debian/pool/main/g/gcc-mingw-w64/gcc-mingw-w64_0.1.dsc
* 
http://mentors.debian.net/debian/pool/main/m/mingw-w64/mingw-w64_1.0+20101003-1.dsc
* 
http://mentors.debian.net/debian/pool/main/w/wine-gecko-1.0.0/wine-gecko-1.0.0_1.0.0+dfsg-1.dsc

The mingw-w64 packaging is also available on collab-maint:
* http://git.debian.org/?p=collab-maint/binutils-mingw-w64.git;a=summary
* http://git.debian.org/?p=collab-maint/gcc-mingw-w64.git;a=summary
* http://git.debian.org/?p=collab-maint/mingw-w64.git;a=summary

Uploading these packages would fix these bugs: 602996, 602997, 569914,
594371, 600451, 479861.

The packages are lintian-clean, albeit with a fair amount of overrides which
are documented in the various packages (mainly related to the cross-compiling
nature of the packages, which thus include binaries in Arch: all packages
and place files in non-FHS-compliant directories). They currently also
generate a warning from dpkg-source since they specify the Built-Using
field. I've built them using an up-to-date unstable pbuilder, and the
resulting wine-gecko package displays Google in Wine's wrapper (and allows
searches etc.).

To build:
* build binutils-mingw-w64 as usual;
* bootstrap gcc-mingw-w64 by linking control to control.bootstrap and
  rules.variant to rules.bootstrap, and building normally;
* build mingw-w64; one of the resulting packages, mingw-w64, will be
  uninstallable for now;
* build the full gcc-mingw-w64 by cleaning the build if necessary and then
  linking control to control.full and rules.variant to rules.full;
* build wine-gecko as usual.

This will produce binutils-mingw-w64, gcc-mingw-w64, mingw-w64-dev, mingw-w64
and wine-gecko-1.0.0 packages. To test wine-gecko you'll need wine 1.2; I can
upload my package to debian.mentors.net if necessary. (An older version is
still on http://www.sk2.org/wine/wine_1.2-0.1.dsc but you'll need to change
the wine control file so the wine package depends on wine-gecko-1.0.0 instead
of wine-gecko.) In order to upload to Debian, it would theoretically be
possible to upload mingw-w64 since it's Arch: all, then upload the full
gcc-mingw-w64 without bootstrapping. Alternatively, bootstrapping the
toolchain would only require two steps (but with two passages through NEW):
binutils-mingw-w64, gcc-mingw-w64 in bootstrap mode, mingw-w64 as a first
step; then gcc-mingw-w64 in full mode (with an incremented version number)
and wine-gecko-1.0.0.

These packages can certainly be improved (for instance, mingw-w64 should be
updated to a later version of the 1.0 branch at least, and include the DDK
headers), but I'd like to get them as-is (or close enough) into Debian if
possible so that Ove Kaaven can get started on his wine improvements ;-).
I'll work on improving mingw-w64 once that's done. It may be worth waiting
for dpkg-dev to support Built-Using for now though, hopefully that won't take
too long!

Note also that I'm a DM, but I don't expect a DMUA on such involved packages
just yet.

Thank you for your time,

Stephen


signature.asc
Description: PGP signature

Re: Git Package Versioning

[Stephen Kitt]

Hi,

On Mon, 21 Mar 2011 06:36:19 +0100, Julien Valroff jul...@debian.org wrote:
  or 1.2.1~gitMMDD.githash-1, which could be read as the 1.2.1
  release currently being prepared, as of git hash ... on MMDD.
 
 Though it is perfectly correct, I try and avoid using this scheme: what
 happens if upstream releases eg. 1.2.1 Beta1 which I would normally version
 as 1.2.1~b1?
 
 Even if contact with upstream are good, the may change their mind. Take
 Firefox 4 which should have been released after the 1st RC… before they
 decide to release a 2nd RC.

Indeed, using 1.2.1~ only makes sense when it is absolutely certain that the
next version will indeed be 1.2.1!

 I think there's no universal answer to the original question, but just
 common sense and good use of `dpkg --compare-versions'.

That's an excellent summary, thanks.

Regards,

Stephen


--
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/20110321220314.688d5...@sk2.org

Re: Git Package Versioning

[Stephen Kitt]

On Sun, 20 Mar 2011 22:25:38 +0100, Joachim Wiedorn ad_deb...@joonet.de
wrote:
 Julien Valroff jul...@debian.org wrote on 2011-03-20 21:48:
 
  The best I have found is to use something like:
  latest_upstream_release+gitMMDD.githash
 
 Please be aware, that + is not the optimal connector.
 Try dpkg --compare-versions and see:
 
 a)   1.2.0  is less than  1.2.0+git2011
 
 b)   1.2.0  is greater than  1.2.0~git2011
 
 The version b) is the better way. So please use ~ 
 as connector.

Except that Julien did mention using the latest upstream release version,
which implies that the git hash is later than the upstream release, so '+' is
correct... Here's an example with a timeline:

  |
  |  1.2.0 is released (if packaged, version 1.2.0-1 or whatever)
  |
  |  new Debian package version, including git changes since 1.2.0
  |
  |  1.2.1 is released
  |
  V

In this example, the Debian package version could be either
1.2.0+gitMMDD.githash-1, which could be read as everything in the
1.2.0 release plus all changes since, up to git hash ... on MMDD, or
1.2.1~gitMMDD.githash-1, which could be read as the 1.2.1 release
currently being prepared, as of git hash ... on MMDD. Which you choose
would depend on whether you're packaging the release plus some fixes, or
you're packaging a preview of the next release...

Regards,

Stephen


-- 
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/20110320231647.13dc6...@sk2.org

Re: RFS: mail-notification (RC bug fix, NMU with maintainer's approval)

[Stephen Kitt]

Hi Sven,

On Mon, 14 Mar 2011 20:26:23 +0100, Sven Hoexter s...@timegate.de wrote:
 On Sun, Mar 13, 2011 at 11:36:30PM +0100, Stephen Kitt wrote:
  I am looking for a sponsor for the new version 5.4.dfsg.1-2.4
  of my package mail-notification. This is an NMU approved by LUI Qi, the
  current maintainer.
 
 Uploaded. I hope it works cause I can't test the evolution part ...

Thanks! I did make a point of testing mail-notification with evolution 2.32
before uploading the package to mentors.debian.net, and it works fine at
least on my machine.

 Please consider
 a) setting up a team VCS so that you can co-maintain it properly

Qi has taken care of that already, we haven't had time to get organised
properly yet.

 and
 b) forking it with some people from other distros to handle the growing
patchset in a more pleasant way. 

I had thought of that too, I'll at least try to get in touch with Jean-Yves
Lefort (the original upstream author).

 Usually I would offer help at least for a) but I'm busy and/or offline for
 the next weeks.

No problem, it won't be necessary this time round!

Regards,

Stephen


signature.asc
Description: PGP signature

RFS: gdmap (adopting, updated package)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the new version 0.8.1-2
of my package gdmap.

It builds these binary packages:
gdmap  - Tool to visualize diskspace

The package appears to be lintian clean.

The upload would fix these bugs: 579043, 594406

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gdmap
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/g/gdmap/gdmap_0.8.1-2.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Stephen Kitt


signature.asc
Description: Digital signature

RFS: mail-notification (RC bug fix, NMU with maintainer's approval)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the new version 5.4.dfsg.1-2.4
of my package mail-notification. This is an NMU approved by LUI Qi, the
current maintainer.

It builds these binary packages:
mail-notification - mail notification in system tray
mail-notification-evolution - evolution support for mail notification

The package appears to be lintian clean.

The upload would fix these bugs: 547287, 617771; the latter is RC. The former
is fixed incidentally by the patch provided by Michel Dänzer for the RC bug.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/mail-notification
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/m/mail-notification/mail-notification_5.4.dfsg.1-2.4.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Stephen Kitt


signature.asc
Description: PGP signature

Re: RFS: mail-notification (updated package)

[Stephen Kitt]

On Tue, 1 Mar 2011 23:03:33 +0100, Sven Hoexter s...@timegate.de wrote:
 On Mon, Feb 28, 2011 at 01:15:17AM +0100, Stephen Kitt wrote:
  Note that I should soon be a DM, so if you do sponsor my package and deem
  it appropriate, I'd appreciate a DMUA field. (This is my third NMU of this
  package; I'll gladly adopt it once it's orphaned.)
 
 Without some more details this looks rather strange. What's up with the
 current maintainer? Is there some agreement that he'll orphan the package?
 Oh and for a NMU at least the RC bug should've the diff attached and a
 message that you plan to NMU etc.

As far as I'm aware LUI Qi is MIA (mia have been notified), but the package
hasn't been QA-orphaned yet. I did contact the maintainer regarding possible
co-maintainership a while ago, after Sandro Tosi suggested it (see the thread
starting at http://lists.debian.org/debian-mentors/2010/05/msg00387.html).

I've added the NMU diff to the bug.

 Beside that do you know what's the state of all those patches upstream?
 The 'mail-notification' project on launchpad has some 4.0 version from 2010
 while the mailnotify page on nongnu.org (from the same author) holds a
 version 5.4 from 2008 which seems to be what's in the Debian package.

There is no upstream any more, the package is kept alive by various people
and the patches float around Ubuntu, Fedora and the Debian BTS. 5.4 is the
last upstream release, version 4.0 as available on launchpad is the same as
the January 2007 release available from nongnu.org.

Regards,

Stephen


-- 
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/20110302092540.719bd...@sk2.org

RFS: mail-notification (updated package)

[Stephen Kitt]

Dear mentors,

I am looking for a sponsor for the new version 5.4.dfsg.1-2.3
of my package mail-notification.

It builds these binary packages:
mail-notification - mail notification in system tray
mail-notification-evolution - evolution support for mail notification

The package appears to be lintian clean.

The upload would fix these bugs: 549057 (RC). It would also fix compilation
issues with the versions of gcc/binutils and evolution-data-server currently
in unstable.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/mail-notification
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/m/mail-notification/mail-notification_5.4.dfsg.1-2.3.dsc

I would be glad if someone uploaded this package for me.

Note that I should soon be a DM, so if you do sponsor my package and deem it
appropriate, I'd appreciate a DMUA field. (This is my third NMU of this
package; I'll gladly adopt it once it's orphaned.)

Kind regards
 Stephen Kitt


signature.asc
Description: PGP signature

RFS: jstest-gtk

[Stephen Kitt]

Dear mentors and games team,

I am looking for a sponsor for my package jstest-gtk.

* Package name: jstest-gtk
  Version : 0.1.1~git20090722-1
  Upstream Author : Ingo Ruhnke grum...@gmx.de
* URL : http://pingus.seul.org/~grumbel/jstest-gtk/
* License : GPL-3+
  Section : utils

It builds these binary packages:
jstest-gtk - joystick testing and configuration tool
jstest-gtk-dbg - joystick testing and configuration tool - debug

The package has no lintian errors or warnings; it does have some info and
pedantic-level issues, the most severe of which in my mind is the lack of
descriptions in the patches (although they're all very short and
straightforward which is why I haven't fixed them before requesting a
sponsor).

The upload would fix these bugs: 527962

My motivation for maintaining this package is that this is an ideal
complement to the joystick package which I already maintain: joystick
provides command-line tools to manage joysticks, including calibrating them
and remapping their axes and buttons, and jstest-gtk provides a more
user-friendly graphical interface to the same functions.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/j/jstest-gtk
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/j/jstest-gtk/jstest-gtk_0.1.1~git20090722-1.dsc

The packaging is largely to be credited to Miriam Ruiz.

I would be glad if someone uploaded this package for me.

Kind regards
 Stephen Kitt


signature.asc
Description: PGP signature

Re: RFS: jstest-gtk

[Stephen Kitt]

On Thu, 24 Feb 2011 00:22:06 +0100, Miriam Ruiz mir...@debian.org wrote:
 I will review and uload it :)

Great, thanks! I forgot to mention my key should soon appear in the
debian-maintainers keyring, so if you reckon it's appropriate there's also
the possibility of adding a DMUA field.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)

[Stephen Kitt]

On Fri, 17 Dec 2010 14:45:06 +0100, Matthias Klose d...@debian.org wrote:
 On 11.12.2010 17:40, Stephen Kitt wrote:
  I imagine this could mean that the gcj and gnats builds don't use the
  patches in the gcc-4.x-source package, and only use the tarball which
  won't change from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2
  etc.)...
 
 yes.
 
  That
  seems a shame to me since the patches are useful, and it still leaves the
  problem of having a package build using gcc-4.5-source 4.5-1 for example,
  and then gcc-4.5-source being replaced with version 4.5.1-1 with a new
  tarball.
 
 no, the tarball doesn't change. it's in the .orig.tar.gz. all other 
 patches/packging are synced with the gcc-4.5 package. Nothing is lost, all 
 patches are applied.

I must be misunderstanding something here then:
% dpkg-deb -c gcc-4.5-source_4.5.0-10_all.deb|grep tar
-rw-r--r-- root/root  52023076 2010-04-14 13:56 
./usr/src/gcc-4.5/gcc-4.5.0-dfsg.tar.xz
% dpkg-deb -c gcc-4.5-source_4.5.1-1_all.deb|grep tar
-rw-r--r-- root/root  52073572 2010-07-31 16:20 
./usr/src/gcc-4.5/gcc-4.5.1-dfsg.tar.xz
% dpkg-deb -c gcc-4.5-source_4.5.1-12_all.deb|grep tar
-rw-r--r-- root/root  52073572 2010-07-31 16:20 
./usr/src/gcc-4.5/gcc-4.5.1-dfsg.tar.xz
% dpkg-deb -c gcc-4.5-source_4.5.2-1_all.deb|grep tar
-rw-r--r-- root/root  52182428 2010-12-18 13:38 
./usr/src/gcc-4.5/gcc-4.5.2-dfsg.tar.xz

Surely depending on when something build-depending on gcc-4.5-source is
built, it might be built using gcc-4.5.0-dfsg.tar.xz, but not necessarily
rebuilt with one of the later tarballs? Once gcc-4.5-source_4.5.1-1_all.deb
is uploaded and gcc-4.5-source_4.5.0-10_all.deb disappears from the archive,
it would require a binNMU at least to make sure the depending packages use
the source available in Debian, wouldn't it?

  The other solution based on Marcin's work, which is also readily
  supported by the existing -source packages, requires that the target
  architecture be understood by dpkg (as pointed out by Dmitrijs); that may
  be a worthwhile goal, notably since it solves the problem of how to
  provide build packages for the various libraries people find useful, but
  it's a much longer-term goal as far as I can see...
 
 otoh, this approach breaks more often with updates on patches and
 packaging. Manageable however.

Yup, as long as the downstream maintainers are on the ball, it should be OK!
The nice thing for you of course is that it means the gcc packaging gets even
more tests.

Regards,

Stephen


-- 
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/20101219101640.69aaa...@sk2.org

Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)

[Stephen Kitt]

On Sat, 11 Dec 2010 17:28:10 +1030, Ron r...@debian.org wrote:
 On Fri, Dec 10, 2010 at 10:29:24PM +0100, Matthias Klose wrote:
  On 23.11.2010 12:49, Dmitrijs Ledkovs wrote:
  debian-gcc is a bit specific to the native libc based toolchains and
  cross-toolchains using libc. I didn't manage to find an easy place to
  plugin mingw-w64 bootstrap into that packaging.
  
  You might want to have a look at Marcin's cross-build packages,
  using the gcc-, binutils- and eglibc- source packages.
 
 I wasn't aware of Marcin's work, but I also agree this is probably
 the best avenue to explore if these are all building from identical
 source.  I believe Robert's original attempt even did exactly this,
 and I tried to point Stephen in this direction too when he first
 contacted me, but I think that point got lost, and I got too busy
 to point again in more detail immediately.

I'm not sure whether it got lost or not, my packages (with Dmitrijs'
contributions) currently build-depend on binutils-source and gcc-4.5-source
and avoid duplicating anything from the original binutils and gcc packages; in
fact I went to some effort (see my bug reports against gcc-4.5-source, now
resolved) to make sure the resulting packages would not only use the tarballs
provided in the -source packages but also apply any relevant patches.

 AIUI, the main problem with this is that the distro archive tools
 currently don't have good support for ensuring these 'binary' -source
 packages will remain available and linked to the derivative binary
 debs that might be built from them and uploaded to the distro.
 
 I believe ftp-master indicated to Robert that this could be fixed,
 but he went back to the quick and dirty duplication instead.  If
 there are people with time to spend on this, talking to the archive
 maintenance people about what needs to be done for that, and when
 and how it might happen, is probably a productive step at this point.

Indeed; I'm not sure what Matthias means by

On Fri, Dec 10, 2010 22:29:24 +0100, Matthias Klose d...@debian.org wrote:
 this is already guaranteed by the gcj and gnat builds by only relying on
 the tarball in the gcc-4.x-source package.

I imagine this could mean that the gcj and gnats builds don't use the patches
in the gcc-4.x-source package, and only use the tarball which won't change
from one Debian version to another (e.g. 4.5.1-1 to 4.5.1-2 etc.)... That
seems a shame to me since the patches are useful, and it still leaves the
problem of having a package build using gcc-4.5-source 4.5-1 for example, and
then gcc-4.5-source being replaced with version 4.5.1-1 with a new tarball.

Matthias, is that what you meant?

I'll take it up with ftpmaster as you suggest, Ron!

The other solution based on Marcin's work, which is also readily supported by
the existing -source packages, requires that the target architecture be
understood by dpkg (as pointed out by Dmitrijs); that may be a worthwhile
goal, notably since it solves the problem of how to provide build packages
for the various libraries people find useful, but it's a much longer-term
goal as far as I can see...

Regards,

Stephen


-- 
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/20101211174005.3ea56...@sk2.org

Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)

[Stephen Kitt]

Hi Jonathan,

(I'll reply separately to the remaining points from your earlier
email.)

On Tue, Nov 23, 2010 at 04:17:32AM -0600, Jonathan Nieder wrote:
  mingw-w64 do all they work upstream. All patches that were created
  mingw-w64 project are applied directly to binutils and gcc head.
 
 That's great.  One possibility in the long run might be to package
 this as part of the usual gcc and binutils packages, then.

Yes, that would definitely be a possibility, in the same vein as the
existing -hppa64 and -spu packages. It would add an odd
build-dependency on gcc though (mingw-w64-dev), which might not sit
too well with some people!

  Any examples for how this can be used directly?  e.g., can simple
  Windows toys in assembler be compiled this way, and can it help with
  analyzing binaries from such systems?
 
  The following projects (taken from mingw-w64 website) confirmed using
  ming-w64 based toolchain to provide windows releases:
 
 Mm, that answers a different question.  What I meant is, is a copy
 of binutils-mingw without gcc useful for anything?
 
 Analogy: ordinary binutils without gcc is useful for:
 
  - compiling firmware and simple binaries written in assembler
 
  - objdump (see http://bugs.debian.org/19471)

A number of binutils tools are useful without gcc when working with
Windows executables: objdump, windmc, windres, dlltool at least. ld is
also useful when working with assembly code, gas less so since most
such code targets NASM or MASM in the Windows world.

  * gcc-mingw-w64, a more complex gcc-4.5-source-based package providing gcc
    targetting MinGW-w64's triplets;
 
  I don't remember how far the dak work has proceeded in supporting this. :(
 
  How is dak involved? This will be just a regular binary deb package.
 
 In the past people have proposed additional packages like gcc-mips
 depending at build time on the gcc-source binary package.  This way,
 the archive would only need two copies (the .orig.tar.gz and the .deb)
 of the gcc source, and variants building separately could reuse that.
 
 The problem with that it required separate work to follow the GPL.
 Normally the archive software guarantees that (1) the precise source
 package used to build each binary package is available and (2) the
 build-time dependencies for packages in main are available in some
 version from the Debian archive.  So after building gcc-mips,
 gcc-source could be updated, and the result would be that gcc-mips
 binaries were available for download but the exact corresponding
 source would not be.  Avoiding this required some manual configuration
 and there were some thoughts about how to make it automatic.

I see... gcc-avr is in the archive and depends on gcc-4.3-source, so
there is a precedent (which is why I pursued this idea). Do you reckon
this would be a problem when it comes to getting gcc-mingw-w64 into
the archive?

There is another advantage to build-depending on gcc-4.5-source: in
addition to reducing the storage requirements, we also automatically
benefit from the various patches in the Debian package (and any future
updates).

What manual configuration is involved?

  . It would be simpler to have only one debian/rules file, with a
   makefile variable to control which packages get built.  See the
   binutils package for an example.
 
  . debian/rules is allowed to generate debian/control, so one would only
   need one starting debian/control for this.  See the binutils package
   for an example.

I know it's possible to do this, but in gcc-mingw-w64's case the build
dependencies change, so generating debian/control from debian/rules
doesn't work. Using a symlink to fix this seemed OK to me, and once
control is a symlink, rules might as well use one too; I didn't think
it would necessarily be a good idea to have two different setups to
think about when bootstrapping the package (symlink control and set a
Makefile variable).

In addition, how would the use of a Makefile variable work on the
buildds?

I'm adding a shell script to automate the operations involved in
bootstrapping the gcc package though, it's in the git repository.

Thanks for taking the time to look into all this!

Regards,

Stephen


-- 
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/20101123105501.gg9...@sk2.org

Re: [Mingw-w64] RFC: MinGW-w64 toolchain (adoption and new packages)

[Stephen Kitt]

(For anyone else following, see the other subthread too.)

On Mon, Nov 22, 2010 at 05:22:41PM -0600, Jonathan Nieder wrote:
  Building the packages is slightly involved:
  1. Build binutils-mingw-w64 and install it.
 
 So the first step could be to get this package alone in Debian.

Indeed, although the bootstrap gcc package could be uploaded
simultaneously.

  binutils has manpage errors and spelling errors in its binaries, none of
  which I thought really warranted fixing (especially since they're all in
  binutils-source anyway).
 
 Please feel free to file a bug, especially if you have time to write a
 patch.

I did intend to, I'm checking which errors are still present in the
experimental binutils source.

  * copyright-refers-to-symlink-license: this is part of debian/copyright 
  which
is reproduced from gcc-4.5-source's, and justified IMO; the
version-specific licence symlink follows it immediately;
 
 Perhaps this is worth a bug on the lintian package?

Yup, I'll file one...

  mingw-w64 has a ton of warnings, all instances of non-standard-dir-in-usr or
  file-in-unusual-dir because it ships its headers and libraries
  in /usr/$target/{include,lib}.
 
 Sounds like a lintian bug.

Probably not, since the directories aren't FHS-compliant. As far as
I'm aware though there isn't an agreed-upon FHS-compliant directory
structure for cross-compilers; you'd know more about that than me,
given your existing involvement with the toolchain!

Regards,

Stephen


-- 
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/20101123110035.gh9...@sk2.org

RFC: MinGW-w64 toolchain (adoption and new packages)

[Stephen Kitt]

Dear mentors,

I'm working on packaging a new version of the MinGW-w64 toolchain, which
allows 32- and 64-bit Windows software to be compiled as a cross-compiler
target using gcc. This all started with the requirement for a new version of
gcc and MinGW-w64 to build wine-gecko, the browser engine used by Wine, but
MinGW-w64 is more than just a build dependency for Wine.

The way I've packaged the toolchain so far involves three packages:
* binutils-mingw-w64, a simple binutils-source-based package providing
  binutils targetting MinGW-w64's triplets;
* gcc-mingw-w64, a more complex gcc-4.5-source-based package providing gcc
  targetting MinGW-w64's triplets;
* mingw-w64, the MinGW-w64 development headers and libraries.

MinGW-w64 now has its own official triplets, differing from MinGW's which are
what had been used so far in Debian with the gcc-mingw32 and co. packages.
This is why new packages are needed; upstream would also like it to be clear
these are MinGW-w64 packages and not MinGW (formerly MinGW32) packages.

Everything is available at http://www.sk2.org/mingw-w64, along with a
wine-gecko package which allows the toolchain to be tested.
binutils-mingw-w64 and mingw-w64 are also on mentors.debian.net, but
gcc-mingw-w64 and wine-gecko won't upload for some reason. The DSCs are
* http://www.sk2.org/mingw-w64/binutils-mingw-w64_2.20.1-1.dsc
* http://www.sk2.org/mingw-w64/gcc-mingw-w64_4.5.1-1.dsc
* http://www.sk2.org/mingw-w64/mingw-w64_1.0+20101003-1.dsc
* http://www.sk2.org/mingw-w64/wine-gecko-1.0.0_1.0.0+dfsg-1.dsc

The first three are also hosted on Alioth:
* http://git.debian.org/?p=collab-maint/binutils-mingw-w64.git;a=summary
* http://git.debian.org/?p=collab-maint/gcc-mingw-w64.git;a=summary
* http://git.debian.org/?p=collab-maint/mingw-w64.git;a=summary

Building the packages is slightly involved:
1. Build binutils-mingw-w64 and install it.
2. Extract gcc-mingw-w64, and change the debian/control and
   debian/rules.variant links so they point to debian/control.bootstrap and
   debian/rules.bootstrap respectively.
3. Build gcc-mingw-w64 and install the resulting gcc-mingw-w64-bootstrap
   package.
4. Build mingw-w64 and install the resulting mingw-w64-dev package.
5. Return to the gcc-mingw-w64 folder, and clean the build
fakeroot debian/rules clean
6. Change the debian/control and debian/rules.variant links so they point to
   debian/control.full and debian/rules.full.
7. Build gcc-mingw-w64.

Note that since mingw-w64-dev is Architecture: all, this should only be
required to prepare the first upload. Once the packages are in Debian, future
versions will be easier to build! Also note that while this bootstrapping
sequence follows the existing Debian packaging structure, with separate
binutils, gcc and mingw packages, Dmitrijs Ledkovs (who is assisting me
with this packaging effort) has an alternative scheme with a single
self-bootstrapping package at https://launchpad.net/~mingw-w64

As far as Lintian is concerned, all the packages have a number of warnings.
binutils has manpage errors and spelling errors in its binaries, none of
which I thought really warranted fixing (especially since they're all in
binutils-source anyway). gcc emits the following:
* debian-control-file-is-a-symlink: this is done on purpose, to make
  bootstrapping easier; once the first upload is in Debian the symlink can be
  removed (while preserving the bootstrap files for documentation purposes
  and should they ever become necessary in the future again);
* copyright-refers-to-symlink-license: this is part of debian/copyright which
  is reproduced from gcc-4.5-source's, and justified IMO; the
  version-specific licence symlink follows it immediately;
* binary-without-manpage: on the todo list, although it doesn't seem
  particularly urgent to me; should MinGW-w64-specific manpages be provided,
  or would it do to just symlink the (old) gcc manpages?
mingw-w64 has a ton of warnings, all instances of non-standard-dir-in-usr or
file-in-unusual-dir because it ships its headers and libraries
in /usr/$target/{include,lib}. I'm not sure what (if anything - the existing
packages in Debian do this too) should be done about this.

gcc-mingw-w64 will eventually be split up, to provide smaller packages
providing the various compilers, headers and libraries in a similar fashion
to the mainline gcc package. For now it's a single package to make
bootstrapping easier.

The aim of this email is primarily to get feedback on the general approach
and any specific issues with the packages themselves. Obviously if the
packages are deemed upload-worthy and a sponsor volunteers I won't complain
though!

As far as the variety of MinGW packages in Debian is concerned, the plan is
as follows:
* this set of packages should allow Robert Millan's set of (orphaned)
  packages to be dropped entirely (this is gcc-mingw32 and the packages
  formerly built by mingw-w64);
* once the packages have been tested in actual use, we'll determine with 

Re: RFS: stella (updated package, adoption)

[Stephen Kitt]

Hi Piotr,

On Tue, 13 Jul 2010 10:51:29 +0200, Piotr Ożarowski pi...@debian.org wrote:
 I'm interested in sponsoring stella, but I don't understand why you CCed
 debian-mentors - is that Debian Games Team policy? If not, are you DGT
 member? If not, why DGT is in Maintainer field?

I'm not sure whether it's DGT policy, but it seems fairly common practice. I
also did it just to cast a wider net... I am a DGT member, that is why DGT is
in the Maintainer field (I'd rather have the package team-maintained, even if
in practice most DGT packages have a single actual maintainer).

 [Stephen Kitt, 2010-07-13]
  I am looking for a sponsor for the new version 3.1.2-1
  of my package stella.
 
 please mention that you adapt the package, I was close to skip this
 one after noticing how many previous sponsors this package had.

Sorry, I mentioned it in the subject but forgot to mention it in the body of
the email.

Regards,

Stephen


--
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/20100713133101.39ef6...@sk2.org