Re: Bug#818974: packaging

[Dominique Dumont]

On Saturday 23 April 2016 10:10:28 Roderick MacKenzie wrote:
> I've now used license-reconcile and a bit of copy and paste from
> hedgewars to sort out the copyright file.

You can also try "cme update dpkg-copyright". 

See 
https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme
for instructions,

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#822360: marked as done (RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to Phoneme conversion tool)

[Debian Bug Tracking System]

Your message dated Sun, 24 Apr 2016 12:14:18 +0200
with message-id 

and subject line Re: Bug#822360: RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to 
Phoneme conversion tool
has caused the Debian Bug report #822360,
regarding RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to Phoneme conversion tool
to be marked as done.

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

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


-- 
822360: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822360
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: Jakub Wilk 

Dear Jakub,

I am looking for a sponsor for an updated version of my package "sequitur-g2p"

 * Package name: sequitur-g2p
   Version : 0.0.r1668-3
   Upstream Author : Maximilian Bisani 
 * URL : 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html
 * License : GPL-2
   Section : science

It builds those binary packages:

   sequitur-g2p - Grapheme to Phoneme conversion tool


You can download the package with git using this command:

   git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git

More information about sequitur-g2p can be obtained from 
http://www-i6.informatik.rwth-aachen.de/web/Software/g2p.html.

Would you like to review and upload it?

Regards,
 Giulio
--- End Message ---
--- Begin Message ---
Il 24/apr/2016 11:59, "Christian Kastner"  ha scritto:
>
> On 2016-04-24 01:30, Giulio Paci wrote:
> >> What update was that? From the other commits, I can deduce that this
was
> >> merely a refreshing of d/control from d/control.in, and the actual
> >> changes -- namely bumping Standards-Version, and updating Vcs-* --
> >> happened earlier. This was a bit confusing, so being explicit about
this
> >> could be helpful.
> >
> > You are perfectly right.
> > I think "Refreshed" is a much better word in this case, so I will use
this word in future.
>
> In hindsight, something like "Regenerated X from X.in" might be even
> better -- that would make it even clearer from the subject that this
> commit can probably be ignored.

I perfectly agree, so I think I will use this formula. Thank you for it.
Indeed I just drop it from the changelog. I mostly use it as a marker of
the fact that I think that there are no issues with control file anymore.
In the same way I tend to use changelog updates as a marker of the fact
that I completed some work on the package.

> And just for comparison, here's another approach: the Nautilus team
> seems to be doing it by committing both changes at the same time, and
> also adding a warning header to the generated file:
>
>   https://

anonscm.debian.org
/

viewvc
/

pkg-gnome
?

view
=

revision
&

revision

=48120

>   http://

sources.debian.net
/
src
/
nautilus

/3.20.0-1/debian/
control
/


I think I should take from here at least the idea of the warning header
from here. Although, probably, the best option is to change cdbs so that
this will automatically happen for all automatically generated files.
@Jonas: what do you think?

> >>   * d/patches:
> >> -

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Jakub Wilk]

* Giulio Paci , 2016-04-24, 01:13:

+  * Update Source field in copyright.
Policy §12.5 says that the “the copyright file must say where the 
upstream sources (if any) were obtained”, but they are not available 
(and never were AIUI) at the new location. So I think keeping the 
original Source would be better^Wless wrong, at least until the 
tarball Debian uses appears on the new site.

Reverted the change


But the changelog still say it's been updated.


spellintian(1) says:
debian/patches/1003_make_logger_more_flexible.patch: Allows to -> 
Allows one to

Fixed.


But not documented in the changelog...

--
Jakub Wilk

Re: noopt not working

[Jakub Wilk]

* Shawn Sörbom , 2016-04-23, 15:28:
The problem is that optimization appears to cause a segfault during 
runtime.


I'd normally advise fixing the root cause of segfault, instead of 
disabling optimization, ...



https://github.com/devshane/zork


... but trying to wrap your head around this code is almost certainly 
not worth the trouble. :-)



export DEB_BUILD_MAINT_OPTIONS = hardening=+all noopt


"noopt" doesn't work in DEB_BUILD_MAINT_OPTIONS.


#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic -g
export DEB_CFLAGS_MAINT_STRIP  = -O2


This should normally do the trick, although probably appending -O0 would 
be more robust that stripping -O2.



CFLAGS = -O2 #-static


So this upstream makefile doesn't honour CFLAGS from environment. 
Luckily, this is trivial to fix: just use "?=" instead of "=". 

(This makefile doesn't honour CPPFLAGS or LDFLAGS either; fixing this 
would be a bit more work.)


--
Jakub Wilk

Re: Bug#818974: packaging

[Adam Borowski]

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

Bad advice, I'm afraid.

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

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


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

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

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

-- 
A tit a day keeps the vet away.

if a changelog is on a wiki, does the debian package need a local version?

[Nicholas D Steeves]

Hi,

If a package's changelog is published on a wiki, is it still necessary
and/or desirable to ship a changelog with the Debian package?  If yes,
is something like the following the best solution:

