Bug#815224: ITP: osmo-pcu -- Packet Control Unit for GPRS
Package: wnpp Severity: wishlist Owner: Ruben Undheim * Package name: osmo-pcu Version : 0.2 Upstream Author : Jacob Erlbeck (Sysmocom) * URL : http://openbsc.osmocom.org/trac/wiki/osmo-pcu * License : GPL-2+ Programming Lang: C++ Description : Packet Control Unit for GPRS osmo-pcu is the Packet Control Unit (PCU) in the Osmocom GSM infrastructure. A PCU is one of the two GPRS elements in the BSS. It implements the RLC and MAC layers of the GPRS Um (radio) interface on the MS-facing side, as well as the Gb Interface (NS,BSSGP) on the SGSN-facing side. osmo-pcu should be in Debian in order to complete the inclusion of all the Osmocom software related to GSM base stations. I plan to maintain it as part of the Debian Science team.
Bug#815236: ITP: libatteanx-query-cache-perl -- experimental prefetching SPARQL query cacher
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libatteanx-query-cache-perl Version : 0.001 Upstream Author : Kjetil Kjernsmo * URL : https://metacpan.org/release/AtteanX-Query-Cache * License : Artistic or GPL-1+ Programming Lang: Perl Description : experimental prefetching SPARQL query cacher AtteanX::Query::Cache provides an experimental prefetching SPARQL query cacher. . SPARQL is an RDF query language, that is, a semantic query language for databases, able to retrieve and manipulate data stored in Resource Description Framework format. . Resource Description Framework (RDF) is a standard model for data interchange on the Web. The package will be maintained in the Debian Perl team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWyE/KAAoJECx8MUbBoAEhw5IP/3EZvP4nGGju5VUPHvkc4Acj fxaqQvPD9CREgGOtGvaypkFZJSorv5fKfX6uBw/qHavQnAd3cPCVuZAFKICarTvo r1VkbvLwRFBswcEjl2lRUbn/NXg0hMNuMKx32KHbWiG5kOngOEe11UvD5mKF1D/m 3JAVycD8Pg/l//ztairDywiUntU8kVpePSK2Fd6d9eOMJSlWQLlXoPHusB9VrIdu 4/5004IOQxSuK1H/AmX5zr2QTFNNwEYaD/UToAFE2kXrq+NO57R1wwAqzTVCbiWd ehl9oTZh2zv4VMLUHteFVF6+ulCsRUaAVEfi266qloiC6K/8OQUp7yBSzD6ubQ0G AWLXN6ilwDUHgrzykz4HD92/mq954PfUvSLdd3vu4T3Zd9mCUaqSBVgnW/MDUEGH N4q+yAKj1oNwL5c7KTRNG8kTTe2bTOkuRuutwis8bQXaqM6k4j2Kyec55tGCb5Cb JfF6ho/voIApHQ31hW50oCAYbudA8SEK09o13QRej25Na5OxpS0eXUFrt4QL/dQH ihjeVC8qLSSnnB33+XvyMx9wKFKbOya6sO4Q6pBW/FlgiXpBw13T0gO3CYGFBd9L 1VrgFyekWouX+wjEJhBi5PZ6LFtdW7qFq5cM+yg6Syzb3KnU4bdwspdx0zE270Kt 0N5bVCK9TfDROvIzKE4j =4+aQ -END PGP SIGNATURE-
Bug#815245: ITP: libatteanx-store-ldf-perl -- Linked Data Fragment RDF store
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libatteanx-store-ldf-perl Version : 0.01 Upstream Author : Patrick Hochstenbach & Kjetil Kjernsmo * URL : https://metacpan.org/release/AtteanX-Store-LDF * License : Artistic or GPL-1+ Programming Lang: Perl Description : Linked Data Fragment RDF store AtteanX::Store::LDF provides a triple-store connected to a Linked Data Fragment server. . Linked Data Fragment (LDF) is a protocol to exchange specific views of Linked Data. . Linked Data is a method of publishing structured data so that it can be interlinked and become more useful through semantic queries. It builds upon standard Web technologies such as HTTP, RDF and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers. . A triplestore or RDF store is a purpose-built database for the storage and retrieval of triples through semantic queries. A triple is a data entity composed of subject-predicate-object, like "Bob is 35" or "Bob knows Fred". . Resource Description Framework (RDF) is a standard model for data interchange on the Web. This package will be maintained in the Debian Perl team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWyFlTAAoJECx8MUbBoAEhB30P/08FIhna7Sp1Zz71j0OaE+ra eF2cc7dXBacCEMAGSbqSO56zr7aKhNKWVJ6cuwaERFoSBWjMRcX5GrqzGuG0BRVE +Rbep3B9ZPXz5CZqAouBh993OkaDYGDNs9PxntE53LSFQ9MRyHtUKMaMEq4BttEV WFjdseJiY7QaOPzGcRBzICITE8HrvxLkPt2BvawNtKvDGkYYyWJWChKIcECnv4R7 cuyDHXkfJ6q/llzKFTLXzVHaWLNTE5m1MoQ/Kjc8rvtOvVMkr7RFuGLAeoVrZGMH fmZfuYSMTAfsEzYW+lxw3nEs6yQXKZFCaRBG/y4sR5+ASkN7fsvBhCxRs5eOnWz8 hCFLtzNVJsDQuDjVTyeOEz/pXLGlpPpiwVkkGkJhV1d84rPQ+rgyfdiHM+nsJAPW pjcS6dOd+k9LpEQL2RpnrxJgoUHr4NlNjwk3EJG5jVDpeEaWcVyDqEq6a4TailQs d7ZJ2/S/fW652FaNdQIJzMKIcBMmJQUWqkXExl3vUo6J/CLN8axgspdDZqx1yPbq FBlDtPHNCWypzkZ+UtkChUHLYVjymNBboNJ1s51uiNxKfrUJrM9hgIRuChg5khFc g+o6WGvtq/RyoGV26PmjOkoloZA5jlUe71It6QBYOp/cbeAxdxytqwqUoTWO44KP 1xAr7UWP2PnUXZnzMlt5 =p90s -END PGP SIGNATURE-
Bug#815274: ITP: libtest-redisserver-perl -- redis-server runner for tests
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libtest-redisserver-perl Version : 0.20 Upstream Author : Daisuke Murase * URL : https://github.com/typester/Test-RedisServer * License : Artistic or GPL-1+ Programming Lang: Perl Description : redis-server runner for tests Test::RedisServer automatically sets up a Redis instance, and destroys it when the perl script exits. . Redis is a key-value database in a similar vein to memcache but the dataset is non-volatile. This package will be maintained in the Debian Perl team. It is needed for regression tests of libatteanx-query-cache-perl. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWyH4cAAoJECx8MUbBoAEhe4MP/32+EELvl6NA0dx60T/mQ5x7 LUPKkD91sp9yGc97LK1A9Rj8GQJ3XP5cMa9+oocWqmi6Z/eGx5qzYxDZpQbeBfE2 LAoLkMy7lMZXzLMGLPDl0xkquL+l+lZppb1q6CynlYJgHmn/G+XjDg9DuXAslWxL rT5+lESVCU7njo8HIN3iEPBn1SQoyfChL6Aom5dKurdTlrMmtkI6iGMS034yn0sR Nyb1fUGULXChPO5T5KFF433lO2QLzhD+zgfWELLDIky0jz4ZLLhIukGzTMV6j9Ky 1qmSibZzsIz8Xnwn8I2Qbk4FYWEREtSvO5LYYxLTdsydshTs/HMBlLEE3gez40nf eKp4XsIUKubgW45VCyhu/8rK9ry19WcTlBfLrK9QzWlEzFBxyaeCNcsGnmZoTGZk ly8TI8DqwWLonZ2wIlfCmprIgndskgGoR7JCavm01akoW+tT/ttRy8DnGzJ3ehtw RfuKZKm8HOJHqBYt6R3ykswiBbx7wjV9dlkzwCl2kZO1HXfSK89vQHd+rzVBXpLk ZoaIQecX5Azt4PrydpnJHnjKPNQe2tIFvzPqfWxZ0dFAL4/36/tVO3Mn2kFLi4oz zRhrK3ayDmoWRS3+x+KEff9wjhrYe58bHuCYs4sHv6CNfjyKzVOIYpX4NiOZM4DY MpnYINrPFcQGDy3VuGGi =He47 -END PGP SIGNATURE-
are -dbgsym packages supposed to be modified?
Hi, this is seen with the recent upload of the librevenge package. The maintainer scripts modify the librevenge-0.0-0-dbgsym package to include the gdb pretty printer files (around 10kB of python scripts). I got aware of this, because the package fails to build on Launchpad, not yet having the new dbgsym packages enabled. It probably will fail to build on other build infrastructures as well. I couldn't find anything in policy which allows or forbids modification of -dbgsym packages, but think it's worth to document this in policy whether the outcome is. While the pretty printers are not that useful without debug information, the size of these files compared to the library package (821kB) is sufficiently small that it could be including in the library package itself. Matthias
Re: are -dbgsym packages supposed to be modified?
On Sat, Feb 20, 2016 at 06:10:18PM +0100, Matthias Klose wrote: > this is seen with the recent upload of the librevenge package. The LibreOffice has that, too (even before librevenge had it). See last paragraph. > maintainer scripts modify the librevenge-0.0-0-dbgsym package to include the No, maintainer scripts not. debian/rules, yes. > infrastructures as well. I couldn't find anything in policy which allows or backports could have that disabled. As could other people who don't build -dbgsym. It's not magic, it's just commenting stuff out in debian/rules. > forbids modification of -dbgsym packages, but think it's worth to document > this in policy whether the outcome is. Indeed. > While the pretty printers are not > that useful without debug information, the size of these files compared to > the library package (821kB) is sufficiently small that it could be including > in the library package itself. No, they are for debugging. Thus they belong into -dbg (or in this case as we're migrating away from -dbg: -dbgsym). Either there or it isn't installed anymore anyway. (Which isn't a big loss, though) But yeah, I agree it should be documented whether it's allowed. When I asked Niels about that for LO (because the -dbg contained them and I didn't want to "regress") he said I was relying on debhelper internals and it could break (which it did one time, where I needed to adapt it to work again) but didn't say "don't do that"... Regards, Rene
Bug#815308: streamlining license version "or later" version syntax
Package: lintian Version: 2.5.30+deb8u4 X-Debbugs-cc: debian-devel@lists.debian.org Let's say that debian/copyright contains the following: Files: foo Copyright: 2016, Mr Foo License: GPL-2 Files: bar Copyright: 2016, Mr Bar License: GPL-2+ License: GPL-2 On Debian systems, the complete text of the GNU General Public License version 2 can be found in "/usr/share/common-licenses/GPL-2". Lintian will complain with a warning: W: libfoobar source: missing-license-paragraph-in-dep5-copyright gpl-2+ (paragraph at line X) Should lintian ignore the '+' suffix when determining if a License paragraph exists?
Re: [Mailman-Developers] Let's try to package mailman3 in Debian!
Pierre-Elliott Bécue wrote:
Hi Pierre,
> Before requesting for sponsorship, and packaging officially the other
> components of mailman3, I'd like some "testers" for the core package I
> built, in order to be sure that it works, and that I will not introduce some
> stupid caveats on the packaging of the other components.
>
> .deb can be found here: http://peb.pimeys.fr/mailman/mailman3-core/
> git repo can be found there: https://gitlab.pimeys.fr/PEB/mailman3-core
> and there: https://github.com/P-EB/mailman3-core
>
> Any volunteer welcome! Please, I need your help, I cannot review my work
> alone! :)
I just tried to have a look in a stretch docker image.
- There are three .deb files on your webserver
mailman3-core_3.0.0-1_all.deb
mailman3-core_3.0.0-3_all.deb
mailman3-core_3.0.0-3_amd64.deb
It is not immediately obvious which one to test, since -1 has actually
a newer timestamp.
- Mailman Core 3.0.1 and 3.0.2 have been released in the meantime
- it does not work on stretch/sid because it is not compatible with
Python 3.5, see https://gitlab.com/mailman/mailman/issues/181
- it does not install on Jessie (even with jessie-backports because of
missing dependencies) (just a note because of not working on stretch
either)
- The systemd unit won't work because the parameter for the
configuration file is '-C', not '-c'
- installing python3.4 and changing the shebang in /usr/bin/mailman
leads to the following error
root@4ca9477a166c:~# /usr/bin/mailman -C /etc/mailman3/mailman.cfg start
Starting Mailman's master runner
/usr/bin/python3.4: can't open file '/var/lib/mailman/bin/master':
[Errno 2] No such file or directory
The files are installed in /var/lib/mailman3/bin, but bin_dir in
/etc/mailman3/mailman.cfg points to /var/lib/mailman/bin ... both
directories are wrong from my POV, it should probably be
/usr/lib/mailman3 or something like that
- Fixing this up leads to
root@4ca9477a166c:~# /usr/bin/mailman -C /etc/mailman3/mailman.cfg start
Starting Mailman's master runner
Traceback (most recent call last):
File "/var/lib/mailman3/bin/master", line 9, in
load_entry_point('mailman==3.0.0', 'console_scripts', 'master')()
File "/usr/lib/python3/dist-packages/mailman/bin/master.py", line 536,
in main
with open(config.PID_FILE, 'w') as fp:
FileNotFoundError: [Errno 2] No such file or directory:
'/run/mailman3/master.pid'
because the directory does not exist. Since you are shipping a systemd
unit only you should probably ship a .tmpfile as well.
I now have a running daemon. I haven't done anything with Mailman3 so
far, so I need to read up on that first.
Bernhard
Re: How to handle JavaScript npm + gulp web GUI packaging?
On 02/12/2016 09:22 PM, Jonas Smedegaard wrote: > Quoting Thomas Goirand (2016-02-12 11:51:41) >> On 02/12/2016 05:23 PM, Jonas Smedegaard wrote: >>> Quoting Thomas Goirand (2016-02-12 08:27:12) I would like to package a web app which contains Javascript stuff, which are using npm + gulp (to disclose everything: I am packaging fuel-web). >>> >>> [details on dirty upstream build routines snipped] >>> I'd like to fix this in a better way so that Fuel can be fully uploaded to Debian main. How to make this all in a Debian policy compliant way? >>> >>> I suggest as first step to avoid cross-posting: I see no need for >>> involving all Debian developers in this - Javascript Maintainers >>> suffice. :-) >> >> I really thought it was of general interest, though I'm ok >> following-up only there (though see below...). > > I am confident that all especially interested in javascript packaging > are happy to subscribe to our javascript-specific mailinglist. > > So yes, please do follow-up there only. > > > - Jonas I'm register with *another* email address (which I use only for receiving lists), not with my @debian.org address. I tried to get in touch with team on IRC, but no reply so far. I BTW wonder if anyone is even monitoring the moderation message, and also, if @debian.org domain could be whitelisted (which is a feature of mailman admin). Could anyone in the PKG JavaScript team help and fix this situation? Cheers, Thomas Goirand (zigo)
Bug#815308: streamlining license version "or later" version syntax
Daniel Pocock writes: > W: libfoobar source: missing-license-paragraph-in-dep5-copyright gpl-2+ > (paragraph at line X) > > Should lintian ignore the '+' suffix when determining if a License > paragraph exists? Your position, if I understand correctly, is that the trailing “+” should not be considered part of the license name; it should instead be considered part of the license grant. That's a position I agree with. Perhaps we should progress bug#786470 https://bugs.debian.org/786470> and clarify the distinction between the license grant and license conditions. Lintian is presently doing the right thing according to the copyright format specification 1.0, I believe. The trailing “+” is not distinguished in that specification; a plain reading of the specification has that just as another character in the license name. Part of that revision to the specification should then be to make clear that the License-Grant field grants a set of licenses to the recipient; the License field specifies the effective license conditions on the work; and a trailing “+” is to be interpreted as a special non-name character that modifies the set of license conditions granted. I think the proposed change to Lintian would not be appropriate until after the change to policy's specification of the copyright file, to make explicit the effect of “+”. That policy change could be part of resolving bug#786470. -- \ “I used to be an airline pilot. I got fired because I kept | `\ locking the keys in the plane. They caught me on an 80 foot | _o__)stepladder with a coathanger.” —Steven Wright | Ben Finney
Bug#815387: ITP: python-attrs -- Python attributes without boilerplate
Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-attrs Version : 15.2.0 Upstream Author : Hynek Schlawack * URL : https://github.com/hynek/attrs * License : MIT Programming Lang: Python Description : Python attributes without boilerplate attrs is an MIT-licensed Python package with class decorators that ease the chores of implementing the most common attribute-related object protocol. attrs is the successor to Characteristic, and is a dependency of python-servicy-identity from 16.0.0.
