Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.

[Johannes Schauer Marin Rodrigues]

Hi Aidan,

On Thu, 18 Jan 2024 16:52:26 +0100 Andrey Rakhmatullin  wrote:
> I see you added this tool to the list of similar tools on the wiki so you
> at least know about that list. So how is your tool better than other tools
> on that list, or at least than the ones packaged in Debian? 
> Please also note that if you followed the procedure outlined at
> https://mentors.debian.net/intro-maintainers/ and filed an ITP bug before
> doing the packaging this discussion would happen there, not on the RFS bug.

I'm the current maintainer of sbuild. You found the wiki page and you saw that
there already exist 10 different implementations of utilities that build Debian
packages inside a docker container. You still decided to add an eleventh
implementation so I guess my plea here will not amount to much but anyways here
goes my sales pitch:

If you want your code to be in Debian, please consider reviewing the patch
attached to this bug report:

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

I'm not a docker user, so I cannot verify whether this is indeed doing the
right thing but you are, so it should be easy for you to take it, test it and
finalize it.

I'm afraid contributing to an existing tool is not as sexy as supplying one
that is 100% written by you but I can guarantee you that if you can clean up
that patch, I will apply it to sbuild and your code will be in Debian proper.

Maybe, hopefully we can make sbuilder and/or pbuilder work with docker instead
of having eleven competing implementations doing the same thing?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1031284: RFS: wl-mirror/0.12.2-1 [ITP] -- output-mirroring tool for wlroots-based Wayland desktops

[Johannes Schauer Marin Rodrigues]

Hi Ferdinand,

in #1012684 Antoine Beaupré said they'd be happy to sponsor you. Did They
already contact you about that?

Quoting Ferdinand Bachmann (2023-02-14 16:41:49)
> Alternatively, you can download the package with 'dget' using this command:
> 
>dget -x 
> https://mentors.debian.net/debian/pool/main/w/wl-mirror/wl-mirror_0.12.2-1.dsc
> 
> Additionally, my current development tree for the Debian source package, 
> including scripts/Dockerfiles (since I am developing this on a 
> non-Debian system) is the following URL:
> 
>https://github.com/Ferdi265/wl-mirror-debian

I tried out your package and it works great on my ARM Cortex A57 platform. How
does it manage to not consume any CPU even when recursively mirroring itself?

Thanks!

cheers, josch

Re: Cross-compiling a package that build-depends on Python

[Johannes Schauer]

Quoting Łukasz Walewski (2018-02-05 21:19:27)
> On 03.02.2018 14:23, Helmut Grohne wrote:
> > All Build-Depends are treated as host architecture by default. In this
> > case, it seems very likely that python is a build tool so you
> > (implicitly) requested python for the wrong architecture. Switching a
> > dependency from host architecture to build architecture happens by
> > annotating it with ":native" (<- only works in Build-Depends, not
> > Depends).
> This is exactly what I was looking for! I anticipated that there must a 
> way to enforce the native build architecture, but I could not find it 
> anywhere. Could you please point me to the respective documentation?

https://wiki.ubuntu.com/MultiarchCross

Unfortunately, documenting multiarch properly is hard. :(

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


signature.asc
Description: signature

Re: Request for sponsor for Runescape

[Johannes Schauer]

Hi Carlos,

Quoting Carlos Donizete Froes (2017-07-23 09:44:10)
> I am looking for a sponsor for my package "runescape" version 0.2
> 
> To access further information about this package:
> 
> https://mentors.debian.net/package/runescape
> 
> https://tracker.debian.org/pkg/runescape

the debdiff between versions 0.1-4 and 0.2-1 is 41318 lines long - what
happened?

According to debian/copyright, the upstream authors changed. Is this a
different software package?

The Homepage field in debian/control should not point to
https://www.runescape.com/ because you are not packaging anything from there.
Instead it should point to the website of the software you *are* packaging. As
far as I can see, that's the github page.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: SBuild: Post-build fails to fetch some packages

[Johannes Schauer]

Hola,

Quoting Ben Finney (2017-07-02 02:57:25)
> > Secondly, just using --upgrade will do nothing unless you also --update the
> > chroot.
> That seems like a bug; why would ‘--upgrade’ silently do nothing? I
> would think it should either complain that it's useless, or implicitly
> turn on ‘--update’ as well (I certainly assume that ‘sbuild-update
> --upgrade’ means “do update, then also do upgrade”.)
> 
> Should I file a bug report for that?

I'm unsure. The "sbuild-update" script is thought of as a "apt-get" wrapper in
the sense that it runs the apt-get command you want inside the chroot. And if
you run "apt-get upgrade" on your host system without running "apt-get update"
first then also nothing happens.

Also, specifying "--upgrade" alone can make sense if you run it after running
"--update" like this:

$ sbuild-update --update unstable
$ sbuild-update --upgrade unstable

But what I have no doubt about is, that the documentation can be better. If you
would like to file a bug that it could be better documented how this part of
sbuild works, then please file a bug about it. Thank you!

> > As it says at the bottom of the man page, you can easily do an update,
> > (dist-)upgrade, clean, autoclean and autoremove in one go by doing:
> >
> > % sbuild-update -udcar unstable
> >
> > Does that fix your problem?
> 
> Is that equivalent to:
> 
> $ sudo sbuild-update --update --dist-upgrade --clean --autoclean 
> --autoremove unstable
> 
> (I prefer, when recording commands in a script, to use the explicit
> options; it makes it easier to understand when coming back months
> later.)

Yes, that is the same command using long options.

> Yes, after running that command the ‘adt-run’ command now is able to download
> the right versions of packages.
> 
> Now I need to convert that to an ‘autopkgtest’ command instead :-)

Cool! Have fun! :)

cheers, josch


signature.asc
Description: signature

Re: SBuild: Post-build fails to fetch some packages

[Johannes Schauer]

Hi Ben,

sbuild maintainer here. In these cases you can always file a bug but lets see
if we can solve this here.

Quoting Ben Finney (2017-07-01 13:08:17)
> Andreas Moog  writes:
> 
> > Your sbuild-environment has outdated mirror information. For example
> > the current libreadline version in unstable is 7.0-3. Does the build
> > work after running sbuild-update?
> 
> The ‘sbuild’ process updates from the mirrors when it begins:
> 
> 
> +--+
> | Update chroot   
>  |
> +--+
> 
> Get:1 http://mirror.internode.on.net/pub/debian unstable InRelease [255 kB]
> Get:2 http://mirror.internode.on.net/pub/debian unstable/main 
> Sources.diff/Index [27.9 kB]
> Get:3 http://mirror.internode.on.net/pub/debian unstable/main amd64 
> Packages.diff/Index [27.9 kB]
> Ign:2 http://mirror.internode.on.net/pub/debian unstable/main 
> Sources.diff/Index
> Ign:3 http://mirror.internode.on.net/pub/debian unstable/main amd64 
> Packages.diff/Index
> Get:4 http://mirror.internode.on.net/pub/debian unstable/main Sources [7488 
> kB]
> Get:5 http://mirror.internode.on.net/pub/debian unstable/main amd64 Packages 
> [7559 kB]
> Fetched 15.4 MB in 29s (523 kB/s)
> […]
> =
> 
> yet fails to download packages as before.

That's to be expected because the updating that sbuild does happens in its own
schroot session (assuming you use the default schroot backend) and whatever is
done in that session gets discarded after sbuild closes the session that was
used for building. Autopkgtest then opens its own schroot session in which
nothing that sbuild did with it exists anymore.

I see that your sbuild is running autopkgtest even though you didn't tell it to
do so on the command line. In this case it would also be helpful to see all
your non-default modifications from your ~/.sbuildrc

> To be sure, I ran ‘sudo sbuild-update --upgrade --dist unstable’ before
> another ‘sbuild’ and got the same result.

Did you read the sbuild-update man page? There are a couple of problems with
the command as you are running it.

Firstly, there is no --dist option. The chroot is supplied as a positional
argument.

Secondly, just using --upgrade will do nothing unless you also --update the
chroot. If you only "apt-get upgrade" without "apt-get update" then apt did not
yet learn that mirrors have newer versions of your packages and nothing will be
upgraded.

As it says at the bottom of the man page, you can easily do an update,
(dist-)upgrade, clean, autoclean and autoremove in one go by doing:

% sbuild-update -udcar unstable

Does that fix your problem?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Sbuild & lxc problems

[Johannes Schauer]

Hi Ross,

sbuild maintainer here. :)

Quoting Ross Gammon (2017-06-23 21:18:13)
> I mainly use pbuilder/cowbuilder to build my packages, but I would
> really like to try using the tool from pkg-ruby-extras, because I am
> told it is very good for test building reverse dependencies and also
> runs debci to test any autopkgtest testsuites. It uses sbuild.

pkg-ruby-extras? The alioth group? What is "the tool" you are referring to? If
this part of your question is ruby specific, then maybe the debian-ruby list is
a better fit?

> However, sbuild does not seem to agree with me, and I have had several
> attempts over the years to get it going but I gave up each time.

Please help by filing bugs with the problems you faced! I am aware that many
things are not well documented that but to make the software better I need to
know which things need more explanation.

> One time I thing I ran out of room on the root partition halfway through
> setting it up (my fault). Once I had fixed the space problem, I had all sorts
> of problems working out how to clear out the failed sbuild schroot (and I
> can't remember how I did it now).

That's probably a schroot problem and I share your pain - it also took me quite
a while until I understood schroot and its relationship to sbuild. ^^

> Then the next time I think it failed with some gpg archive key problem. I got
> around this by upgrading to sbuild from jessie-backports.

The problem was, that apt in unstable stopped depending on gpg but sbuild in
jessie still required gpg inside the chroot. As you figured out yourself
already, the problem got fixed by an upload to jessie-backports.

> But then it failed for some reason I can't remember. It is difficult to
> search for help when everything seems to be a wrapper for something else, and
> you can't workout where in the chain the problem is. I have been around in
> circles several times :-)

Yes, the wrapper count is indeed high in this one:

sbuild -> schroot -> dpkg-buildpackage -> debian/rules

The man pages should be enough but there is also this potentially useful wiki
page:

https://wiki.debian.org/sbuild

> Anyway, that is the background. I am hoping that with some help from mentors,
> I will get up and running this time. Here goes:
> 
> -
> 
> ross@DebianJessieLaptop:~/debian/pkg-ruby-extras$ git remote -v
> origin   
> https://anonscm.debian.org/cgit/pkg-ruby-extras/pkg-ruby-extras.git (fetch)
> origin   
> https://anonscm.debian.org/cgit/pkg-ruby-extras/pkg-ruby-extras.git (push)
> 
> ross@DebianJessieLaptop:~/debian/pkg-ruby-extras$ setup
> + sudo apt-get install -qy autopkgtest build-essential gem2deb git
> git-buildpackage myrepos quilt sbuild lxc debci
> 
> + sudo mkdir -p /root/.gnupg
> + sudo sbuild-update --keygen
> Generating archive key.
> 
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 188 more bytes)
> .+
> .+
> gpg: /root/.gnupg/trustdb.gpg: trustdb created
> gpg: key 5F4C78AD marked as ultimately trusted

This is not needed anymore since sbuild 0.67.0

> + sudo sbuild-adduser ross
> The user `ross' is already a member of `sbuild'.

This only needs to be done once and not multiple times.

> 
> # Setup tasks for sudo users:
> 
> # BUILD
> # HOME directory in chroot, user:sbuild, 0770 perms, from
> # passwd/group copying to chroot, filtered
> # Maybe source 50sbuild, or move into common location.
> 
> Next, copy the example sbuildrc file to the home directory of each user and
> set the variables for your system:
> 
>   cp /usr/share/doc/sbuild/examples/example.sbuildrc /home/ross/.sbuildrc
> 
> Now try a build:
> 
>   cd /path/to/source
>   sbuild-update -ud 
>   (or "sbuild-apt  apt-get -f install"
>first if the chroot is broken)
>   sbuild -d  _
> + dpkg --print-architecture
> + chrootname=unstable-amd64-sbuild
> + chroot=/srv/chroots/unstable-amd64-sbuild
> + grep unstable-amd64-sbuild
> + schroot --list --all-source-chroots
> + sudo sbuild-createchroot unstable /srv/chroots/unstable-amd64-sbuild
> http://httpredir.debian.org/debian
> I: SUITE: unstable
> I: TARGET: /srv/chroots/unstable-amd64-sbuild
> I: MIRROR: http://httpredir.debian.org/debian
> I: Running debootstrap --arch=amd64 --variant=buildd --verbose
> --include=fakeroot,build-essential --components=main --resolve-deps
> unstable /srv/chroots/unstable-amd64-sbuild
> http://httpredir.debian.org/debian
> I: Retrieving Release
> I: Retrieving Release.gpg
> I: Checking Release signature
> I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
> I: Retrieving Packages
> I: Validating Packages
> 
> 
> I: Base system installed successfully.
> I: Configured /usr/sbin/policy-rc.d:
>+
>|#!/bin/sh
>|echo "All runlevel operations denied by policy" >&2
>|exit 101
>

Bug#855354: RFS: alot/0.5.1-1 [ITA]

[Johannes Schauer]

Hi Jordan & Simon,

Quoting Jordan Justen (2017-04-24 10:00:32)
> On 2017-04-21 10:04:39, Jordan Justen wrote:
> > On 2017-04-21 06:12:21, Johannes Schauer wrote:
> > > Quoting Ben Finney (2017-04-21 14:44:52)
> > > > Jordan, have you made more changes that should be released?
> > > > 
> > > > Johannes, are you waiting on any changes before you approve and upload
> > > > this package?
> > > 
> > > Jordan and I were writing each other privately in February. Currently 
> > > progress
> > > is stalled on the question of how to maintain the package. The options 
> > > are:
> > > 
> > >  1. maintaining it under the umbrella of the Python Applications 
> > > Packaging Team
> > > but they use svn which Jordan wants to avoid in favour of git. There 
> > > is the
> > > question of whether it would be acceptable to use PAPT+git:
> > > 
> > > http://lists.alioth.debian.org/pipermail/python-apps-team/2017-February/013126.html
> > > But as the last message indicates, there seems to be no consensus yet
> > > whether to use git-dpm or switch to gbp-pq when moving python-apps 
> > > from svn
> > > to git...
> > 
> > I was trying to see if I could work with Stefano (Cc'd) to help with
> > the PAPT svn=>git transition, but that didn't end up going anywhere. :\
> > 
> > >  2. using collab-maint with whatever git packaging workflow but it seems 
> > > that
> > > Jordan isn't sure yet which one to pick for maintenance of alot
> > > 
> > > Jordan, are you still on board? Otherwise I just pick the option I like 
> > > and
> > > start committing your work. :)
> > 
> > Yes, I am still interested. I'd convinced myself that I just needed to
> > give up on using git for now, so I planning to commit the patches to
> > svn under the current PAPT packaging area. I'll do that and then work
> > with you (Johannes) to upload the new package.
> >

Jordan, thanks a lot for your recent contributions to the alot package! I think
your changes are fine and I just uploaded your package to experimental. If
there are any additional problems, we can make iterative changes and upload
them later.

Simon, you added yourself to the Uploaders of alot. Are you still interested in
maintaining the package?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#855354: RFS: alot/0.5.1-1 [ITA]

[Johannes Schauer]

Hi Ben,

Quoting Ben Finney (2017-04-21 14:44:52)
> How is this going?

thanks a lot for the ping!

> Jordan, have you made more changes that should be released?
> 
> Johannes, are you waiting on any changes before you approve and upload
> this package?

Jordan and I were writing each other privately in February. Currently progress
is stalled on the question of how to maintain the package. The options are:

 1. maintaining it under the umbrella of the Python Applications Packaging Team
but they use svn which Jordan wants to avoid in favour of git. There is the
question of whether it would be acceptable to use PAPT+git:

http://lists.alioth.debian.org/pipermail/python-apps-team/2017-February/013126.html
But as the last message indicates, there seems to be no consensus yet
whether to use git-dpm or switch to gbp-pq when moving python-apps from svn
to git...

 2. using collab-maint with whatever git packaging workflow but it seems that
Jordan isn't sure yet which one to pick for maintenance of alot

Jordan, are you still on board? Otherwise I just pick the option I like and
start committing your work. :)

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Johannes Schauer]

