Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

[Stefan Ahlers]

Hi,

here is the rest of the list.

> data/www/js/html5shim.js

Will be removed, because it's not necessary for the linux build.

> data/www/css/font-awesome.css
> data/www/css/bootstrap.css
> data/www/css/animate.css

This files are necessary for the integrated webserver of tomahawk. If
I'm searching for this files in the debian sources I found a multiple
times this files integrated in a project.

> data/js/cryptojs/
> data/js/cryptojs-core.js

cryptojs will be removed in the next release. Using the debian package
for this release.

> data/fonts/

Replace it with the debian package.

Regards,
Stefan Ahlers

Re: controlling error handling in sourced shell code

[Paul Gevers]

control: tags -1 -help

On 20-12-15 15:03, Paul Gevers wrote:
> I am looking into fixing bug 807353¹ against my package dbconfig-common.
> dbconfig-common is written in shell, such that it can easily be sourced
> and used in maintainer scripts. The issue is that when you call a
> sourced function in the test part of an if-then-fi statement, the "set
> -e" option of the calling script doesn't propagate into the sourced
> function. Unfortunately, dbconfig-commons error handling relies on that
> behavior. I found a (slightly hacky, but probably adequate) solution for
> bash², but that doesn't seem to be generic enough for e.g. dash as it
> relies on the errtrace option. Does anybody here have an idea how to
> solve this properly?

I think I'll just have to add a "|| return $?" in several dozens of
locations and hope I don't miss any. Anybody a better idea?

And I'll probably contact the packages that call dbconfig-common in such
an if statement to reconsider.

Paul



signature.asc
Description: OpenPGP digital signature

new version python3

[Daniel Echeverry]

Hi mentors

I am working in a new version of lfm, the new version is python3 for
this reason I want to know if necessary create a ITP bug with a new
package like this lfm3, to package this new version, or if I could
continue with the same package.

regards

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
Linux user: #477840
Debian user
Software libre

Re: new version python3

[Gianfranco Costamagna]

Hi,

>I am working in a new version of lfm, the new version is python3 for
>this reason I want to know if necessary create a ITP bug with a new
>package like this lfm3, to package this new version, or if I could
>continue with the same package.


the question is:

is this something that the average normal use will notice or care about?
e.g. if the user experience won't change, and the upstream development has 
moved to python3 only
seems legit to just switch the dependencies.

Moreover nowadays both are installed on the end user system, and if the user 
experience is the same
the average user won't even know something has changed.

cheers,

G.

Re: new version python3

[Daniel Echeverry]

Hi!

2015-12-21 17:18 GMT-05:00 Gianfranco Costamagna
:
> Hi,
>
>>I am working in a new version of lfm, the new version is python3 for
>>this reason I want to know if necessary create a ITP bug with a new
>>package like this lfm3, to package this new version, or if I could
>>continue with the same package.
>
>
> the question is:
>
> is this something that the average normal use will notice or care about?
> e.g. if the user experience won't change, and the upstream development has 
> moved to python3 only
> seems legit to just switch the dependencies.
>
> Moreover nowadays both are installed on the end user system, and if the user 
> experience is the same
> the average user won't even know something has changed.
>
> cheers,
>
> G.

I am not sure but upstream provides something [1] A lot of changes and
the new version is written from scratch what do you think ?

Also the python2 version is orphan, the upstream doesn't provide support

Really, thank you very much!

Regards

[1]: https://inigo.katxi.org/devel/lfm/#upgrading-from-2-x-to-3-x

-- 
Daniel Echeverry
http://wiki.debian.org/DanielEcheverry
Linux user: #477840
Debian user
Software libre

Re: new version python3

[Ben Finney]

Daniel Echeverry  writes:

> I am working in a new version of lfm, the new version is python3 for
> this reason I want to know if necessary create a ITP bug with a new
> package like this lfm3, to package this new version

The name ‘lfm3’ implies you are packaging version 3 *of lfm*. Is that
the case for this package?

To put the version of LFM in the package name also implies LFM 3 and
some other version of LFM (version 2, or version 4, etc.) are likely
candidates to be installed on the same system. Is that true for this
case?

The implementation language of the program is generally quite irrelevant
to what the program should be called.

An exception would be if the program's purpose is primarily *about* that
language, such as a development tool for that language. Is that the
case for this program?

> or if I could continue with the same package.

If the change of implementation doesn't entail a significant change in
how the program is expected to behave, then yes, I think keeping the
package name the same is important to reflect that continuity.