curl https://btrfs.wiki.kernel.org/index.php/Changelog | html2text |
sed '0,/(announcement)/d;/By version (linux kernel)/Q' | gzip -9 >
debian/local/changelog.gz

Or is it the case, from what I've read here:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs

that the following is preferred?:
curl https://btrfs.wiki.kernel.org/index.php/Changelog | gzip -9 >
debian/local/changelog.html.gz

Given standards-version 3.9.7, this has to be done when preparing a
new version of the package, and not when building, correct?  And to
actually add the changelog to the package, add the following to the
appropriate section of debian/rules:

install -D -m 644 debian/local/changelog.html.gz
debian/btrfs-progs/usr/share/doc/btrfs-progs/changelog.html.gz

If the upstream changelog was specific to just btrfs-progs, then I
would use the html version without question; however, because a
substantial portion of it does not pertain to the btrfs-progs package
itself, I wonder it's better to convert to text and cut the
non-applicable sections...

Please let me know,
Nicholas

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

[Mateusz Łukasik]

Pong back.

http://mentors.debian.net/debian/pool/main/c/connman/connman_1.21-1.3.dsc

I was tested it on Ubuntu 16.04 and all is fine.

Re: if a changelog is on a wiki, does the debian package need a local version?

[Jakub Wilk]

* Nicholas D Steeves , 2016-04-24, 08:02:
If a package's changelog is published on a wiki, is it still necessary 
and/or desirable to ship a changelog with the Debian package?


It's not strictly necessary, but it is desirable.


If yes, is something like the following the best solution:

curl https://btrfs.wiki.kernel.org/index.php/Changelog | html2text | sed 
'0,/(announcement)/d;/By version (linux kernel)/Q' | gzip -9 > 
debian/local/changelog.gz


You should probably pass -n to gzip; or even better, let dh_compress 
gzip it for you.



Or is it the case, from what I've read here:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs

that the following is preferred?:
curl https://btrfs.wiki.kernel.org/index.php/Changelog | gzip -9 > 
debian/local/changelog.html.gz


I wouldn't bother providing HTML version of the changelog.

Given standards-version 3.9.7, this has to be done when preparing a new 
version of the package, and not when building, correct?


That's right.


install -D -m 644 debian/local/changelog.html.gz 
debian/btrfs-progs/usr/share/doc/btrfs-progs/changelog.html.gz


I'd recommend using dh_installchangelogs for this job.

If the upstream changelog was specific to just btrfs-progs, then I 
would use the html version without question; however, because a 
substantial portion of it does not pertain to the btrfs-progs package 
itself, I wonder it's better to convert to text and cut the 
non-applicable sections...


Sounds reasonable.

--
Jakub Wilk

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Giulio Paci]

Il 24/apr/2016 12:54, "Jakub Wilk"  ha scritto:
>
> * Giulio Paci , 2016-04-24, 01:13:
>
 +  * Update Source field in copyright.
>>>
>>> Policy §12.5 says that the “the copyright file must say where the
upstream sources (if any) were obtained”, but they are not available (and
never were AIUI) at the new location. So I think keeping the original
Source would be better^Wless wrong, at least until the tarball Debian uses
appears on the new site.
>>
>> Reverted the change
>
>
> But the changelog still say it's been updated.

Removed the line.

>>> spellintian(1) says:
>>> debian/patches/1003_make_logger_more_flexible.patch: Allows to ->
Allows one to
>>
>> Fixed.
>
> But not documented in the changelog...

Added a line for it.

Bests,
Giulio

Bug#822362: marked as done (RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit)

[Debian Bug Tracking System]

Your message dated Sun, 24 Apr 2016 16:45:07 +0200
with message-id <20160424144507.ga5...@jwilk.net>
and subject line Re: Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling 
toolkit
has caused the Debian Bug report #822362,
regarding RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit
to be marked as done.

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

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


-- 
822362: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822362
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: Jakub Wilk 

Dear Jakub,

  I am looking for a sponsor for an updated version of my package "mitlm"

* Package name: mitlm
  Version : 0.4
  Upstream Author : Bo-June (Paul) Hsu 
* URL : https://github.com/mitlm/mitlm
* License : BSD
  Programming Lang: (C, C++, Fortran)
  Section : misc

It builds those binary packages:

 libmitlm0  - MIT Language Modeling toolkit library
 libmitlm0-dev - MIT Language Modeling toolkit development files
 mitlm - MIT Language Modeling toolkit

You can find the source of the package at:

  https://anonscm.debian.org/cgit/collab-maint/mitlm.git

Regards,
   Giulio Paci
--- End Message ---
--- Begin Message ---

54225b104bcb uploaded.

--
Jakub Wilk--- End Message ---

Re: noopt not working

[Shawn Sörbom]