Quoting Mattia Rizzolo (2017-03-18 08:53:21)
> On Sat, Mar 18, 2017 at 08:22:36AM +0100, Johannes Schauer wrote:
> > So just as with sbuild I don't see why anybody would want to *only* build 
> > the
> > source package inside a chroot. Since the source package is the *input* to 
> > the
> > whole operation, you would just get back what you already put in.
> The only gain would be in a situation where you can't run the clean target
> outside of the chroot, due to missing dependencies, so `dpkg-source -b .`
> will produce an "unclean" source.  After moving it inside a throw-away chroot
> with the build-deps installed you can call the clean rules, and produce the
> source again, which will be "cleaner" than the one produced outside.
> Personally I'd call this case quite borderline and unusual, especially in
> this world of git where the working directory is easily cleaned by a `git
> clean -fdx` et al.

how would the unpacked source directory become unclean if I'm using pbuilder or
sbuild to build my packages?

If I'm not mistaken that would only happen if I ever call some targets from
debian/rules outside the chroot and that again requires the build dependencies
to be installed at which point you can also run the clean target.

cheers, josch


signature.asc
Description: signature

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

[Johannes Schauer]

Hi,

Quoting Andrey Rahmatullin (2017-03-18 07:58:56)
> On Sat, Mar 18, 2017 at 07:25:32AM +0100, Andreas Tille wrote:
> > > James Clarke wrote in https://bugs.debian.org/853886#10:
> > > 
> > > "For source-only builds, I don't understand why you would want to
> > > perform the build in a chroot.
> > 
> > Since Build-Depends are requested on my local machine anyway
> -nc is usually enough. And are you saying it was possible to build a source
> package in a chroot without already having a source package?

I am also highly confused by this thread. Maybe I'm misunderstanding pbuilder
(I'm just the sbuild maintainer) but isn't the source package the *input* to
pbuilder just as it is for sbuild? What sbuild does when you execute it on an
unpacked source directory, is to first build the source package which it then
hands to the chroot. I think pbuilder does the same, judging from this line:

http://sources.debian.net/src/pbuilder/0.228.6/pdebuild/?hl=91#L91

And I don't think what this has to do with build dependencies. You don't need
the build dependencies installed to build a source package. In your local
unpacked source tree, just run:

dpkg-source -b .

So just as with sbuild I don't see why anybody would want to *only* build the
source package inside a chroot. Since the source package is the *input* to the
whole operation, you would just get back what you already put in.

If you want to make a source-only upload, you should build everything in a
chroot and instruct pbuilder or sbuild to create a .changes file that only
includes the relevant source package bits and not the binary packages. This is
what you do with the --source-only-changes option for both sbuild and pbuilder.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#855354: RFS: alot/0.5.1-1 [ITA]

[Johannes Schauer]

Hi Jordan,

Quoting Gianfranco Costamagna (2017-02-17 11:11:35)
> >I do have reservations about moving the package from the PAPT umbrella into 
> >collab-maint, but it's not my call anymore.
> 
> 
> lets review:
> a) PAPT seems more appropriate
> b) "alot (0.3.7-1) unstable; urgency=medium"
> this never went in unstable, please merge the two changelog entries together 
> with the correct
> author attributions
> c) #846314 <-- please fix it
> d) please close #792108 in the correct "new upstream release" changelog
> e) #701806 wontfix?
> f) the runtime dependencies needs to match the versions on setup.py
> and if oldstable/stable already have higher versions, you can just drop them 
> and let
> python:Depends fill them correctly
> g) please consider using pybuild for building it
> h) please consider bumping compat level to 10

You may also want to close bug #792108 with that release.

You may also want to add yourself to debian/copyright if your changes are
substantial (like switching to pybuild and compat level 10 might be).

Feel free to contact me for sponsorship as I'm an alot user and also
fixed/filed a couple of bugs together with upstream. I'm thus very interested
in keeping this package in Debian.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Writing outside of build dir

[Johannes Schauer]

Hi!

Quoting Christian Seiler (2016-11-26 01:30:59)
> On 11/26/2016 01:59 AM, Ross Vandegrift wrote:
> > Could you point me to this policy?  I'd like to learn more, but haven't
> > been able to find it.
> I just checked and it really isn't in there.

Oh. This is odd. I just reported #845715 to rectify this situation.

> My guess is that it probably never got added to policy because autobuilders
> fail with similar errors as pbuilder does, so packages that violate this
> FTBFS, which is an automatic RC bug, regardless of policy.

More specifically, autobuilders use sbuild which also sets $HOME to
/sbuild-nonexistent for package builds. If the source package tries to create
that path it will fail because it lacks permissions to do so.

This practice of course doesn't catch source packages which will not write into
$HOME if it does not exist but will do so if it does. It would be interesting
to do an archive rebuild with $HOME set to a writable location and to record
which source packages still violate this rule.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Debian privacy policy

[Johannes Schauer]

Hi,

Quoting Ole Streicher (2016-11-17 10:11:42)
> Paul Wise  writes:
> > AFAICT we don't have an official statement about this, but:
> > https://lists.debian.org/debian-policy/2008/02/msg00060.html [...]
> 
> Is there a reason why it is not there?

I guess because nobody wrote a patch for policy yet?

> > Debian packages must respect sysadmin and user privacy and encourage
> > sysadmins and users to respect the privacy of everyone. So, disabled by
> > default, informed consent and don't manipulate people into destroying their
> > privacy with click-through stuff. Some discussion of click-through culture
> > is in the recent episode of FaiF:
> >
> > http://faif.us/cast/2016/nov/01/0x5E/
> 
> I observe that the common opinion in Debian is strictly pro privacy --
> but why it is not in the policy? It is quite hard to discuss those
> topics with upstream if there is no reference to a settled opinion, but
> rather a number of lengthy discussions.

I suggest you submit a patch to #726998 and we continue discussion there.

The wording should reflect the difference between programs where it should be
obvious for the user that information sent to remote parties (firefox, wget,
curl, youtube-dl) and programs which do so as a convenience feature but without
having their functionality depend on it (auto updaters, reporting usage
statistics). The user should explicitly asked for their consent in the latter
case.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Best GPG practices before sending computer to maintenance.

[Johannes Schauer]

Hi,

Quoting Charles Plessy (2016-11-12 06:06:13)
> the laptop that I use mainly for Debian development will go to hardware
> maintainance tomorrow.  I will of course remove my .gnupg folder, but out of
> curiosity I wonder if there are better practices.  The mass storage is a SSD
> that I am not going to remove it before sending the laptop.

 - remove that SSD
 - use full disk encryption
 - mirror the SSD content to another media (using dd or some such) and then
   wipe the whole disk with zeros

If you are just worried about GPG, then removing .gnupg should be all you need
to do.

cheers, josch


signature.asc
Description: signature

Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU --

[Johannes Schauer]

Hi,

Quoting Thomas Pircher (2016-09-14 20:21:14)
> Changes since the last upload:
> 
>* Non-maintainer upload.
>* New upstream release (closes: #833081, #811988, #798624, #645616).

I once made a similar mistake in one of my packages and just listed all the
closed bugs without writing down how the new release closes them. You can see
for yourself which version you like better in this commit where I fixed the
problem for my package:

https://anonscm.debian.org/cgit/buildd-tools/sbuild.git/commit/?h=debian/unstable=5b06c85f93862f004053f1d85c1d69c9d7716955

Indeed it is not strictly *necessary* to list exactly how each bug was closed,
but it is nice for the submitter of the bug to read how it got handled in the
email they receive when your upload closes the bug. With just a list, as a bug
submitter you don't know how your problem was taken care of without manually
diffing the two versions. Here is a nice write-up about why to be more
elaborate in d/changelog:

https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-debian-changelog

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Multiarch hinter on package tracker: Shall i obey ?

[Johannes Schauer]

Hi,

Quoting Thomas Schmitt (2016-09-18 09:09:09)
> Johannes Schauer wrote:
> > [the need for Javascript] should be reported as a bug against the tracker.
> 
> Submitted as
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178
> and subscribed to it.

thanks!

> > imagine an Architecture:all package doing this:
> >   #!/bin/sh
> >   gcc "$@"
> > Certainly, what this architecture independent shell script does is
> > architecture dependent and thus the package containing it cannot be
> > marked as Multi-Arch:foreign.
> 
> How can this script be "Architecture:all" if it does not work as expected
> on some architectures ?
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
> says:
>   "all, which indicates an architecture-independent package."
> 
> So is there a difference between "being architecture independent" and
> "acting architecture independent" ?
> (Hopefully i will never have to decide which of both is in effect.)

When we say "an Architecture:all package is architecture independent" then we
actually mean to say "an Architecture:all package contains content (files)
which are the same across all architectures".

In fact, we could easily live without Architecture:all packages. It would just
mean that mirrors would then carry many identical binary packages for different
architectures.

So in the debian/control of src:libisofs you could mark libisofs-doc as
Architecture:any and then you would get a libisofs-doc package on each
architecture which would be completely identical (because src:libisofs seems to
build reproducibly [1]). This would totally work as far as dependency
relationships are concerned. It would just "waste" a little bit of mirror space
because now you have to store X identical copies of a binary package, where X
is the number of architectures in Debian.

So the only thing that marking a package as Architecture:all tells you is, that
its *content* is equal across all architectures and that it is thus not
necessary to build and ship an individual copy of that binary package for each
architecture.

Thanks!

cheers, josch

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libisofs.html


signature.asc
Description: signature

Re: Multiarch hinter on package tracker: Shall i obey ?

[Johannes Schauer]

Hi,

Quoting Thomas Schmitt (2016-09-17 17:51:16)
> I saw the mouseover text "Toggle details", but the click only brought me to
>   https://tracker.debian.org/pkg/libisofs#
> because i have Javascript disabled.

that should be reported as a bug against the tracker. Without Javascript, the
default should be to see the expanded view or otherwise the data will be
invisible for users without Javascript. It should be simple to make it such
that users with javascript see the collapsed view by default and have to click
to expand it.

Though since I also didn't see the drop-down "button" myself at first maybe
this UI element of the tracker needs some rethinking anyways.

> Is there a diagram or table which relates Architecture: and Multi-arch: ?

I don't see how this should be done. The fields are not related except that
they both have the character sequence "arch" in them.

The Architecture field tells you whether the binary package is architecture
specific or not and if it is architecture specific to which architecture it
belongs. Architecture:all means that the data inside the package doesn't differ
between different architectures. Hence, Architecture:all packages are only
built once by buildds and can then be used on any other architecture where
their dependencies are satisfied, even before there was multiarch. For all
other values of the Architecture field, the binary package is architecture
specific and before there was multiarch you only were able to install a package
that was of Architecture:foo on a system with native architecture foo. You can
find out your system's native architecture via $(dpkg --print-architecture).
With multiarch it is now also potentially possible to install a package of
architecture bar on a system with native architecture foo. A short summary:

If a package is Multi-Arch:same then it is potentially possible to install a
package with same name and version but different architecture at the same time.

If a package is Multi-Arch:foreign, then a package of architecture foo is
potentially able to satisfy a dependency of a package with architecture bar.

> Coming back to the diagram question: Doesn't "Architecture: all" imply
> "Multi-arch: foreign" ?

No. Multi-arch:foreign means that a package of architecture foo is able to
satisfy the dependencies of a package with architecture bar. This means that
the functionality and interface that your Architecture:all package provides
must be independent of the native architecture (Architecture:all packages are
currently treated as if they were of the native architecture). While this is
certainly the case for many Architecture:all packages, there also exist many
for which it is not the case. Here an example:

Imagine your Architecture:all package was just a shell script which provided
the functionality of printing "hello world" on standard output:

#!/bin/sh
echo "hello world"

The package that just contains this script could probably be marked as
Multi-Arch:foreign as the functionality it provides is architecture
independent. No matter the architecture of the package depending on it, they
would get the requested functionality: the string "hello world".

But now imagine an Architecture:all package doing this:

#!/bin/sh
gcc "$@"

Certainly, what this architecture independent shell script does is architecture
dependent and thus the package containing it cannot be marked as
Multi-Arch:foreign.

I hope this helps.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Multiarch hinter on package tracker: Shall i obey ?

[Johannes Schauer]

Hi,

Quoting Thomas Schmitt (2016-09-17 16:00:28)
> i am preparing the Debian package for a new upstream release of libisofs
> and see on its tracker page
>   https://tracker.debian.org/pkg/libisofs
> a new "action needed":
> 
>   "Multiarch hinter reports 1 issue(s)"
> 
> The link points to 
>   https://wiki.debian.org/MultiArch/Hints
> 
> But where to see the actual complaint ?

I was confused by this as well when I first saw the hints appear in the
tracker.

You have to click at the small downward arrow at the left of the "Multiarch
hinter" text. Then you can see:

There are issues with the multiarch metadata for this package.

libisofs-doc could be marked Multi-Arch: foreign

> Google "multiarch hinter" brings me to
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833623
> where i find in the patch a URL:
>   https://dedup.debian.net/static/multiarch-hints.yaml
> which says:
>   - binary: libisofs-doc
> description: 'libisofs-doc could be marked Multi-Arch: foreign'
> link: https://wiki.debian.org/MultiArch/Hints#ma-foreign
> severity: low
> source: libisofs
> The MultiArch/Hints wiki page says
>   "marking it Multi-Arch: foreign usually is safe."
> but does not clearly state what it means by "usually".

The package libisofs-doc is Architecture: all, does not contain any maintainer
scripts and does not have any dependencies on architecture-dependent packages.
Thus, marking it as Multi-Arch:foreign should be correct.

It says "usually" because this analysis is wrong if any of the metadata the
analysis is based on is wrong.

> There is no mentioning of "Multi-arch" in
>   https://www.debian.org/doc/debian-policy/ch-controlfields.html

Multiarch is not in policy yet but it has been in Debian since Wheezy. The four
year old policy bug can be found here:

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

> nor is there an explanation of "foreign" in
>   
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture

"foreign" is no architecture but one of the possible values of the Multi-arch
field.

> More Google brings me to
>   https://wiki.debian.org/Multiarch/HOWTO
> with the statement:
>   "If a package is marked 'Multi-Arch: foreign', then it can satisfy
>dependencies of a package of a different architecture."
> 
> Duh !
> I am about as confused as a year ago:

A better (and the probably still most complete) explanation is here:

https://wiki.ubuntu.com/MultiarchSpec


>   "Multi-arch and debian/control"
>   https://lists.debian.org/debian-mentors/2015/09/msg00403.html
> All packages got "Multi-arch: same" then, except libisofs-doc which
> got no Multi-arch header at all. I cannot find or remember the reason
> for that.

Some packages are just neither Multi-arch same, foreign nor allowed. In the
case of libisofs-doc, it is very likely that it can be correctly marked as
"foreign".

> Could somebody please look into
> https://tracker.debian.org/media/packages/libi/libisofs/control-1.4.4-1 and
> tell me what to do ?

You could just mark libisofs-doc as Multi-Arch:foreign.

> (And was i really expected to google for a link to the 1.9 MB yaml file ?)

Nope and I agree that the current way to find the actual problem in the tracker
is suboptimal.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#834262: RFS: pdfrw/0.2-3 [QA] -- PDF file manipulation library

[Johannes Schauer]

Hi Sean,

Quoting Sean Whitton (2016-08-13 23:30:54)
> Changes since the last upload:
> 
>   * QA upload.
>   * Drop "Conflicts:/Provides:/Replaces: pdfrw" lines (Closes: #814289).
> The pdfrw binary package is long gone and was never part of a release.
> This fixes co-installing python-pdfrw and python3-pdfrw, and other
> package combinations.
> Thanks to Aaron M. Ucko and Yuri D'Elia for useful information.
>   * d/copyright improvements:
> - Add proper DEP-5 header
> - Correct licence name MIT -> Expat
> - Factor out Expat license text into its own paragraph
> - Update copyright years for Patrick Maupin
> - Add missing copyrights of Attila Tajti, Narijus Mika & Mathieu Fenniak
>   See LICENSE.txt in upstream source.
>   * Fix Vcs-* URIs.
> They were previously pointing at the dgit repo for src:botch.

whoops! I have *no idea* who could've made this mistake! :D

>   * Declare compliance with Policy 3.9.8 (no changes required).
>   * Drop duplicate build-dependency on python-setuptools.
>   * Run wrap-and-sort -abst

Thanks, I did not know of wrap-and-sort. It looks useful!

> Since this package already has history on the dgit git server, I would
> like to request that the package be sponsored using dgit (non-DDs cannot
> push the history there).  To do that:
> 
> dgit clone pdfrw
> cd pdfrw
> git remote add -f spwhitton https://git.spwhitton.name/pdfrw
> git merge --ff-only spwhitton/master

This failed.

Instead, I rebased your branch on top of dgit/sid (which worked without
conflicts) and then rebased dgit/sid on top of your branch.

> git log -1
> # ^ confirm that commit hash is d715f1ef184907956865d94be4f14648bb279342

The latest commit hash in dgit/sid is now obviously different due to the rebase
but I confirmed it to be the right hash in your branch.

> # now perform all your pre-upload tests, builds etc., and then:
> dgit build-source
> dgit push

The last command is missing a -k. Otherwise it will fail because gpg cannot
find your private key on my system. ;)

Thanks a lot for your work!

Your changes all look good and thus I built, tested and uploaded the package
unstable.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi Paul,

Quoting Paul Elliott (2016-08-05 21:28:25)
> OK this time I deleted the recommended files as before, but I noted there
> were no other chroots in use. So I purged both sbuild and schroot with
> apt-get and reinstalled.

note that purging sbuild and schroot will not remove the chroots. But it will
get you a clean initual configuration.

> I then recreated th chroot using steps 1-6 of "Create the chroot" from the
> wiki page.

Which sbuild version are you using? Since fixing of bug #801798 (so since
sbuild version 0.67.0) steps 2 and 3 from that wiki page are not useful
anymore, unless you want to build packages for Debian squeeze.

