Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Adam Borowski]

On Fri, Jul 08, 2016 at 09:42:10AM +, Gianfranco Costamagna wrote:
> control: owner -1 x...@debian.org

Sounds more like "close" to me...


> >lowNMU is not meant for hostile takeovers of the package, ok?! =)
> 
> sure, this is why  only one NMU was done on your package :)

I'd guess the problem here is that continuing after this issue was flagged
certainly didn't send a message that a next NMU won't be done.


> >And I have accepted some patches from you, not all, and I did respond
> >to you about that.
> >
> >The urgency about the updates and fixes, for the issues that you
> >yourself raise, are a bit self-inflicted. Maybe I am wrong, but
> >certainly, there isn't an immediate needs to NMU this package.
> 
> the copyright issues seems to be a policy violation, and this is what
> I'm mostly concerned about (I asked to make them RC, but you are of course
> free to disagree/downgrade)

Might be RC but certainly isn't urgent.  I don't see Nicholas pointing any
of the upstream changes as immediately important (and I _do_ read
linux-bt...@vger.kernel.org); debian/copyright changes are hardly ever
time-sentitive too.

Especially that the proposed new contents of debian/copyright is, IMHO,
containing far more inaccuracies than the old one did.


Meow!
-- 
An imaginary friend squared is a real enemy.

Re: wrong version number ?

[Adam Borowski]

On Thu, Jul 07, 2016 at 08:01:03PM +, Gianfranco Costamagna wrote:
> I guess a filename containing ":" character might be problematic in linux
> (not techically problematic, but better to avoid escapes)

: is AFAIK supported by all Linux filesystems, although in some cases it
comes at the cost of breaking the official spec (iso9660 variants).

On the other hand, it drastically breaks interoperability with Windows, and
there's quite a few scenarios where users may want to carry .debs either
through a Windows system (for example due to lacking means to download a
file) or over media that's accessed from Windows (CD, USB stick).

-- 
An imaginary friend squared is a real enemy.

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Adam Borowski]

Hi!

On Fri, Jul 01, 2016 at 08:16:14AM -0400, Nicholas D Steeves wrote:
> I am looking for a sponsor for this update of "btrfs-progs".

Have you coordinated with Dimitri?  When the regular maintainer is active,
NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
of random sponsors, I'd suggest letting him do uploads.

As you've helped with this package before, perhaps it might be good to
consider co-maintenance?


>   * Fix serious errors in debian/copyright.  This is not a GPL2+ package.
> Cme was used to generate a machine-readable copyright file, then

I'm afraid the new debian/copyright is a good deal _worse_ than before.

For example, you claim there's a file under GPL3, which would make the
package undistributable.  That file's license would be GPL3+ (not =3),
still bad, if not for an exception "... you may include it under the same
distribution terms that you use for the rest of that program".  Ie, GPL2.

Except for some specific projects with tightly controlled copyright notices,
Cme produces output indistinguishable from noise.  And knowingly providing
obviously incorrect copyright data is bad.  This Cme-produced output claims
every file has a single copyright holder who last touched the file years
ago -- easily disproven by "git log" on any file I looked at.

And btrfs-progs is a massively cooperative project, with a core gang each of
whom holds copyright to most of files (or rather, their companies do -- but
those change) and a gaggle of minor contributors (including you and me).

Thus, I see two alternatives:
* you do a massive work of archeology on every file to find the set of
  copyright holders.  Every file will have a long list.
* a blanket statement, listing maybe some major holders but with a stress on
  "and others".

I'd say the important points to convey are "1. many contributors, 2. GPL2".


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#829692: RFS: libu2f-host/1.1.2-0.1 [NMU] -- library for Universal 2nd Factor

[Adam Borowski]

On Tue, Jul 05, 2016 at 01:59:59PM +0200, Nicolas Braud-Santoni wrote:
> 
> I am looking for a sponsor for a NMU to the package libu2f-host.
> 
>  * Package name: libu2f-host
>Version : 1.1.2-0.1

> The proper maintainer of the package seems unresponsive, and 2 RC bugs
> (FTBFS) were previously fixed by codehelp and myself after sitting
> without acknowledgment for a month.

Appears to be good, uploaded.
Thanks for your work!

-- 
An imaginary friend squared is a real enemy.

Re: Bug#829605: RFS: aspell-sk/2.02-0-0.1 [RC, NMU]

[Adam Borowski]

On Tue, Jul 05, 2016 at 02:28:30PM +0200, Pali Rohár wrote:
> On Tuesday 05 July 2016 01:17:39 Jakub Wilk wrote:
> > Did you need to do any packaging changes to update S-V?
> > I wouldn't recommend updating S-V in an NMU.
> 
> Well, Debian has in archives very old (maybe prehistoric) version of 
> aspell-sk package. I reported this problem in bug 603719 in past *six* 
> years ago and everybody in Debian ignored it, current maintainer too.
> 
> And now when I saw that aspell-sk package is going to be removed from 
> Debian, I updated compat level and thought that bringing new version 
> should be done too...

The package hasn't been updated since 2005, despite upstream being alive.
I'd say it's hijack time (or, if you prefer a veneer of propriety, orphaning
then adopting 20 minutes later).

-- 
An imaginary friend squared is a real enemy.

Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library

[Adam Borowski]

On Fri, Jun 24, 2016 at 04:06:28PM +0200, Nicolas Braud-Santoni wrote:
> Note that the version number changed: it was following a previous
> UNRELEASED version, which could have led to it being preferred to
> a later release from the maintainer.

I'm afraid that your upload removes data about an upload from the changelog:

.--
libu2f-host (1.0.0-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Switch from libjson0-dev to libjson-c-dev (Closes: #815413)

 -- Neil Williams   Sun, 21 Feb 2016 11:52:27 +
`

which you overwrite with:

.--
libu2f-host (1.0.0-1+nmu1) unstable; urgency=medium

  * Non-maintainer upload.
  * Fix dependencies (libjson & glib2.0) (Closes: #820686).

 -- Nicolas Braud-Santoni   Wed, 01 Jun 2016 23:55:05 
+0200
`

Your only actual change is adding libglib2.0-dev to Build-Depends.

Also, your version number is bad for a non-native package: it should be
1.0.0-1.2.

Last but not least:
$ dpkg --compare-versions 1.0.0-1.1 lt 1.0.0-1+nmu1;echo $?
1
ie, your version number is actually less than what's in the archive.


Otherwise, it builds correctly now.


Meow!
-- 
An imaginary friend squared is a real enemy.

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

[Adam Borowski]

On Wed, Jun 22, 2016 at 06:54:38AM +, Gianfranco Costamagna wrote:
> >The changes I have quoted above are not usually appropriate for NMUs.
> >
> >In this case, it looks like those package maintainers are inactive (no
> >uploads since 2005).  You should contact the MIA team to have the
> >package orphaned.
> 
> well, the package hasn't been touched in over a decade, so I presume
> it might be fine to upload the fixes in deferred/15, even as NMU.
> I guess they had *all* the time to refactor the package, and update it.
> 
> I'm ccing them both, and a member of MIA team, even if I'm unsure about the
> MIA process for non DD people,

The MIA database does contain information about everyone, any DD can query it:
 ssh qa.debian.org /srv/qa.debian.org/mia/mia-query jesus.clim...@hispalinux.es
 ssh qa.debian.org /srv/qa.debian.org/mia/mia-query pe...@p12n.org

As activity-pgp is Dec 2006 and Apr 2013 respectively, both of them are
pretty thoroughly inactive.  I've thus pushed the big "O" button and filed
#827890.

> So, I think the particular bug can be fixed only with a package refactor, and
> I don't want to throw away half of your work just because of policy, in case
> of a package *clearly* unmaintained since 11 years.

With the package freshly orphaned, it's a matter of a QA upload or adoption.
We're in salvage not hijack land...


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826986: marked as done (RFS: faba-icon-theme/4.1.2-1 ITP)

[Adam Borowski]

On Tue, Jun 21, 2016 at 09:46:26PM +0100, foss.freedom wrote:
>   I've corrected the Vcs fields in our budgie-remix debian source repo -
> https://github.com/budgie-remix/faba-icon-theme/tree/debian
> 
> If you want me to-do another RFS/ITP happy to-do so.  Alternatively when
> the upstream maintainer releases a new version of faba-icon-theme then I'll
> RFS/ITP this new version with the corrected vcs fields.

I see that upstream is moving pretty fast, so the second option sounds
better to me.  So let's wait for an upload with some meaningful changes,
like a new upstream version.

-- 
An imaginary friend squared is a real enemy.

Bug#827487: bytes-circle_2.2-1_amd64.changes REJECTED

[Adam Borowski]

On Tue, Jun 21, 2016 at 09:38:46AM +0200, Roberto S. Galende wrote:
> Hi Adam,
> It appears as just amd64, when it's marked "any", but I don't know if it'll
> be compiled for other architectures or I'm just too impatient :-)

It will, you can watch the current progress, failures and logs at:
https://buildd.debian.org/status/package.php?p=bytes-circle=unstable

Debian is currently moving towards source-only uploads, but at the moment
binaries of at least one architecture are still required for NEW packages. 
This is bad, as I could have snuck some nefarious code through, be it
accidentally (like, via having an experimental or out-of-Debian compiler or
a library installed) or to subvert security.  Sure, it is possible to sneak
something nasty in the source (the Underhanded C Contest has some nice ideas
how, even in face of thorough review) but it's MASSIVELY easier to do it
undetected by uploading a binary that doesn't correspond to the source. 
Thus, you have no assurance bytes-circle:amd64 is untainted.

Any subsequent uploads can be source-only.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826769: RFS: arc-theme/20160605-1 ITP

[Adam Borowski]

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

On Wed, Jun 08, 2016 at 09:05:54PM +0100, foss.freedom wrote:
>   I am looking for a sponsor for my package "arc-theme"
> 
>  * Package name: arc-theme
>Version : 20160605-1

Two minor issues:

W: arc-theme: description-synopsis-starts-with-article

Vcs-Browser points to upstream rather than debianisation (like in your two
other packages).


Otherwise, everything seems fine.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826974: RFS: moka-icon-theme/5.3.2-1 ITP

[Adam Borowski]

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

On Fri, Jun 10, 2016 at 08:18:12PM +0100, foss.freedom wrote:
>   I am looking for a sponsor for my package "moka-icon-theme"
> 
>  * Package name: moka-icon-theme
>Version : 5.3.2-1
> 
> moka-icon-theme - Moka Icon Theme

First, please run lintian on the package.  It currently returns:
E: moka-icon-theme: copyright-should-refer-to-common-license-file-for-gpl
E: moka-icon-theme: description-is-pkg-name Moka Icon Theme

The Vcs-Browser needs to point to a VCS of the packaging rather than the
upstream code.  The VCS might contain just the debian/ dir or everything
-- a ready-to-build source package.  If you haven't used git for packaging,
please delete the field.

debian/rules contains:
override_dh_auto_install:
--sourcedir=Moka
which has no effect.  Not sure what you intended to do here; this paragraph
can be safely deleted.


>From minute differences I noticed in a few places, I see logos included in
this package were drawn by hand by the author rather than copied exactly. 
However, they are still derived from the originals.  Copying by wetware is
still copying.  This package includes a massive number of icons for various
software and companies, both free and non-free.  I'm not sure what the exact
rules are: faenza was forced to remove most logos, yet I see those in a
number of other packages.  I guess it's up to ftpmasters to decide.

Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#826986: marked as done (RFS: faba-icon-theme/4.1.2-1 ITP)

[Adam Borowski]

On Tue, Jun 21, 2016 at 03:00:05AM +, Debian Bug Tracking System wrote:
> Looks good, uploaded.

One minor issue I noticed too late:
the Vcs-Browser field should point to a repository containing the Debian
packaging, rather than just the upstream code.  The latter may be put into
debian/upstream/metadata which you already included.

Thus, if you have your packaging in git, please point both Vcs-Git and
Vcs-Browser to it.  Otherwise, delete the field.

-- 
An imaginary friend squared is a real enemy.

Bug#827487: bytes-circle_2.2-1_amd64.changes REJECTED

[Adam Borowski]

On Mon, Jun 20, 2016 at 07:34:54PM +0200, Roberto S. Galende wrote:
> I've updated license in source code and
> also at github.com to match it, with "GPL v3 or higher".

Where may I get the updated package?  I see nothing on mentors.debian.net.

> I'd update the man page with very few mathematical details (hope this
> doesn't disturb the process).

Feel free to make any updates you want, man page changes are among least
intrusive ones.  And in general, the more documentation, the better.

Feel free to make any updates other than man page, too -- some extra review
churn is a good price to pay for having better quality packages.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#827487: bytes-circle_2.2-1_amd64.changes REJECTED

[Adam Borowski]

On Mon, Jun 20, 2016 at 08:00:20AM +, Thorsten Alteholz wrote:
> Hi Roberto,
> 
> shouldn't the license be only GPL-3 instead of GPL-3+? At least the 
> file headers and the website say so ..

As you're the sole author, I guess it'd be better to change the headers
instead, to say "version 3 or higher".

But either way will do.

-- 
An imaginary friend squared is a real enemy.

Bug#827487: RFS: circle/2.2-1 [ITP]

[Adam Borowski]

On Sat, Jun 18, 2016 at 09:15:41PM +0200, Roberto S. Galende wrote:
> I am looking for a sponsor for my package "bytes-circle"
> 
> Package name: bytes-circle
> Version : 2.2-2

Hi!
Looks almost good, I found just three minor issues.  None of them is a
show-stopper, but let's have the package in a better shape from the start.

debian/changelog:
* why the Debian revision is -2 rather than -1?  That's appropriate only of
  there's a -1 in the changelog.  And that would make sense only if the
  packaging had a meaningful history in the wild (like, import from a
  derivative or a public repository).

debian/control:
* please say what the program is for (ie, the first and last paragraphs)
  rather than describing its use and output.  That's what the man page
  and/or README are for.

debian/rules:
* please move flags exports before including dpkg/default.mk.  The order
  matters -- your version doesn't use hardening.

Also, I wonder if there's a better place for the URL than
/usr/share/doc/README.  Other stuff in that file are build instructions
which are irrelevant for packaged software.

BTW, ♥ the "circulos meos" reference.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#827487: RFS: circle/2.2-1 [ITP]

[Adam Borowski]

Control: tag -1 moreinfo

On Thu, Jun 16, 2016 at 11:50:02PM +0200, Roberto S. Galende wrote:
> I am looking for a sponsor for my package "circle"
> 
> Package name: circle
> Version : 2.2-1
> URL : http://wp.me/p2FmmK-96
> 
> circle - Show byte statistics as an ascii circle graph

Hi!
First, please file an ITP bug (via "reportbug wnpp").  This is no mere
formality, as it lets readers of debian-devel make comments with respect to
your plans.


debian/changelog:
* "This is my first Debian package." is a comment that doesn't belong in the
  changelog.
* please "(Closes: # ascii
* the long description could use some elaboration

debian/copyright:
* please delete the boilerplate comments, they don't apply
* [nitpick] Files: * already includes Files: debian/*

debian/rules:
* all commented out boilerplate other than #DH_VERBOSE = 1 (somewhat useful
  as a reminder while debugging) should be axed
* you may want to uncomment some, though: hardening, -Wall

debian/circle/1:
* s/SECTION/1/
* again, s/ascci/ascii/

Otherwise, the package builds correctly and seems to work.


Please use "lintian" both on source and binary packages and address problems
it reports before uploading.  Using "lintian -i" will give quite helpful
hints how to fix them.


Meow!
-- 
An imaginary friend squared is a real enemy.

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

[Adam Borowski]

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

The docs on the LTS wiki suggest it is, but I asked to confirm.

> you can see the accept email here
> https://packages.qa.debian.org/v/virtualbox/news/20160129T103406Z.html
> 
> but I never and I think they really don't like it, pushed without having an 
> explicit ack
> from security team (and it should even be mentioned in the security policy)

It is mentioned, in the Developer Reference.

I assume Mateusz discussed the upload -- it's only a copy of a patch already
applied to jessie, and what I see in debian-lts archives includes a part of
such a discussion.

> BTW according to security tracker wheezy is EOL for that cve, no DSA is 
> released, so I guess you won't
> have the ack
> https://security-tracker.debian.org/tracker/CVE-2016-5108

The discussion continued after the EOL was mentioned, and Mateusz was
obviously aware of it, thus I assume the RFS he filed was acked in parts of
the discussion that are missing from list archives.

In any case, the patch is simple and works for me.

> (well, since there is a patch and an upload ready they might give an 
> exception, but I think
> asking before is the right way to deal with this bug)

Right... which is exactly what I'm doing right now :)
Wheezy has been handed off from security to the LTS team.


Meow!
-- 
An imaginary friend squared is a real enemy.

Bug#827398: RFS: pkg-kde-tools/0.15.21~bpo8+1

[Adam Borowski]

On Wed, Jun 15, 2016 at 08:08:59PM +0200, Mateusz Łukasik wrote:
>   I am looking for a sponsor for my package "pkg-kde-tools"
> 
>  * Package name: pkg-kde-tools
>Version : 0.15.21~bpo8+1
>Upstream Author : Copyright © 2007-2008 Sune Vuorela
> 

I'm not sure whether you've coordinated this with the KDE team.  I don't see
you among KDE packagers, and you haven't noted this in the RFS.  NMU
backports are fine, but please say so if this is your intent.


Meow!
-- 
An imaginary friend squared is a real enemy.

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

[Adam Borowski]

On Wed, Jun 15, 2016 at 08:03:28PM +0200, Mateusz Łukasik wrote:
> I am looking for a sponsor for my package "vlc"
> 
>  * Package name: vlc
>Version : 2.0.3-5+deb7u3
> https://mentors.debian.net/debian/pool/main/v/vlc/vlc_2.0.3-5+deb7u3.dsc
> 
>   Changes since the last upload:
> 
>   Fix CVE-2016-5108. (Closes: #825728)

Hi!
I've reviewed the upload, but I'm not sure if you coordinated it
with the LTS team.  I find a contradition:
  https://lists.debian.org/debian-lts/2016/06/msg00031.html
says vlc is no longer supported in wheezy, yet in
  https://lists.debian.org/debian-lts/2016/06/msg00035.html
the quoted mail sounds as if the upload is expected.

Should I proceed?

As I haven't ever made a security upload before, mine nor sponsored, let me
recap: I make a source-only upload targetted at wheezy-security to
security-master, right?

Tested on amd64, the patch indeed fixes the exploit posted in the CVE.

-- 
An imaginary friend squared is a real enemy.

Re: how to build packages with a specific complier ?

[Adam Borowski]

On Wed, Jun 15, 2016 at 12:16:05PM +, Gianfranco Costamagna wrote:
> >It appears that some tests fail for one of my package (gmp-ecm) on one 
> >architecture (s390x):
> >after some investigation, it appears that it is a compiler issue: building 
> >with gcc-6 (instead of gcc-5)
> >causes no issue. So now I want to impose the gcc-6 to d/rules ? What is the 
> >best way to do so ?
> 
> 
> Debug and fix gcc-5 is preferred, otherwise something like
> add gcc-6 to build dependencies (and g++-6 if needed)

As far as I know, the plan is to switch to gcc-6 by default for stretch:
https://lists.debian.org/debian-gcc/2016/01/msg00100.html
so while identifying and backporting the fix to gcc-5 would be nice, I'd
recommend not putting too much effort there.

-- 
An imaginary friend squared is a real enemy.

Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library

[Adam Borowski]

control: tags -1 moreinfo

On Thu, Jun 02, 2016 at 01:31:02AM +0200, Nicolas Braud-Santoni wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my upload for the libu2f-host package.
> It fixes the following RC bug:
>   #820686: FTBFS - missing build-dep libglib2.0-dev
> 
> The package's maintainer team, the Debian Authentication Maintainers, has
>   not commented on the bug since it was opened, 2 months ago.
> 
> 
> The dsc and build artifacts can be found in
>   https://nicolas.braud-santoni.eu/tmp/deb/

The dsc there doesn't unpack -- filenames nor checksums don't match.

> They were produced, using pdebuild(1), from the source in
>   https://github.com/nbraud/libu2f-host-dpkg/tree/bug-820686
>   (signed commit 4e6802ca12362e415ee45fcab64f38a601b02420)
> 
> This changed has been submitted back to the packaging repo as a pull request:
>   https://github.com/Yubico/libu2f-host-dpkg/pull/1
> 
> It ignores the commits that got added since the last version that was 
> published
>   in the archive (esp. the merging of a new upstream version).

Only one of four commits atop of debian/1.0.0-1 looks relevant:
40d4511 has the following changes:
+ updated build-dependencies (ie, the meat of the NMU)
+ standards version bump
+ a changelog entry (with an error: you need # after "Closes: " before the
  number)

e12e613 adds an UNRELEASED changelog entry and some gbp junk.
3d0722a tries to invent a way of generating "orig" tarballs.
+ this is bad as those don't match upstream.  Besides details like losing
  timestamps or degrading xz to gz, you really should use what upstream
  provides, unless this is impossible because of git-only releases or a
  need to repack.
+ not using upstream tarballs ie especially bad as these are signed
4e6802c tries to ignore changes in a generated file instead of properly
  cleaning it (deletion would suffice)

On the other hand, something in clean-up after build does happen to break
the package.  If you try to package the source from a fresh repository, it
succeeds.  After a build, newly repacked source won't build anymore:

/bin/bash /home/kilobyte/tmp/pkg/libu2f-host-dpkg/build-aux/missing help2man \
--output=u2f-host.1 ./u2f-host \
--name="Yubico Universal 2nd Factor (U2F) Host Tool" \
--no-info
help2man: can't get `--help' info from ./u2f-host
Try `--no-discard-stderr' if option outputs to stderr
WARNING: 'help2man' is missing on your system.
 You should only need it if you modified a dependency of a man page.
 You may want to install the GNU Help2man package:
 
Makefile:952: recipe for target 'u2f-host.1' failed
make[4]: *** [u2f-host.1] Error 127


Meow!
-- 
An imaginary friend squared is a real enemy.

Re: When to use "Replaces"?

[Adam Borowski]

On Tue, May 31, 2016 at 05:13:14PM +1000, Scott Leggett wrote:
> On 2016-05-30.21:22, gregor herrmann wrote:
> > On Mon, 30 May 2016 20:25:56 +0200, Adam Borowski wrote:
> > 
> > > >   c) Something else ...?
> > > As both unclutters provide generally the same functionality, you may also
> > > use the "alternatives" method.  
> > 
> > My impression is that the "new" version has different command line
> > options. So calls to unclutter with the old options in
> > .xsession/.xinit would break if /usr/bin/unclutter points to the new
> > implementation via alternatives.
> > 
> > I think I'd go for renaming here.
> 
> Using the alternatives system is an interesting idea. Yes, the "new"
> version is *not* a drop-in replacement - while the functionality is the
> same, accepted arguments are not totally identical. However the
> description and example given in the policy manual of different "vi"
> clones seems to match the "unclutter" situation quite well.

I can't seem to find a relevant definition in the Policy, so here's my
common-sense reasoning:

is the primary use mode compatible?  That is, will the usual mode of
invocation of one alternative work with the other?  For example a vast
majority of invocations of "editor" is just "editor $FILENAME"; comparing
command-line options of jstar and vim the only one that seems to be common
to both is +$LINENUM -- and even that is not officially mandated anywhere.

It's obvious arguments will almost never be totally identical -- different
implementations have different features and different needs.  That's ok and
expected.  I'd say such programs are unfit to be alternatives to each other
only if the usual, basic functionality needs different invocations.

> Am I correct in understanding that using alternatives requires
> co-operation between the two packages, "unclutter" and
> "unclutter-fixes"? If that's the case, I'll approach the "unclutter"
> maintainer, and if they disagree on using alternatives, will just rename
> my package.

Yes, all packages in an alternatives set must cooperate.


Meow!
-- 
An imaginary friend squared is a real enemy.

Re: When to use "Replaces"?

[Adam Borowski]

On Tue, May 31, 2016 at 01:06:57AM +1000, Scott Leggett wrote:
> I've just filed an ITP for "unclutter-xfixes"[0]. This package is a
> rewrite of the "unclutter" package. It provides the same functionality
> (hiding your mouse pointer after some period of inactivity), but uses a
> different API which may avoid some of the issues seen in "unclutter".
> 
> Upstream's Makefile installs the binary and manpage as "unclutter" -
> it's clearly intended to be used in place of the original package.
[...]
> So should I:
> 
>   a) Patch the Makefile to rename the binary "unclutter-xfixes", with
>   the downside of diverging from Upstream;
> 
>   b) Go with Upstream in naming the binary "unclutter", and make the
>   "unclutter-xfixes" package Break/Replace "unclutter", with the
>   downside of not being able to install both at the same time; or
> 
>   c) Something else ...?

As both unclutters provide generally the same functionality, you may also
use the "alternatives" method.  

-- 
An imaginary friend squared is a real enemy.

Bug#820488: RFS: roadfighter/1.0.1269-1 [ITP] -- Drive a car in a death race

[Adam Borowski]

On Sun, May 22, 2016 at 02:07:39AM +0500, Andrey Rahmatullin wrote:
> I'm worried about fonts/*.ttf. If these fonts are packaged in Debian they
> shouldn't be shipped in the binary package. Otherwise, there is no info
> that they are free, no license, no canonical name etc. In any case
> shipping some random fonts in the source package is troublesome.

If you open them in fontforge, their true names are DroidSerif-Bold and
DroidSerif-Italic.  Those are gone from Debian, but according to Wikipedia
they're subsumed into NotoSerif.  Ie, package fonts-noto-hinted files
/usr/share/fonts/truetype/noto/NotoSerif-{Bold,Italic}.ttf

-- 
An imaginary friend squared is a real enemy.

Bug#823895: RFS: lsm/1.0.4-1

[Adam Borowski]

On Sat, May 21, 2016 at 12:09:14PM -0300, Lucas Castro wrote:
> On 21-05-2016 11:59, Adam Borowski wrote:
> > On Fri, May 20, 2016 at 10:31:49PM -0300, Lucas Castro wrote:
> >> But I don't think I need to write a documentation how to setup
> >> the config file is easy to understand, just feeding back it's needed to
> >> setup to get working.
> >> what do you think?
> > I meant mostly what's needed to get the basics running.
> My problem I didn't noticed problem about setup needed because I've
> installed at a machine was already working. 

Right, that's understandable.

If you're going to make complex changes to the packaging, it'd be a good
idea to test it in virtual machines, both fresh and as upgrades.  However,
if you believe you can make it work without, there's no need to do so --
I'll test it for you as I already have an array of VMs, some simple, some
bridged/etc.  And especially, some with systemd some with modular inits,
as this package has .service divergent from its init script.

> > I got the impression you're -trying- to have it work out of the box, in
> > which case no action is needed.  If I'm wrong and configuration is required,
> > then you need to 1. handle lack of such config gracefully, and 2. point the
> > user as to what needs to be done.
> I've done the most changed you pointed, either the feedback about that
> setup is needed to get it running.
> my question is just about user perspective, if I really need to write a
> documentation how to configure or
> just show to user they need to setup. Something like "Edit
> /etc/lsm/lsm.conf is needed to get it running."

Just that line included in the fail message would be enough, I think.


-- 
An imaginary friend squared is a real enemy.

Bug#823895: RFS: lsm/1.0.4-1

[Adam Borowski]

On Fri, May 20, 2016 at 10:31:49PM -0300, Lucas Castro wrote:
> On 14-05-2016 20:45, Adam Borowski wrote:
> > Only upon checking the syslog I see:
> > May 15 00:30:37 umbar lsm[12853]: no targets found in config file
> > yet according to comments in /etc/lsm/lsm.conf:
> > # Defaults for the connection entries
> > # These are set in the code. You may override any values here.
> > which suggests there's no need to edit the config for basic functionality.
> >
> > If I read this wrong and some setup is needed, then the package shouldn't
> > try to start the daemon on initial install, and provide a feedback that
> > editing the config file is required.
> >
> > There's no documentation describing what's needed to get lsm running.
> I'm almost fishing.
> But I don't think I need to write a documentation how to setup
> the config file is easy to understand, just feeding back it's needed to
> setup to get working.
> what do you think?

I meant mostly what's needed to get the basics running.

I got the impression you're -trying- to have it work out of the box, in
which case no action is needed.  If I'm wrong and configuration is required,
then you need to 1. handle lack of such config gracefully, and 2. point the
user as to what needs to be done.


-- 
An imaginary friend squared is a real enemy.

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Adam Borowski]

On Sun, May 15, 2016 at 03:04:37AM +0200, Eric Heintzmann wrote:
> Le 15/05/2016 02:46, Adam Borowski a écrit :
> > On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote:
> >>   I am looking for a sponsor for my package "gnustep-make"
> >>
> >>  * Package name: gnustep-make
> >>Version : 2.6.8-1
> >>
> >> dget -x 
> >> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc
> > As there's LOADS of packaging changes, could you please push them to a VCS? 
> > That'd make reviewing greatly easier.  From the new changelog I assume you
> > used git, I just don't see anything new past 2.6.6-3 on any branches on
> > pkg-gnustep/gnustep-make.git.
> 
> Sorry, but I've not used git nor any VCS because I work all alone
> since I am the last active member of the Debian GNUstep maintainers.
> If I had knew that make reviewing easier, I would have used Git.
> If you want I can push my changes on pkg-gnustep/gnustep-make.git
> but there will be only one big commit.
> Sorry, I ve done a mistake how can I repair it ?

Oif.  I guess trying to split this big commit would be far more work than
just reviewing it the hard way, so there's nothing that can be done here.
That's unfortunate as it raises the difficulty of review considerably.

As gnustep-make is a complex package I'm not familiar with, I'm afraid
I'll leave it to someone with more time and experience.

Apologies.
-- 
A tit a day keeps the vet away.

Bug#824262: RFS: gnustep-make/2.6.8-1 [RC] -- GNUstep build system

[Adam Borowski]

Hi!

On Sat, May 14, 2016 at 12:39:16PM +0200, Eric Heintzmann wrote:
>   I am looking for a sponsor for my package "gnustep-make"
> 
>  * Package name: gnustep-make
>Version : 2.6.8-1
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/g/gnustep-make/gnustep-make_2.6.8-1.dsc

As there's LOADS of packaging changes, could you please push them to a VCS? 
That'd make reviewing greatly easier.  From the new changelog I assume you
used git, I just don't see anything new past 2.6.6-3 on any branches on
pkg-gnustep/gnustep-make.git.

If for whatever reason you can't/don't want to push your changes there (no
access, dislike for amends, etc), any other repository would be fine for
now.  I just don't feel like going through such a huge diff unassisted.

Meow!
-- 
A tit a day keeps the vet away.

Bug#823895: RFS: lsm/1.0.4-1

[Adam Borowski]

On Sun, May 15, 2016 at 01:45:32AM +0200, Adam Borowski wrote:
> Too bad, when actually trying to install the package:
> 
> [] Starting Link Monitor.: lsminvoke-rc.d: initscript lsm, action "start" 
> failed.
> dpkg: error processing package lsm (--install):
>  subprocess installed post-installation script returned error exit status 1
> Processing triggers for man-db (2.7.5-1) ...
> Errors were encountered while processing:
>  lsm

Failing to uninstall is even worse:
Removing lsm (1.0.4-1) ...
[] Stopping Link Monitor.: lsminvoke-rc.d: initscript lsm, action "stop" 
failed.
dpkg: error processing package lsm (--purge):
 subprocess installed pre-removal script returned error exit status 1
Errors were encountered while processing:
 lsm

Please either use --oknodo in the stop target or otherwise make it handle
the "wasn't running" case as success.  I see you attempt to do so, but "set
-e" breaks that.


Meow!
-- 
A tit a day keeps the vet away.

Bug#823895: RFS: lsm/1.0.4-1

[Adam Borowski]

On Sat, May 14, 2016 at 12:22:13AM -0300, Lucas Castro wrote:
> On 13-05-2016 11:46, Adam Borowski wrote:
> >> On 10-05-2016 02:43, Lucas Castro wrote
> >>> I am looking for a sponsor for my package "lsm"
> >>>
> >>> dget -x 
> >>> https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc
> >
> > 2. The manpage seems mangled:
> >
> >While simple to configure, provides easy way reconfigure routes, 
> > calling notifyscript
> >
> >lsmVery configurable, but doesn't support domain names yet.
> Thanks, fixed.

Hmm, it looks like you merely added a space and lowercased V:

   While simple to configure, provides easy way reconfigure routes, calling 
notifyscript.

   lsm very configurable program, but doesn't support domain names yet.

These two lines don't quite make sense...


> > 3. Typo: exectuble.
> if you mean man page typo, fixed.

It's still in the init script, line 32.


Too bad, when actually trying to install the package:

[] Starting Link Monitor.: lsminvoke-rc.d: initscript lsm, action "start" 
failed.
dpkg: error processing package lsm (--install):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db (2.7.5-1) ...
Errors were encountered while processing:
 lsm

[~]# /etc/init.d/lsm start
[] Starting Link Monitor.: lsm[~]# echo $?
1
(no newline, by the way -- init scripts shouldn't use "set -e")

[~]# lsm --config /etc/lsm/lsm.conf 
[~]# echo $?
1

An error message describing what went wrong would be nice...

Only upon checking the syslog I see:
May 15 00:30:37 umbar lsm[12853]: no targets found in config file
yet according to comments in /etc/lsm/lsm.conf:
# Defaults for the connection entries
# These are set in the code. You may override any values here.
which suggests there's no need to edit the config for basic functionality.

If I read this wrong and some setup is needed, then the package shouldn't
try to start the daemon on initial install, and provide a feedback that
editing the config file is required.

There's no documentation describing what's needed to get lsm running.


Also, it appears the only copy of upstream's changelog is hidden inside
lsm.spec (lines between "%changelog" and "#EOF").  Please cut this (with sed
or a similar tool) and install as /usr/share/doc/*/changelog.gz


In /usr/share/doc/lsm/examples/lsm.conf.sample, there are references to
/usr/libexec/lsm/ instead of /usr/share/lsm/, it'd be nice to sed that to
what's installed on Debian.


> > Meow!
> Done.

Hah!  This was intended as an onomatopeia not an imperative, but I really
like your interpretation :)

-- 
A tit a day keeps the vet away.

Bug#824271: RFS: primesieve/5.6.0+ds-2 [Refreshment] - fast prime number generator C/C++

[Adam Borowski]

On Sat, May 14, 2016 at 04:08:31PM +0100, Jerome Benoit wrote:
>  I am looking for a sponsor for the package primesieve, an efficient C/C++
>  library to generates the prime numbers. This versy package is mainly a
>  Debian material refreshment.
> 
> [1] https://anonscm.debian.org/cgit/debian-science/packages/primesieve.git

Hi!
I see the changelog include:
 - reproducible build, attempt.
yet I see nothing of that kind.  Is something amiss?

Otherwise, looks fine.


Meow!
-- 
A tit a day keeps the vet away.

Bug#823895: RFS: lsm/1.0.4-1

[Adam Borowski]

> On 10-05-2016 02:43, Lucas Castro wrote
> > I am looking for a sponsor for my package "lsm"
> >
> > * Package name: lsm
> >   Upstream Author : Mika Ilmaranta 
> > * URL : http://lsm.foobar.fi/
> >
> > dget -x 
> > https://mentors.debian.net/debian/pool/main/l/lsm/lsm_1.0.4-1.dsc

>From a superficial review:

1. Please delete (or fill out) debian/README.source

2. The manpage seems mangled:

   While simple to configure, provides easy way reconfigure routes, calling 
notifyscript

   lsmVery configurable, but doesn't support domain names yet.

3. Typo: exectuble.


Meow!
-- 
A tit a day keeps the vet away.

Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]