On Sunday, April 24, 2016 13:22:59 Jakub Wilk wrote:
> * Shawn Sörbom , 2016-04-23, 15:28:
> >The problem is that optimization appears to cause a segfault during
> >runtime.
> 
> I'd normally advise fixing the root cause of segfault, instead of
> disabling optimization, ...
> 
> >https://github.com/devshane/zork
> 
> ... but trying to wrap your head around this code is almost certainly
> not worth the trouble. :-)
> 
> >export DEB_BUILD_MAINT_OPTIONS = hardening=+all noopt
> 
> "noopt" doesn't work in DEB_BUILD_MAINT_OPTIONS.
> 
> >#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic -g
> >export DEB_CFLAGS_MAINT_STRIP  = -O2
> 
> This should normally do the trick, although probably appending -O0 would
> be more robust that stripping -O2.
> 
> >CFLAGS = -O2 #-static
> 
> So this upstream makefile doesn't honour CFLAGS from environment.
> Luckily, this is trivial to fix: just use "?=" instead of "=".
> 
> (This makefile doesn't honour CPPFLAGS or LDFLAGS either; fixing this
> would be a bit more work.)

Thank you. I will fix this ASAP. I am rather curious to see if anyone would 
sponsor the resulting package, given that Debian seems to have so many folks 
involved from the era of DECs...

Re: Seeking Sponsors for my package - roadfighter

[Paul Wise]

On Fri, 2016-04-22 at 01:49 -0300, Carlos Donizete Froes wrote:

> My problem is in upstream Makefile which causes some lintian.

Generally, problems with upstream code or build systems should be fixed
by sending upstream a patch and asking them for a new release. If they
don't respond, then you can include the patch in the Debian package.

> 1. P: roadfighter source: debian-watch-may-check-gpg-signature

Needs upstream to sign their releases using OpenPG first, ask them to
do so and ignore the lintian warning until they do that.

https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
https://help.riseup.net/en/security/message-security/openpgp/best-practices

> 2. E: roadfighter: arch-dependent-file-in-usr-share
> usr/share/games/roadfighter/roadfighter

Sounds like it should be installed in /usr/games instead.

> 3. P: roadfighter: no-upstream-changelog

If there is an upstream NEWS file or other changelog-related file not
detected by dh_installchangelogs then you can override the
dh_installchangelogs command to make it install that file. If such a
file does not exist then you can ask upstream to add one.

> 4. W: roadfighter: duplicate-font-file
> usr/share/games/roadfighter/fonts/DroidSerif-Bold.ttf also in
> fonts-droid
> 
> 5. W: roadfighter: duplicate-font-file
> usr/share/games/roadfighter/fonts/DroidSerif-Italic.ttf also in
> fonts-droid

Disable installing these files and replace them with symlinks to the
equivalent file from fonts-droid.

> 6. I: roadfighter: arch-dep-package-has-big-usr-share 13398kB 100%

Split the data out into a roadfighter-common package.

> 7. W: roadfighter: executable-not-elf-or-script usr/games/roadfighter

Looks like upstream intended to add a shell script there but forgot
that shell scripts need #!/bin/sh as the first line.

> 1. In first upstream unfortunately does not have a signature of this
> game. But so far so good. :)

Talk to upstream about it.

> 2. Makefile upstream requires the binary is in the same directory with
> independent files in '/usr/share/games'. I have no idea how to solve
> this. :/

You will need to patch the code and send upstream your changes.

> 3. This third without problem, has no previous changelog.

Talk to upstream about it.

> 4-5. Previously made a 'd/roadfighter.links' with the following path:
> ===
> /usr/share/fonts/truetype/droid/DroidSerif-Bold.ttf 
> /usr/share/games/roadfighter/fonts/DroidSerif-Bold.ttf
> /usr/share/fonts/truetype/droid/DroidSerif-Italic.ttf 
> /usr/share/games/roadfighter/fonts/DroidSerif-Italic.ttf
> ===
> Then blacked out line 12 of Makefile - 'fonts', but to run the binary
> the message "Segmentation fault".

Sounds like you will need to learn debugging (with gdb) to fix this.

> 6. I have no idea how to solve this. :/

See above.

> 7. I made a 'd/install', but as demands that the binary is in the same
> location independent of the game files, which gave error "Segmentation
> fault".
> 
> Also did a binary link to 'usr/games' without success. :/

See above, fixing the Makefile would fix this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part

Bug#819615: RFS: spin/6.4.5-1 [ITP] -- formal software verification tool

[Tom Lee]

Still looking for a sponsor for the spin verification tool. I added a
spin-dbg binary package to the mix earlier today:

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

Builds fine in pbuilder, is lint clean, etc. Appreciate reviews too!

-- 
*Tom Lee */ http://tomlee.co / @tglee 

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

[Adam Borowski]

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

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

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

-- 
A tit a day keeps the vet away.

Bug#822524: RFS: bliss/0.73-1 [ITA] - library to compute graph automorphisms and labelings

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Sponsor,

I am looking for a sponsor for the Debian package bliss [1].
This package version brings to Debian the latest release and
refresh the Debian material.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/bliss.git/

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)