Also, step 4 has only to be done once after you installed sbuild and not every
time you create a new chroot.

> I get the same error!
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: build-essential, fakeroot
> Filtered Build-Depends: build-essential, fakeroot
> dpkg-deb: building package 'sbuild-build-depends-core-dummy' in
> '/<>/resolver-aIr7Ri/apt_archive/sbuild-build-depends-core-dummy.deb'.
> dpkg-deb: error: failed to make temporary file (control member): No such
> file or directory
> Dummy package creation failed
> E: Setting up apt archive failed
> +--+
> | Cleanup
> 
> 
> Some how some bad data is being stored in some unknown place.
> 
> Is there any way to figure out what directory does not exist? (control
> member)

Please file a bug report against sbuild. Even if the problem is on your side,
the above error message is very cryptic and not helpful at all. In your bug
report, please include the following:

 - which sbuild version are you using?
 - which Debian release are you using?
 - list precisely which commands you are executing

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi,

Quoting Andrey Rahmatullin (2016-08-05 09:49:11)
> On Fri, Aug 05, 2016 at 02:42:27AM -0500, Paul Elliott wrote:
> > Before I was getting a different error complaining
> > that debfoster does not exist under "testing". BTW why does debfoster fail
> > to exist under testing?
> Because it was removed from testing and the new version hasn't entered
> testing yet.

note, that version 0.70.0 of sbuild in unstable (also didn't migrate to testing
yet) doesn't add debfoster to the chroot by default anymore.

So your problem shouldn't exist anymore with the most recent sbuild release.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi,

Quoting Paul Wise (2016-08-03 12:41:28)
> On Wed, Aug 3, 2016 at 1:06 PM, Johannes Schauer wrote:
> 
> > The main issue here is, that it is not clear *where* the bug should be 
> > filed.
> > Sbuild supports multiple backends. The probably most used one is the schroot
> > backend because that is used by sbuild-createchroot and the default of the
> > CHROOT_MODE configuration variable.
> >
> > Indeed I do remember having had a similar question when I started using 
> > sbuild
> > but never got around filing a bug. As far as I know, schroot still doesn't
> > document how to delete a chroot.
> 
> Seems to me like sbuild should have an sbuild-deletechroot command
> that should call the relevant tool for the chroot in question and
> schroot should have a corresponding command that would DTRT.

it is unlikely, that there will be a schroot command that does the right thing
because schroot also leaves it up to the user to create the chroot in the first
place. This is also why sbuild-createchroot is doing everything manually
including assembling the right schroot configuration file.

My last attempt at implementing a command that does this was stopped early on
by the question how this tool should best be called:

 - sbuild-deletechroot
 - sbuild-removechroot
 - sbuild-destroychroot

Maybe a native English speaker could tell me the most natural choice for a tool
that does the opposite of what sbuild-createchroot does.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi Paul,

Quoting Sean Whitton (2016-08-03 06:20:26)
> On Tue, Aug 02, 2016 at 11:06:31PM -0500, Paul Elliott wrote:
> > Sometimes a user gets a sbuild chroot so screwed up that it does not
> > work anymore, and the user has no idea how to fix it, because he does not
> > know what he did wrong.
> > 
> > He wants to start over from scratch.
> > 
> > The problem is, it is not documented the correct way to delete
> > the chroot and tar ball. The users want to put sbuild back to
> > the way it was just after sbuild was installed.

if it's not documented, you should file a bug about that. ;)

The main issue here is, that it is not clear *where* the bug should be filed.
Sbuild supports multiple backends. The probably most used one is the schroot
backend because that is used by sbuild-createchroot and the default of the
CHROOT_MODE configuration variable.

Indeed I do remember having had a similar question when I started using sbuild
but never got around filing a bug. As far as I know, schroot still doesn't
document how to delete a chroot.