[Adam Borowski]

On Fri, May 06, 2016 at 09:55:47AM +, Gianfranco Costamagna wrote:
> unfortunately I'm not sure this is enough for ftpmasters...
> 
> I'm afraid we need an official tarball with the fixed licenses, otherwise
> they won't be coherent license-wise.
> 
> this seems to be a blocker for now.

What's the problem?

1. A statement from the copyright holder is enough.  The license doesn't
need to be in the tarball -- Fernando can include the statement in
debian/copyright.

2. Even without the clarification, the only thing the old licenses forbid
is putting additions (such as the packaging) under GPL3 or some other
license not compatible with GPL2-only.

3. Other than compatibility with other licenses, no one really cares about
confusion wrt GPL2 vs GPL2+.  They don't conflict, all we lose is the
permission to use the code under a higher version of GPL.  As long as
debian/copyright assumes the worse option, I don't think any ftpmaster would
reject.

(Points 2. and 3. being moot now that Alexander, the copyright holder,
spoke.)

-- 
A tit a day keeps the vet away.

Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]

[Adam Borowski]

On Fri, Apr 29, 2016 at 09:31:50PM -0300, Fernando Toledo wrote:
> El 29/04/16 a las 18:31, Adam Borowski escribió:
> > On Fri, Apr 29, 2016 at 08:45:27PM +, Gianfranco Costamagna wrote:
> >> licensecheck *
> >> shows the license of some files as GPL-2+ not GPL-2
> > 
> > It looks like there's a mismatch:
> > 
> > README says:
> > # Copyright 2003 by Alexander K.nig - a...@lisas.de
> > # License: GPL V2 - see the file COPYING
> > (COPYING is the text of GPL-2)
> > 
> > but, aseqjoy.c says:
> > # or (at your option) any later version.
> > 
> > Too bad, while it's the only C source, there's one more copyrightable file,
> > aseqjoy.1.in, which doesn't embed a license statement and thus is covered by
> > the README.
> > 
> > So unless you contact the author or rewrite the manpage, the effective
> > license is GPL-2 only.
> >
> 
> if i understand, if i change the debian/* to GPL-2+ will solved only the
> patches issues? and still have problem with the upstream man file?
> my own patch just is trivial and solve spell lintian warning only.

GPL-2 is compatible with GPL-2+, so that's enough.

> i just send a email to the upstream author with this comments also.
> will need to release a new tarball with this changes?

Clarifying the license would be nice, but is not required: while it's not
sure what the author meant, there is one safe option: assuming GPL-2.
Of course, that means you can't combine it with GPL-3 patches or packaging.

Unless you hear back from the author soon, I'd recommend using GPL-2+ for
the packaging.  That's compatible with GPL-2, GPL-3, GPL-3+, or even future
GPL-4 or GPL-65535.

-- 
A tit a day keeps the vet away.

Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]

[Adam Borowski]

On Fri, Apr 29, 2016 at 08:45:27PM +, Gianfranco Costamagna wrote:
> >Fixed. Is possible to have upstream => gpl2 and debian/* => gpl3, true?
> 
> this means that it will be impossible to forward patches upstream without 
> manually
> relicensing them.
> 
> I personally don't prefer, because only the author of each patch will be able 
> to forward
> it upstream.

It's worse: as the package is built from sources under mutually conflicting
licenses, it is indistributable.

As both the packaging and the only patch come exclusively from you, I'd
simply change the license for debian/* to GPL-2+ (but, see below).

> licensecheck *
> shows the license of some files as GPL-2+ not GPL-2

It looks like there's a mismatch:

README says:
# Copyright 2003 by Alexander K.nig - a...@lisas.de
# License: GPL V2 - see the file COPYING
(COPYING is the text of GPL-2)

but, aseqjoy.c says:
# or (at your option) any later version.

Too bad, while it's the only C source, there's one more copyrightable file,
aseqjoy.1.in, which doesn't embed a license statement and thus is covered by
the README.

So unless you contact the author or rewrite the manpage, the effective
license is GPL-2 only.

-- 
A tit a day keeps the vet away.

Re: Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Adam Borowski]

On Wed, Apr 27, 2016 at 12:40:59PM +0200, Jakub Wilk wrote:
> * Adam Borowski <kilob...@angband.pl>, 2016-04-27, 12:02:
> >>>export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l`
> >>Refuse the temptation to parse /proc/cpuinfo. Use nproc(1) instead.
> >Oh, that's something new (for the value of "new" of "added upstream on
> >2009-11-06, to Debian in 8.1-1 for squeeze").  Good to know.
> 
> For pre-squeeze, there's "getconf _NPROCESSORS_ONLN".

At least one Debian derivative, Dyson, has:

draconis:[~]$ dpkg --print-architecture
illumos-amd64
draconis:[~]$ getconf _NPROCESSORS_ONLN
getconf: Invalid argument (_NPROCESSORS_ONLN)

so let's not advertise getconf, as -j`something with no stdout output`
results in a fork bomb.


On the other hand, nproc works everywhere I tried.

-- 
A tit a day keeps the vet away.

Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Adam Borowski]

Control: owner -1 !

On Wed, Apr 27, 2016 at 09:45:18AM +, Gianfranco Costamagna wrote:
> Adam, do you plan to sponsor the package? in this case can I set you as 
> owner? :)

Sure, can do.  I did most of the review already, and if we decide otherwise
wrt 1.6-pre1, can always unset.

> Fabian, why are you trying to package an upstream snapshot?
> (not asking to package 1.5.1, I'm just wondering about why a new library 
> should
> eventually enter Debian in a snapshot form)

Upstream says:
# Note that 1.6 is bleeding edge and still needs polishing before it can
# replace 1.5.  It is recommended you use 1.5.

On the other hand, moving from SDL1.2 to SDL2 is a big change, so I
understand wanting to use the new version already, both for programs using
this library and to avoid doing this part of packaging twice.

On the third hand, though, there's a significant risk the API/ABI might
change before final 1.6.

-- 
A tit a day keeps the vet away.

Re: Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Adam Borowski]

On Wed, Apr 27, 2016 at 11:40:47AM +0200, Jakub Wilk wrote:
> * Adam Borowski <kilob...@angband.pl>, 2016-04-27, 05:27:
> >export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l`
> 
> Refuse the temptation to parse /proc/cpuinfo. Use nproc(1) instead.

Oh, that's something new (for the value of "new" of "added upstream on
2009-11-06, to Debian in 8.1-1 for squeeze").  Good to know.

And it works with /proc not mounted.

-- 
A tit a day keeps the vet away.

Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Adam Borowski]

On Tue, Apr 26, 2016 at 10:22:32PM +0200, Fabian Wolff wrote:
>  * Package name: libtcod

I'm afraid that it builds only on 64-bit architectures (I tried amd64 and
arm64), on 32-bit ones (x32 armhf i386) it fails with:

dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libtcod0/DEBIAN/symbols doesn't match 
completely debian/libtcod0.symbols
--- debian/libtcod0.symbols (libtcod0_1.6.0~pre1+dfsg-1_x32)
+++ dpkg-gensymbolsZSmCIg   2016-04-27 02:14:30.890101840 +
@@ -1511,7 +1511,7 @@
  (c++)"TCODSystem::newMutex()@Base" 1.6.0~pre1
  (c++)"TCODSystem::newSemaphore(int)@Base" 1.6.0~pre1
  (c++)"TCODSystem::newThread(int (*)(void*), void*)@Base" 1.6.0~pre1
- (c++)"TCODSystem::readFile(char const*, unsigned char**, unsigned 
long*)@Base" 1.6.0~pre1
+#MISSING: 1.6.0~pre1+dfsg-1# (c++)"TCODSystem::readFile(char const*, unsigned 
char**, unsigned long*)@Base" 1.6.0~pre1
  (c++)"TCODSystem::registerSDLRenderer(ITCODSDLRenderer*)@Base" 1.6.0~pre1
  (c++)"TCODSystem::saveScreenshot(char const*)@Base" 1.6.0~pre1
  (c++)"TCODSystem::setClipboard(char const*)@Base" 1.6.0~pre1
@@ -1560,6 +1560,7 @@
  (c++)"TCODZip::~TCODZip()@Base" 1.6.0~pre1
  TCOD_CRenderer@Base 1.6.0~pre1
  (c++)"TCOD_path_func(int, int, int, int, void*)@Base" 1.6.0~pre1
+ _ZN10TCODSystem8readFileEPKcPPhPj@Base 1.6.0~pre1+dfsg-1
  end_struct@Base 1.6.0~pre1
  error@Base 1.6.0~pre1
  internalListener@Base 1.6.0~pre1

So you need to adjust the symbols file.

Also, it'd be nice if you added --parallel to the dh call, it massively
speeds up builds[1] on any non-museal machine.  It's default in upcoming
debhelper 10.


Meow!

[1]. To actually make --parallel work, the person running the build needs to
set: export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l`
but this is outside the packaging.
-- 
A tit a day keeps the vet away.

Re: Package maintainers, I feel like such an outsider

[Adam Borowski]

On Tue, Apr 26, 2016 at 07:54:32PM +, Wayne Booth wrote:
> Recently, I found that one of the libraries I use has just dropped off the
> Debian repositories (
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751916). This kills the
> USP for my application. I can provide a .deb to my users for my app, but
> cannot for the requisite libraries.

For the value of "just" of "two years ago".

> So, my question is this. Is there anything I can do, as someone with no
> special merit or connections at Debian, but with time, technical skill and
> the motivation to see this happen, to get the "pHash" re-included into the
> repositories?

libphash was removed due to lack of maintenance in Debian, not because of
being dead in general -- at the time, it had an active upstream.  I see that
the last upstream version is 3 years old now, though.  This is not a
show-stopper, but you need to be prepared to fix issues yourself if upstream
won't do so in a timely matter.

> (I originally posted this question on debian-users (
> https://lists.debian.org/debian-user/2016/04/msg00947.html), who suggested
> it was more appropriately directed here. There was also some interesting
> feedback from 'Thomas Schmitt', who suggested that if I could fix the
> outstanding bugs, and bring the code up to the current upstream version,
> things would get moving. I can certainly do that, but wouldn't know how to
> progress from there.)

You need to either step up as a maintainer of libphash or find someone to
maintain it for you.  If, as you say, you already provide .deb packages
outside Debian, and have time and motivation, you're in a good position to
become such a maintainer yourself.

The process for reintroducing a removed package is same as for adding a new
one: please file an ITP ("reportbug wnpp").  Most ITPs go unopposed, but
it's possible someone may raise an issue (in this case, perhaps because of
reasons libphash was removed for).

Once that's done, and you have a version ready for upload (don't hesitate to
ask here if you have some problems!), you may request sponsoring the upload
("reportbug sponsorship-requests").

-- 
A tit a day keeps the vet away.

Re: Bug#816542: RFS: connman/1.31-0.1 [RC]

[Adam Borowski]

On Sun, Apr 24, 2016 at 02:19:59PM +0200, Mateusz Łukasik wrote:
> Pong back.
> 
> http://mentors.debian.net/debian/pool/main/c/connman/connman_1.21-1.3.dsc
> 
> I was tested it on Ubuntu 16.04 and all is fine.

But alas, it doesn't build on current unstable.

#822393 which looks like a problem between iptables-dev and libc6-dev rather
than in connman -- but whatever the cause, uploading connman would be no
good at the moment.

-- 
A tit a day keeps the vet away.

Re: Bug#818974: packaging

[Adam Borowski]

On Sun, Apr 24, 2016 at 09:06:26AM +0200, Dominique Dumont wrote:
> You can also try "cme update dpkg-copyright". 
> 
> See 
> https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme
> for instructions,

Bad advice, I'm afraid.

Here's a typical result of using cme:
https://anonscm.debian.org/cgit/pkg-fonts/ttfautohint.git/commit/?id=8a0a29b8ef50fb4e7316826a916167fd66acdd5f

All of the output is obviously bogus, both the claim that almost everything
is "FTL or GPL-2+" or the oft-repeated Comment: about Freetype license.


It's not an isolated case, too: I tried cme's "scan-copyright" on a few
packages (not many, I admit), and have yet to see a case when cme's output
is fit even as a start for manual review.

It appears that it relies on the dubious practice of copying a page of
licensing boilerplate into every source file.  This practice is a source of
controversy, with many arguments for and against so let's not discuss its
merit here (as it's a question for upstream not you).  But even if such
boilerplate is included, in most cases it's worthless as it says only who
_started_ coding the given file.

Collecting accurate copyright information is not as easy as running a simple
tool...

-- 
A tit a day keeps the vet away.

Re: Bug#821270: RFS: firefox-branding-iceweasel/0.3.0 [ITP] -- Preserves Iceweasel branding for new Firefox packages

[Adam Borowski]

On Wed, Apr 20, 2016 at 10:42:04AM +0800, Paul Wise wrote:
> On Mon, 2016-04-18 at 14:31 +, nord-stream wrote:
> 
> > Technically a Firefox extension cannot change this. It's a .desktop
> > file's job, I assume. But can we replace a .desktop file from another
> > package? Adding extra files to be installed also complicates rules a
> > lot.
> 
> I think this would have to be handled in the iceweasel package:

Alternatively, you can dpkg-divert the .desktop file.  Just remember to
undivert it back when the extension is being removed.

-- 
A tit a day keeps the vet away.

Re: Any reason to keep libsdsl in experimental (Was: Please help creating shared *and* static library with cmake)

[Adam Borowski]

On Sun, Apr 10, 2016 at 07:20:50PM +0200, Tomasz Buchert wrote:
> > ] Architecture: amd64 arm64 ppc64el s390x
> > 
> > But why would you artificially restrict this to just these?
> > 
> > 2.0.3-1 successfully built also on:
> > alpha kfreebsd-amd64 mips64el ppc64 sparc64 x32
> > 
> > Of these, only alpha can be considered a doorstop architecture.
> 
> Damn, I only looked at the officially released archs, sorry.
> I'll upload the less restricted version soon.

Thanks!

I don't know the real use of other 2nd class architectures, but at least for
x32 the benefits over amd64 are:

* drastically lower memory use: relevant for server consolidation and
  vhosting, not really for scientific software
* modest speed gains.  Sometimes 40%, sometimes 0%, a realistic figure on
  some piece of diverse code I've tested is only 7%.

A speed gain of only 7% is typically something only a "gentoo ricer" would
look at, with one exception: when you build a $1M cluster you get to save
$70k, all for the cost of debootstrap+recompile (and go back to amd64 in case
of any problems).

Which seems to be just the purpose of current users of libsdsl.


-- 
A tit a day keeps the vet away.

Re: Any reason to keep libsdsl in experimental (Was: Please help creating shared *and* static library with cmake)

[Adam Borowski]

On Sun, Apr 10, 2016 at 05:52:29PM +0200, Tomasz Buchert wrote:
> On 09/04/16 18:31, Andreas Tille wrote:
> > On Sat, Apr 09, 2016 at 04:47:35PM +0200, Tomasz Buchert wrote:
> > > the only reason is that it doesn't build on most architectures. The
> > > upstream devel version build, I think, on other archs, but it hasn't
> > > been released yet. I've asked the upstream author to release a new
> > > version, but unfortunately without any success.
> 
> > > So, what I can do is to release libsdsl to only limited number of
> > > archs (amd64, arm64, ppc64el, s390x) and then in the future I would
> > > extend this list. This will obviously limit the architectures that
> > > any reverse dependency will build on.
> 
> I've just done it.

] Architecture: amd64 arm64 ppc64el s390x

But why would you artificially restrict this to just these?

2.0.3-1 successfully built also on:
alpha kfreebsd-amd64 mips64el ppc64 sparc64 x32

Of these, only alpha can be considered a doorstop architecture.

-- 
A tit a day keeps the vet away.

Re: Seeking Sponsors for my package - roadfighter

[Adam Borowski]

On Fri, Apr 08, 2016 at 09:45:35PM -0300, Carlos Donizete Froes wrote:
> > > However, there's a wee little problem:
> > > [~]$ roadfighter 
> > > Segmentation fault (core dumped)

It looks like it _does_ work when ran from the build dir, fails otherwise.
(Sorry for the delay, I was, uhm, making sure it really works...)

And here's why:
open("fonts/NoticiaText-Italic.ttf", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("fonts/LiberationSans-Bold.ttf", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("fonts/LiberationSans-Bold.ttf", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("fonts/LiberationSans-Bold.ttf", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("graphics/disclaimer.jpg", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("graphics/retroremakes.bmp", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("graphics/konami1.jpg", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("graphics/konami2.jpg", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("graphics/title.jpg", O_RDONLY)= -1 ENOENT (No such file or directory)
open("graphics/arrow.bmp", O_RDONLY)= -1 ENOENT (No such file or directory)
open("graphics/gamemap.bmp", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("graphics/minicar1.bmp", O_RDONLY) = -1 ENOENT (No such file or directory)
open("graphics/minicar2.bmp", O_RDONLY) = -1 ENOENT (No such file or directory)
open("graphics/gameover.jpg", O_RDONLY) = -1 ENOENT (No such file or directory)
open("graphics/scoreboard.bmp", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("graphics/scoreboard_left.bmp", O_RDONLY) = -1 ENOENT (No such file or 
directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---

[~]$ dpkg -L roadfighter
/.
/usr
/usr/games
/usr/games/roadfighter
/usr/share
/usr/share/man
/usr/share/man/man6
/usr/share/man/man6/roadfighter.6.gz
/usr/share/doc
/usr/share/doc/roadfighter
/usr/share/doc/roadfighter/changelog.Debian.gz
/usr/share/doc/roadfighter/copyright
/usr/share/pixmaps
/usr/share/pixmaps/roadfighter.png
/usr/share/applications
/usr/share/applications/roadfighter.desktop

You need to actually install the assets and tell the game how to find them. 
LiberationSans-Bold.ttf should be a dependency on fonts-liberation instead
of shipping a copy yourself, NoticiaText-Italic.ttf is not currently
packaged.


-- 
A tit a day keeps the vet away.

Re: Seeking Sponsors for my package - roadfighter

[Adam Borowski]

On Fri, Apr 08, 2016 at 08:44:24PM -0300, Carlos Donizete Froes wrote:
> I'm looking for a sponsor my game package roadfighter [Road Fighter
> Remake].
> 
> http://mentors.debian.net/package/roadfighter

The packaging itself looks good.

You might want to ask debian-l10n-english for a proofreading of the man page
and other docs.  This isn't vital though, I'd upload as-is for now.

However, there's a wee little problem:
[~]$ roadfighter 
Segmentation fault (core dumped)

Program received signal SIGSEGV, Segmentation fault.
0x7707f02a in TTF_SizeUNICODE () from 
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0
(gdb) bt
#0  0x7707f02a in TTF_SizeUNICODE () from 
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0
#1  0x770803b7 in TTF_RenderUNICODE_Blended ()
   from /usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0
#2  0x7708082a in TTF_RenderText_Blended () from 
/usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0
#3  0x5558aa75 in ?? ()
#4  0x7f66 in main ()

Same crash on amd64 and armhf.


-- 
A tit a day keeps the vet away.

Re: Program upgrade directly from upstream

[Adam Borowski]

On Mon, Apr 04, 2016 at 12:41:02AM -0300, Paulo wrote:
> I'm packaging the package Selektor (ITP) [1] that has a particular
> behavior that I have doubts.
> 
> When program runs it checks for new version from upstream. When there are
> new version, it suggests and download a new version directly from upstream
> by a user decision.

Ie, an auto-updater.  This needs to be disabled, all updates are supposed to
go via apt.

-- 
A tit a day keeps the vet away.

Re: Bug#818505: sortmerna FTBFS on !x86

[Adam Borowski]

On Sun, Mar 27, 2016 at 05:32:31PM +0200, Gert Wollny wrote:
> On Sun, 2016-03-27 at 14:49 +0200, Adam Borowski wrote:
> > You're not allowed to use -msse2 on i386 either, unless for a code
> > path that's run conditionally on runtime.
> 
> Actually, "not allowed" it not the right expression, "discouraged"
> would be correct. If upstream requires sse2 then not enabling it would
> mean that all users of i386 would not have access to this software,
> even though one can assume that the majority uses hardware that is sse2
> capable. 
[...]
> I think this discussion could be helpful (linking to the conclusion of
> the maintainer): 
> 
> https://lists.debian.org/debian-devel/2014/09/msg00666.html

Yeah, if you include this:

# Given all the opinions expressed on the list (thanks!), I have decided
# to keep the i386 package and make it display an explicit error message
# at runtime if there is no SSE2 support in the processor.

Ie, as long as it's handled in a more graceful way than dumping core.

An alternative to detecting non-SSE2 at runtime would be doing this in
preinst and aborting installation.

It might be also good to make a "sse2-support" package as mentioned in the
thread Gert linked to to reduce duplication of such detection logic.  Please
say so if you think this is a good idea.

-- 
A tit a day keeps the vet away.

Re: Bug#818505: sortmerna FTBFS on !x86

[Adam Borowski]

On Sun, Mar 27, 2016 at 07:31:23AM +0200, Andreas Tille wrote:
> On Thu, Mar 17, 2016 at 05:04:21PM +, Jurica Stanojkovic wrote:
> > Package sortmerna FTBFS on archs not in x86 group (amd64, i386, x32, etc. )
> > with following error:
> > gcc: error: unrecognized command line option '-msse2'
> > 
> > build logs:
> > https://buildd.debian.org/status/logs.php?pkg=sortmerna=2.1-1=sid
> > 
> > Package use -msse2 for all architectures, 
> > but not all archs have support for sse2 instruction set.
> > 
> > if -msee2 flag is removed from build next error reported is:
> > src/ssw.c:45:23: fatal error: emmintrin.h: No such file or directory
> 
> As far as I can see this might restrict the package to intel
> architectures.  If there is no hint how to build on those other
> architectures I'd restrict the architectures to these.

You're not allowed to use -msse2 on i386 either, unless for a code path
that's run conditionally on runtime.

And on amd64 and x32, -msse2 is redundant as it's already implied by default
compiler settings for those architectures.

-- 
A tit a day keeps the vet away.

Bug#818724: RFS: task-spooler/0.7.6-1

[Adam Borowski]

On Sun, Mar 20, 2016 at 12:04:12PM +0300, Alexander Inyukhin wrote:
> On Sun, Mar 20, 2016 at 05:40:59AM +, Mattia Rizzolo wrote:
> > and btw, having debian/* GPL-2+ technically makes upstream unable to
> > pull patches from debian/patches/*, as GPL-2+ is incompatible with
> > GPL-2 (only).

This is incorrect.  GPL-2 and GPL-2+ are compatible, both ways, with the
combined result being effectively GPL-2 but anyone can still pick GPL-2+
parts and use them under GPL-2, GPL-3, GPL-4, GPL-4636467912 and,
unfortunately, AGPL-3 (which I consider a non-free license).

> Isn't that a one-way incompatibility?
> As far as I understand, GPL2+ is a set of licenses including GPL2,
> so GPL2+ code could be used in GPL2-only project.

So can GPL2-only code be used in a GPL2+ project (at the cost of restricting
the result to GPL2-only).

> Anyway, I do not want to restrict use of these patches.
> What license should I use?

GPL-2+ as you currently do.  This way upstream can use your patches now, and
will continue to be able even if they relicense to a higher version of GPL
in the future.

-- 
A tit a day keeps the vet away.

Re: Request for sponser

[Adam Borowski]

On Tue, Feb 16, 2016 at 02:24:52PM +0100, MENGUAL Jean-Philippe wrote:
> Le 16/02/2016 04:50, Adam Borowski a écrit :
> > On Tue, Feb 16, 2016 at 03:00:24AM +0100, MENGUAL Jean-Philippe wrote:
> >> Could a mentor have a look on this RFS please?
> >> http://bugs.debian.org/722451
> > 
> > Why do you rename an ITP to RFS?  Please file a separate bug.
> 
> Reallly!? But what about history? And how do we deal with 2 bug reports
> then: we close ITP? I'm afraid I don't understand. I really thought the
> bug needed to live its life until end. Could you explain to me how such
> bug reports should live (or tell me wether it's documented or not)?

ITP and RFS server different purposes:

ITP stakes your claim for the package, stating it's you who's working on it
and that others should talk/cooperate with you or risk work duplication or
worse.  The history on the ITP is important as it documents who's or was
interested in working on the package.  You don't close it until the package
actually enters Debian.  Packages should have exactly one ITP.

RFS is for requesting sponsoring a specific upload.  You file a new one
whenever you prepared a new version -- including updates to packages already
in Debian.  It's for coordinating with a sponsor about fixing problems in
the upload.

-- 
A tit a day keeps the vet away.

Re: Request for sponsor

[Adam Borowski]

On Tue, Feb 16, 2016 at 11:06:31AM +0100, Ksamak wrote:
> On Tue, Feb 16, 2016 at 04:50:18AM +0100, Adam Borowski wrote:
> > * please build-depend on libjpeg-dev rather than libjpeg8-dev, while the
> >   latter exists in unstable we really don't want anything to depend on
> >   it in stretch
> Ok, so we will try to depend on libjpeg-turbo, if that is the preferred

It's best to depend on "libjpeg-dev" rather than a specific version, this
way you can use whatever future default may change to.

> > * please build-depend on libpng-dev first (or solely)
> The upstream version has already been packaged with libpng-dev. However,
> there is a whole compiz plugin bound to managing jpeg, getting rid of libjpeg
> would mean getting rid of that plugin.

I meant instead of "libpng12-dev | libpng-dev".  The buildds strip any
alternative dependencies but the first, thus your package will become
unbuildable when the png16 transition starts in a few days.

I did not mean "please drop libjpeg, libbmp or libpcx" :)


Meow!
-- 
A tit a day keeps the vet away.

Re: Request for sponser

[Adam Borowski]

On Tue, Feb 16, 2016 at 03:00:24AM +0100, MENGUAL Jean-Philippe wrote:
> Could a mentor have a look on this RFS please?
> http://bugs.debian.org/722451

Why do you rename an ITP to RFS?  Please file a separate bug.

> We try to include Compiz again in Debian, from the Knoppix alioth
> project. We're preparing, but in background, the next update to be sync
> with upstream when Compiz released.

Wouldn't it be easier to start directly from Ubuntu packages instead of
outdated Knoppix ones?

> FYI,alioth project: https://alioth.debian.org/projects/compiz
> 
> git address to pull:
> git+ssh://alioth_u...@git.debian.org/git/pkg-a11y/compiz.git

I'm afraid it doesn't even build in unstable, for a number of reasons.
Some of these look as if you ever tried to compile it only within some old
environment.

A few random other things I noticed:

* please build-depend on libjpeg-dev rather than libjpeg8-dev, while the
  latter exists in unstable we really don't want anything to depend on
  it in stretch
* please build-depend on libpng-dev first (or solely)
* all those transitional packages are pointless as those from oldoldstable
  compiz can't possibly be installed on a system ever upgraded to jessie

I didn't look any closer.


Meow!
-- 
A tit a day keeps the vet away.

Bug#812922: closing 812922

[Adam Borowski]

close 812922 
thanks

The package is now in NEW.  If an update is needed, please reopen the RFS or
open a new one.

Re: reason not to upload new versions as fast as possible to unstable? (expect attempt to migrate to testing )

[Adam Borowski]

On Fri, Feb 12, 2016 at 01:21:06PM +0100, toogley wrote:
> the wicd package currently has version 1.7.3 in unstable and testing, but
> 1.7.4 is already imported. Generally speaking it seems to me very reasonable
> to try to upload versions as fast as possible into unstable and testing, so
> I'm just asking for clarification:
> 
> Apart from wanting to migrate a version from unstable to testing, is there
> any reason not to upload new upstream versions as fast as possible?

Possible reasons to tone down uploads:
* truly excessive frequency (like, dailies for more than a few days in a
  row)
* interfering with a transition
* during freeze
* libreofficeish build times
* huge tarballs

Doing two uploads in a row is perfectly fine.

-- 
A tit a day keeps the vet away.

Bug#812922: RFS: classic-theme-restorer/1.4.7-1 [ITP] -- customize the new Iceweasel look

[Adam Borowski]

On Mon, Feb 01, 2016 at 09:58:57PM -0700, Sean Whitton wrote:
> * Package name: classic-theme-restorer

In the copyright file, you wrote:

License: MPL-2.0
 This Source Code Form is subject to the terms of the Mozilla Public License,
 v. 2.0. If a copy of the MPL was not distributed with this file,
 You can obtain one at http://mozilla.org/MPL/2.0/.

but the text of the MPL is not actually provided.


Besides, thanks for packaging this!  It's a mandatory extension, no idea
what Mozilla guys were smoking when they made Australis but it must have
been something nasty.

-- 
A tit a day keeps the vet away.

Bug#814235: RFS: swi-prolog [ITA] -- ISO/Edinburgh-style Prolog interpreter

[Adam Borowski]

On Tue, Feb 09, 2016 at 05:13:50PM +0500, Lev Lamberov wrote:
> I would like to take care of swi-prolog in Debian.
> 
> [2] https://anonscm.debian.org/cgit/collab-maint/swi-prolog.git/

Alas, I'm afraid the package ships a minified sourceless copy of jquery,
both in the source and in swi-prolog-nox.  Please remove it and
depend on libjs-jquery.

I did not find any other issues beside this.

-- 
A tit a day keeps the vet away.

Bug#812824: RFS: tiny-initramfs/0.1-1 [ITA] - Minimalistic initramfs implementation

[Adam Borowski]

On Wed, Jan 27, 2016 at 12:40:33AM +0100, Christian Seiler wrote:
> I am looking for a sponsor for my package "tiny-initramfs"

Looks good to me.  There's just a few minor nits:

codespell:
./tiny_initramfs.c:89: moduels  ==> modules

manually noticed:
configure.ac:66: alternativ => alternative
tiny_initramfs.c:83: Begun => Began

configure: WARNING: optimization level other than -Os specified in CFLAGS, this 
will increase your binary size.
configure: WARNING: debugging option -g specified in CFLAGS, this will increase 
your binary size.


These are small enough that it's up to you: do you prefer to fix these now,
or do you want me to upload as-is, to be fixed in a subsequent version?

-- 
A tit a day keeps the vet away.

Re: Bug#810572: marked as done (RFS: twinkle/1:1.9.0+dfsg-3 -- Voice over Internet Protocol (VoIP) SIP Phone)

[Adam Borowski]

On Tue, Jan 12, 2016 at 10:54:05AM +, Debian Bug Tracking System wrote:
> Note for future: in debian/rules you have this line:
> 
>   ifeq (,$(filter $(DEB_HOST_ARCH),kfreebsd-amd64 kfreebsd-i386 hurd-i386))
> 
> You need to have $(DEB_HOST_ARCH) properly defined (dpkg-buildpackage does
> this for you, but you should not rely on that). Please see the “Usage in
> debian/rules” section of dpkg-architecture(1) for details.
> 
> Also, it's better to replace that with this line:
> 
>   ifneq (,$(filter $(DEB_HOST_ARCH_OS),linux))
> 
> That will work even when we get hurd-amd64 or kfreebsd-armhf ;)

You can install illumos-amd64 right now: http://osdyson.org/
(No, I don't port there, other than to troll :p)

-- 
A tit a day keeps the vet away.

Re: Bug#808538: RFS: corebird

[Adam Borowski]

On Wed, Dec 30, 2015 at 01:11:52PM +0100, Iain R. Learmonth wrote:
> When I asked before about this, although this was a while ago, I was told
> the buildds would only use one core per build anyway so I didn't think this
> would be useful. I guess this has changed now.

Let's take a look at package build logs:
amd64   DEB_BUILD_OPTIONS=parallel=4
arm64   DEB_BUILD_OPTIONS=parallel=8
armel   DEB_BUILD_OPTIONS=parallel=4
armhf   DEB_BUILD_OPTIONS=parallel=4
i386DEB_BUILD_OPTIONS=parallel=8
mipsDEB_BUILD_OPTIONS=parallel=2
mipsel  DEB_BUILD_OPTIONS=parallel=5
powerpc DEB_BUILD_OPTIONS=parallel=2
ppc64el DEB_BUILD_OPTIONS=parallel=8
s390x   DEB_BUILD_OPTIONS=parallel=2
hppa-
hurd-i386   -
kfreebsd-amd64  DEB_BUILD_OPTIONS=parallel=2
kfreebsd-i386   DEB_BUILD_OPTIONS=parallel=2
m68kDEB_BUILD_OPTIONS=nobench nocheck
mips64elDEB_BUILD_OPTIONS=parallel=4
ppc64   -
sh4 DEB_BUILD_OPTIONS=nobench nocheck
sparc64 DEB_BUILD_OPTIONS=nobench nocheck
x32 DEB_BUILD_OPTIONS=nobench nocheck
(yeah, I know there are more than 1 buildds per arch, the above data shows
just the one that was used)

So every release architecture builds in parallel.

-- 
A tit a day keeps the vet away.

Bug#808613: RFS: re2c/0.15.3-1 [ITA] -- tool for generating fast C-based recognizers

[Adam Borowski]

>   Package name: re2c

Alas, the new version failed to build on five architectures.  Even worse,
the build logs contain no meaningful output:

.--
make  check-TESTS
make[2]: Entering directory '/«PKGBUILDDIR»'
make[3]: Entering directory '/«PKGBUILDDIR»'
FAIL: run_tests.sh
PASS: testrange
PASS: testston32unsafe

Testsuite summary for re2c 0.15.3

# TOTAL: 3
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See ./test-suite.log
Please report to re2c-gene...@lists.sourceforge.net

Makefile:1313: recipe for target 'test-suite.log' failed
`--

Could you please create an "override_dh_auto_test" target in debian/rules that
runs "$(MAKE) check" and if it fails, cats test-suite.log?

Debugging the failure requires access to a machine, real or emulated, of one
of architectures that fail.  I suspect that you have no mips, powerpc,
s390x, hppa or sparc64 machines lying around -- and access to Debian's
porterboxes is restricted to DDs only which makes using them greatly
unconvenient.  Thus, I'd strongly recommend using qemu.  You can either
install a virtual machine by hand (which requires reading arch-specific
docs) or fetch a pre-made image from
https://people.debian.org/~aurel32/qemu/ -- unfortunately, these haven't
been updated since wheezy which requires dist-upgrades to jessie then
unstable.


-- 
A tit a day keeps the vet away.

Re: Bug#809199: RFS: gap-guava/3.12+ds1-3 [unrep fix] [dbg] -- coding theory library for GAP

[Adam Borowski]

On Mon, Dec 28, 2015 at 07:35:13PM +, Mattia Rizzolo wrote:
> On Mon, Dec 28, 2015 at 08:23:39PM +0100, Jerome BENOIT wrote:
> > I play with the bpo version on my every day box,
> > but, since debhelp is the Jessie version, no extra/hidden -dbgsym
> > is generated.
> 
> You should build your package in a chroot of the target distribution,
> always (in this case, you need a sid chroot).

Having such a chroot is good for testing whether the package works, but if
you want to check whether build-depends are appropriate, you need a minimal
clean build environment.  For this, you can use pbuilder or sbuild.

-- 
A tit a day keeps the vet away.

Bug#808231: RFS: mkcast/1.0.0-1 [ITP]

[Adam Borowski]

On Thu, Dec 17, 2015 at 06:57:56PM +0530, 55abhil...@openmailbox.org wrote:
>  * Package name: mkcast
>  * URL : https://github.com/KeyboardFire/mkcast
> mkcast - A tool for creating GIF screencasts of a window, with key
> presses
> 
>   http://mentors.debian.net/package/mkcast

Hi!
Before requesting sponsoring could you please address what lintian says?
It returns a pretty long list, so a manual review at this point would be
a waste of time.
If you invoke lintian with -i, it gives a pretty good description of what a
problem is and how to fix it.


Meow!
-- 
A tit a day keeps the vet away.

Bug#782847: endless-sky: uploaded

[Adam Borowski]

Hi!

I've became a DD today.  Thus, as promised, I've just uploaded endless-sky
to Debian.  It will spend some times in the "NEW" purgatory where the
ftpmasters review it.

There were two issues with what you uploaded to mentors.debian.net:
* the package was versioned 0.8.8-2 with no 0.8.8-1
* the copyright file didn't obey the special-casing for "public-domain"

The latter is partially my fault, I did not know the machine-readable
copyright format handles public-domain differently.  According to
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ :

# When the License field in a paragraph has the short name public-domain,
# the remaining lines of the field must explain exactly what exemption the
# corresponding files for that paragraph have from default copyright
# restrictions.

and indeed, unlike other licenses which must have exactly one definition,
public-domain needs further data in its every use.


I took the liberty to change both of these myself.  If for some reason I did
something wrong (like, if you insist on 0.8.8-2 due to having 0.8.8-1 in
some other repository), please say so, there's plenty of time to
cancel/amend the upload before it clears NEW.  I'm still learning myself...

I attached the debdiff, please apply it to your private copy of the
packaging so it's included in your next upload.

When there's a new version, there's no need to file a RFS, you can contact
me directly.


Meow!
-- 
A tit a day keeps the vet away.
diff -Nru endless-sky-0.8.8/debian/changelog endless-sky-0.8.8/debian/changelog
--- endless-sky-0.8.8/debian/changelog  2015-11-25 21:30:26.0 +0100
+++ endless-sky-0.8.8/debian/changelog  2015-12-09 13:14:27.0 +0100
@@ -1,4 +1,4 @@
-endless-sky (0.8.8-2) unstable; urgency=low
+endless-sky (0.8.8-1) unstable; urgency=low
 
   * Initial release. (Closes: #782846)
 
diff -Nru endless-sky-0.8.8/debian/copyright endless-sky-0.8.8/debian/copyright
--- endless-sky-0.8.8/debian/copyright  2015-11-25 21:27:16.0 +0100
+++ endless-sky-0.8.8/debian/copyright  2015-12-09 13:37:06.0 +0100
@@ -32,25 +32,25 @@
  images/planet/venus*
 Copyright: NASA
 License: public-domain
-Comment: From NASA, and therefore in the public domain because they were 
created
+ From NASA, and therefore in the public domain because they were created
  by government employees while doing work for the government.
 
 Files: images/scene/*
 Copyright: Various
 License: public-domain
-Comment: Taken from morguefile.com, a collection of photographs that have been
+ Taken from morguefile.com, a collection of photographs that have been
  donated and placed in the public domain. (Exceptions noted below.)
 
 Files: images/scene/loc*
 Copyright: Library of Congress
 License: public-domain
-Comment: From the Library of Congress. Public domain because they are
+ From the Library of Congress. Public domain because they are
  photographs taken by a government employee as part of their job.
 
 Files: images/scene/army*
 Copyright: US Army
 License: public-domain
-Comment: From the US Army. Public domain because they are photographs taken by 
a
+ From the US Army. Public domain because they are photographs taken by a
  government employee as part of their job.
 
 Files:
@@ -58,13 +58,13 @@
  images/scene/engine2*
 Copyright: NASA
 License: public-domain
-Comment: From NASA, and therefore in the public domain because they were 
created
+ From NASA, and therefore in the public domain because they were created
  by government employees while doing work for the government.
 
 Files: images/land/*
 Copyright: Various
 License: public-domain
-Comment: Taken from morgue-file.com, a collection of photographs that have been
+ Taken from morgue-file.com, a collection of photographs that have been
  donated and placed in the public domain. (Exceptions noted below.)
 
 Files: images/land/bwerner*
@@ -127,14 +127,14 @@
  images/land/water8*
 Copyright: Various
 License: public-domain
-Comment: Taken from unsplash.com, a collection of photographs that have been
+ Taken from unsplash.com, a collection of photographs that have been
  donated and placed in the public domain.
 
 Files:
  images/land/lava0*
 Copyright: USGS
 License: public-domain
-Comment: From the USGS, and therefore in the public domain because they were
+ From the USGS, and therefore in the public domain because they were
  created by government employees while doing work for the government.
 
 Files:
@@ -148,7 +148,7 @@
  images/land/station4*
 Copyright: NASA
 License: public-domain
-Comment: From NASA, and therefore in the public domain because they were 
created
+ From NASA, and therefore in the public domain because they were created
  by government employees while doing work for the government.
 
 Files:
@@ -161,7 +161,7 @@
 Files: sounds/*
 Copyright: Écrivain, Iwan Gabovitch, Bart Kelsey, others.
 License: public-domain
-Comment: From opengameart.org. The contributors have placed these sounds in the
+ From opengameart.org. 

Bug#782847: RFS: endless-sky/0.8.0-1 [ITP]

[Adam Borowski]

Hi!

On Fri, Jul 24, 2015 at 12:22:56AM +0200, Adam Borowski wrote:
> On Tue, Jul 21, 2015 at 10:50:23PM -0400, Michael Zahniser wrote:
> >  * Package name: endless-sky

I see you've just made a new release, 0.8.8-1.  I reviewed it.  Too bad,
almost all points I described in my previous review are still there -- could
you please address them?

I'm almost a DD, waiting only for account creation.  It seems this is done
roughly monthly, so I expect to be able to be able to upload before the end
of the year.  Thus, if you won't find a sponsor before then, I'll do so.

> I'm afraid it fails to build in sbuild, because the first alternative in
> "libjpeg-turbo8-dev | libjpeg62-turbo-dev" is notexistant, and sbuild
> ignores everything but the first, per the buildd policy.  And sbuild is
> what the autobuilders use...

Please depend on "libjpeg-dev", either solely or as the first alternative. 
That's a metapackage that depends on the default libjpeg implementation, in
Debian that's libjpeg62-turbo-dev, in Ubuntu libjpeg-turbo8-dev.

> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 76)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 82)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 88)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 165)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 184)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 189)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 194)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 199)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 561)
> W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
> line 875)
> 
> This is because you use paragraphs like:
> .
> License: CC-BY-SA-3.0
>  (creativecommons.org/licenses/by-sa/3.0)
>  Taken from Wikimedia commons. Cropped and edited.
> `
> You want instead:
> .
> License: CC-BY-SA-3.0
> Comment: Taken from Wikimedia commons. Cropped and edited.
> `
> as the definition of what "CC-BY-SA-3.0" means is already included.


> Also, single-threaded build is _slow_.  This may be fixed by using:
> .
> ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))
>PROCS=$(patsubst parallel=%,%,$(filter 
> parallel=%,$(DEB_BUILD_OPTIONS)))
>SCONS_OPTIONS += -j$(PROCS)
> endif
> `
> then changing scons invocations to $(SCONS) $(SCONS_OPTIONS)

This one is not mandatory, but makes test builds of the package a lot
faster.  If you have a 6-way machine and set DEB_BUILD_OPTIONS=parallel=6
the build will be nearly that much faster.


Meow!
-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Bug#782847: RFS: endless-sky/0.8.0-1 [ITP]

[Adam Borowski]

On Wed, Nov 25, 2015 at 02:05:04PM -0500, Michael Zahniser wrote:
> The issue with libjpeg is that I'm relying on the JCS_EXT_BGRA extention in
> libjpeg-turbo to decode JPEGs in the proper byte order for on-screen
> display. The ordinary libjpeg does not provide that extension.

Right, that's something I wondered about.

> But, I suppose I could switch to putting the Debian-specific option first,
> since I don't think Ubuntu / Launchpad has issues with the "|" syntax.  Or
> I could just use plain libjpeg-dev and trust that everyone building the
> package is on an OS where that means libjpeg-turbo, but that seems risky.

I don't know Ubuntu's autobuilders, so I don't know what's needed to make
them happy, other that every supported release (precise and up) has a
libjpeg-dev metapackage that depends on libjpeg-turbo8-dev.  On Debian's
side, though, there are only two obvious solutions:
1. build-depending on libjpeg-dev first or only
2. build-depending on libjpeg62-turbo-dev first or only

Also, in Debian, wheezy (oldstable) doesn't have jpeg-turbo at all.  I
wonder how much do you care for backports to oldstable.  As that would
entail backporting libraries, I'd personally not bother at all.

Thus, my recommendation is libjpeg-dev, as that handles both Debian and
Ubuntu from a single source.  In theory, one could add build-conflicts
against unsuitable libjpegs, but as that won't allow wheezy builds anyway
I wouldn't bother.

> The other changes sound easy, so if you let me know what you think is a
> good approach for libjpeg, I can upload a fixed package.

Sadly, I cannot upload today as I'm only _almost_ a DD...  Account requests
are processed roughly monthly, and there might be some delay before the
keyring gets updated.  But as others can sponsor you immediately, it can't
hurt to prepare the package soon.


Meow!
-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Re: Package gresolver don't go to package list

[Adam Borowski]

On Fri, Nov 13, 2015 at 01:25:37PM -0200, Paulo wrote:
> I adopted the package gresolver recently, in my first upload to mentors my 
> sponsor discovery that
> even a package is in perl, architecture in d/control was defined as "any" and 
> suggests me to change to "all".
> 
> So I changed d/control and put architecture to "all".
> 
> The package in version 0.0.5-6: all was upload and now is in repositories [1]
> but old version 0.0.5-5 remains in binary list.

You need to ask for a manual removal of old binaries, as in any case when an
architecture is no longer built.  Please file a bug on the ftp.debian.org
pseudopackage titled "RM: gresolver [any]", mentioning that you changed it
from arch:any to arch:all.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Re: Best practices for downloader packages

[Adam Borowski]

On Mon, Aug 17, 2015 at 01:29:12PM +0200, Ole Streicher wrote:
  * Since the download code if DFSG-Free, the downloader goes to
  contrib, independently of the copyright of the data, right?
 
  Right.
 
  which is a bit pity, since the package *is* actually DFSG-free,
 including the downloaded data. The reason that they are not in the
 Debian archive is just a technical, not a license one: The source data
 size is about 8 GB, and the binary packages are from 160 MB to ~13 GB.

As, unlike most downloaders, it doesn't deal with non-free data, I don't get
why it would be unacceptable for main.  It's strictly better than clients
for various proprietary services, which sit in main.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Re: RFS: cl-launch (updated package)

[Adam Borowski]

On Sat, Aug 01, 2015 at 11:22:09AM -0400, Faré wrote:
  - Copyright years are not up to date
 Interestingly, lawyers at $BIG_COMPANY_EMPLOYER have recently opined
 that the year the software was started is the only one needed on
 copyright statements.

Strictly speaking, it will make a difference when copyright is about to
expire, but as none of us will be then alive, it's not our problem.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150801175701.ga32...@angband.pl

Re: Are the build-arch and build-indep targets required?

[Adam Borowski]

On Wed, Jul 29, 2015 at 12:04:10PM +0200, Ferenc Wagner wrote:
 build-arch (required), build-indep (required)
 
 but a couple of paragraphs later is also says:
 
 Both binary-* targets should depend on the build target, or on the
 appropriate build-arch or build-indep target, *if provided*, [...]
 
 (emphasis mine) which implies that build-{arch,indep} may not be
 provided after all, that is, they are not required.
 
 So, what is the right interpretation of the above?  Are they required or
 not?

Historically these targets didn't exist then for a period of time were only
optional.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150729104839.ga11...@angband.pl

Re: Bug#782847: RFS: endless-sky/0.8.0-1 [ITP]

[Adam Borowski]

On Tue, Jul 21, 2015 at 10:50:23PM -0400, Michael Zahniser wrote:
  * Package name: endless-sky

I'm afraid it fails to build in sbuild, because the first alternative in
libjpeg-turbo8-dev | libjpeg62-turbo-dev is notexistant, and sbuild
ignores everything but the first, per the buildd policy.  And sbuild is
what the autobuilders use...

I wonder, why do you depend on particular versions of libjpeg?  Do you
happen to use libjpeg-turbo extensions, or just want a fast optimized
version?  If the latter, it'd be better to declare a dependency on just
libjpeg-dev, which on jessie or higher means jpeg-turbo but will degrade
to libjpeg8 if someone wants a backport to wheezy.


Lintian says:
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 76)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 82)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 88)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 165)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 184)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 189)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 194)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 199)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 561)
W: endless-sky source: dep5-copyright-license-name-not-unique (paragraph at 
line 875)

This is because you use paragraphs like:
.
License: CC-BY-SA-3.0
 (creativecommons.org/licenses/by-sa/3.0)
 Taken from Wikimedia commons. Cropped and edited.
`
You want instead:
.
License: CC-BY-SA-3.0
Comment: Taken from Wikimedia commons. Cropped and edited.
`
as the definition of what CC-BY-SA-3.0 means is already included.


Also, single-threaded build is _slow_.  This may be fixed by using:
.
ifneq (,$(findstring parallel,$(DEB_BUILD_OPTIONS)))
   PROCS=$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
   SCONS_OPTIONS += -j$(PROCS)
endif
`
then changing scons invocations to $(SCONS) $(SCONS_OPTIONS)


Also, the .desktop entry doesn't show in the menu for me (XFCE), I have no
idea why, though.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015072356.ga19...@angband.pl

Re: dh --buildsystem=none?

[Adam Borowski]

On Mon, Jun 15, 2015 at 04:34:04PM +0200, Ole Streicher wrote:
 So, the debian/rules file is simple
 ---8--
 #!/usr/bin/make -f
 %:
   dh $@
 ---8--
 
 However, for some reason dh tries to run configure etc., which
 ofcourse fails. How can I explicitely specify a build system that
 actually does nothing?

Do you have a configure lying around?  If it's not present, dh will not
try to run it.  Works for me, at least.

As detection of configure works by looking at the presence of configure
(duh), it feels odd to me to get a false positive.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150615204451.gb28...@angband.pl

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

[Adam Borowski]

On Mon, Mar 09, 2015 at 11:49:08PM +0100, Stephen Kitt wrote:
  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...

Good idea, I've just done so.

   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.

The version number is just something help2man wants, man works fine without.

  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.

Done.

 Shall I wait for that then before uploading?

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


-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150309233829.ga25...@angband.pl

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

[Adam Borowski]

On Sun, Mar 08, 2015 at 04:20:08PM +0100, Stephen Kitt wrote:
 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
 
 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.

 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.

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


Meow!
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150309095701.ga29...@angband.pl

Re: shlib symbolic link to optional lib in libfoo-dev ?

[Adam Borowski]

On Mon, Mar 09, 2015 at 10:45:36AM +0100, Václav Ovsík wrote:
 On Mon, Mar 09, 2015 at 11:03:33AM +0800, Paul Wise wrote:
  Could you mention how the debug variant differs from the normal variant?
 
 The debug variant is compiled with -O1 (the normal/optimized variant
 with -O2) and the debug variant has many checks (assertions).

With recent gcc, it's better to use -Og for that.  That level of
optimization is made to use only optimizations that don't interfere with
debugging, yet still produce code that's way faster than -O0.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150309100024.gb29...@angband.pl

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

[Adam Borowski]

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

The m.d.n page:
http://mentors.debian.net/package/git-tools
dget
http://mentors.debian.net/debian/pool/main/g/git-tools/git-tools_1.0.0-1.dsc

The main installed tool, git restore-mtime sets the timestamp of each file
in the working dir to the date of the last commit that touched that file.
This is useful whenever timestamps provide some value, as opposed to just
being older/newer than the result of a make command.

There's three other tools: git clone-subset butchers a repository (incl. 
history) leaving only files you choose, git find-uncommitted-repos
searches your filesystem for unclean git repos, git strip-merge helps
drop some files during merge.


It would be nice if someone could sponsor this for me.


[¹]. Lintian checks only programs in [/usr]/[s]bin, not in /usr/lib/git-core,
so this did not get caught.
-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150303225215.ga8...@angband.pl

Bug#778729: RFS: git-tools

[Adam Borowski]

On Thu, Feb 19, 2015 at 02:09:49AM +, Chris Lamb wrote:
  Actually, the upstream project name is git-tools as there's a bunch more
  utilities included.  I dropped three that were obsolete or redundant, and
  bundled three others, yet the package name I used reflects only what I
  consider to be the main meat.
 
 I would strongly recommend the source package name be  git-tools (or
 similar) to match upstream, even if the binary package is, for example,
 git-restore-mtime (although even here I am not sure that is wise).

Ok, I uploaded a renamed version, as you suggested.  The dget address is now:
http://mentors.debian.net/debian/pool/main/g/git-tools/git-tools_1.0.0-1.dsc

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150219164137.ga15...@angband.pl

Bug#778729: RFS: git-restore-mtime/1.0.0-1 [ITP]

[Adam Borowski]

Package: sponsorship-requests
Severity: wishlist

Hi folks!

I am looking for a sponsor for my package git-restore-mtime.

* Package name: git-restore-mtime
  Version : 1.0.0-1
  Upstream Author : Rodrigo Silva (MestreLion) li...@rodrigosilva.com
* URL : https://github.com/MestreLion/git-tools
* License : GPL3+
  Section : vcs

It builds those binary packages:
  git-restore-mtime - set timestamps to the date of a file's last commit

The m.d.n page:
http://mentors.debian.net/package/git-restore-mtime

Dgettable .dsc:
http://mentors.debian.net/debian/pool/main/g/git-restore-mtime/git-restore-mtime_1.0.0-1.dsc

It's a tool that, when ran in a git repository, sets each file's mtime
to the date of most recent commit that changed that file -- ie, an
approximation of what mtimes are supposed to do.  This is nice when
making a release tarball, or if you're using git for storing something
else than a program's sources.

Actually, the upstream project name is git-tools as there's a bunch more
utilities included.  I dropped three that were obsolete or redundant, and
bundled three others, yet the package name I used reflects only what I
consider to be the main meat.  My reason is, the name git-tools is too
generic, and git-restore-mtime is what users would be looking for.
If you disagree with my judgement, please say so!


As the Supreme Species say,
meow.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150219015352.ga13...@angband.pl

Bug#776534: RFS: 3270font/1.2-1 [ITP]

[Adam Borowski]

Package: sponsorship-requests
Severity: wishlist

Hi folks!
I am looking for a sponsor for my package 3270font.

* Package name: 3270font
  Version : 1.2-1
  Upstream Author : Ricardo Bánffy rban...@gmail.com
* URL : https://github.com/rbanffy/3270font
* License : BSD3
  Section : fonts

It builds those binary packages:

  fonts-3270 - monospaced font based on IBM 3270 terminals

The mentors page: http://mentors.debian.net/package/3270font

Dgettable from:
http://mentors.debian.net/debian/pool/main/3/3270font/3270font_1.2-1.dsc

Lintian clean, tested in sbuild.

Fontforge's fontlint gives one warning when ran on source .sfd:
Missing BlueValues entry in PostScript Private dictionary
but this has no apparent effect on produced .otf.
There was a lot of other warnings, but they're all fixed, sent and
accepted upstream.

Other checkers (ftvalid, ftlint) are quiet.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150129030643.26988.22844.report...@umbar.angband.pl

Re: Bug#769673: RFS: lletters/0.1.95+gtk2-4 [ITA, RC]

[Adam Borowski]

On Tue, Jan 06, 2015 at 11:37:04PM +0200, Dmitry Borisyuk wrote:
 I looked at everything once more, and decided not to adopt lletters.
 Sorry for wasting your time.

Perhaps the package (both lletters and letters-media) should be RMed
instead?
* dead upstream since 2001
* not quite the best children's game...
* can be recreated in a RAD tool like Lazarus in minutes:
  • make a button, resize it
  • set the button's action to launch a modal dialog with the button's
caption (the letter) as argument
  • copypaste it 35 times, labelling with sequential digits+letters,
arranged in a rough grid without caring much about alignment
  • set the main window to scalable
  • create that dialog -- with a large image inside that's loaded from
the disk, the image's click action being close the dialog
  • on the dialog's start, play a sound if it exists.  For bonus points
compared to lletters, DON'T crash doing so.
  • ... and that's all
* likewise, lletters-media can be recreated/greatly improved by throwing
  everything away then raiding a collection of freely-licensed images. 
  Picking a set with a semi-consistent style would be a large change.
* localization is worse than none.  For Polish, for example, more than
  half buttons use a word from some other language.
* letters not in Polish (q, v, x) are present while ć, ł, ó, ś, ż, ź
  are missing

Thus, if no one steps up to maintain, perhaps it'd be better to axe
lletters.  It would save the time of QA (most recently, Markus Koschany
fixing multiple FTBFS bugs).


-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150107071511.ga21...@angband.pl

Re: Bug#767588: RFS: 2048/1.0-3 [ITP] Simple number game for the text console

[Adam Borowski]

On Sun, Nov 02, 2014 at 06:50:08PM +0100, Gabriel Pérez-Cerezo wrote:
  Speaking of source, how was the .orig.tar generated? I don't see any
  tarballs on the upstream homepage.
 The tarball was generated with `make dist` on the source in the git 
 repository.

The .orig.tar.gz on m.d.n doesn't match the dsc.

   snprintf(color,length,\033[38;5;%d;48;5;%dm,*foreground,*background);
 This seems to work on all X terminal emulators that I have tried, maybe
 because they support 256 colors, but it doesn't work on the framebuffer. 
 I will try to fix this.

I did fix this one already, in kernel 3.16 :p

You still might want to use traditional color codes, for older kernels, BSD
console, ajaxterm and possibly others.  Debian's package rxvt
misinterprets xterm-256 colors as well, we should have replaced it with
rxvt-unicode-256color ages ago.  Otherwise, support for 256 colors is
pretty ubiquitous.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103030302.ga18...@angband.pl

Re: Bug Severity Help

[Adam Borowski]

On Tue, Oct 07, 2014 at 11:40:53PM -0400, Bill Blough wrote:
 In my opinion, people *shouldn't* be running untrusted stylesheets any more
 than they should run untrusted shell scripts or other code.  If we 
 conveniently
 ignore that sometimes people do things that are unwise, then I would say the
 likelyhood is low.

In that case, it's a normal severity bug at most.  Most of Turing-complete
languages allow OOMing, and if Xalan stylesheets can already run arbitrary
code, an attacker can do things a lot funnier than just OOM.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141008043850.ga19...@angband.pl

Re: Build-depending on non-free package

[Adam Borowski]

On Tue, Sep 02, 2014 at 02:20:59PM -0400, Paul Tagliamonte wrote:
  We want to provide a binary distribution to our end users, and we want
  to have best possible experience, right?
 
 We want to provide a libre / *free* distribution to our end users.
 Anything else is just tolerated / hosted. non-free is *not* Debian (the
 distribution), it's simply hosted on Debian project infra.

While I hate non-free as much as you do, it's sadly needed for way too many
reasons to dismiss it.

For example, every single non-headless computer I own requires non-free for
graphical display: nvidia (nouveau crashes hourly on my card), mali (with a
non-packaged blob), etc.  Non-free network card firmware[1].  CPU microcode
updates.

Compiler documentation, from FSF itself[2]!

Even main contains some thoroughly non-free stuff like AGPL (nasty use
restrictions).

Seriously, the world we live in sucks.  We should do all we can to replace
non-free bits, but for now, refusing for a package in contrib to autobuild
is counterproductive.


[1]. Technically, the card in question does work with firmware in ROM.  Yet
I see no reason non-free code in ROM would be better than bug-fixed non-free
code loaded from disk that updates it.

[2]. And it's not an issue of just immutable sections.  GFDL without those
is accepted in main for political reasons, despite forbidding such use as
chmod o-r or locking the door to your server room with technological means
known as a key.

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140902191259.ga25...@angband.pl

Bug#759796: RFS: gemrb/0.8.1-1

[Adam Borowski]

On Sat, Aug 30, 2014 at 04:13:45PM +0200, Beren Minor wrote:
 * Package name: gemrb

When attempting to build:

.
CMake Error at CMakeLists.txt:211 (MESSAGE):
  Looking for Glew: not found!


CMake Error at CMakeLists.txt:212 (MESSAGE):
  Please install the Glew library and headers first!


-- Configuring incomplete, errors occurred!
`

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140830222040.ga24...@angband.pl

Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]

[Adam Borowski]

On Mon, Jul 14, 2014 at 04:27:40PM +0100, bofh80 wrote:
 Thanks for the feedback, I've uploaded 0.6.1 with an extra depends.
 I've checked in a vm without e17 installed this time to make sure it works
 first.
 If you'd be so kind as to check the new version and let me know?

The new version appears to work for me.

I have not looked at packaging details, testing merely the functionality
itself.

By the way, do you happen to know if terminology is supposed to replace
eterm, or are both going to live together?

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140714200407.ga11...@angband.pl

Re: Bug#754260: RFS: terminology/0.6.0-1 [ITP]

[Adam Borowski]

On Wed, Jul 09, 2014 at 09:57:20AM +0100, Anthony F McInerney wrote:
  * Package name: terminology

It fails to start, with the following output:

CRI20400:elementary elm_win.c:2858 _win_constructor() Software X11 engine 
creation failed. Trying default.
ERR20400:elementary elm_win.c:2994 _win_constructor() Cannot create window.
ERR20400:eo lib/eo/eo.c:1217 eo_error_set_internal() Error with obj 
'0x2369c00' at elm_win.c:2995
ERR20400:eo lib/eo/eo.c:1107 eo_add_internal() in elm_win.c:2718, Object of 
class 'Elm_Win' - One of the object constructors have failed.
ERR20400:eo lib/eo/eo_ptr_indirection.x:275 _eo_obj_pointer_get() obj_id 
(nil) is not pointing to a valid object. Maybe it has already been freed.
ERR20400:efreet_cache lib/efreet/efreet_cache.c:1108 on_send_register() 
org.enlightenment.DBus.Canceled Canceled by user.


-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140709101745.ga26...@angband.pl

Re: Please help reproducing / fixing #751277 on architectures mips*, powerpc and s390x

[Adam Borowski]

On Fri, Jun 13, 2014 at 07:11:05PM +0200, Jakub Wilk wrote:
 Don't be afraid! :-) Fixing most portability doesn't require deep
 knowledge about the architecture. It's often enough to be aware
 about the basic differences between them, like endianness, bitness,
 or whether unaligned access is permissible

And in this case, where build fails on all big-endian architectures but
succeeds on all little-endian, let us think what the cause might be.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140613173503.ga29...@angband.pl

Re: Starting an application on login

[Adam Borowski]

On Wed, Jun 04, 2014 at 11:07:25AM +0100, Daniel Lintott wrote:
 currently BuildNotify needs to be
 started/running to access the configuration GUI.

What about this:
make the menu entry call a script that:
* checks if the BuildNotify daemon is running
* if not, starts it (as the user)
* then starts the GUI

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140604204349.ga13...@angband.pl

Bug#748882: RFS: hashalot/0.3-6 (updated, resend)

[Adam Borowski]

Package: sponsorship-requests
Severity: normal

Hi guys!  It would be nice if someone could upload hashalot for me
(a tool for securely reading a passphrase).  This upload fixes a must
requirement of the policy.

The package can be dgetted from:
http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc

The changelog is:
  * Document that only the first line of input is hashed, for people who
are looking for a general purpose hasher.  Closes: #544165.
  * Fix warnings from man.
  * Replace debian/rules with dh.
  * Use DEP-5 copyright format.
  * Drop useless README and ancient NEWS.Debian.
  * Upgrade the VCS to git.
+ ... including Vcs- fields (closes: #720265).
  * Upgrade to policy 3.9.5 (build-{arch,indep}), debhelper 9 (hardening).

The big change here is changing old style packaging to a dh two-liner.
Thus, it's probably easier to review this upload as a new package -- but
thanks to dh, that's quite minimal work.

Meow!


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140521190620.4084.33347.report...@umbar.angband.pl

Re: What do you do when your sid development system stops working?

[Adam Borowski]

On Sun, May 11, 2014 at 09:33:58PM -0500, Paul Elliott wrote:
 I like to do my packaging under sid, because
 that is where the packages will first have to run, so
 I can test them there.
 
 But what do you do when your sid system stop work
 after doing an apt-get dist-upgrade? X11 stopped working
 no screens found.

When running unstable, you really want some way to restore the system to a
working state quickly.  Ie, backup with convenient means of restore,
preferably ones that work when the system became unbootable.

I'd heartily recommend a btrfs based scheme here.  A traditional filesystem
plus a recovery partition can do the trick, but restore with a single
command is just too nifty to not have if, say, your X relies on nvidia
drivers[1], or some folks upload broken init systems that switch without
warning.

I for one use this set of subvolumes[1]:

boot   /boot
sys-current/
home   /home

In cron, there is:
btrfs subv snap sys-current sys-`date +%Y-%m-%d`

When shit happens, you snapshot sys-2001-09-10 back onto sys-current and
reboot.  If the system is too broken to give you a shell, you append
subvol=2001-09-10 to the kernel's cmdline in grub.

This way, you can use unstable without fear.



[1]. They stay broken for weeks whenever a new kernel comes, xorg gets a new
ABI, etc.  But unlike nouveau, they don't crash on my box.

[2]. Plus cache for /var/cache, plus kb-cache for /home/kilobyte/.cache
(especially a big ccache), plus SSD/HDD micromanaging, plus tens of chroots,
etc, etc.  I'd recommend these three for a start, though.  And you must not
split /usr from /var /bin /sbin /lib /etc or you'll risk them going out of
sync.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140512090327.ga22...@angband.pl

Re: DFSG and assembler code

[Adam Borowski]

On Wed, Aug 21, 2013 at 10:36:12PM +0900, Charles Plessy wrote:
 Le Wed, Aug 21, 2013 at 10:01:29AM +0200, Andreas B. Mundt a écrit :
  
  To be able to compile the program with standard tools, the
  pre-compiled code of the ROM-dumpers is included in the source.  This
  code needs to be removed for DFSG reasons.
 
 note that the DFSG do not imply that we need to remove the pre-compiled code
 from the source package.  If 1) it can be redistributed; 2) its source code is
 provided; 3,4) its modification is allowed in practical terms; 5,6) there are
 no unreasonable restrictions on how to use it, and 7,8,9) its license is not
 awkward, then the work is Free according to the DFSG.
 
 Nevertheless, our current quality standards for the binary packages is that
 each file must be rebuildable from source, and for the ROMs discused here,
 without the proper compiler in Debian it is not possible.  So in practice, 
 this
 pre-compiled code can not be added to the binary packages, but I would like to
 stress that it is not because of the DFSG.

Such code is welcome in the contrib section, though.

And you don't even need to split the source package: sources in main may
produce contrib binaries.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130821181758.ga14...@angband.pl

Re: DFSG and assembler code

[Adam Borowski]

On Mon, Aug 19, 2013 at 11:55:12PM +0200, Andreas B. Mundt wrote:
 It contains so-called ROM-dumpers in assembler code which have been
 removed for DFSG reasons on the older versions of this package, and I
 followed that example and removed them from the version in sid as
 well.
 
 However, as dumping the ROM of the calculator is an important feature,
 I had a closer look at the files removed and I found that they are all
 GPLv2+ (the upstream changelog mentions some rewrite and also some
 licence changes).  However, they are still assembler.

Assembler is just as valid a programming language as any other (or more,
compared to, say, Malbolge).  And here you have comments, #ifdefs and so
on, so it's not the result of disassembly.

Ie, fully kosher DFSG code.

 Is it necessary to remove the files for DFSG reasons?

No, why?  They come with source which is clearly the preferred form for
modification.  If assembler was forbidden, we'd have to kick out such
unimportant packages as linux, etc.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130819223032.ga11...@angband.pl

Re: Packaging for multiarch i386 sse2/non-sse2

[Adam Borowski]

On Sun, Aug 18, 2013 at 10:39:12PM +0200, Fabien Givors (Debian) wrote:
 As this can be expected, this library rely on sse2 instruction set.
 However, most of the features (except for software video rendering) are
 available (sometimes in a degraded mode, eg. the sound part might be
 slower) for non-sse2-capable hardware.
 
 Should I preferably:
 
 A - build a lib-without-sse2 package on all but amd64 architectures
 and a lib-with-sse2 package on i386 and amd64 architectures ?

That would make it useless on most i386 machines.  sse2 support doesn't
imply being amd64 capable, but the subset of systems that have sse2 but
can't run amd64 is limited to just some early Pentium 4 models.

Quite a few people run i386 on amd64 machines, true, but I'd say the
primary purpose of i386 is to support legacy stuff.  Thus, shipping a
library that requires a newer processor is pointless -- precisely same
as if you required hardware math in an armel package.  It will run on
some machines but not all (heck, I'm typing these words on an armhf
capable device running armel maemo, with a good subset of packages
recompiled for thumb2).

 B - build a lib package on all architectures which will be build with
 sse2 options on amd64, with non-sse2 on all except i386 and amd64 and
 with both versions on i386 (I've heard that multiarch permits to ship
 both versions so that ld chose the right one at runtime)

Multiarch by itself permits only shipping per-architecture but not per-model
versions.  There are proposals to do so, but they're in exploratory stages
yet.  If such a support for sub-architectures gets added to dpkg, it would
be a solution for you.

 C - your solution here

C - ship both versions on i386 and switch between them on runtime

D - just build non-sse2 on i386

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130818214420.ga7...@angband.pl

Bug#719652: RFS: hashalot/0.3-6

[Adam Borowski]

Package: sponsorship-requests
Severity: normal

Hi folks!

I'm looking for a sponsor for an update to hashalot.

This includes a fix for missing build-{arch,indep}, which are supposed to
become RC soon (already a must clause of the policy).

Otherwise, though, this just a regular cleaning for a package that works
without further modification.  The packaging, though, was so old and musty
that it was faster to nuke it from the orbit and replace with a trivial
call to dh.  The copyright file has been rewritten to DEP-5 as well.

The changelog:
  * Document that only the first line of input is hashed, for people who
are looking for a general purpose hasher.  Closes: #544165
  * Fix warnings from man.
  * Replace debian/rules with dh.
  * Use DEP-5 copyright format.
  * Drop useless README and ancient NEWS.Debian.
  * Upgrade the VCS to git.
  * Upgrade to policy 3.9.4 (build-{arch,indep}), debhelper 9 (hardening).

To get it:
dget http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130813221329.ga3...@angband.pl

Re: RFS: fio 2.11

[Adam Borowski]

On Mon, Aug 05, 2013 at 08:52:47PM +0200, Sven Hoexter wrote:
 On Mon, Aug 05, 2013 at 04:57:41PM +0200, Martin Steigerwald wrote:
 a) Is it worth to switch to xz for this package?
 b) Is it a good idea to force the compression-level to 9?
 
 For a) I think maybe for b) I guess buildd maintainers and maybe even
 devs of weaker arches might hate you. I've no good idea myself how
 xz works internally but if I recall the threads on d-d correctly about
 making xz the default a compression level above 6 was deemed way too much.
 I think even lower levels were proposed as a Debian default when xz will
 be the default compression method.

xz is already the default.

I don't think micromanaging the compressor in every package is a good idea,
especially for a regular package without special needs.  Setting it on
openclipart (big, no gain) or linux-image-dbg (big and highly compressible)
is worth the effort, using something non-standard on a random package is
not -- and will bring us extra work if some policy changes.

So let's not muck with compression settings without a good reason.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130805200347.ga31...@angband.pl

Re: Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game

[Adam Borowski]

On Fri, Aug 02, 2013 at 01:21:26PM +0200, chrysn wrote:
 On Wed, Jul 31, 2013 at 12:39:13AM +0200, Adam Borowski wrote:
  If the player grinds long enough, he will gain access to an unfinished
  land that doesn't work yet.  In game.cpp, you'd want to comment out
  the following lines:
if(tkills() = 2000  gold() = 2000)
  tab[cnt++] = laCocytus;
 
 that's far beyond the game's high score

Well, this is a roguelike game, and thus, players looking for degenerate
ways to break the game is probably more prevalent than playing it straight.

I've found three ways to get an infinite score so far (bounded by patience,
as it's hard to connect a bot to a graphics-only game):

* Alchemist Lab (tested):
  0. don't touch any gold anywhere else
  1. get 30 gold in, say, the Jungle
  2. stand at the edge of the Lab with no Jungle in sight, kill 5000 slimes
  3. harvest infinite gold with no slimes being able to spawn
* sandworm farming (tested):
  1. find a Desert entrance that forms a corridor
 a. they sometimes occur naturally
 b. Living Caves trolls can be used for terrain modification
 c. a well-fed sandworm with its head out of range stays dormant
  2. ensure no interlopers come from the other side.  This might be either
 a land you picked no gold in (thus no respawns), a trolled-off
 Living Cave, crossroads with all lands in sight harmless (Lab,
 Eternal Motion, overgrown Jungle, blocked Living Caves), etc
  3. kill all spawning desert men, watch sandworms explode, pick up spice
* edge dipping:
  1. take gold from only one land
  2. walk in a safe[ish] land, at some distance parallel to an edge
  3. find an entrance with no other entrances close
  4. fight hordes upon hordes of pre-spawned enemies
  5. walk closer, fighting respawns, and hordes from areas that just came
 into view
  6. grab a few gold (there's one in every cell, but dipping too far wakes
 new hordes, and respawns come too fast)
  7. tediously repeat the whole process
  This works for only some combinations of farmed/safe lands, it is easy
  to make a mistake, and I have no proof it can be done infinitely.

You may edit the source to set a land's items/monsters to 10, this is
an easy way to see how a land degenerates, and to test strategies how to
keep collecting gold even in such a degenerate state.

Possible fixes against these strategies:
* allow purple slimes to spawn on items, or
* don't allow any spawn chance to reach 100% (other than asymptotically)
* allow sandworms out of the Desert

 cocytus may be visually and balancing-wise unfinished, but it's not like
 it makes the game crash.  (it's inaccessible even without orbs of
 teleport).

I'd say it's in a bad enough state that it shouldn't spawn in a released
version, and thus if I were you, I'd comment that out.

  The desc of Dead Orb (classes.cpp) is actively misleading: it claims
  these orbs have no use, while they can be used to flip slime colours.
  No matter what is one's stance on spoilers, documentation shouldn't
  outright lie.
 
 i think it's ok for an in-game help (which the text in classes.cpp is;
 it gets displayed when pressing F1 on the orb item) in a role playing
 game to lie, even more to omit particular uses. (i presume its primary
 use is to serve as breadcrumbs to mark the way back to an orb of yendor
 from its key).

Even games that heavily rely on spoilers (like Nethack) don't provide false
information, merely omit it.  It's especially jarring in a spoiler-less
game like Hyperrogue where the docs are otherwise complete[1].

What about a wording like [...] No _apparent_ way to use them [...]?


[1]. Other than the bizarre rules for greater-lesser demon conversion in
Hell.
-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130804053030.ga13...@angband.pl

Re: Bug#718323: RFS: hyperrogue/3.7+dfsg-1 [ITP] -- non-euclidean graphical rogue-like game

[Adam Borowski]

On Tue, Jul 30, 2013 at 10:23:54AM +0200, chrysn wrote:
 * Package name: hyperrogue

Why do you use ttf-bitstream-vera?  fonts-dejavu-core is a superset, and
is installed on about every X-capable Debian system thanks to existing
dependencies.  Upstream wants an ASCII-only font for a smaller download,
but in Debian that's a net loss of both disk space and memory.

There's quite a few projects shipping a convenience copy of vera that's
patched away using dejavu in Debian.  Please, join the club.


A few upstreamish issues:

The window's title is Untitled window.  You want to call
SDL_WM_SetCaption().

If the player grinds long enough, he will gain access to an unfinished
land that doesn't work yet.  In game.cpp, you'd want to comment out
the following lines:
  if(tkills() = 2000  gold() = 2000)
tab[cnt++] = laCocytus;

The desc of Dead Orb (classes.cpp) is actively misleading: it claims
these orbs have no use, while they can be used to flip slime colours.
No matter what is one's stance on spoilers, documentation shouldn't
outright lie.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130730223913.ga6...@angband.pl

Bug#716905: ITP missing for package goodbye with RFS 716905 with ITP in title

[Adam Borowski]

On Mon, Jul 15, 2013 at 10:16:59AM +0200, Mònica Ramírez Arceda wrote:
 According to [0], goodbye has not its corresponding ITP bug, despite 716905 
 title.
 Please, could you file this ITP bug?

#636016, from two years ago.  I guess your check didn't match it as it had
been renamed to RFP for inactivity.  Retitled.

Meow!
-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130715105059.ga30...@angband.pl

Re: Bug#716905: RFS: goodbye/0.3-1 [ITP]

[Adam Borowski]

On Mon, Jul 15, 2013 at 05:42:41PM +0200, Gergely Nagy wrote:
 Adam Borowski kilob...@angband.pl writes:
 
  Let's add some WTF to FTPmasters' day! :)
 
 This package is a perfect fit for a personal archive, but if anyone
 wants to upload it: you're in for a race for the fastest REJECT ever.

I'm afraid you managed to find an error.  One.  Which is a terrible shame,
as the point of perversing the rules means one should have a spotless
record.  Fixed and reuploaded.


So, let's go through what you pointed out:

 * debian/rules without arguments does not behave sanely:
 
   make: *** No targets.  Stop.
 
   It should at least do something, but no targets is unexpected.

There is no requirement for it to do anything, and failing immediately
is a sane thing to do.

As for consistency, let's compare with a bunch of packages:

9base: does most of the build, returns 0
aalib: calls configure, returns 0
dadadodo: says make: *** No targets.  Stop., returns 2
dh-exec: says dh_auto_configure -- --libexecdir=/usr/lib, returns 0
dpatch: patches itself, returns 0
edbrowse: attempts compilation with no earlier targets called, fails
returning 2
git-flow: says dh override_dh_auto_build, returns 0
ivykis: tries to chmod some non-existant files (no target dependency),
fails returning 2
libmikmod: fails due to some unset variables, returns 2
libmongo-client: says make: Nothing to be done for `build'.,
returns 0
mikmod: fails configuration, returns 2

I'd say, goodbye behaves best of these (same as dadadodo).  The error
message accurately describes what's wrong (you specified no targets).

   It says the same when tcc is not installed too, instead of failing
   violently for build-deps not being present.

/bin/sh: 142: tcc: not found
make: *** [binary] Error 127

The error message is informative, again.

 * It unconditionally rewrites debian/control
 
   This is REJECT reason alone. You simply don't do that.

Thus I don't.  Please tell me in what circumstances would it overwrite
debian/control.

 * debian/rules with an invalid target name still works:
 
   debian/rules binary == debian/rules yranib
 
   It should produce an error. This kind of unexpected behaviour is
   confusing, and not something we want in the archive. We already have
   CDBS for that[1], thank you.

Policy 4.9 explicitely allows extra targets.  Using any not defined in
the policy is undefined behaviour; a comment in goodbye mentions that.

 * There is no error checking:
 
   Trying to build the package in a chroot that doesn't have enough
   space: it will result in an empty, invalid package.
 
   The return value of mkdir(), system() and all that needs to be
   checked, or you're not complying with Policy 4.6.

You got me here.

While this is a rather popular error, it is unacceptable in a packaging
example.

 * d/rules can be exploited by an overly long version string

There's no buffer overflow (scanf(%127), snprintf), merely truncation. 
I'd call a limit of 127 characters in a version number reasonable.  I can
use asprintf if you wish, but I prefer it this way, with a sanity check.

In any case, you can already run arbitrary code like, say, rm -rf ~ in a
makefile.  Breaking a build system by editing said build system is not an
accomplishment.

 * The binary created by d/rules is invalid:
 
 algernon@hadhodrond:/tmp/b$ dget -x -u 
 http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc 
 dget: retrieving 
 http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.dsc
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  1440  100  14400 0   342k  0 --:--:-- --:--:-- --:--:--  703k
 dget: retrieving 
 http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3.orig.tar.xz
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  1824  100  18240 0   471k  0 --:--:-- --:--:-- --:--:-- 1781k
 dget: retrieving 
 http://mentors.debian.net/debian/pool/main/g/goodbye/goodbye_0.3-1.debian.tar.gz
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  3133  100  31330 0   133k  0 --:--:-- --:--:-- --:--:--  145k
 dpkg-source: info: extracting goodbye in goodbye-0.3
 dpkg-source: info: unpacking goodbye_0.3.orig.tar.xz
 dpkg-source: info: unpacking goodbye_0.3-1.debian.tar.gz
 algernon@hadhodrond:/tmp/b$ cd goodbye-0.3/
 algernon@hadhodrond:/tmp/b/goodbye-0.3$ debian/rules binary
 ar: creating ../goodbye_0.3-1_all.deb
 doing: [binary]\n
 algernon@hadhodrond:/tmp/b/goodbye-0.3$ dpkg-deb -c ../goodbye_0.3-1_all.deb
 dpkg-deb: error: archive has no newlines in header
 
 And indeed, debian-binary contains 2.0\n, and no newline.

Uh?

dpkg-deb -c ../goodbye_0.3