Bug#610356: ITP: lastfmlib -- An implementation of the Last.Fm Submissions Protocol v1.2
Package: wnpp Severity: wishlist Owner: Andreas Noteng * Package name: lastfmlib Version : 0.4.0 Upstream Author : Dirk Vanden Boer * URL : http://code.google.com/p/lastfmlib/ * License : GPL-2 Programming Lang: C++ Description : An implementation of the Last.Fm Submissions Protocol v1.2 lastfmlib is a C++ library that provides an implementation of the Last.fm Submissions Protocol v1.2. It allows you to scrobble your tracks on Last.fm Inclution of this package in Debian, will make it possible to rebuild Mediatomb with Last.FM scrobbling support. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110117202128.15117.7525.reportbug@andreas-debian
machine readable copyright v1 and "GPL version 2 or later"
Hello, in one of my packages I have multiple files paragraphs with license GPL-2+, at the end I have a standalone license paragraph labeled GPL-2, this generates a lintian warning about missing license paragraph GPL-2+. Shouldn't lintian ignore the +, because it only means this version or, at your choice, any later version? I think it would be wrong to label the GPL-2 license paragraph GPL-2+, because this text is the exact text of version 2, even if you can choose to use any later version. If you only have GPL-2+ files paragraphs, lintian also generates a warning about unused license paragraph: GPL-2. What if you have both GPL-2 and GPL-2+ files paragraphs? Regards Andreas Noteng signature.asc Description: OpenPGP digital signature
Re: machine readable copyright v1 and "GPL version 2 or later"
On 05. april 2012 16:07, Gergely Nagy wrote: > Then you will have to have a GPL-2 and a GPL-2+ License section, where > one says: > > License: GPL-2+ > This program is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License version 2 as published > by the Free Software Foundation, or (at your option) any later version. > [...] > > And the other: > > License: GPL-2 > This program is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License version 2 as published > by the Free Software Foundation. > [...] > > Notice the difference between the two. OK, thanks for clarifying this for me. I'll update my packages accordingly. Andreas signature.asc Description: OpenPGP digital signature
Re: RFH with a couple of packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2011 02:17 PM, Leo 'costela' Antunes wrote: > Hey, > > I've recently been having some problems keeping up with my basic debian > duties, being overwhelmed by Real Life™ issues, so I thought it would be > a good idea to ask for co-maintainers for a couple of my packages. I > still very much want to keep maintaining them and would also accept > team-maintenance, but I'll admit I'm a bit wary of big teams - where the > responsibility can be pushed around too much - and would therefore > prefer small teams if possible. > > The biggest problem is transmission[0]. It's not a complicated package, > but it has a few FTBFSs for which I simply don't have the time right > now. Upstream is very responsive, friendly and even proactive about > debian bugs, so it's really just a matter of man-power. I'd love to help out any way I can with transmission. I currently maintain the transmission PPA on launchpad together with Krzysztof Klimonda. If you need som real brainpower though, I'd ask Krzysztof (CC'd). He has done a lot for the transmission packages in Ubuntu.. > > The second item in my list is the statusnet ITP[1]. It has a relatively > long story, including a packaging attempt by upstream (Evan is a DD), > but it's been kinda stuck lately. The git repo in collab-maint included > upstream's repo, so I decided it would be cleaner to create a new one > with just debian stuff, which is currently here[2]. AFAICS the only > thing missing for a first upload is the debian/copyright file, but since > I've been pulling some late shifts for debian work lately, the chance is > pretty high I forgot something important. > > And since I'm already on the subject: I also have a couple of RFAs for > packages which probably deserve removal in the long run, but in case > there's anyone interested... I'll have a look and see if it's anything I'm interested in, and capable of adopting. Regards Andreas Noteng > > > Cheers > > [0] http://packages.qa.debian.org/t/transmission.html > [1] http://bugs.debian.org/491723 > [2] git://git.debian.org/~costela/public_git/statusnet.git > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJNtX+iAAoJELRG7qgympRaWmYP+wTmXRHKuZ0ZjtHhEmk4dAoZ 5aedCe29m/AZw9LWKKq2Up1E8/lupf6U1eIDtbm3NiDqPWnDCGwF1ph9i0YoLSIR 0vQXhi8nk6jhnaXEIDcV3fANTn5SkwHm/PSNG4XcrIJTTOJ+iDqFOfV+aUSaRWmR Pqj53rld9mrQWFpc/WlzjAnfXJER22EjHcPWYqwmC2uygAUkOwBmNzEmO1TyBg+M sjlNNU2B7Tm0Xtxv4uqJp8jIz3bpk/4OQmYUAAJQyNLYVrTucWDIo2l1GB4M2TDW mTLNlUXMMqehIRTRELwDHK3lHRYG8f9pLNAS16BYWMCnj7wWFHrQDLpYgWChmnR4 OQ2IXRSFXU50l6Cq3VCrneMJzZNYPv0q1wD7USCU58FK7XnymcEl2zCS/2Rhlpfc vSqCqySUd2nOkrZXR3iltAYtgAcldgGcRTFg0uH2qXW+g8ORUH+G1Cc0yr9iHYC2 txRHJ7IEZA/P/HVx1hOpv28EFSWVnP/VsQ1Fzj3vuqhBbemlDAeYU7HbhcY+yUH6 ehTHub3iCuA3SjsbVF/hixY/45Ni1fZhrBWxstj9hPdtPHbXX2vKbi4dgZGJkMGs RWMQDz5gS8FtnOcFkoQyCVhTK+UEZ8Cd7P575QM8IZQgYtphFJoQfqEIleuPkdpk Hlx5mt/yyayaLGybhMqw =6xlR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db57fa6.7090...@noteng.no
Minified javascripts in packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I have a question regarding the use of minified javascripts in pacakges. Of course these need to be accompanied by the proper source code, but is it acceptable to simply use already minified js that often accompany the source packages, as long as the source is also there? Builing (at least in an automated manner) stuff like for instance jQuery can be a pain in Debian since we do not have all the required tools [1]. I agree that this approach is not ideal, but as long as we don't have a working grunt i believe it is the most sensible approach. We don't build the lib ourself, but it is possible to download the source package and manually build if you're ok with installing software that is not in Debian. If we had multiple versions of the libs in Debian one could simply remove the minified js from the source and use the one in Debian, but at least in the case of jQuery the package in Debian is hopelessly outdated because of [1]. I have experimented a bit with using the old (pre grunt) build system for jQuery, and it seems to be possible, but to spend hours doing this kind of build system reinvetion for every lib upstream uses seems a bit silly to me. Regards Andreas Noteng [1]: https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVITFvAAoJELRG7qgympRaXXQQAKjP0TbJVANK+zGWDAGBM4aK SiTFdiQCuD2elDf5o3yD02DXrvL1mdpS1psf+8KT+52hCAl0sagFauD9NJ2Uv6uy me2RKznQC/1+pV1cO1LZBwMVggcb130Xhv6s468hVr/3Iqm3gdgG20HYbM7NNrme QZKxdgEstjeQyKIAukPf3nPRtzSIGQ3VJ6H7HEEhfSxXteB825ZYqjfhLJOGVhok RlpE6oWE4h8mb2N2ErqBkAqNR08BOkVXy+S2xNh6NnYVbc+ykIcEbRXUr5ueBTwi gOvXoj5fYHBbo5htA5Xeaf8jqocWDQCDZtZw5zrqWOLskhi/cMwzcc0hOtLrcrnS zBP7v+K392akI57fhvVu5TxYxtGwqkhG5rbyQqrLHMGLmUTypf6YcdAIrawRP4qY kx0P1xJ+0bVlmj+iZipmFafxLqG28ECmvEjsaYPLuLO59+uddpLcW5uhC023HuzH DLH6up/qnJ/1aIrCNx0fEEMiYBjy7kYXTKc9jRK/284lGZWitqjHmjM4Ry3bwCwg Vio6T7stnYI2EeoXZ6DT99jjTNon5bWc1zqFy86lbaDFH10jBlKAk3haZZiRSsm+ meeiSaROpi2ZOBU/Mk6/OWJiNylKNVHDerW9lAiso8q4p9N3NW4g60erM7GveJrp Nl0f+Cr4IGW6leyjNRsD =vY95 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55213170.6010...@noteng.no
Re: Minified javascripts in packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Den 13. april 2015 14:05, skrev Wookey: > +++ Ben Finney [2015-04-13 14:59 +1000]: >> Paul Wise writes: >> >>> On Mon, Apr 13, 2015 at 11:37 AM, Ben Finney wrote: >>> Can we agree, in the context of the original post of this thread: Rebuilding from source *is* a reasonable requirement, attainable with what we have today in Debian, for JavaScript works. > >> Right, I wasn't clear enough: I'm saying that despite all the >> other non-JavaScript cases brought up later in the thread, the >> requirement (build from source form, with only build dependencies >> also in Debian) applies just fine to JavaScript libraries. >> >> Can we agree on that? > > That seems eminently reasonable to me, yes. > > Wookey > Well then my question would be: Would the concatenated but un-minified javascript files be approved as source code? What I have done so far in my package is to include the concatenated but unminified js from the upstream (that would be my upstream's upstream) source tarball in debian/missing-sources. During package build i use uglifyjs (which is already in Debian) to place minified copies where the app I'm building expects them to be. As mentioned above, what constitutes preferred form of modification really is a question of who is doing the modification. Upstream uses the un-concatenated files, but personally, I would find it easier to modify one big file, at least for something interpreted like javascript. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVLWUSAAoJELRG7qgympRaF/0QAIONDrBE54kVamgiIEcJDwaO YdsXV9C1lz01/PC7yTu7qEam0YIsWScHkI/ltPuWzPCKgTrcGjJ8LAOT3fK9yyYL Dn7o8sBconHURHB1V9UAQ39IK2mEMVusYWC/W+4n0ZFQxG7gcje/umnmiftXgKfU Ds4nBm9l4CkIhoxA+3Y5yMnPlccph4GvHCVgBftbeopkRwsA4v0dPivxYGg4ZJ44 pFgdG6h0x5qO1E40bvX/GocOU9bKkKi+p26Tx1Pxz0oZJKYGv/5GFf4MkFf4BH9k zR3hg5m9NAYLKhEEdS5OqvCm/tsp7CI585L9HAtwXigEBHXoocEjHN6OEEqNJHIH 9fqsOdeBVBVkFKq2CrzNHAcRPo5NaLgIbTS3yBJm9F9YJVBuITeFtEl832aoZ8Wy BL8Fp22PlF2PTAuGSrZCYHh2RyLPWsevCHeBeR0Y9yH/q46BuuP+TxhQ1aD29GdT 0K5ebv0rZworZH1JXiaGk9fpXhHPUaTygxoYyMnUu60dKFQ5zbYkvPvhft8L5I97 1E/fxNPDSgNzAaREsOiM61IcLXajgrhowi9S8Tg/dSVaptSnKyHqE8L5ixiF1LH+ vP2KzwSwa4EBsLNEP39FWJ0XKs08jofKMUnNWa3VCP+hFGkVYjPhQhdJdMF4f21h oHtBOKlcyg/0Yjl++dW/ =xDcA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552d6512.7080...@noteng.no
Re: Minified javascripts in packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Den 15. april 2015 11:45, skrev Riley Baird: > While I still maintain my previous position that concatenated js > is DFSG-free, even if it is not what upstream requires, I'm just > wondering - what is your .orig.tar.gz? You might not need to repack > it if you can concatenate the files with a debhelper override in > d/rules. And you're still distributing source the way upstream > wants it, so everyone's happy. My upstream simply includes the minified copy of the js's, I exclude these files in a repacked tarball using the exclude field of d/copyright. This is no problem. My problem is that building the javascript libs the way upstream's upstream intended requires grunt. Guess I'll have to start over again and figure out how to manually concatenate the separate upstream files into one huge file. I can see how it makes sense, but it also seems like a lot of work for very little gain… Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVMAjpAAoJELRG7qgympRagfwP/2Rg2rEkDoQs8xA9wUybcJ/k Phj/LXGVg/wuvaZAT1ZFttMkEoHNBHbD1Q63xdslmy0oH6+W2VC7KaUNx5NvXE6H BQPzIb5m//7lqXZeGh0d2bems+QciuiRmwuTHRBMIvpYpHgc/L/FyhDB33tadMjx /a39l1Qhqnr9Xx+ZEdJJBroIxhwt6iuyhGO+XDdA6oOCk4qm+Ugff0z4mgoUTojr SXxglFyyFQ+jCkUgUnvqL5rv0GFLjO3SH+tKsxLVA+e2gsfWsF0cwMBbTlNAyzrQ ZOhb3RVzV6N5vw6bY+jA5MTOSWzUX8Y5+dyH72sZ7a8Q/tXgL/ox7UuDh7GXoeHk nEE18OtNRSIPH/7Y9hxfRANzJXohIXvJzkpM6C281xWqC6e8s2sh7ZRo6MCZjLEa ZoWW0Zgo5Cc8fMEnnp0QHpSo9n3uqhG/k/UiMLpznrt7anmxQtvHxSHJwNg1DLhh 5KimbrBeJnYAm3gjV1k4tYzZYqA05ea+xtc3sA5/6h7KkbQ/hsPAwp34Qpl2JGNR A7VPONYtOZyA8thBvFxbsYMtWa+AOI7W/0k51ne9gIlmqz2lWAuzM/mX4btxGHgx QDl/SlGaW2xOuLlvbQUSUO6sS/zkOsHtCoVVWbT73byRyU2+ON6Iomr5q4GMh7yI c8t5cl6PXdA57QQYgoap =BvwD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553008ea.8000...@noteng.no
Re: Minified javascripts in packages
Not really. Just use the information from the grunt config to build the single
file javascript using cat. It's a sub-optimal solution because it's a lot of
work for doing something upstream allready did, and we can't run the tests. It
was actually quite easy with jQuery, working with angular and angular-translate
now.
Please read the first post of this thread [1], work is allready underway on
packaging Grunt, but there are some dependency issues and som (hopefully solved
by now) licensing issues.
[1]: https://lists.debian.org/debian-devel/2015/04/msg00056.html
--
Andreas Noteng
> Den 17. apr. 2015 kl. 01.32 skrev Ian Jackson
> :
>
> Andreas Noteng writes ("Re: Minified javascripts in packages"):
>> Guess I'll have to start over again and figure out how to manually
>> concatenate the separate upstream files into one huge file. I can see
>> how it makes sense, but it also seems like a lot of work for very
>> little gain…
>
> So you propose to manually reimplement the needed build-time
> functionality, for which upstream expect to use grunt ?
>
> Wouldn't it be easier to package grunt ? Forgive me if I've missed,
> in this thread, the explanation of why that's difficult.
>
> Ian.
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/21808.18062.611515.955...@chiark.greenend.org.uk
>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2df0db4a-0741-4586-94df-c294af3e3...@noteng.no
Bug#940329: (no subject)
Package: wnpp Severity: wishlist Owner: Andreas Noteng * Package name: scantailor-advanced Version : 1.0.17~2019.08.16-1 Upstream Author : 4lex4 <4le...@zoho.com> * URL : https://github.com/4lex4/scantailor-advanced/ * License : GPL3+ Programming Lang: C++ Description : Interactive post-processing tool for scanned pages Scan Tailor is an interactive post-processing tool for scanned pages. It performs operations such as page splitting, deskewing, adding/removing borders, and others. You give it raw scans, and you get pages ready to be printed or assembled into a PDF or DJVU file. Scanning, optical character recognition, and assembling multi-page documents are out of scope of this project. The current scantailor package in Debain is removed from stable and testing due to it blocking QT4-removal (#875176). The project is not dead upstream, but development is going slow. Scantailor Advanced is a fork that uses QT5, and also includes some extended features.