> > What is the proper way to do that?
> 
> Asking for a friend? ;)
> 
> Assuming you used the suggestions for making the chroot on the sbuild
> wiki page, this should do it:
> 
> # rm -rf /srv/chroot/* /etc/sbuild/chroot/*-sbuild 
> /etc/schroot/chroot.d/*-sbuild
> 
> If you didn't use the suggestions on the wiki page, just start nuking
> stuff in those three directories.

Paul was talking about "a chroot" (singular). The above advice kills all
chroots including those that are not related to sbuild. Assuming that you are
using the schroot backend, you can do the following:

 1. figure out which schroot you were using with sbuild. If you used an
unstable chroot on amd64, then look out for a file that is called like
/etc/schroot/chroot.d/unstable-amd64-sbuild-XX where XX is a random
ASCII string
 2. look inside that file to figure out where the chroot data lives in your
file system by looking at the directory= or the file= options
 3. if you want to delete the schroot, just delete the configuration file under
/etc/schroot/chroot.d/unstable-amd64-sbuild-XX together with the actual
chroot the configuration file pointed to

I never heard about /etc/sbuild/chroot/ but it seems it's used for the sudo
backend. I don't even know where the code is that creates this. But if you
don't care, then you can leave that directory alone.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#814859: RFS: runescape/0.1-1 [ITP] -- Set in a fantasy world of war, landscapes and sinister powers

[Johannes Schauer]

Hi,

On Tue, 16 Feb 2016 00:16:06 -0200 Carlos Donizete Froes  
wrote:
>   To access further information about this package, please visit the
>   following URL:
> 
>   http://mentors.debian.net/package/runescape

is it me or did the package vanish from mentors.debian.net?

How much sense does it make to package the java archive instead of the
rsu-client or (possibly even better) the NXT client?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Mass-rebuilding packages

[Johannes Schauer]

Hi,

Quoting Paul Wise (2016-05-02 08:37:49)
> On Mon, May 2, 2016 at 7:44 AM, Sean Whitton wrote:
> 
> > Thanks for the responses, all.
> 
> Another one is ratt (rebuild-all-the-things).
> 
> I wonder if some of these should be merged together or removed.

from this thread I gather that there are the following tools:

reverse-depends (from ubuntu-dev-tools), build-rdeps (from devscripts) and ratt
(from ratt).

From reading the reverse-depends source I gather that it doesn't do the
computation locally but queries http://qa.ubuntuwire.org/rdepends The source
for that tool is available but seems to suffer from similar problems with
dependency resolution as I reported for build-rdeps and ratt:

 - build-rdeps: https://bugs.debian.org/797858
 - ratt: https://bugs.debian.org/801593

It probably doesn't make much sense to post a bug against reverse-depends
because the tool it relies upon for its computation is not part of Debian.
Both above bugs are fixed and both tools now use dose-ceve for reverse build
dependency resolution. So both tools should yield the same results and there is
only one source package that has to be touched if their results are wrong
(dose3).

I think the advantages of ratt over build-rdeps are:

- ratt uses "apt indextargets" and "apt-helper cat-file" to retrieve Packages
  and Sources file contents while build-rdeps relies on manually interpreting
  the contents of /var/lib/apt/lists (See #752702 why this is problematic)

- ratt also drives a package builder (only sbuild for now) to build the
  affected source packages

I think it's suboptimal that reverse-depends only works when it can query an
online resource. On the other hand, the dose-ceve run done by ratt and
build-rdeps also takes quite a while (20 seconds on my laptop) so maybe it
would be nice to have an online resource with the same API as
http://qa.ubuntuwire.org/rdepends for Debian. Then users could choose to use
that instead of waiting 20 seconds for each query.

cheers, josch


signature.asc
Description: signature

Re: sbuild “Failed to fetch source files”

[Johannes Schauer]

Hi,

Quoting Ben Finney (2016-04-21 04:17:02)
> I am using ‘sbuild(1)’ successfully for some packages. For one package,
> though, I'm getting an error I don't understand: The source package is not
> found by Sbuild.
> 
> One version finds the source package correctly:
> 
> =
> +==+
> | python-coverage 3.7.1+dfsg.1-1 (amd64) 21 Apr 2016 
> 11:29 |
> +==+
> 
> Package: python-coverage
> Version: 3.7.1+dfsg.1-1
> Source Version: 3.7.1+dfsg.1-1
> […]
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Local sources
> -
> 
> /home/bignose/Projects/debian/python-coverage/build-area/python-coverage/python-coverage_3.7.1+dfsg.1-1.dsc
>  exists in 
> /home/bignose/Projects/debian/python-coverage/build-area/python-coverage; 
> copying to chroot
> […]
> =
> 
> 
> When I try another version, Sbuild apparently can't find the source package:
> 
> =
> +==+
> | ./python-coverage 4.0.3+dfsg.1-1 (amd64)   21 Apr 2016 
> 11:10 |
> +==+
> 
> Package: ./python-coverage
> Version: 4.0.3+dfsg.1-1
> Source Version: 4.0.3+dfsg.1-1
> […]
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Check APT
> -
> 
> Checking available source versions...
> W: Unable to locate package ./python-coverage
> apt-cache returned no information about ./python-coverage source
> Are there any deb-src lines in your /etc/apt/sources.list?
> […]
> =
> 
> Why does it need to check APT, when the source package is all local to
> the source control file?

could you show us the exact sbuild invocation you used in each of the above two
cases?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: debian/control: Multi-Arch: no

[Johannes Schauer]

Hi,

Quoting Andrey Rahmatullin (2016-02-11 15:16:01)
> On Thu, Feb 11, 2016 at 11:20:14AM -0200, Herbert Fortes wrote:
> > libcdk5-dev was rejected by ftp-masters because
> > it has 'Multi-Arch: no' on debian/control.
> You could just omit the field, no need to use the explicit "no".

While this is correct, I don't see what should be wrong with explicitly stating
the default. It could have the meaning of: the package was looked at for
multi-archification but it was deemed that it is either not possible or that
there is no need to make it multi-arch aware, so setting the value explicitly.

Unfortunately, multi-arch is not in policy yet (#687900).

> > "Multi-Arch: no support in Debian is broken (#768353)"
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768353
> The bug is closed in 2014, though.

I do not understand why this bug was cited as the reason for the package not
being allowed in Debian. If the messages in the bugs are right, then this
dose3-related problem was fixed with version 3.2.2-3 and Jessie has version
3.3~beta1-3.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: conditionally require dependency

[Johannes Schauer]

Hi Nico,

Quoting Nico Schlömer (2015-10-26 00:47:54)
> particularly those which have been released a while ago and are closed
> to adding now packages now.

packages can be added via backports.

> > - if you were talking about a *build* dependency, then you can generate
> these
> >   before building by having a debian/control.in and turning that into the
> >   right debian/control depending on what you want to build
> 
> Good idea. I'll look into it.

remember that the other way I mentioned, having different git branches for
different target distributions would also apply for your use case.

> >  - alternatively, if you were talking about a *build* dependency you
> could use
> >build profiles to selectively enable or disable build dependencies
> 
> Never heard of it. I'll check it out as well.

This would work technically but there is no accepted way to do this in practice
yet in Debian or Ubuntu. Build profiles allow you to select or unselect build
dependencies depending on conditions you specify in the Build-Depends line. So
technically it would be possible to say that a build dependency should only be
used if the profiles "debian" and "unstable" are active and then when you build
your source package you would have to take care to have the right profiles
active per build with the DEB_BUILD_PROFILES environment variable or with the
-P option to dpkg-buildpackage. There is more info on
https://wiki.debian.org/BuildProfileSpec But remember that at this point this
would just be another hack! While build profiles can be used this way to
support multiple distributions and releases with a single debian/control file,
there is not yet any decision (or even the attempt to have it) of how the build
profiles should be named for this use case.

cheers, josch


signature.asc
Description: signature

Re: conditionally require dependency

[Johannes Schauer]

Hi Nico,

Quoting Nico Schlömer (2015-10-24 20:04:19)
> In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) depend on
> a rather new version of the [Metis](https://packages.debian.org/sid/metis)
> package, and that's what's enforced in our debian/control, too.

I cannot see any (build-)dependency on metis in your debian/control:

https://bitbucket.org/fathomteam/moab/src/HEAD/debian/control?at=master

> Now, we would like to provide MOAB for older versions of Debian/Ubuntu as
> well, and for those older distros would drop the optional Metis dependency.

Runtime dependency or build dependency?

> How is this situation best handled?

The best way to do this is to get your package into Debian. In that case the
content of debian/control will be different in testing/unstable as well as in a
backport that you can do for the current stable or oldstable.

Your problem arises because you want a one-size-fits-all of your upstream
debian/control. Such a one-size-fits-all often doesn't exist but having a
one-size-fits all is also usually not required because the packaging data
including debian/control between different Debian releases can be (and mostly
is) different.

If you do not want to get your package into Debian (and through there into
Ubuntu) but instead provide Debian/Ubuntu packages yourself as the upstream
project, I see these options:

 - have one git branch for every Debian/Ubuntu release you want to support and
   let them have different debian/control content depending on what is required

 - if you were talking about a *runtime* dependency earlier then you could just
   make it a Recommends

 - if you were talking about a *runtime* dependency but need a *strict*
   dependency then you can generate this dependency during package build time
   using a substvar (see man deb-substvars) in your Depends line

 - if you were talking about a *build* dependency, then you can generate these
   before building by having a debian/control.in and turning that into the
   right debian/control depending on what you want to build

 - alternatively, if you were talking about a *build* dependency you could use
   build profiles to selectively enable or disable build dependencies

Note, that all of these suggestions are *not* the right way to do things in
case your package is in Debian or Ubuntu itself. In this case your problem
doesn't arise in the first plae.

cheers, josch


signature.asc
Description: signature

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Johannes Schauer]

Hi,

Quoting Christoph Biedl (2015-09-30 08:25:50)
> Personally, I'm not happy about adding extra magic to version numbers
> to identify binNMUs and would rather introduce a way to define a range
> of version numbers a package satifies, like in
> 
> | Version: 5.25-3+b1# upper bound
> | Also-Satifies: 5.25-3 # lower bound
> 
> or by allowing two version numbers in the Version: header. But that's
> certainly not my cup of tea, and might bring in a huge amount of new
> problems I cannot even imagine yet.

in fact, this can already be done:

Package: foo
Architecture: any
Version: 5.25-3+b1
Provides: foo (= 5.25-3)

This is possible since fixing of bug #7330 in dpkg 1.17.11 and bug #758153 in
apt 1.0.7. So this should work in Jessie.

cheers, josch


signature.asc
Description: signature

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Johannes Schauer]

Hi,

Quoting gregor herrmann (2015-09-30 18:24:22)
> The last thing I heard about versioned Provides is that not all pieces of the
> infrastructure support it yet. (wanna-build or something was missing).
> 
> I'd be more than happy to hear if this is all fixed by now.

dose3 (which is used to check for build dependency satisfaction before giving
source packages to the buildds) does not yet support versioned provides. Fixing
this is in the works in the dose3 upstream git but the latest commits are not
fully compatible with the dpkg interpretation of versioned provides so it needs
more work.

Here is the Debian bug:

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

And here the upstream bug:

https://gforge.inria.fr/tracker/index.php?func=detail=17903_id=4395=13808

cheers, josch


signature.asc
Description: signature

Re: +dfsg extension with Files-Excluded: in d/copyright

[Johannes Schauer]

Hi,

Quoting Sebastiaan Couwenberg (2015-09-01 12:13:07)
> Add the repacksuffix option, e.g.:
> 
> version=3
> opts=\
> dversionmangle=s/\+dfsg//,\
> uversionmangle=s/$/+dfsg/,\
> repacksuffix=+dfsg \
> http://heasarc.gsfc.nasa.gov/FTP/software/lheasoft/fv/ \
> fv(.+\..+)_src\.tar\.gz
> 

is the uversionmangle option still needed with repacksuffix?

I maintain several packages (fuzzylite, ldraw-parts, libfixbuf, pdf2htmlex and
vcmi) which all repack the upstream tarball with Files-Excluded but which are
all happy with just repacksuffix and dversionmangle.

In fact, when I try to uversionmangle a suffix like +dfsg, +ds or +debian, I
get this lintian problem:

https://lintian.debian.org/tags/debian-watch-file-should-dversionmangle-not-uversionmangle.html

cheers, josch


signature.asc
Description: signature

Re: +dfsg extension with Files-Excluded: in d/copyright

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2015-09-01 12:22:22)
> See #748465. Some people abuse debian/copyright for excluding files for
> reasons unrelated to DFSG...

so am I for my packages. The simple reason: just running "uscan" to check,
download and repack upstream sources is just too simple and convenient if
compared with putting a custom repack script into my package.

So far I did not see another declarative way to specify paths to be excluded
from my upstream tarball automatically upon download.

> My recommendation is to never use Files-Excluded.

What is your recommendation then?

> It's a broken design.

I would argue: so is the whole format of debian/watch. It would've been a much
better idea to have this file in deb822 format so that it would be easily
extensible. In that case we could now just add the Files-Excluded field to
debian/watch and be done with it. Surely, in theory you could also make another
"opts" argument for uscan but putting path wildcards in the current
debian/watch format will surely not be pretty...

cheers, josch


signature.asc
Description: signature

Re: don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2015-08-31 16:02:38)
> * Johannes Schauer <jo...@debian.org>, 2015-08-31, 15:53:
> >>From now on, "sbuild --dist sid --arch amd64 path/to/my.dsc" works.
> >
> >It must be mentioned that a common problem with sbuild is, that the 
> >.changes file it generates will have a *different* distribution from 
> >the one you set in debian/changelog if you use the --dist or -d option! 
> >If sbuild changed the value of the distribution field in the .changes 
> >file, it will do so in *red* but it is still easy to miss this.
> >
> >The *right* thing to do is to choose the chroot with the -c or --chroot 
> >option. The -d or --dist option will do the same job, but the side 
> >effect that it changes the distribution field in the .changes file it 
> >creates can be a very dangerous one.
> >
> >So please don't further advertise the -d or --dist option anymore if 
> >you actually want to use the -c or --chroot option instead!
> 
> Um, except that -d/--dist is obligatory. Without it you get:
> 
> No distribution defined

indeed I must've made an error when testing this. This just makes the whole
problem even worse...

So now the advise becomes: never let the argument to -d/--dist be different
from what you want to have in the distribution field in your changes file.

This then also puts some constraints on the naming of schroots - unless of
course the -c option is specified *in addition*.

cheers, josch


signature.asc
Description: signature

don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)

[Johannes Schauer]

Hi,

Quoting Danny Edel (2015-08-21 13:43:41)
> On 21/08/15 13:21, Danny Edel wrote:
> > Once sbuild is setup
> 
> Just to clarify. In this use case (using sbuild as close to buildd as
> possible), the steps labeled "for personal use" in
> https://wiki.debian.org/sbuild#Configuration
> are *not* what we want.
> 
> The Source package will be created by debuild -S on the host machine,
> and sbuild will *only* build the binary.

for the pure purpose of building a source package, having devscripts installed
for debuild is not needed. You can instead use dpkg-buildpackage directly.
Though, if you really just want to build the source package, then even better
than `dpkg-buildpackage -S` is to run `dpkg-source -b .`. The advantage is,
that you do not have to have any packages installed which are necessary to run
the clean target. You probably don't want to install any extra packages like
that on your host if you are using sbuild later anyways.

Furthermore, instead of creating the source package manually before invoking
sbuild on the dsc, you can also execute sbuild directly without any arguments
inside the unpacked source. It will detect this and build the source package
automatically for you.

> logout-relogin or use "newgrp sbuild" in your current shell.

Good suggestion, I added it to the wiki page.

> Now to create the chroots:
> 
> [...]
> 
> Thats it. Note that you can also use "wheezy" or "jessie" if you plan on
> testing backporting to those.
> 
> From now on, "sbuild --dist sid --arch amd64 path/to/my.dsc" works.

It must be mentioned that a common problem with sbuild is, that the .changes
file it generates will have a *different* distribution from the one you set in
debian/changelog if you use the --dist or -d option! If sbuild changed the
value of the distribution field in the .changes file, it will do so in *red*
but it is still easy to miss this.

The *right* thing to do is to choose the chroot with the -c or --chroot option.
The -d or --dist option will do the same job, but the side effect that it
changes the distribution field in the .changes file it creates can be a very
dangerous one.

So please don't further advertise the -d or --dist option anymore if you
actually want to use the -c or --chroot option instead!

The -d or --dist option is used for when you want sbuild to even acquire the
source package for you, in which case it otherwise does not know from which
distribution to `apt-get source` it from.

I raised the issue in this thread on buildd-tools-devel@l.a.d.o:

http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2015-July/009671.html

Please comment over there if you have a good idea to solve this common mistake.

> I would recommend setting up a local (partial) debian mirror to speed up the
> package fetching step, but I've gotten weird "500 invalid header" errors when
> I use apt-cacher-ng, so I'm not recommending this for now.

I am using apt-cacher-ng as well but I don't think I've encountered HTTP 500
errors so far. Maybe you can investigate the issue and file a bug?

> The only sbuild configuration line I *strongly* suggest is
> 
> $environment_filter = [ ];
> 
> This will ensure that no CXXFLAGS= or similar from your working environment
> contaminate the clean chroot.

If you think the default should be changed, could you please file a bug against
sbuild about that?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Build on hurd-i386 and kfreebsd-amd64 ... at home

[Johannes Schauer]

Hi,

Quoting gustavo panizzo (gfa) (2015-07-21 08:05:47)
 On 2015-07-20 16:34, Johannes Schauer wrote:
  crossbuilding is not equal to native building. I think Daniel was looking 
  for a
  way to test if their packages build natively on hurd-i386 or kfreebsd-amd64.
  But crossbuilding from linux (which I'll just assume Daniel runs on their 
  host)
  to hurd or kfreebsd will lead to different results than natively building on
  these kernels in (probably) most cases.
 would that make the test useless? I build test using qemu-static-
 before upload to debian to avoid FTBFS when the package reach the buildd
 network

are you using qemu-static- to build on linux for hurd or kfreebsd?

The *only* 100% sure way to know if your package builds on the buildds is... to
upload and build your packages on the buildds.

The second best way is to build either on real hardware (your own or a
porterbox) or in a virtual machine which emulates a whole machine, including a
kernel.

The third best way is to only emulate the architecture but not the kernel. This
is what qemu-user does. This will probably let you run into kernel specific
problems.

For example, lets create a chroot for hurd-i386 on my amd64 box. Since my amd64
machine is perfectly able to execute i386 code, we don't even need qemu here:

sudo debootstrap --arch=hurd-i386 sid debian-sid-hurd-i386

Trying to execute anything inside there yields a segmentation fault which I do
not find surprising. For example, the above debootstrap command, since
hurd-i386 a foreign architecture to my amd64 machine, will only execute the
first stage (unpacking) of debootstrap. For the second stage to work I'd have
to mount /proc but I'd not know how a hurd-i386 system would work with my linux
/proc (probably not at all).

But even if you are usign qemu-static only with linux-any arches on linux,
there are packages for which you'll run into problems. For example lets try the
following:

$ sudo debootstrap --arch=armhf sid debian-sid-armhf
$ sudo apt-get install qemu-user-static binfmt-support
$ sudo cp /usr/bin/qemu-arm-static debian-sid-armhf/usr/bin
$ sudo chroot debian-sid-armhf uname -a
Linux hoothoot 4.0.0-2-amd64 #1 SMP Debian 4.0.5-1 (2015-06-16) armv7l GNU/Linux

whoops! So the emulated system is able to find out that my kernel actually
has an amd64 release number! It becomes worse if, for your build you have to
bind mount things from your host into the chroot because then even more will
spill from your amd64 host into your armhf system. There are more ways for a
program being emulated by qemu-static to find out that it's not running on real
hardware. And these differences might break some packages.

If it doesn't break yours: cool! But qemu-user will fail for *some* packages,
so it is not a general cure.

And sure, if your package does noting fancy but just calls cp a couple of times
to put everything in the right location, then nothing will go wrong with the
qemu-user method. But if your package is that simple, then you probably also
don't need to test it.

cheers, josch


signature.asc
Description: signature

Re: Build on hurd-i386 and kfreebsd-amd64 ... at home

[Johannes Schauer]

Hi,

Quoting Daniel Stender (2015-07-19 17:52:16)
 I'm looking for a convenient way to test build source packages against resp.
 on hurd-i386 or kfreebsd-amd64 instead of setting up simple end user Qemu
 boxes and build within them. Sbuild and qemu-debootstrap somehow?

there seems to be this: https://wiki.debian.org/qemubuilder but I never tried
that and don't know if these instructions still work.

sbuild itself only supports two chroot methods right now (schroot and sudo,
settable via $chroot_mode, look into sbuild.conf(5)) so it currently is not
able to make use of qemu.  I've eyed the adt-virt-* from the autopkgtest
package for a while. It would be cool to add support for them to sbuild because
then sbuild would immediately support building in a chroot, in lxc, qemu or a
machine connected via ssh.  Since adt-run does package builds itself, these
tools probably are powerful enough for that purpose. I just have no time to
implement this :)

cheers, josch


signature.asc
Description: signature

Re: Build on hurd-i386 and kfreebsd-amd64 ... at home

[Johannes Schauer]

Hi,

Quoting gregor herrmann (2015-07-20 10:14:12)
 cowbuilder and qemu-debootstrap work for me (with armhf and armel,
 haven't tried with other architectures):
 http://info.comodo.priv.at/blog/cowbuilder_crossbuilds_for_raspbian.html
 
 The linked article
 http://blog.waja.info/2013/11/25/crossbuilding-debian-packages-with-sbuild-for-raspbian/
 explains a setup with sbuild and qemu; also for Raspbian and armhf
 but it's probably worth a try for hurd or kfreebsd as well.

crossbuilding is not equal to native building. I think Daniel was looking for a
way to test if their packages build natively on hurd-i386 or kfreebsd-amd64.
But crossbuilding from linux (which I'll just assume Daniel runs on their host)
to hurd or kfreebsd will lead to different results than natively building on
these kernels in (probably) most cases.

cheers, josch


signature.asc
Description: signature

Re: Sbuild doesn't pick experimental over unstable

[Johannes Schauer]

Hi,

Quoting Daniel Stender (2015-07-10 09:32:19)
 The problem is, I can add experimental as extra repository 
 (--extra-repository),
 but the dependency solver won't pick over the package in Sid and always pulls 
 1.9.0 [1].
 
 Is this the way it's mend to work? Is there a way to cheat this?

the problem is, that the experimental repository has a Release file with
NotAutomatic: yes which means that apt will assign a pin priority of 1 to it.
The apt resolver will only consider the packages with the highest pin priority
for the solution (unless you instruct it to do otherwise) so it will by default
not consider packages coming from experimental.

As jwilk already noted, one solution is to choose aptitude as a resolver. Since
this seems to be a common problem, I wrote an entry in the sbuild Debian wiki
about this. Please extend or correct where necessary:

https://wiki.debian.org/sbuild#enabling_experimental

For example it currently misses that you might also be able to use
--extra-repository to temporarily enable experimental. If this indeed works,
please add this as a solution.

Another way to solve this would be to use apt with an external resolver like
this:

apt-get install --simulate --solver aspcud \
-o APT::Solver::Strict-Pinning=false \
-o 
APT::Solver::aspcud::Preferences=-new,-removed,-changed,+sum(solution,apt-pin)
 \
pkg-a

This would also consider packages from experimental when installing pkg-a while
at the same time find the solution with the most packages with a high pin value
(ie. least packages from experimental).

But this would of course require a change in sbuild and would probably not be
desirable because an external resolver like aspcud would have to become part of
the base chroot.

See apt bug #786609 for some discussion about apt's behaviour with
experimental.

Thanks!

cheers, josch


signature.asc
Description: signature

RE:Sbuild doesn't pick experimental over unstable

[Johannes Schauer]

Hi,

Quoting PICCA Frederic-Emmanuel (2015-07-10 10:54:20)
 Is it possible to configure this per chroot in order to avoir passing this
 command line each time ?

No.

But if bug #790354 (with patch) gets resolved, then you will able to pass a
custom configuration file which you can then use to set custom options and also
select which chroot you want to use for building.

So instead of choosing the chroot you want to build with, you would then choose
the sbuildrc you want to use.

cheers, josch


signature.asc
Description: signature

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

[Johannes Schauer]

Hi,

Quoting lumin (2015-05-22 06:31:34)
 override_dh_auto_clean:
 cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
 dh_auto_clean
 # without following line the the source tree 
 # would be not clean. Hence dpkg-buildpackage
 # refuse to build.
 rm Makefile.config

instead of calling rm explicitly in your d/rules, you can also add
Makefile.config to debian/clean instead which might be considered a bit more
clean :)

cheers, josch


signature.asc
Description: signature

Re: not installed and installed , where they store?

[Johannes Schauer]

Hi,

Quoting Mohsen Pahlevanzadeh (2015-05-10 05:53:17)
When i use : grep ^Status: /var/lib/dpkg/status ,
Unfortunately , i only get Status: install ok installed

how sure are you of that? Did you just look at the first few hundred or did you
really find all unique values? Try:

grep ^Status: /var/lib/dpkg/status | sort | uniq -c

cheers, josch


signature.asc
Description: signature

Re: Re: Big data is needed for unit test

[Johannes Schauer]

Hi,

Quoting Corentin Desfarges (2014-12-02 17:29:12)
  Can you link to the file we are talking about?
 With the authorization of the responsibles of the project, I published the 
 file here [2]
 [2] http://goo.gl/53sAzM

this looks a bit weird. I guess this google thing allows you to inspect the
content of zip files?

The 178 MiB file in question named md_1.jsonz is not a gzipped json file as the
name suggests but a zip archive which contains a 1.4 MiB json file with
metadata and 470 MiB of what seems to be binary data.

If you want to add more complexity to compress this further and save space, you
could add the md_1.jsonz file to a Debian source package in its *unzipped*
version.  The xz compressor will then be able to compress the data down to 120
MiB (with both, -9 and -9e). During build time you would then zip the content
again (with --compression-method=store for speed because size doesn't matter
now) because I guess your software expects the data in this zipped format and
cannot handle it in unpacked form. This method would allow you to safe another
58 MiB in comparison to just adding the original file. I guess it is up to you
whether you want to do it like that to reduce file size or not because as pabs
already pointed out, there are already source packages in Debian that are
larger than 200 MiB. So this is just an idea :)

cheers, josch


--
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/20141202182705.6173.3052@hoothoot

Re: Big data is needed for unit test

[Johannes Schauer]

Hi,

Quoting Paul Wise (2014-12-01 17:03:39)
  Should I simply remove this test, or can I include the data file in the
  package ?
 
 Can you include more details about this data file?
 
 What data format is the file in?

depending on the answer to this question it might be very simple to compress
the file to 5-10% of its original size (usually possible for XML based
formats).

cheers, josch


--
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/20141201162850.6173.1592@hoothoot

Bug#742077: RFS: vcmi/0.97+dfsg-1

[Johannes Schauer]

Hi,

I just packed a new upstream release and am still looking for a sponsor :)

Vcmi is a GPL2+ reimplementation of the Heroes of Might and Magic 3 game
engine. It works with the (proprietary) assets from the original game CDs as
well as with the GOG.com version.

This is the third vcmi release I am packaging and uploading to mentors since I
started packaging it eight months ago:

http://mentors.debian.net/debian/pool/contrib/v/vcmi/vcmi_0.97+dfsg-1.dsc

The great thing about this release is, that upstream added support for
fuzzylite 5.0 after fuzzylite upstream in turn wrote a patch for vcmi. This
means that the embedded copy of fuzzylite is removed from this Debian package
of vcmi which also solves the licensing issue.

On the other hand, this means that before vcmi can go into Debian, I also need
a sponsor of fuzzylite ITP #761075 and RFS #766833

In addition to solving the fuzzylite problem, this release also brings:

 - removal of the embedded copy of minizip
 - improved man pages
 - HTML documentation

Lots of praise goes to jwilk for helping me fix some annoying boost/locale
errors :)

Thanks!

cheers, josch


--
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/20141103074321.23676.1872@hoothoot

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

[Johannes Schauer]

Hi Stephen,

Quoting Stephen Kitt (2014-11-04 00:41:57)
 I've taken a look at the package and it seems fine, apart from the two points
 remaining from your exchanges with Jakub:
 
 * the hard-coded paths in src/Console.cpp
 * the spelling/grammar errors
 
 Regarding the latter, I prefer ... method `static bar` was made `virtual
 foo::bar`, which allows it to be overridden.

Oh sorry, I already submitted a patch to upstream which says:

Its method `static tsukamoto()` was moved to `virtual 
WeightedDefuzzifier::tsukamoto()`, which allows overriding it

And upstream already applied it. https://github.com/fuzzylite/fuzzylite/pull/11

Is the grammar still wrong and should I prepare another pull request?

(plus, of course fix this in the packaging until the next upstream release)

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

The result of the former is, that two possible but undocumented commandline
arguments of the fuzzylite binary do not work and instead produce an error that
they cannot find some files.

Upstream's opinion is, that this functionality is not something that is
intended to be used by anybody but them:

https://github.com/fuzzylite/fuzzylite/issues/10

I see two ways to go forward:

 1) We accept that the two commandline arguments that are not working are
neither found in the --help output of the binary nor in the man page I
wrote, so it's unlikely the user will ever run them except if they read the
source code. The solution would thus be ignoring the issue.

 2) Make a quick patch which removes those two option from the commandline
interface

I'm inclined to do the former, because I see little difference between the
program failing because there is no such commandline argument and the program
failing because you are not upstream because the chances that the user will
ever have this problem go towards zero as neither of those two non-working
options are documented anywhere but the source code itself.

What do you think?

Thanks!

cheers, josch


--
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/20141104060705.13657.8041@hoothoot

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

[Johannes Schauer]

Package: sponsorship-requests

Dear mentors,

I am looking for a sponsor for my package fuzzylite

 * Package name: fuzzylite
   Version : 5.0+dfsg-1
   Upstream Author : Juan Rada-Vilela
 * URL : http://www.fuzzylite.com/cpp/
 * License : LGPL3
   Section : misc

It builds those binary packages:

 fuzzylite  - fuzzy logic control binary
 libfuzzylite-dev - fuzzy logic control development headers
 libfuzzylite5.0 - fuzzy logic control shared library

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

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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/f/fuzzylite/fuzzylite_5.0+dfsg-1.dsc

I'm CC-ing the Debian Games list because fuzzylite is required for
packaging vcmi, a free reimplementation of Heroes of Might and Magic 3.
See ITP #742077.

Vcmi includes an ancient copy of fuzzylite with custom patches. To make
vcmi fit for Debian, the embedded copy of fuzzylite has to be removed.
Unfortunately, the fuzzylite API changed considerably between 2012 and
now. Thus, porting vcmi to current fuzzylite 5.0 is a non-trivial
effort.

Luckily, Juan Rada-Vilela, the author of fuzzylite volunteered to do
this porting task because he is interested in getting fuzzylite into
Debian and he wishes to see more users of his library. I now forwarded
his work to vcmi upstream and they say they will try to get fuzzylite
5.0 support into their next release.

With this development I'm now looking for sponsors for fuzzylite 5.0.
Having it in Debian is an important step to convince vcmi upstream to
remove their embedded copy. To quote Not much point in doing this until
at least some of somewhat popular distros will have their own copy of
fuzzylite (http://bugs.vcmi.eu/view.php?id=1886)

It would be great to find a sponsor for my package and get that and vcmi
into Debian because Heroes of Might and Magic is a fantastic game and
vcmi not only makes its engine free as in freedom but also adds tons of
additional features such as modding capabilities to the engine.

Thanks!

cheers, josch


-- 
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/20141026080155.6292.34932.reportbug@hoothoot

Bug#742077: vcmi will start using fuzzylite 5.0

[Johannes Schauer]

Control: block -1 by #761075

Everybody rejoice \o/

Juan Rada-Vilela, the author of fuzzylite agreed to port the parts of vcmi that
used the old fuzzylite to fuzzylite 5.0. He now finished his work and I
submitted his patch to vcmi upstream: https://github.com/vcmi/vcmi/pull/45
According to one of the upstream developers, they'll try to get his patch
working for the next vcmi release!

Once this is done, vcmi will no longer need the embedded copy of fuzzylite and
can instead build with the system version of fuzzylite 5.0. Since fuzzylite 5.0
is LGPL3 there are also no licensing issues anymore.

Now we only need to get fuzzylite into Debian. I filed RFS bug #766833 about
that.

Thanks!

cheers, josch


--
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/20141026080332.5388.28542@hoothoot

Re: How to resolve circular build dependency?

[Johannes Schauer]

Hi,

Quoting Ole Streicher (2014-09-13 15:20:36)
 Am 13.09.2014 um 15:09 schrieb Mattia Rizzolo:
  On Sep 13, 2014 3:01 PM, Ole Streicher debian-de...@liska.ath.cx wrote:
  - the casacore needs the casacore-data package for unit tests
  - the casacore-data needs casacore to be build from the source data.
  
  What's about upload casacore with the tests disabled, then upload
  casacore-data, then re-upload casacore with the tests re-enabled?
 
 Still, the packages would have a circular build dependency, which I think 
 should be avoided, right?

It is indeed nice to bootstrappers if circular build dependencies are avoided.
This is especially the case if a package has many reverse (build-)dependencies.

But there are two bootstrapping scenarios to consider. One is the one where
somebody wants to bootstrap a new architecture. The casacore-data binary
package sounds as if it is Architecture:all? In that case you should not worry
about circular build dependencies during bootstrapping for a new architecture
because the bootstrapper can just take an existing casacore-data binary package
to build first src:casacore and then src:casacore-data.

The other scenario is bootstrapping from nothing just for the sake of checking
bootstrappability of the archive including bootstrapping Architecture:all
packages. To be nice to bootstrappers you have several options:

 1. split the source package as Alexander Wolf suggested so that the unit tests
are in their own package and cascore can be built without cascore-data. You
could still run tests by using the cascore-unit-tests package as a
autopkgtest
 2. join src:casacore-data and src:casacore into a single source package and
handle bootstrapping of both via debian/rules
 3. make it such that src:casacore can be cross compiled from an existing
architecture so that src:casacore-data can be compiled natively after which
src:casacore can be compiled natively
 4. use build profiles once Jessie is released. Once Jessie is released, you
can 'tag' the build dependency of src:casacore on casacore-data with
!nocheck and then the build dependency would not be required when being
built with the nocheck profile active

Options 1-3 might make maintaining src:casacore and src:casacore-data very
difficult, so that together with the fact that neither is currently in Debian
and thus there are no reverse (build-)dependencies on it, you might want to
wait until Jessie is released and then use build profiles. Until you can use
build profiles, just write down in README.Source of both packages that this
build dependency cycle exists and how to best break it manually.

cheers, josch


--
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/20140913135312.3685.17954@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

Quoting Eriberto (2014-08-29 17:08:37)
 2014-08-29 12:02 GMT-03:00 Paul Wise p...@debian.org:
  Please ask vmci upstream to remove the embedded copy of fuzzylite and
  depend on the system version.
 
  https://wiki.debian.org/EmbeddedCodeCopies
 I thought about it too. This is the best option.

I started packaging fuzzylite 5.0 and found out that they do not offer
versioned SONAMES (I reported that and seven other bugs I found to fuzzylite
upstream).

At the same time I asked on debian-legal and it seems to be possible to
distribute vcmi (gpl2+) together with fuzzylite (apache2) because gpl2+ implies
gpl3 which is compatible with apache2.

So the only remaining problem seems to be the embedded copy of fuzzylite in
vcmi.

I agree that embedded copies are not nice but given the following:

 - vcmi upstream uses an outdated copy of fuzzylite and is hesitating to
   upgrade to 5.0 because of api changes
 - fuzzylite upstream does not version their SONAME so it would be hard to
   maintain it in Debian
 - the fuzzylite version in vcmi contains their own set of patches which are
   unknown because when fuzzylite was imported into their version control
   system, their custom patches were already applied.
 - nobody else in Debian uses fuzzylite

would letting vcmi include the embedded fuzzylite copy be an acceptable option
given the other tradeoffs?

cheers, josch


--
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/20140902100247.3685.43580@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

Quoting Eriberto (2014-09-02 13:52:11)
 vcmi (GPL-2+) with fuzzylite (Apache 2.0) can't be distributed from upstream.
 It is the problem. IMHO, you can't make a -dfsg version because the source
 code is 'improper', can't be distributed.

These two emails suggest otherwise:

http://lists.debian.org/54038d81.4050...@bitmessage.ch
http://lists.debian.org/54039338.7090...@debian.org

It can only not be distributed as (gpl2 and apache2) but since vcmi is gpl2+ it
can be distributed as (gpl3+ and apache2).

The vcmi authors let us freely choose which version of the gpl we want to
comply with by saying gpl2+. Since we cannot possible comply with gpl2 since it
conflicts with apache2, we choose to comply with gpl3 instead.

 But, if the upstream distribute the source code without fuzzylite 4, then you
 can package vcmi and fuzzylite 4 (you need use fuzzylite4 as name to avoid an
 upgrade to 5). This is my idea.

The fuzzylite version used by vcmi predates fuzzylite version in its git
repository. Therefore, the fuzzylite version used by vcmi must be earlier than
fuzzylite 1.5.

I looked into how hard it is to port vcmi to fuzzylite 5.0 and it seems to be
quite an undertaking because fuzzylite did a number of major refactorings
between 1.5 and 5.0.

Packaging the fuzzylite version prior to 1.5 which vcmi uses seems the wrong
thing to do in my eyes because nobody else will use this outdated version.

 What is your oppinion, Pabs?
 
 Thank you for your willingness to make the package and contribute to Debian.

Thanks for mentoring me :)

cheers, josch


--
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/20140902120607.3685.91403@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

iyou dropped the ITP bug as a recipient - was that intended?

In case it was I only quoted the small part below. I hope that's okay?

Quoting Eriberto (2014-08-25 16:01:36)
 2014-08-24 17:22 GMT-03:00 Johannes Schauer j.scha...@email.de:
  But vcmi itself is GPL-2+ and both resources agreed that Apache2 is 
  compatible
  with GPL3. So could vcmi in Debian thus not be shipped as GPL3+ instead of
  GPL2+?
 
 I think that no. You can ask about this issue in mentors. However, I
 think that this code is, currently, undistributable. I already had a
 similar case and the upstream wrote a new code to drop an reused GPLed
 code. The software is Yara.
 
  I submitted the problem to the upstream bugtracker.
 
  http://bugs.vcmi.eu/view.php?id=1884
 
 
 Ok. I hope you get a solution.

the upstream of fuzzylite relicensed from apache 2.0 to LGPL 3.0 with the
release of fuzzylite 5.0 (but not the versions prior to that).  So if upstream
should upgrade their copy of the embedded fuzzylite, then the license problem
should go away.

cheers, josch


--
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/20140829135205.3685.59631@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

Quoting Paul Wise (2014-08-29 17:02:35)
 On Fri, Aug 29, 2014 at 6:52 AM, Johannes Schauer wrote:
  the upstream of fuzzylite relicensed from apache 2.0 to LGPL 3.0 with the
  release of fuzzylite 5.0 (but not the versions prior to that).  So if
  upstream should upgrade their copy of the embedded fuzzylite, then the
  license problem should go away.
 
 Please ask vmci upstream to remove the embedded copy of fuzzylite and
 depend on the system version.
 
 https://wiki.debian.org/EmbeddedCodeCopies

Would this solve the license incompatibility between fuzzylite (apache 2.0) and
vcmi (gpl2+)?

I asked upstream whether they can remove the embedded copy and depend on the
system version instead: http://bugs.vcmi.eu/view.php?id=1886

Currently, fuzzylite is not in Debian nor does any other software in Debian
carry an embedded copy of it (at least according to codesearch.d.n). This is
why I did not consider packaging fuzzylite separately yet.

But if it would solve the licensing problem, then I will certainly see if I can
get fuzzylite packaged.

A problem might be that vcmi as the only user of that library uses the old 4.0
version while upstream just released 5.0. Vcmi upstream expressed that
migration to fuzzylite 5.0 would be very troublesome here:
http://bugs.vcmi.eu/view.php?id=1884#c4932

Would it be okay to package fuzzylite 4.0 even though upstream is at 5.0?

cheers, josch


--
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/20140829151623.3685.12351@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

Quoting Paul Wise (2014-08-29 17:47:10)
 On Fri, Aug 29, 2014 at 8:16 AM, Johannes Schauer wrote:
  Would this solve the license incompatibility between fuzzylite (apache 2.0)
  and vcmi (gpl2+)?
 
 Yes because the latest version (5.0) of fuzzylite (LGPLv3) is
 compatible with vmci (GPLv2+).

I'm confused. I asked whether removing fuzzylite from vcmi and making it a
shared library instead would solve the license incompatibility. I am aware that
using fuzzylite 5.0 will solve the issue but not using the embedded copy is a
different issue than upgrading the code to be compatible with version 5.0.

So the answer is: No, but switching to 5.0 will?

  I asked upstream whether they can remove the embedded copy and depend on
  the system version instead: http://bugs.vcmi.eu/view.php?id=1886
 ...
  A problem might be that vcmi as the only user of that library uses the old 
  4.0
  version while upstream just released 5.0. Vcmi upstream expressed that
  migration to fuzzylite 5.0 would be very troublesome here:
  http://bugs.vcmi.eu/view.php?id=1884#c4932
 
  Would it be okay to package fuzzylite 4.0 even though upstream is at 5.0?
 
 Since it is not GPLv2+ compatible, that wouldn't solve the problem.

Okay. Thank you for clarifying this.

 Perhaps fuzzylite upstream would be willing to apply the license change to
 4.0 too?

I sent off an email to ask about that.

 The code copy should be removed in any case, if that proves impossible
 (perhaps it is patched), please contact the security team to report the
 issue.

It turns out that their embedded code copy is patched but I am in the process
of clarifying with upstream which parts they patched. Maybe no patching is
necessary anymore with fuzzylite 5.0 or maybe upstream can integrate their
patches into the 4.0 branch.

Thanks!

cheers, josch


--
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/20140829155203.3685.39246@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

Quoting Dariusz Dwornikowski (2014-08-23 11:04:09)
 Thanks for your work, but I think that your package should go to contrib,
 because in order to work it needs HoMM game, so it depends on something non
 free [1]. 
 
 Installation instruction from upstream's web page clearly state that
 you need to install Heroes data files [2]
 
 I also found info on this game on Debian Games suggested games
 website [3] stating the above. 
 
 I am CCing the Debian Games list too.

you are right, vcmi is a classical case for a game in contrib as its assets
(graphics, music, sounds, text) are non-free. That debian/control said it was
for main is an artifact from when I started packaging it. I developed a tool
with which I made it possible to play the game with colorful rectangle graphics
instead of the original sprites. Here is the email thread about this:

http://lists.debian.org/20140317153554.1302.95390@hoothoot

While this makes the game playable, upstream disliked that their engine could
be abused in such a way so I stopped doing this. Thus I changed the Section to
contrib/games now. Thanks for noticing this!

cheers, josch


--
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/20140824185700.3685.51565@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi Eriberto,

Quoting Eriberto (2014-08-24 07:09:20)
  Thank you for elaborating on this and sorry for my dismissive last message.
 Ok. I just want help you. If you let me do it I will be grateful.

your help is very much appreciated! My packaging can only get better with your
help :)

  At the time of writing I had just finished writing man pages for 43
  applications and at that point I couldn't see man pages anymore XD
 I understand you. A very hard work. Do you know txt2man?

I used pod2man.

 Yes. You can suggest to upstream to provide a GPG signature.

I did: http://bugs.vcmi.eu/view.php?id=1883

  Checking with blhc showed that the flags -fstack-protector and
  --param=ssp-buffer-size=4 are not passed. But instead
  -fstack-protector-strong is used. So things showd be fine, no?
 Not ideal but appears acceptable.

Jakub Wilk suggested that my blhc version was outdated and indeed after
upgrading from the version in testing to the version from unstable, there are
no warnings at all with blhc --all

 I found a problem in d/changelog. For the first upload, the priority must be
 'low'.

You probably mean urgency instead of priority?

I cannot find anything in the devref or policy that states this:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Urgency
https://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog

Not that I don't trust you about it but if it is like that then there could
be:

 - a devscripts bug against dch that `dch --new` defaults to urgency=low
   (currently the default is urgency=medium which is how the value got there)
 - a lintian warning if the first entry in debian/changelog is not urgency=low

I changed the urgency to low in debian/changelog.

  2. d/copyright: I suggest put the range of years to 'Files: *'. Can be a
 unique range for all authors (2007-2014).
 
  I figured out that the range 2002-2014 seems to be correct.
 
 I didn't found 2002 in the upstream code. Can you point me this
 information? You said about 2014 but wrote 2012 in d/copyright...

That's odd... I was sure I read 2002 somewhere but I cannot find it. The
upstream vcs has 2007 as the first commit date so I'll use that.

 I suggest you to use this format (clean):
 
 Files: *
 Copyright:
  2007-2014 Andrea Palmate and...@amigasoft.net
Benjamin Gentner
Frank Zago fr...@zago.net
Ivan Savenko saven.i...@gmail.com
Lukasz Wychrystenko t...@czlug.icis.pcz.pl
Mateusz B. matc...@gmail.com
Michał Urbańczyk imp...@gmail.com
Rafal R. ambt...@wp.pl
Rickard Westerlund onionkn...@gmail.com
Stefan Pavlov mail...@gmail.com
Tom Zielinski warmon...@vp.pl
Trevor Standley
Vadim Glazunov newea...@gmail.com
Xiaomin Ding dingding...@gmail.com
Yifeng Sun pkusunyif...@gmail.com
 License: GPL-2+

Okay, done.

  I think that there are files with copyright not listed at d/copyright. I
  found lib/minizip/mztools.h.  You can use 'grep -sri copyright *' to see
  all files.
 
 You put ' 2010 Juan Rada-Vilela' in last block. However, all files in
 AI/FuzzyLite/ is under Apache 2.

Correct. I created a new block for Juan Rada-Vilela and added Apache2.

 It is a problem. See http://www.gnu.org/licenses/license-list.en.html#apache2
 and http://www.apache.org/licenses/GPL-compatibility.html. So, in current
 stage, I think that the source code is undistributable.

But vcmi itself is GPL-2+ and both resources agreed that Apache2 is compatible
with GPL3. So could vcmi in Debian thus not be shipped as GPL3+ instead of
GPL2+?

I submitted the problem to the upstream bugtracker.

http://bugs.vcmi.eu/view.php?id=1884

  Upstream does not care about others using the shared library and will break
  ABI and API with every release. The shared library is not intended to have
  any users besides vcmi itself. There is a warning about this:
 
  dpkg-shlibdeps: warning: can't extract name and version from library name 
  'libvcmi.so'
 
  hat's why I put it in the vcmi subdirectory in /usr/share/triplet. Should 
  the
  library be put somewhere different in this case?
 
 
 I think that it is another problem. I don't know a case of shared libraries
 put outside */lib or packaged with a non lib code.