-- 
 \  “Generally speaking, the errors in religion are dangerous; |
  `\those in philosophy only ridiculous.” —David Hume, _A Treatise |
_o__)   of Human Nature_, 1739 |
Ben Finney

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

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for "re2c":

  Package name: re2c
  Version : 0.15.3-1
  Upstream Author : Peter Bumbulis et al.
  URL : http://re2c.org
  License : public domain
  Section : devel

It builds a single binary package:
  re2c  - tool for generating fast C-based recognizers

Mentors URL:
  http://mentors.debian.net/package/re2c

Download with dget:
  dget -x http://mentors.debian.net/debian/pool/main/r/re2c/re2c_0.15.3-1.dsc


Changes since last upload:
  * New upstream release. (Closes: #747184)
  * New maintainer. (Closes: #808410)
  * Add d/source/format, set to 3.0 (quilt).
  * Control:
+ Set debhelper version (and d/compat) to 9.
+ Add missing ${misc:Depends} dependency to the binary package.
+ Add VCS links.
+ Change upstream homepage to re2c.org.
+ Description: remove needless dot from the end, stop using first
  person.
  * Copyright: update list of upstream authors.
  * Docs: don't install README, not relevant for end users and
duplicating info already in the packaging.
  * Rules: convert to dh sequencer.
  * Examples: don't install "lessons", removed upstream.
  * Bump standards-version to 3.9.6 (from 3.8.0), no further changes.
  * Add patch 01: fix typos in manpage and usage info.
  * Watch: escape dot in version matching regexp.


Regards.


pgpYNBjkyd5GG.pgp
Description: OpenPGP digital signature

Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]

[foss.freedom]

Hi Gianfranco

 I've re-uploaded to mentors.debian.net

This corrects the issues mentioned previously.  Note - I've resolved the
LICENSE issue by two debian/patches

Note - This still produces an informational lintian issue with the
remove-license.diff patch.  This is very odd because this does have a PEP3
header on the diff file

* Package name: rhythmbox-plugin-alternative-toolbar
   Version : 0.15.0-1
I've uploaded a newer version with a new autotools build mechanism+patches here:
  http://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar

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

dget -x 
http://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.15.0-1.dsc


thanks

David


On 21 December 2015 at 11:05, foss.freedom  wrote:

> Many thanks Gianfranco,
>
>   to answer your questions
>
> 1. python3 - yes I should include this as a dependency - you are correct
> rhythmbox does have a dependency - but belt-and-braces
> 2. When the topic of changing the interface for rhythmbox came up on a
> bugzilla report, the rhythmbox maintainer dismissed very quickly the
> approach of using a python3 plugin.  Thus I havent attempted to upstream
> this
>
>  - https://bugzilla.gnome.org/show_bug.cgi?id=735648
>
> With regards to the lintian report:
>
> 1.  W: rhythmbox-plugin-alternative-toolbar source:
> build-depends-on-python-dev-with-no-arch-any
>
> There is no reason for the package to have a build-depends on python3-dev
> so I'll remove this.
>
> 2. P: rhythmbox-plugin-alternative-toolbar source:
> debian-watch-may-check-gpg-signature
>
> No idea on this - dont think GitHub provides a means to gpg-signature the
> tar.gz tag file
>
> 3. P: rhythmbox-plugin-alternative-toolbar: no-upstream-changelog
>
> Think this means I need to change my source and thus bump the version. If
> you don't mind I would like to bump this into a future version of the
> plugin.
>
> 4. I: rhythmbox-plugin-alternative-toolbar:
> capitalization-error-in-description Gnome GNOME
>
> Doh! - yes, quite correct - I'll change all references for Gnome to GNOME
> in the description
>
> 5. W: rhythmbox-plugin-alternative-toolbar: extra-license-file
> usr/lib/rhythmbox/plugins/alternative-toolbar/LICENSE
>
> I'm not sure how to do this - I thought of using a debian/rules 
> override_dh_auto_install
> but this doesnt seem to be working.  If you have any thoughts on this I
> would be very grateful - for the moment I've created a unix-and-linux
> stackexchange question and I hope someone can answer:
>
>  -
> http://unix.stackexchange.com/questions/250683/how-to-remove-a-license-file-when-debian-packaging-using-autotools-automake#250683
>
> thanks
>
> David
>
>  -
>
> On 21 December 2015 at 09:20, Gianfranco Costamagna <
> costamagnagianfra...@yahoo.it> wrote:
>
>> Hi,
>>
>>
>>
>> the package looks really nice now!
>>
>> however there still are some minor issues here
>>
>> http://debomatic-amd64.debian.net/distribution#unstable/rhythmbox-plugin-alternative-toolbar/0.15.0-1/lintian
>>
>> can you please address them? the package works in both debian and ubuntu.
>>
>> I have a few questions:
>> 1) isn't python3 a runtime dependency? (not a problem, because seems that
>> rhythmbox already depends on it)
>> 2) why didn't you upstream the plugin into the rhythmbox-plugins package?
>> https://packages.qa.debian.org/r/rhythmbox.html
>>
>> thanks,
>>
>> Gianfranco
>>
>
>

Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]

[foss.freedom]

Many thanks Gianfranco,

  to answer your questions

1. python3 - yes I should include this as a dependency - you are correct
rhythmbox does have a dependency - but belt-and-braces
2. When the topic of changing the interface for rhythmbox came up on a
bugzilla report, the rhythmbox maintainer dismissed very quickly the
approach of using a python3 plugin.  Thus I havent attempted to upstream
this

 - https://bugzilla.gnome.org/show_bug.cgi?id=735648

With regards to the lintian report:

1.  W: rhythmbox-plugin-alternative-toolbar source:
build-depends-on-python-dev-with-no-arch-any

There is no reason for the package to have a build-depends on python3-dev
so I'll remove this.

2. P: rhythmbox-plugin-alternative-toolbar source:
debian-watch-may-check-gpg-signature

No idea on this - dont think GitHub provides a means to gpg-signature the
tar.gz tag file

3. P: rhythmbox-plugin-alternative-toolbar: no-upstream-changelog

Think this means I need to change my source and thus bump the version. If
you don't mind I would like to bump this into a future version of the
plugin.

4. I: rhythmbox-plugin-alternative-toolbar:
capitalization-error-in-description Gnome GNOME

Doh! - yes, quite correct - I'll change all references for Gnome to GNOME
in the description

5. W: rhythmbox-plugin-alternative-toolbar: extra-license-file
usr/lib/rhythmbox/plugins/alternative-toolbar/LICENSE

I'm not sure how to do this - I thought of using a debian/rules
override_dh_auto_install
but this doesnt seem to be working.  If you have any thoughts on this I
would be very grateful - for the moment I've created a unix-and-linux
stackexchange question and I hope someone can answer:

 -
http://unix.stackexchange.com/questions/250683/how-to-remove-a-license-file-when-debian-packaging-using-autotools-automake#250683

thanks

David

 -

On 21 December 2015 at 09:20, Gianfranco Costamagna <
costamagnagianfra...@yahoo.it> wrote:

> Hi,
>
>
>
> the package looks really nice now!
>
> however there still are some minor issues here
>
> http://debomatic-amd64.debian.net/distribution#unstable/rhythmbox-plugin-alternative-toolbar/0.15.0-1/lintian
>
> can you please address them? the package works in both debian and ubuntu.
>
> I have a few questions:
> 1) isn't python3 a runtime dependency? (not a problem, because seems that
> rhythmbox already depends on it)
> 2) why didn't you upstream the plugin into the rhythmbox-plugins package?
> https://packages.qa.debian.org/r/rhythmbox.html
>
> thanks,
>
> Gianfranco
>

Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]

[Gianfranco Costamagna]

Hi,



the package looks really nice now!

however there still are some minor issues here
http://debomatic-amd64.debian.net/distribution#unstable/rhythmbox-plugin-alternative-toolbar/0.15.0-1/lintian

can you please address them? the package works in both debian and ubuntu.

I have a few questions:
1) isn't python3 a runtime dependency? (not a problem, because seems that 
rhythmbox already depends on it)
2) why didn't you upstream the plugin into the rhythmbox-plugins package?
https://packages.qa.debian.org/r/rhythmbox.html

thanks,

Gianfranco

Bug#808441: marked as done (RFS: rfcdiff/1.42-1 ITP)

[Debian Bug Tracking System]

Your message dated Mon, 21 Dec 2015 11:49:55 +
with message-id <20151221114955.gi10...@chase.mapreri.org>
and subject line Re: Bug#808441: RFS: rfcdiff/1.42-1 ITP
has caused the Debian Bug report #808441,
regarding RFS: rfcdiff/1.42-1 ITP
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.)


-- 
808441: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808441
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "rfcdiff".

I want to package abi-monitor and abi-tracker [1], because I think it is
useful for
lots of DDs and DMs maintaining shared libraries. abi-tracker has
rfcdiff as dependency, therefore I need to package it.

Aside that its quite a useful tool to generate html reports of file diff
s.



 * Package name: rfcdiff
   Version : 1.42-1
   Upstream Author : Henrik Levkowetz 
 * URL : https://tools.ietf.org/tools/rfcdiff/index
 * License : GPL-2.0+
   Section : text

  It builds those binary packages:

rfcdiff- compares two internet draft files and outputs the
difference

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

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


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

dget -x
http://mentors.debian.net/debian/pool/main/r/rfcdiff/rfcdiff_1.42-1.dsc


  Changes since the last upload:

This is an initial upload.


  Regards,
   Peter Spiess-Knafl

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808260

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWdmTpAAoJED/ImGelQYVWZQcQAIrRrgq7FqPpFlqBOTt0cBfw
Z7aEiyWsvuet/wQMuBun9ho+cO5f6wW674/afwVrqUIO64M0cWvNYm3+2UuAaVKX
Qra6c4dTHvlxHcxFDTBBIxz1ft0c6X9byY9G39tNiXQdwGi8/ol7vcTD07nbnmFR
KG7cgFVrBRtGVch7kiDQQ7RDRYHMsABMbs5SRLMuRUIRI2rbgxOXlNRjXkOukI/C
2rap6i5mXFNxwUJOudlmqPBzBHciqH8x3u5RiWOyDVHcu8A1ByEFo24ciETZlP6L
+cRvk4YxpsIdR0HPZKyQ3BnTne7mw0FeDHeTajs9SRG6vk8+VaI43EzNO7aWBqPt
jrbYlMuSXXCUWqPl6KzlUmJfvHpfYEopjALZWir/u9CgBDFTIOLegbh8wIBozOBi
YZTxwfegtk5D1zyPb/5lPCLbsOuQBezzIFq+XZqFCru4LuozbbX0zxXW9RJRiAvj
sI2wPjkqBP0mclLqh0LzhCZoWzjHgXRg36o77Y0/4XOCljhIb9mLSbM44FfnennV
busrUGTVR/2Rx9fn8lq0Dd8tzbj8F4BT/q0SC9vD2mBiGUBBSctNYIkFPnIhXZAT
MO/mbX4iHARYKTwXUk9gAQz+uN4utBugRBu7ht/Qr2o36QaMtdU7igtTwsx2R8Qj
taVtcYGdP1LzlbRb+/wc
=BLji
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
On Mon, Dec 21, 2015 at 07:54:10AM +0100, Peter Spiess-Knafl wrote:
> Hey Mattia!
> 
> Thanks again for taking the time.

Uploaded :)

I removed the other traisling whitespace you didn't remove, and pushed a
tag to git.

> On 12/21/2015 12:04 AM, Mattia Rizzolo wrote:
> I did not know about that. I've gone over the manpages of wrap-and-sort.
> Thanks for pointing that out.
> 
> Do you know some sort of command which lists me all occurrences of
> trailing whitespaces?

nope, sorry.

> I got you wrong there. I removed the lines from d/rules but changed your
> patch a little bit for rfcdiff.install.

uops, yeah, clearly I didn't try that before proposing it, of course you
have to specify the destination directory

> > btw, I'll happily work through git, given that you have a packaging
> > repository, and you're using it sanely I'd use it, rather than going
> > with tarballs, is way easier for me.
> > Just poke when you do changes to review/upload.
> 
> That is great, it also makes things easier for me.

:)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature
--- End Message ---

Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

[Stefan Ahlers]

Hi,

> I'm assuming the GMail, itunes, echonest, beats, soundcloud, spotify
> and maybe playdar logos are not under a free license.

I understand the problem and I discuss it with the upstream maintainer.
But for the most of the companies they do not like to replace their
logos if you are using their services. And so I think it is better to
provide the freely distributable logos. For example the clementine
debian package do it in the same way.

Kind regards,
Stefan Ahlers

Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

[Stefan Ahlers]

Hi,

thank you for your review!

> I would suggest removing the whole thirdparty/ directory (using
> Files-Excluded in debian/copyright and repacksuffix in debian/watch)
> and packaging each dependency separately. Same goes for the other
> embedded copies in these files, some of them are already packaged,
> others are not. 

I asked upstream about the thirdparty/ directory and here is the response:

SPMediaKeyTap: It is only necessary for MAC. I have removed it.

kdsingleapplicationguard: Will maybe be replaced with
qtsingleapplication in the next release. I think it is better to package
qtsingleapplication for the next tomahawk release.

libportfwd: it's written in tomahawk and maintained there, the external
one might or might not be updated at all. And so I would not pack this
in a extra package, but miniupnp is a external dependency, now.

libqnetwm: It's only used for tomahawk Qt4 and will be obsolete in the
next release because tomahawk changes to Qt5. I would not pack this in a
extra package.

qt-certificate-addon: The source is not available and  the project seems
dead. And so I'm unable to replace it with a external package.

qxt: I would not use a external package, because of the following
statement of the libqtx developers: "Qxt will likely not work with newer
Qt versions due to usage of internal api. We recommend that you pick out
the parts you want instead of using the entire libqxt."

I will continue checking the rest of your points soon.

Kind regards,
Stefan Ahlers