Well, as by FHS, /usr/lib seems to be the only place they could go, right? So I
cannot imagine where else they should be put.

 You also must consider the comment made by Dariusz.

I responded to that email separately, though strangely, vcmi still shows as
Section: games on mentors. That's probably a bug in the mentors.d.n web
interface?

I uploaded a new version of the vcmi package with the fixes from above.

Thanks!

cheers, josch


--
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/20140824202217.3685.23489@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi Eriberto,

Quoting Eriberto Mota (2014-08-19 14:29:34)
 Hi Johannes. Thanks for your reply.

sorry for my late reply but I was at the Debian Bootstrap sprint in Paris over
the weekend and am moving to Sweden tomorrow, so I'm a bit tight on free time
right now :)

 I understand your POV. However, from Debian Policy[1]:
 
 Each program, utility, and function should have an associated manual
 page included in the same package. It is suggested that all
 configuration files also have a manual page included as well. Manual
 pages for protocols and other auxiliary things are optional.
 
 If no manual page is available, this is considered as a bug and should
 be reported to the Debian Bug Tracking System (the maintainer of the
 package is allowed to write this bug report themselves, if they so
 desire). Do not close the bug report until a proper man page is
 available.
 
 I have some very long manpages and short manpages too. When an user
 see a command but he don't know what is this, he always tries '$man
 command' to get an explanation.
 
 [1] https://www.debian.org/doc/debian-policy/ch-docs.html

Thank you for elaborating on this and sorry for my dismissive last message. At
the time of writing I had just finished writing man pages for 43 applications
and at that point I couldn't see man pages anymore XD

I added a man page to vcmiserver by patching the program to do the commandline
parsing before other initialization which would fail if vcmi is not yet
installed. Then I use help2man to generate the man page like for the other
applications.

For vcmilauncher I wrote a custom man page in `debian/vcmilauncher.1`.

  There is 'hardening-no-fortify-functions' which is a false positive.
 
 Ok, the same case of the GPG signature.

I actually think they are different cases.

Checking for the GPG signature would be a pedantic warning that I would like to
receive every time I package a new upstream version because it reminds me to
check whether upstream still does not provide GPG signatures. If I override the
warning, then I will forget doing this.

Checking with blhc showed that the flags -fstack-protector and
--param=ssp-buffer-size=4 are not passed. But instead -fstack-protector-strong
is used. So things showd be fine, no?

  And there is 'spelling-error-in-binary' which is a false positive as well.
 
 It is a classical Lintian override case.

Right.

 In your package, please:
 
 1. I suggest you add a d/README.source explaining why it is DFSG and telling
which files have been removed. I saw it in d/copyright but I suggest a
detailed README too.

I added a d/README.source. Does it contain everything you think it needs to
contain?

 2. d/copyright: I suggest put the range of years to 'Files: *'. Can be a
unique range for all authors (2007-2014).

I figured out that the range 2002-2014 seems to be correct.

 I think that there are files with copyright not listed at d/copyright. I
 found lib/minizip/mztools.h.  You can use 'grep -sri copyright *' to see all
 files.

I added Xavier Roche as the author of lib/minizip/mztools.h and added further
sections for cmake_modules/cotire.cmake and cmake_modules/FindFFmpeg.cmake. I
hope I caught them all now.

 3. d/docs: the README.linux is useless because a Debian final user doesn't
compile codes. Please, remove it.

That's right. I removed it.

 4. A doubt: why you didn't make a separated package for shared libraries?

Upstream does not care about others using the shared library and will break ABI
and API with every release. The shared library is not intended to have any
users besides vcmi itself. There is a warning about this:

dpkg-shlibdeps: warning: can't extract name and version from library name 
'libvcmi.so'

hat's why I put it in the vcmi subdirectory in /usr/share/triplet. Should the
library be put somewhere different in this case?

 5. You need lintian overrides to 'I: vcmi: spelling-error-in-binary
usr/games/vcmilauncher tEH the' and to 'I: vcmi: spelling-error-in-binary
usr/lib/x86_64-linux-gnu/vcmi/libvcmi.so tEH the'.

I added those lintian overrides.

 6. Please, add a simple manpage to usr/games/vcmilauncher and
usr/games/vcmiserver.

Done.

 Thanks a lot for your work.

Thanks a lot for your feedback. It is very much appreciated!

I also refreshed the date in debian/changelog and uploaded the result to
mentors.

cheers, josch


--
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/20140822183019.3685.64083@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi Eriberto,

Quoting Eriberto (2014-08-18 16:55:20)
 I saw your package in mentors.debian.org and it has several Lintian messages.
 
 IMHO, to get a sponsor you must, at least, clear your package removing
 all possible messages.

which Lintian messages are you referring to?

There is one pedantic warning 'debian-watch-may-check-gpg-signature' which I
cannot fulfill because upstream does not use gpg.

There is 'binary-without-manpage' which I could fulfill but that would be a
very empty man page because the game does not have any commandline options.

There is 'hardening-no-fortify-functions' which is a false positive.

And there is 'spelling-error-in-binary' which is a false positive as well.

cheers, josch


--
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/20140818154752.14069.17190@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-08-04 23:03:54)
 * Johannes Schauer j.scha...@email.de, 2014-08-02, 09:33:
 I'm not familiar enough with the kind of disaster that may 
 happen when linking C++11 compiled code to C++98 libraries
 
 Crashes, I suppose.
 
 I also do not see any advised fix or how to prevent the situation.
 
 There's not much that can be done, other than:
 - porting pdf2htmlEX to C++98 (unlikely to be feasible);
 - not uploading the package yet;
 - keeping your fingers crossed that nothing bad will happen.

I would suggest going for the last option and handle problems once they appear
in practice.

 I uploaded the new version.
 
 There's a new typo:
 comparision - comparison

I created a new patch fix-spelling. But since this is the only correction we
have so far I guess we wait with forwarding it to upstream until there are more
changes than just a single letter?

 I also noticed that the software allows to set ENABLE_SVG=ON which enables
 generating SVG backgrounds and converting type-3 fonts. But this feature
 requires CairoFontEngine, CairoRescaleBox and CairoOutputDev from the
 poppler sources. Should I integrate the required files into the upstream
 tarball so that we can build with ENABLE_SVG=ON?
 
 Embedding a copy of (a part of) Poppler doesn't seem appealing to me. 
 :-(
 
 It would be ideal if Poppler provided the required headers files, and 
 perhaps moved Cairo*.o to a separate library (they are currently part of 
 libpoppler-glib). But I have a hunch Poppler maintainers won't like this 
 idea...

Just in case I filed wishlist bug #757055

 I also noticed that the required files are shipped by the emscripten binary
 package. But it'd be quite messy to depend on that binary package for the
 sources it ships for a different purpose.
 
 Yeah, let's not go that way.

Agreed. In case #757055 gets resolved we can revisit this feature.

I uploaded a new version that fixes the spelling mistake you found.

cheers, josch


--
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/20140804233454.19236.26640@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-08-01 22:31:46)
 * Johannes Schauer j.scha...@email.de, 2014-07-30, 07:24:
 I do not understand why it fails for you but not for me.
 How did you run the tests? I ran sadt(1) in the freshly-unpacked 
 source tree.
 
 I ran `adt-run -o /tmp/log --source pdf2htmlex_0.11+ds-1.dsc --- 
 schroot sid-amd64-sbuild`
 
 This is what the adt-run manpage says about the --source option:
 By default the package will also be built and the resulting binaries 
 will be used to satisfy test dependencies
 Presumably it also means that the built tree is used for running tests.
 
 (What I've been doing in my packages, as a defensive strategy against 
 accidentally testing against not-installed code, is to copy all the bits 
 necessary to run tests from the package directory to $ADTTMP, then chdir 
 to $ADTTMP, and run tests from there.)

I think the last bit makes most sense. I changed the test accordingly.

Notice that there is also a dedicated git repository for tests.

https://github.com/coolwanglu/pdf2htmlEX-tests

But I'd have to ask upstream about copyright first. Also, maybe they can
integrate that repository into their releases which would avoid having to make
the upstream tarball generation more complex.

 Have you seen this thread on d-devel@?
 https://lists.debian.org/53ccf007.6020...@debian.org
 Yes, but how is it relevant to this?
 
 I'm a bit worried, because pdf2htmlex is built in C++11 mode, but it 
 links to libraries built in C++98 mode. If I understand correctly, this 
 is potentially a recipe for disaster.

Maybe. I'm not familiar enough with the kind of disaster that may happen when
linking C++11 compiled code to C++98 libraries and the thread does not expand
much on that. I also do not see any advised fix or how to prevent the
situation. What the thread is about is to ensure that the source is compiled
with a C++11 capable compiler. I never tested building with an older compiler.

 Now, it's probably not something that would stop me from uploading the
 package. Just wanted to make sure that you are aware of this problem.

I did not realize you were offering to sponsor the package but I'm very happy
about it :)

Upstream did a new release a few days ago. It turned out that it allows to drop
nine patches because they integrated them. On the other hand I had to add
another patch to be able to build with an older version of libfontforge. I
uploaded the new version.

I also noticed that the software allows to set ENABLE_SVG=ON which enables
generating SVG backgrounds and converting type-3 fonts. But this feature
requires CairoFontEngine, CairoRescaleBox and CairoOutputDev from the poppler
sources. Should I integrate the required files into the upstream tarball so
that we can build with ENABLE_SVG=ON?

I also noticed that the required files are shipped by the emscripten binary
package. But it'd be quite messy to depend on that binary package for the
sources it ships for a different purpose.

cheers, josch


--
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/20140802073350.19236.95968@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-28 23:08:11)
 I do not understand why it fails for you but not for me.
 
 How did you run the tests? I ran sadt(1) in the freshly-unpacked source 
 tree.

I ran `adt-run -o /tmp/log --source pdf2htmlex_0.11+ds-1.dsc --- schroot 
sid-amd64-sbuild`

Both invocations work now.

 Nevertheless I fixed this by overriding the --data-dir path with an 
 environment variable as well.
 
 I still think it would be better not to pass --data-dir at all.
 
 Unlike build-time tests, as-installed tests have the capability of 
 verifying that all the required files are installed, and that they are 
 installed in a place where the software actually expects them. Let's not 
 ruin this advantage by instructing the software where WE expect the 
 files to be. :-)

Your reasoning makes lots of sense. I changed things accordingly.

 Could you set HOME to a non-existent directory in the test script, just 
 like you did in d/rules?

Done.

 Could you remove the “The information above should follow the Patch 
 Tagging Guidelines …” template from d/p/control-test-executable-name?

Woops... thanks for noticing!

I uploaded the new version to mentors.

 Have you seen this thread on d-devel@?
 https://lists.debian.org/53ccf007.6020...@debian.org

Yes, but how is it relevant to this?

cheers, josch


--
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/20140730052427.19236.90380@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-26 18:35:23)
 * Johannes Schauer j.scha...@email.de, 2014-07-26, 12:37:
 upstream responded and I updated their name with the one they told me.
 
 Perhaps also update patch headers?

Done.

 I used the (fairly incomplete) testsuite of pdf2htmlEX to run a DEP-8 
 test.
 
 The DEP-8 tests fail here. I see lots of errors like this:
 
 Error: Cannot open file /home/jwilk/pdf2htmlex-0.11+ds/share/base.min.css for 
 embedding
 Command return code 1: /usr/bin/pdf2htmlEX --data-dir 
 /home/jwilk/pdf2htmlex-0.11+ds/share --dest-dir /tmp/tmpTajvy6 
 /home/jwilk/pdf2htmlex-0.11+ds/test/test_data/2-pages.pdf
 
 I suppose you shouldn't pass --data-dir when testing the installed 
 version.

I do not understand why it fails for you but not for me. Nevertheless I fixed
this by overriding the --data-dir path with an environment variable as well.

 I don't think the patch description is grammatically correct. I believe that
 instead of “Allow to control …”, it should be “Allow us to control …” or
 “Allow controlling …”.

It seems that the word allow allows both, gerund and infinitive to follow it.
Either should be grammatically fine. I changed it nevertheless to Allow
controlling because I don't have a strong opinion on this.

cheers, josch


--
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/20140728051845.4150.53514@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-19 23:38:14)
 Your d/copyright says:
 
 Files: *
 Copyright: 2012 WANG Lu coolwan...@gmail.com
 
 Shouldn't it be s/WANG Lu/Lu Wang/? The latter seems to be the spelling 
 used in the code.

upstream responded and I updated their name with the one they told me.

 More importantly, some files have newer copyright dates. For example, 
 src/pdf2htmlEX.cc reads:
 
 // Copyright (C) 2012-2014 Lu Wang coolwan...@gmail.com

right, I bumped the dates to 2014

 Please bump date in d/changelog. :-)

and bumped that one too.

 From the wishlist department:
 You might want to implement DEP-8 tests.

I used the (fairly incomplete) testsuite of pdf2htmlEX to run a DEP-8 test.

cheers, josch


--
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/20140726103720.4150.71655@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-17 13:36:47)
 export HOME=`mktemp --dry-run`
 
 This sets HOME literally to `mktemp --dry-run`. I think you wanted to 
 say:
 
 export HOME=$(shell mktemp --dry-run)

oh shoot it's not shell, it's make... while that method will surely also yield
a nonexistant home directory I see why that method is inferior ^^

 But there's a good reason --dry-run is described as “unsafe” in the mktemp
 manpage.

What is the reason? I thought the reason for it being called unsafe was that
if you use --dry-run first and then create the directory with that name
yourself then somebody else could hijack that location in the meantime. But
this is no problem for this use case.

 So how about something like this instead:
 
 export HOME=$(CURDIR)/nonexistent

This is a good solution. As we have control about the directories in $(CURDIR)
we can guarantee that no directory named like that exists during build time.
I'll use it.

cheers, josch


--
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/2014071810.31130.24913@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-16 21:21:15)
 Now --download-current-version is broken:
 
 $ uscan --download-current-version --destdir .
 uscan warning: In debian/watch no matching hrefs for version 0.11 in watch 
 line
   https://github.com/coolwanglu/pdf2htmlEX/releases .*/v(\d[\d\.]*)\.tar\.gz
 It think you need to drop dversionmangle to fix it.

you are right! Though it is quite strange that `uscan --destdir .
--force-download` works and `uscan --download-current-version --destdir .` does
not.

On the other hand I now better understand how version mangling works. I indeed
needed to remove dversionmangle. This kept working because uversionmangle will
also mangle the links from the upstream site. So now instead of adapting the
Debian version to be the upstream version (by removing +ds) the upstream
version is adapted to the Debian version (by adding +ds).

What do we do about debian-watch-file-should-dversionmangle-not-uversionmangle
until #753772 is fixed? Ignore it or create an override?

 If that is all, then all then I only need somebody to sponsor this :)
 
 Do you mean _me_? It's been less than a weak, I haven't even warmed up 
 yet. ;-P

good to hear - that means many more suggestions will be coming my way :)

 I noticed that when you run pdf2htmlEX for the first time, ~/.FontForge/ gets
 created. This is not itself a problem (even though personally I hate dotfiles
 with passion). The problem is that it will also happen at build time, thanks
 to the test suite. Creating dotfiles at build time is a no-no. I guess the
 simplest way to fix it is to set HOME to something non-existent in
 debian/rules.

Is creating files outside the build directory and not in $TMPDIR a policy
violation?

I already gather statistics of file system access using the machinery to find
unused build dependencies (the thing I wrote about on d-devel). But the
gathered data could easily be used to find this kind of things as well. Would
that make sense?

I would have to adapt the call to sbuild though because by default, sbuild sets
$HOME to /sbuild-nonexistent and thus, no dotfiles are created.

Anyways, I set $HOME to a nonexistant directory in debian/rules.

 I think it would be good to add a comment to d/copyright explaining that
 upstream clarified the license; or maybe cherry pick the commit:
 https://github.com/coolwanglu/pdf2htmlEX/commit/6e8d5396cdad Currently it
 might be not obvious to a person who didn't read this RFS thread (such as
 ftp-master) that your copyright matches upstream intentions.

Correct. I cherry picked the relevant parts of the upstream commit.

 I see you have lots of patches. Which of them are upstreamable? Which of them
 have been already forwarded? You can answer the questions by adding
 appropriate Forwarded: headers to the patches. :-)

All done. :)

cheers, josch


--
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/20140717063133.31130.61773@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-17 09:46:58)
 * Johannes Schauer j.scha...@email.de, 2014-07-17, 08:31:
 What do we do about 
 debian-watch-file-should-dversionmangle-not-uversionmangle until 
 #753772 is fixed? Ignore it or create an override?
 
 Either way works for me.

okay then I'll leave things as they are because #753772 seems uncontroversial
enough such than one can assume that
debian-watch-file-should-dversionmangle-not-uversionmangle should go away in
the near future.

 Is creating files outside the build directory and not in $TMPDIR a policy
 violation?
 
 Policy doesn't say anything about it explicitly. It could be argued, 
 that if the package create such files, then there's no sane way to 
 implement policy-compliant clean target. The clean target “must undo any 
 effects that the ‘build’ and ‘binary’ targets may have had, except that 
 it should leave alone any output files created in the parent directory 
 by a run of a ‘binary’ target”.

Good argument.

 All done. :)
 
 Hmm, I don't see the new package on mentors.d.n. Did you upload it?

whoops... I indeed forgot. It is uploaded now and should appear online any
minute.

cheers, josch


--
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/20140717075311.31130.14851@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-16 00:26:09)
 uscan does this automatically when repacking upstream tarballs.
 
 I don't believe this is the case. And the .orig.tar you uploaded to 
 mentors certainly contains debian/:

indeed, you are right! I fixed it and the upstream tarball now comes without
the ./debian directory.

 I don't want to uselessly increase the amount of dependencies of the
 resulting binary package (even though libpython is probably present on most
 systems).
 
 It wouldn't increase the amount of packages required to run pdf2htmlex, 
 at least not for the time being, because libfontforge depends on 
 libpython.

Right.

 The reason linking to unneeded libraries is bad is because it makes Packages
 a tiny bit bigger, makes dependency resolved a tiny bit slower, and becomes
 burdensome when one of the libraries change SONAME.

Thanks for educating me :) I didnt think of especially the SONAME change.

 Though on the other hand it seems I managed to patch the build system such
 that it will not use libpython anymore (see patch no-libpython).
 
 That's much better. Now, can you do the same with gunicode? :-)

It turns out that doing so was just as simple! :D

 What is your opinion about the tarball repacking and the Files-Excluded in
 debian/copyright?
 
 I don't like it, but I'm not going to stop anybody from using it.

Then I think I will keep using it. I do see that using debian/copyright is the
wrong place for repacking information but I find it easier to list the excluded
files in a declarative way instead of embedding yet another fragile repack
script. I do not think there is another way to state the excluded files from
the original upstream tarball without using a turing complete language than
using Files-Excluded.

Once there is, I'll immediately switch to it.

 Note that currently uscan would generate .orig.tar with wrong version; 
 see bug #753772.

I can confirm that I was missing a uversionmangle in my debian/watch. This is
fixed now.

Thanks a lot for your help!

If that is all, then all then I only need somebody to sponsor this :)

cheers, josch


--
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/20140716063637.31130.98246@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi again,

Quoting Jakub Wilk (2014-07-13 20:24:00)
 Who is the copyright holder for the files in debian/? According to the
 copyright file it's WANG Lu. :-P
 Indeed it was. If you look at the upstream repository you'll see a 
 Debian directory
 
 Oops, I missed it.
 (Wouldn't it make sense to remove it from .orig.tar?)

uscan does this automatically when repacking upstream tarballs.

 I don't think there's anything left from the original packaging. You can put
 only your name with clear conscience. :-)

well, now you helped me so much I could start putting your name in ;)

 I could clarify with upstream.
 
 Please do. :-)

I did ask upstream at https://github.com/coolwanglu/pdf2htmlEX/issues/387

 Removing useless linking against libpython2.7.so.1.0 was easily fixed by not
 build depending on python-dev.
 
 Hmm, that doesn't sound right. It means that a user building in a 
 non-minimal environment can get a package with or without 
 libpython2.7-dev in Depends, depending on which packages they had 
 installed. I think I prefer to live with the dpkg-shlibdeps warnings, 
 than to have this sort of non-determinism.

Right. So how about a Build-Conflict with the appropriate binary package? I
don't want to uselessly increase the amount of dependencies of the resulting
binary package (even though libpython is probably present on most systems).

Though on the other hand it seems I managed to patch the build system such that
it will not use libpython anymore (see patch no-libpython).

What is your opinion about the tarball repacking and the Files-Excluded in
debian/copyright? I'm not even a DD so if you tell me that the current way I do
it is wrong than of course I'll change it and use a repack script instead :)

cheers, josch


--
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/20140713202337.31130.43100@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-11 23:48:15)
 * Johannes Schauer j.scha...@email.de, 2014-07-11, 21:33:
 How did you find them? I ran codespell but that didnt find the ones you 
 found.
 
 I read carefully the source code. :-) (I admit that vim's spell checking 
 helped me a bit.)

I just discovered that my Vim spell checking was broken. I fixed it and thus
was able to fix some more misspellings. Thank you for your manual effort of
compiling the list in your last email! :)

 I'm unsure how I should handle the minified js. Surely it is desirable to
 include the minified js in the output pdf2htmlex generates
 
 Probably, but is it worth the trouble? The non-minified version is only 
 8 kilobytes bigger. That's negligible overhead, IMHO.

Maybe. But if 100 people convert 10 files each that's already 8M saved. I'll
see how much effort it takes to let it use the minified version and will give
up if it's too much trouble.

 but that means that pdf2htmlex has to ship a minified version of
 compatibility.js from the libjs-pdf package.
 
 Hmm, there is no protection against the two versions getting of sync. 
 Which means that there is no guarantee that we are shipping source for 
 the minified version. :(

But setting Built-Using: pdf.js would guard against that, would it not? The
only disadvantage then would be that a rebuild of pdf2htmlex would be needed
every time pdf.js releases a new version.

 Should the minified version not be shipped by libjs-pdf instead? What is the
 right way to do this?
 
 I see a few ways to go forward:
 
 1) Stop worrying and love the bomb^Wunminified JS.
 
 2) Ask pdf.js maintainers to provide compatibility.min.js, and wait 
 patiently until they implement it (or not).
 
 3) Keep minifying compatibility.js yourself, but use Built-Using to 
 ensure we always have the source.

I filed a wishlist bug against pdf.js (#754533) and at the same time introduced
a Built-Using: pdf.js. Should pdf.js decide to ship a minified version in the
future I can remove the Built-Using.

 I wouldn't say “In contrast to other converters …” in the package
 description. It sounds a bit like an advertisement. And it means that changes
 in other packages could make your package description inadequate.

I find the latter part a strong argument and rephrased the description.

 Priority should be probably optional.

Done.

 Section should be text or maybe graphics; probably not misc.

I chose text because I guess most people use pdf for that or associate pdf with
that rather than a graphics format.

 In debian/rules you have this:
 
 ( cd logo; ./update_png.sh; )
 
 You don't need parentheses here. You should use  between the 
 statements (see Policy §4.6).

Thanks. I updated myself on the relevant policy section and the inner workings
of make. Indeed the changed directory only affects the subshell and thus does
the right thing even without parenthesis. Semicolon is replaced with  as
well.

 dh_clean deletes all files listed in debian/clean. If you took advantage of
 this, you wouldn't need to override dh_auto_clean.

This is indeed a much nicer method than overriding dh_auto_clean. Fixed.

 The watch file doesn't work here:
 
 $ uscan --destdir . --force-download
 pdf2htmlex: Version (0.11) available on remote site:
   https://github.com/coolwanglu/pdf2htmlEX/archive/v0.11.tar.gz
   (local version is 0.11+ds, mangled local version number 0.11)
 Could not read .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz: No 
 such file or directory at /usr/bin/mk-origtargz line 310.
 uscan: error: mk-origtargz --package pdf2htmlex --version 0.11 --compression 
 gzip --directory . --copyright-file debian/copyright 
 .//coolwanglu/pdf2htmlEX/archive/pdf2htmlEX-0.11.tar.gz gave error exit 
 status 2

Somehow it didnt come to my mind to use --force-download to test whether my
watch file was able to download an archive in addition to picking the right
version. Thanks!

The problem was created because the uscan manpage explicitly recommends to use
a filenamemangle for github projects. Apparently this does the wrong thing as
it also affects the filename used in the download url.

cheers, josch


--
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/20140712074050.31130.75120@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-07-12 11:50:39)
 It would guard against the possibility of losing source.
 
 But it could still happen that compatibility.js and compatibility.min.js 
 versions (in /usr/share/pdf2htmlEX/) don't match.

okay. Indeed that's undesirable.

 Is the non-minified version used by pdf2htmlEX at runtime at all? I think it
 isn't, but I could be wrong. If it's not, then maybe get rid of the symlink,
 and drop libjs-pdf from Depends?

Yes it is. You can check that it is used by running the test suite like this:
`( cd obj-*-linux-gnu; ctest -V; )`. You will see that it aborts because it
cannot find compatibility.min.js in ./share. You have to run the test suite
like that because it wrongly shows success even though the tests fail. I'll
have to fix that and report it upstream.

The file share/manifest or /usr/share/pdf2htmlEX/manifest controls what gets
included into the final pdf. It is the @compatibility.min.js line in that
file which makes compatibility.min.js be included by the function
HTMLRenderer::embed_file in src/HTMLRenderer/general.cc.

compatibility.js is optional though. It is only useful for compatibility with
older browsers. This even if not the minified version, I'd like to include
compatibility.js in the output.

 I don't think it worked:
 dpkg-genchanges: warning: unknown information field 'Built-Using' in input 
 data in general section of control info file
 
 Built-Using should be used in the binary stanza, not in the source 
 stanza. Please see Policy §7.8.

whoops. Sorry.

I removed the Built-Using because while it retains the original source, it will
not fix the version skew :/

I guess I use the unminified version of compatibility.js until bug#754533 is
resolved.

 Not quite. AIUI, the problem is that uscan expects that filenamemangle will
 strip directory components from the filename. The uscan manpage suggests
 using
 
 filenamemangle=s/(?:.*)?v?(\d[\d\.]*)\.tar\.gz/project-$1.tar.gz/
 
 which strip them (note .*), but your filenamemangle wouldn't.

oooh - indeed that makes more sense now.

Thanks a ton for all your very constructive and helpful advice :)

cheers, josch


--
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/20140712110636.31130.85076@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

wow, amazing that you are still investing your time in improving my packaging -
thanks a lot! :D

Quoting Jakub Wilk (2014-07-12 18:24:26)
 I don't doubt that compatibility.min.js is needed. What I questioned is
 whether we ever need compatibility.js in the binary package.

Indeed. I missed the non- of non-minified in your message. The non-minified
version was indeed not used and in fact some other non-minified file there are
not used either so I just deleted them since it's fine to only ship the
minified versions in the binary package as long as the source package has the
real versions, right?

 Who is the copyright holder for the files in debian/? According to the
 copyright file it's WANG Lu. :-P

Indeed it was. If you look at the upstream repository you'll see a Debian
directory there which I used as a start for my packaging. Now I nearly changed
everything. So I'm not sure anymore what would be appropriate as the copyright
of the packaging itself. Probably putting both our names would be most fitting?
I guess I just didnt pay attention to that because I put little importance on
having my name as the copyright holder as long as the license is free enough
for me to make all modifications I want to it.

 The machine-readable debian/copyright file specification advices against
 using “MIT” as the short license name.

I'm currently reading
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ and you
probably mean the part where it says There are many versions of the MIT
license. Please use Expat instead, when it matches.? On the other hand it uses
MIT as the short name in the section Example 4. Complex.

On the other hand, the license seems to also exactly fit the wording of the
Expat license so I did s/MIT/Expat/ for clarity.

 Short license name for GPL version 3 or a later version is “GPL-3+”, not
 “GPL-3”.

I do not think the package is GPL-3+. Have a look at README.md where it says
the license is GPL-3 (without a or later). Or do you see it different
anywhere else? I could clarify with upstream.

 s/On On/On/

Yeah.. I'd like to have some standardized copy-pastable debian/copyright
paragraphs for the standard licenses in /usr/share/common-licenses so that this
kind of stuff does not happen :/

 IMO information about which files where excluded .orig.tar doesn't belong in
 d/copright, especially when they weren't excluded for license reasons.

Why not? debian/copyright lists the copyright of all files in the upstream
source. Since I removed some files from it I list those in debian/copyright,
saying that I will not state copyright information about those files as they
have been removed.

Indeed the files I removed were DFSG free. I only removed them to not have
redundant copies of files that are otherwise in Debian. This in turn made it
easier to write debian/copyright.

If not listing them in Files-Excluded, should I instead write a repack script
which is called by uscan?

 Speaking of which, how exactly was the .orig.tar generated?

The first one manually (by removing the items listed in Files-Excluded) and
then by uscan. Since uscan understands Files-Excluded in debian/copyright it
did the repacking for me and I didnt have to write a repack script or a
get-orig-source target in debian/rules.

I thought this was the most elegant way to achieve this.

Which way is better?

 It would be nice if the TMPDIR environment variable was honoured.

Good catch! How did you find that? I fixed that and will forward the patch to
upstream.

There are still other accesses to /tmp without honoring TMPDIR but I cannot
find the piece of code that makes these. It's just calling stat on /tmp,
creating an empty file with random name and then deleting it without writing
into it. Maybe one of the other libraries does it?

 In the build log I see:
 
 dpkg-shlibdeps: warning: package could avoid a useless dependency if 
 debian/pdf2htmlex/usr/bin/pdf2htmlEX was not linked against libgunicode.so.3 
 (it uses none of the library's symbols)
 dpkg-shlibdeps: warning: package could avoid a useless dependency if 
 debian/pdf2htmlex/usr/bin/pdf2htmlEX was not linked against 
 libpython2.7.so.1.0 (it uses none of the library's symbols)
 
 It would be nice to get rid of these warnings.

Removing useless linking against libpython2.7.so.1.0 was easily fixed by not
build depending on python-dev.

I do not think that not linking against libgunicode.so.3 would avoid a useless
dependency because libgunicode.so.3 is shipped by the libfontforge1 package and
pdf2htmlEX links against libfontforge.so.1 and libgutils.so.1 which are both
from the libfontforge1 package.

 What is default-jre-headless in Build-Depends for?

that was to execute the java jar files that the source package shipped in the
3rd party directory (like yui-compressor). This is not needed anymore as the
dependency on yui-compressor draws that in anyways.  Fixed.

cheers, josch


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a 

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package pdf2htmlex

 * Package name: pdf2htmlex
   Version : 0.11+ds-1
   Upstream Author : WANG Lu coolwan...@gmail.com
 * URL : http://github.com/coolwanglu/pdf2htmlEX
 * License : GPL3, MIT, CC-BY-3.0
   Section : misc

It builds those binary packages:

  pdf2htmlex - Converts PDF to HTML while retaining most formatting

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

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

This is the most advanced PDF to HTML converter that I have seen so far.
I was looking for a way to publish the scientific papers I wrote over
the years and I wanted to offer a way such that one could view them
without having to use a PDF viewer. Unfortunately it seems that the
existing options for converting PDF to HTML are missing many features
which make them unusable for complex PDF as those produced by latex for
scientific conferences and journals (multi column, complicated figures).

While not 100% pixel perfect, pdf2htmlEX produces HTML pages that are
absolutely readable for all the content I tried. Using the fallback mode
it is even possible to view them with javascript disabled.

cheers, josch


-- 
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/2014074759.23101.66334.reportbug@hoothoot

Bug#754463: RFS: pdf2htmlex/0.11+ds-1

[Johannes Schauer]

Hi,

wow, thanks a lot for looking into this! :D

Quoting Jakub Wilk (2014-07-11 20:59:44)
 fix-spelling seems to be mainly about fixing the use - as minus sign in
 manpage... Could split the patch into two, one for hyphens, another for
 actual spelling mistakes?

okay. Done.

 More typos I found:
 
 contributers - contributors
 actualy - actually
 positionig - positioning
 cosider - consider
 tempory - temporary
 deconstructign - deconstructing
 matices - matrices
 new_line_stauts - new_line_status
 Someting - something
 natrual - natural
 negaive - negative
 othere - other
 optimzation - optimization
 cannnot - cannot
 Inactiviy - Inactivity
 calulating - calculating
 lanauges - languages
 costy - costly

How did you find them? I ran codespell but that didnt find the ones you found.

The ones you found are now fixed in the packaging.

 What is ./debian/pdf2htmlex.README for?

That should've been pdf2htmlex.docs. Fixed.

 Is debian/dirs really needed? It should be normally job for upstream build
 system to create the directories it needs.

It is not needed. Removed, thanks!

 adequate says:
 pdf2htmlex: broken-symlink /usr/share/pdf2htmlEX/compatibility.js - 
 ../javascript/pdf/compatibility.js

I fixed that too. The dependency on libjs-pdf was missing.

I'm unsure how I should handle the minified js. Surely it is desirable to
include the minified js in the output pdf2htmlex generates but that means that
pdf2htmlex has to ship a minified version of compatibility.js from the
libjs-pdf package. Should the minified version not be shipped by libjs-pdf
instead? What is the right way to do this?

Thanks!

cheers, josch


--
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/20140711193353.31130.51357@hoothoot

Re: Build-Deps

[Johannes Schauer]

Hi,

Quoting Daniel Lintott (2014-06-01 00:00:03)
 I've had a look at dose-builddebcheck, but this doesn't seem to have an
 option for running on a single package.

dose-builddebcheck is what you are looking for and it can check a single
package by using the --checkonly option.

cheers, josch


--
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/20140531220249.12998.23827@hoothoot

Re: Build-Deps

[Johannes Schauer]

Hi,

Quoting Daniel Lintott (2014-06-01 00:15:09)
 Okay... In fairness I haven't tried that as yet... But the option doesn't
 appear to mentioned in the manpage [0].
 
 [0] 
 http://manpages.debian.org/cgi-bin/man.cgi?query=dose-builddebcheckapropos=0sektion=0manpath=Debian+7.0+wheezyformat=htmllocale=en

correct. Feel free to file a bugreport.

Try to call dose-builddebcheck with --help for a full list of available
options.

The --checkonly argument takes a comma separated list of cudf package names in
case you want to check more than one package at once.

cheers, josch


--
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/20140531221840.12998.57264@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi Jakub,

Quoting Jakub Wilk (2014-03-23 20:11:17)
 I don't think that the “After installing this package, …” instructions belong
 in the package description. I'd rather put them in README.Debian.

Personally I didnt find myself reading README.Debian after package installation
very often. I read the package description much more regularly. Though I could
put a hint into the description that directs the user to README.Debian for
further instructions.

 But if you decide to keep them, the enumerated list should be indented by two
 spaces (see Policy §5.6.13).

A very useful read! Thanks, I wasnt aware of the description format other than
lines with a full stop.

I also investigated your other remarks and submitted solutions to them
upstream. Some of them are already fixed. Your comments also made me remember
https://wiki.debian.org/HowToPackageForDebian as a very helpful first stop.

 I wouldn't repack the .orig.tar just to remove debian/. If you're using
 the 3.0 (quilt) format, dpkg-source removes upstream debian/ for you at
 unpack time.

Ah, I didnt know that either, thanks! It seems that repacking the original
tarball is necessary nevertheless though because there is an osx directory
which contains some mac binaries. Upstream doesnt do the osx packaging and the
person who does didnt respond yet.

Thanks for your help!

cheers, josch


--
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/20140324063049.1302.68234@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Package: sponsorship-requests
Severity: wishlist

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package vcmi

 Package name: vcmi
 Version : 0.95-1
 Upstream Author : Micha³ Urbañczyk imp...@gmail.com and others
 URL : http://forum.vcmi.eu/portal.php
 License : GPL2+
 Section : games

It builds those binary packages:

  vcmi  - Rewrite of the Heroes of Might and Magic 3 game engine
cmi-dbg   - Debug symbols for vcmi package

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

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

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

  dget -x http://mentors.debian.net/debian/pool/main/v/vcmi/vcmi_0.95-1.dsc

VCMI is a free implementation of the Heroes of Might and Magic 3 game
engine as well as a platform for mods. VCMI is a turn-based strategy
game where the player controls a number of heroes commanding an army of
creatures. It extends the original capabilities of the game by
supporting maps of any size, greater display resolutions.

I'm also working on a project which allows to easily replace the proprietary
graphics of the original game by a free version at 
https://github.com/josch/lodextract

More information is available in the respective ITP bug#741640 which
includes some discussion on the debian-devel-games list. 

cheers, josch


-- 
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/20140318223806.12867.34343.reportbug@hoothoot

Bug#742077: RFS: vcmi/0.95-1 [ITP]

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2014-03-18 23:58:19)
 [I don't intend to sponsor this package. Sorry!]

dont worry, I'm happy for any help that can improve my packaging! :)

 We don't have ³ or ñ in the Polish alphabet. :-P It should be: Michał
 Urbańczyk.  Please update debian/copyright accordingly.

Oh awesome! That makes lots of sense! It seems that the AUTHORS file is not
utf8 but either windows-1250 or iso-8859-2

Thanks!

cheers, josch


--
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/20140319053103.1302.53879@hoothoot

Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE

[Johannes Schauer]

Hi,

Quoting The Wanderer (2014-01-22 15:14:34)
 Do things still work fine in Debian when using ld.gold (by installing the
 binutils-gold package) rather than ld.bfd? I know there's an important
 difference in ld.gold related to --as-needed (or possibly to -
 --no-as-needed, I don't recall offhand).

I dont think the binutils-gold package exists anymore. binutils-gold seems to
be provided by the binutils package which now seems to ship /usr/bin/ld.gold

Do you happen to know an easy, undisruptive way to test with ld.gold?

 I seem to recall that there are long-term plans to switch Debian over to
 ld.gold or to produce the same effect in ld.bfd, and that it's recommended
 (or at least preferred) to make sure your package builds with the gold
 linker; I suspect that this is the similar change...  being discussed for
 Debian mentioned in the ToolchainTransition article you linked.
 
 There's no expected completion date for this AFAIK, but trying to be
 compliant with it isn't a bad idea; I've already got the upstream of
 something I haven't even packaged yet to accept a compliance patch, just
 based on test packaging attempts.

Thanks you for the information!

cheers, josch


--
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/20140125102429.11514.34170@hoothoot

Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE

[Johannes Schauer]

Hi Ahmed,

Quoting أحمد المحمودي (2014-01-22 08:52:43)
 At the end of the README it says to use mountlo, but there isn't such a
 utility in Debian.

there is also no such utility in other distributions it seems. After some
digging I found out that mountlo is a utility which uses fuse and a minimal
usermode linux to mount any filesystem the linux kernel understands with fuse
(at least in theory). Unfortunately it only ever built on i386 and upstream is
long dead.

I might have a look at mountlo as well and become its new upstream if it seems
worth it because I have a high interest in being able to mount any filesystem
in userspace [1].

For now, it's maybe makes sense to patch that line in the readme with:

fuse-ext2 -o rw,force mydisk.img /mnt

Do you agree?

cheers, josch


--
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/20140125105728.11514.41749@hoothoot

Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE

[Johannes Schauer]

Hi Ahmed,

Quoting أحمد المحمودي (2014-01-22 08:51:02)
   Sorry, that I forgot to attach it. Please find it attached in this email.

thanks! What problem does that patch fix?

The only differences in comparison to my patch that I can make out are:

 1) you add -lpthread but `pkg-config --libs fuse` already takes care of adding
that

 2) you explicitly write `$(CC) $^ $(CFLAGS) $(LDFLAGS) -o $@` but this already
is the implicit default make rule to compile C files, so there is no need
to explicitly state it, is there?

What problem did you observe with the patch that I submitted?

cheers, josch


--
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/20140122092212.2407.14552@hoothoot

Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE

[Johannes Schauer]

Hi,

Quoting أحمد المحمودي (2014-01-22 10:36:11)
   Actually what happens implicitly (at least on Ubuntu precise) is: $(CC)
   $(CFLAGS) $(LDFLAGS) $^ -o $@
 
   which causes the compilation to fail, because the -l... should be 
   after the object files (or source files in this case).

Ah funny, so it's a ubuntu problem. I did not observe this problem with Debian
unstable.

After trying it out myself in a ubuntu precise and saucy chroot and asking on
#debian-mentors, the reason why this error happens only on Ubuntu seems to be:

https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition

Should I contact upstream to yet again change his makefile or are things okay
as they are because everything works fine in Debian?

cheers, josch


--
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/20140122101209.2407.71197@hoothoot

Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE

[Johannes Schauer]

Hi Ahmed,

Quoting أحمد المحمودي (2014-01-22 06:51:13)
   * I had to modify the hardening patch to get fuseloop to build, modified
   patch is attached.

I think you forgot to attach your patch but notice that after informing
upstream of the issue, they fixed it for fuseloop 1.0.2 which is packaged on
https://mentors.debian.net/package/fuseloop

   * I think it would be useful to install upstream's README.md (just add it
   in debian/fuseloop.docs)

Good idea! Added in 1.0.2-2 on mentors.

   * The README isn't clear about how to actually mount the exposed partition

It is clear for me. Maybe if you tell me how it is not clear for you I can fix
it accordingly. I especially like how the README even includes steps to use
fdisk to figure out the partition offsets.

Thanks for your comments!

cheers, josch


--
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/20140122063905.2407.47299@hoothoot

Bug#734611: RFS: libfixbuf/1.4.0 ITP -- Implementation of the IPFIX protocol

[Johannes Schauer]

Hi,

Quoting Wookey (2014-01-14 01:59:22)
 +++ Johannes Schauer [2014-01-08 15:41 +0100]:
  I am looking for a sponsor for my package libfixbuf:
 OK. Looks sound to me.

thanks for looking at it!

 A couple of minor points: You might want to include a watch file for new
 upstream releases.

I indeed wanted to but the website which offers the releases hides the correct
url behind a JavaScript. It took me a while to find out that I had to enable
JavaScript to be able to click on their links. Because of that it would be
necessary for uscan to parse a JavaScript file. I did not find to out how to do
this with uscan or if it is even possible at all. The default seems to just be
searching for a href= tag values which does not work here because the a
href= is generated by JavaScript.

 Should you do something with the included pyfixbuf-0.1.tar.gz, like drop it
 or add a python package?. It's mostly wasting 400K of space. I guess
 currently you have a pristine upstream tarball - it just happens to have
 another dollop of software somewhat unhelpfully included, and not in a format
 conducive to bulding from it. I guess that's fair enough.

I forgot to remove that tarball from the upstream orig.tar.gz before my upload
to mentors.debian.net.

I solved the debian/watch issue when I noticed that apart from the download
links, there are also links to the individual h1 headers on that website
which include the version number. The resulting debian/watch file is a bit
cryptic but seems to work. I also added debian/repack.sh to debian/watch

debian/repack.sh repacks the upstream tarball, removing the tarball with the
python bindings and some pre-generated documentation.

I added a debian/README.source to explain the changes.

The new version is on mentors as 1.4.0+ds-1

http://mentors.debian.net/debian/pool/main/libf/libfixbuf/libfixbuf_1.4.0+ds-1.dsc

Thanks!

cheers, josch


--
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/20140114124539.2307.86235@hoothoot

Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE

[Johannes Schauer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package fuseloop

* Package name: fuseloop
  Version : 1.0.1-1
  Upstream Author : Johny Mattsson
* URL : https://github.com/jmattsson/fuseloop
* License : BSD
  Section : utils

It builds those binary packages:

   fuseloop   - loopback mount using FUSE

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

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

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

 dget -x 
http://mentors.debian.net/debian/pool/main/f/fuseloop/fuseloop_1.0.1-1.dsc

Fuseloop allows one to populate a disk image which includes a partition
table with file systems by loop mounting one partition of that disk
image to a new file. This allows tools like mke2fs and fuse-ext2 which
are able to work on regular files but do not allow to specify an offset
and size to indirectly work on that disk image.

cheers, josch


-- 
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/20140113153130.19925.22983.reportbug@hoothoot

Bug#734611: RFS: libfixbuf/1.4.0 ITP -- Implementation of the IPFIX protocol

[Johannes Schauer]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package libfixbuf:

 * Package name: libfixbuf
   Version : 1.4.0-1
   Upstream Author : Brian Trammell, Dan Ruef, Emily Ecoff
 * URL : http://tools.netsa.cert.org/fixbuf/index.html
 * License : LGPL-2.0
   Section : net

It builds those binary packages:

libfixbuf2 - Implementation of the IPFIX protocol - shared library
libfixbuf2-dev - Implementation of the IPFIX protocol - development headers
libfixbuf2-doc - Implementation of the IPFIX protocol - documentation

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

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


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

  dget -x 
http://mentors.debian.net/debian/pool/main/libf/libfixbuf/libfixbuf_1.4.0-1.dsc

cheers, josch


-- 
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/20140108144116.10764.97409.reportbug@hoothoot