Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium
On 04/06/2015 12:24 PM, Jeroen Dekkers wrote: At Sun, 05 Apr 2015 22:12:02 +0200, David Douard wrote: Package: wnpp Severity: wishlist Owner: David Douard david.dou...@logilab.fr * Package name: libnacl Version : 1.4.2 Upstream Author : Thomas S Hatch tha...@saltstack.com * URL : https://libnacl.readthedocs.org/ * License : Apache 2.0 Programming Lang: Python Description : ctypes wrapper for libsodium This library is used to gain direct access to the functions exposed by Daniel J. Bernstein's nacl library via libsodium or tweetnacl. It has been constructed to maintain extensive documentation on how to use nacl as well as being completely portable. This package is a dependency for raet, the new transport layer for salt. I think it would be better to name the package python-libnacl to prevent confusion with nacl itself. In my current packaging repo, libnacl is the name of the source package. The binary packages are python-libnacl and python3-libnacl. But I'm ok to rename the source package so there is no possible confusion. -- David DOUARD LOGILAB Directeur du département Outils Systèmes +33 1 45 32 03 12david.dou...@logilab.fr +33 1 83 64 25 26http://www.logilab.fr/id/david.douard Formations - http://www.logilab.fr/formations Développements - http://www.logilab.fr/services Gestion de connaissances - http://www.cubicweb.org/ attachment: david_douard.vcf signature.asc Description: OpenPGP digital signature
Bug#781665: Mathicgb
Hi Doug, I noticed that you added a new line to SoB page and thus I had a look on the package wearing my mentors hat. Unfortunately it does not build due to two missing Build-Depends: The following packages have unmet dependencies: pbuilder-satisfydepends-dummy : Depends: libmathic-dev which is a virtual package. Depends: libmemtailor-dev which is a virtual package. Unable to resolve dependencies! Giving up... May be we need to start the chain of dependencies one step more back? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150406180456.gh29...@an3as.eu
Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium
On Sun, 05 Apr 2015 22:12:02 +0200 David Douard david.dou...@logilab.fr wrote: Package: wnpp Severity: wishlist Owner: David Douard david.dou...@logilab.fr * Package name: libnacl Version : 1.4.2 Upstream Author : Thomas S Hatch tha...@saltstack.com * URL : https://libnacl.readthedocs.org/ * License : Apache 2.0 Programming Lang: Python Description : ctypes wrapper for libsodium This library is used to gain direct access to the functions exposed by Daniel J. Bernstein's nacl library via libsodium or tweetnacl. It has been constructed to maintain extensive documentation on how to use nacl as well as being completely portable. This package is a dependency for raet, the new transport layer for salt. Would you consider including a brief note in the final package description saying This library is unrelated to Native Client (NaCl), the sandbox used in Chromium.? I've seen that particular confusion arise several times, particularly since people often want a library version of the Chromium NaCl sandbox. Thanks, Josh Triplett -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150406213720.GA8782@jtriplet-mobl1
Bug#772086: linrad
Hi Leif, On Mon, Apr 06, 2015 at 09:30:05PM +0200, Leif Asbrink wrote: I would avoid putting messages into your code that talk about specific distributions. Today such things are in the configure script. In case a uset selects for example to use a BladeRF, Linrad would try to load libbladeRF.so and if it fails the message is: Could not load library libbladeRF.so Did you run ./configure after installing this library? the configure script contains the information about how to install everything needed to the extent that I know about it. The hint at the end of the script is: Missing or not working libraries (non fatal.) For information, type ./configure --with-help Ok, cool. So what I usually do with Debian packaging is make sure all the options are compilied in unless there are insane options that only 3 people in the world are going to user ever. If you move to dynamic loading of libraries, then they would be made available in the build environment when building the package, but on the package itself the libraries would be Recommends instead of Depends (RPM doesn't appear to have anything similar to the Debian recommends, and I think autodependencies would pick up the libraries as Requires anyway, so I'm not sure dynamic loading helps with Fedora). This would mean that on Debian at least, linrad could be installed without optional extras if that is desired, though by default apt does install packages in Recommends. A message to tell you what is missing, and maybe a link to a webpage that explains where the package can be found for different distributions would be better. We don't want to make it harder for other distributions to package your code and a webpage can be easily updated with contributions from others after the package is released. Do make sure the URL can stay the same for a long time though. It would be nice if that URL could be managed by others. I have tested Debian, Ubuntu, Fedora, Suse, Mageia, Mandriva Slackware, PCLinuxOS, Gentoo and Sabayon. There are also a couple of hints for Mac OSX. I have failed to install several other distributions and I have not verified all the installation instructions in several years so there are probably many obsolete packages. Maybe this: echo Old Fedora: yum install libusb1-devel echo New Fedora: yum install libusbx-devel One or the other should install libusb-1.0.so but I guess the package name could have changed again?? Hmm. This is an interesting problem. What you really want is a distribution independent .so to package name lookup system. I'm not entirely sure how to solve this. OK. I post releases here occasionally: http://www.sm5bsz.com/linuxdsp/linrad.htm The development code is likely to contain new bugs now and then so packaging releases should be the appropriate strategy. Cool. When I filed the RFP bug in Debian I see I was looking at 04.02, but you've since released 04.05. This 04.05 release is the one that would be packaged most likely. Please read the entire text: It is free for anyone for any purpose. Copyright laws are complicated and to make sure I will not change my mind and claim copyright Linrad comes with the MIT license starting with version 03-45. By granting a very permissive license to anyone who has obtained a copy of Linrad there should be no doubt that the freedom to use linrad or parts of the code for any purpose will remain for ever. Use the code for any purpose means ANY purpose such as distribution, modification, etc. To further clarify the files come with the MIT license. There is a zz-COPYRIGHT.txt file containing the MIT license. This is the most free license I have found. Oops. Sorry, was reading in a hurry. Yep, no licensing problems here! Thanks, Iain. -- e: i...@fsfe.orgw: iain.learmonth.me x: i...@jabber.fsfe.org t: EPVPN 2105 c: 2M0STB g: IO87we p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49 pgpKFpsAICnLI.pgp Description: PGP signature
Bug#777000: Sponsor for limereg: Lightweight Image Registration
cc'ing sponsorship request to bugs.debian.org (see below). Package: git.debian.org/git/debian-science/packages/limereg.git Forwarded Message Subject:Sponsor for limereg: Lightweight Image Registration Date: Tue, 07 Apr 2015 00:36:02 +0200 From: Roelof Berg rb...@berg-solutions.de To: debian-scie...@lists.debian.org Hi, I'm new to Debian packaging and pepared everything to close my ITP #777000. I announced the location of the new files on debian-science-maintainers-requ...@lists.alioth.debian.org and I'm not shure what comes next. I might need a sponsor and will announce this on: https://wiki.debian.org/DebianPureBlends/SoB. Is there anything else I have to do now ? Somebody would like to sponsor this ? --- snip --- Package description: limereg V 1.3.1: Lightweight Image Registration, finds the alignment of two 2D greyscale images taken from different angles or views or points in time (rigid, analytical, derivative/optimization based, very fast (1s usually, kind of unique aproach), paper available at Springer JRTIP). It can either output the rigid registration parameters (angle and shift for the best detected overlay) or it can output the registered and/or difference image. The interface is ready for a registration-based subimage search with an optional stencil-map, this feature will come in the next upstream version. The interface is extendable to affine instead of rigid transformations, this is planned for an upcoming major release. The current version has one limitation: The image size must be square, that will be solved in the next minor release V1.4, then arbitrary aspect ratios will be supported. The packaging consists out of a library (liblimereg1, liblimereg-dev) that does the math and has no special dependencies. Furthermore there's a command-line tool (limereg) with UI and file in/output and depencencies to OpenCV. The library might be added to ImageMagick (under investigation, looks good) and maybe also to other frameworks like maybe OpenCV. Homepage: http://embedded-software-architecture.com/?p=183 --- snip --- Regards, Thanks Roelof
Bug#781665: Mathicgb
Hi Andreas, On 04/06/2015 01:04 PM, Andreas Tille wrote: I noticed that you added a new line to SoB page and thus I had a look on the package wearing my mentors hat. Unfortunately it does not build due to two missing Build-Depends: The following packages have unmet dependencies: pbuilder-satisfydepends-dummy : Depends: libmathic-dev which is a virtual package. Depends: libmemtailor-dev which is a virtual package. Unable to resolve dependencies! Giving up... May be we need to start the chain of dependencies one step more back? Yeah, I probably should have been a little more clear in my initial email to the list about mathicgb. It depends on mathic, which is also currently waiting for a sponsor, and memtailor, which I packaged not too long ago and is sitting in NEW. Both packages are available in git: ssh://anonscm.debian.org/git/debian-science/packages/mathic.git ssh://anonscm.debian.org/git/debian-science/packages/memtailor.git I've also attached a patch to for the Blends task list that adds these two (plus frobby, another Macaulay2 dependency I packaged earlier and is also in NEW). Thanks! Doug From 7f6d619890b0b014ee3d3da160c52f7b09efa23a Mon Sep 17 00:00:00 2001 From: Doug Torrance dtorra...@monmouthcollege.edu Date: Mon, 6 Apr 2015 16:30:19 -0500 Subject: [PATCH] Add frobby, mathic, and memtailor. --- tasks/mathematics | 2 ++ tasks/mathematics-dev | 4 tasks/tools | 1 + 3 files changed, 7 insertions(+) diff --git a/tasks/mathematics b/tasks/mathematics index 150f52d..883d8e7 100644 --- a/tasks/mathematics +++ b/tasks/mathematics @@ -147,6 +147,8 @@ Depends: qhull-bin Depends: mathicgb +Depends: frobby + X-Removed: Packages removed from Debian Depends: octaviz diff --git a/tasks/mathematics-dev b/tasks/mathematics-dev index 3e31003..6e384d2 100644 --- a/tasks/mathematics-dev +++ b/tasks/mathematics-dev @@ -210,3 +210,7 @@ Depends: python-pyoperators | python3-pyoperators Depends: libplb-dev Depends: libmathicgb-dev + +Depends: libfrobby-dev + +Depends: libmathic-dev diff --git a/tasks/tools b/tasks/tools index 8abb8b1..f96dc7f 100644 --- a/tasks/tools +++ b/tasks/tools @@ -15,3 +15,4 @@ Depends: openstereogram Depends: xoscope +Depends: libmemtailor-dev -- 2.1.0
Bug#781928: marked as done (ITA: shtool -- portable shell tool from the GNU project)
Your message dated Tue, 07 Apr 2015 01:48:54 + with message-id e1yfidk-0008r4...@franck.debian.org and subject line Bug#781928: fixed in shtool 2.0.8-7 has caused the Debian Bug report #781928, regarding ITA: shtool -- portable shell tool from the GNU project 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.) -- 781928: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781928 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: wnpp Severity: normal The maintainer of the shtool is MIA. I am orphaning this package to adopt it soon. Thanks to William Vera for your work over this package. Regards, Eriberto ---End Message--- ---BeginMessage--- Source: shtool Source-Version: 2.0.8-7 We believe that the bug you reported is fixed in the latest version of shtool, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 781...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Joao Eriberto Mota Filho eribe...@debian.org (supplier of updated shtool package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 04 Apr 2015 20:50:27 -0300 Source: shtool Binary: shtool Architecture: source all Version: 2.0.8-7 Distribution: experimental Urgency: medium Maintainer: Joao Eriberto Mota Filho eribe...@debian.org Changed-By: Joao Eriberto Mota Filho eribe...@debian.org Description: shtool - portable shell tool from the GNU project Closes: 781928 Changes: shtool (2.0.8-7) experimental; urgency=medium . * New maintainer. Thanks to William Vera for your work over this package. (Closes: #781928) * Migrations: - Added cryptographic signature verification for upstream tarballs. - debian/copyright to version 1.0. - DH level to 9. - Using dh-autoreconf. * debian/control: - Added the Vcs-* fields. - Bumped Standards-Version to 3.9.6. - Improved the long description. - Removed the deprecated field 'DM-Upload-Allowed'. * debian/copyright: full updated. * debian/patches/: - fix-spelling.diff: added a new fix. - Updated the headers in all patches. * debian/rules: removed an unnecessary target override_dh_auto_install. * debian/shtool.docs: renamed to docs. * debian/watch: improved. Checksums-Sha1: ae2efa33872bc343365fe9175c7f4460c490073d 1827 shtool_2.0.8-7.dsc b5ce62b7cbafeef8884975eb3175588d0480f292 12464 shtool_2.0.8-7.debian.tar.xz a11c90ead20148bed61084686c7dbe8210f4ae71 134182 shtool_2.0.8-7_all.deb Checksums-Sha256: 50758fbc467290af0fb7f6520a9c1df9b482317a8038df35b9a297b6e0adca33 1827 shtool_2.0.8-7.dsc 386d8d2659afadf2341a02545945563e233f5eb88cb466ba5375044456ded1d6 12464 shtool_2.0.8-7.debian.tar.xz 2d7ded2adfa174ca70c26903541d1b85c2a29e1c4f4ec68285020e54df1a6573 134182 shtool_2.0.8-7_all.deb Files: fe0f84a6aa372250195c76f9cdb70e8e 1827 devel optional shtool_2.0.8-7.dsc 9d424637d6ee576d5e2a40e39883a3db 12464 devel optional shtool_2.0.8-7.debian.tar.xz 5f40a85459dd548d546e257f78a1bf46 134182 devel optional shtool_2.0.8-7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVIJEPAAoJEN5juccE6+nvFeAQAI9rVo6RRFpah8yHK0+v9NEZ tEj0mVAxCphulGVCg/oxl3Bp7oD6Rt+wJ6PbzQAjT+RoBb6FsDKJvHKNlHk9iZiT CF++GY3Uu+NN59wbR98nhlK8ddXODboH+qvTLZx2dJuvowBx7gzFWv9gBIvgc322 9MLiIpkJ9b1KTdTi7JHohBKWtKaUw4STLzf+uLQIM96jqWRgSBi7p8RwIJKPP5qx TC6vGTtBFR9igYytNFQaAQi5njGHI0vw3H41ISBDaIcoYNtrt1TjyXRNdh7Czj4c z1eDdujb1l28xFhTWuPFBtAtX9IfAS2wvq9KQ/NMsl12gDUrR9aMDKCjoKn5/bp4 Ngz3X0bP4dnFowfpg/GlDgyr00KKJMgumeYDRqCs1I8Zoio6IMinOAPfRxFrlKlw X8/d78s8WK8tJuQR4JzRlVLrKKSMTyQX6Z6tY8A69VJt/jgJTBYlBCDz8Sf7bBE+ W0mcAaC1UmV06hOj3AyxoAVyeBLawfdRbthzLS8qwYi4G54LI5V47wg943LjIf0E w95+TYMBbKo4ylIYJbMorGxPwV4toNPY7xFg5IplrXfG8u3pGtFVvq8K19cc6mgr J0/imVvIQbtUmTaZacUtyjqkK+pPnkD8HS02gjbQZJRO4Jv6le1QCxZNksVmyWxe 61xsvS8kyAas58WOS1Tf =XaLW -END PGP SIGNATUREEnd Message---
Bug#781993: ITP: raet -- RAET is a secure reliable scalable asynchronous message/event transport writen in Python
Package: wnpp Severity: wishlist Owner: David Douard david.dou...@logilab.fr * Package name: raet Version : 0.6.3 Upstream Author : SaltStack Team tha...@saltstack.com * URL : https://github.com/saltstack/raet * License : Apache 2.0 Programming Lang: Python Description : RAET is a secure reliable scalable asynchronous message/event transport writen in Python RAET is designed to provide secure reliable scalable asynchronous message/event transport over the internet in a micro-threaded multi-process application framework that uses UDP for interhost communication and LibSodium for authentication, encryption and the CurveCP handshake for secure bootstrap. It's one of the 3 transport layers supported by salt. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150406080256.22621.13231.report...@perseus.logilab.fr
Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium
At Sun, 05 Apr 2015 22:12:02 +0200, David Douard wrote: Package: wnpp Severity: wishlist Owner: David Douard david.dou...@logilab.fr * Package name: libnacl Version : 1.4.2 Upstream Author : Thomas S Hatch tha...@saltstack.com * URL : https://libnacl.readthedocs.org/ * License : Apache 2.0 Programming Lang: Python Description : ctypes wrapper for libsodium This library is used to gain direct access to the functions exposed by Daniel J. Bernstein's nacl library via libsodium or tweetnacl. It has been constructed to maintain extensive documentation on how to use nacl as well as being completely portable. This package is a dependency for raet, the new transport layer for salt. I think it would be better to name the package python-libnacl to prevent confusion with nacl itself. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d23ha71n.wl%jer...@dekkers.ch
Bug#781765: ITP: graph-tool -- Python library for network (graph) analysis
On 06.04.2015 08:55, Andreas Tille wrote: Hi, On Fri, Apr 03, 2015 at 10:27:43AM +0200, Daniel Stender wrote: On 02.04.2015 23:43, Iain R. Learmonth wrote: Hi, On Thu, Apr 02, 2015 at 11:25:44PM +0200, Daniel Stender wrote: * Package name: graph-tool If it is a python library/module, should't it be in the python- namespace ? Sorry, I've forgot to mention, the binary would be: python3-graph-tool. Hmmm, this sounds unusual as well to me. Could you please clarify whether it is a python3 module or rater a user oriented application? In case of the later please stick to graph-tool as the binary name. For user applications it does not make any sense to add the programming language to the package name. graph-tool is a python module, not a user oriented application. Best, Tiago -- Tiago de Paula Peixoto ti...@skewed.de signature.asc Description: OpenPGP digital signature
Bug#781765: ITP: graph-tool -- Python library for network (graph) analysis
Hi, On Fri, Apr 03, 2015 at 10:27:43AM +0200, Daniel Stender wrote: On 02.04.2015 23:43, Iain R. Learmonth wrote: Hi, On Thu, Apr 02, 2015 at 11:25:44PM +0200, Daniel Stender wrote: * Package name: graph-tool If it is a python library/module, should't it be in the python- namespace ? Sorry, I've forgot to mention, the binary would be: python3-graph-tool. Hmmm, this sounds unusual as well to me. Could you please clarify whether it is a python3 module or rater a user oriented application? In case of the later please stick to graph-tool as the binary name. For user applications it does not make any sense to add the programming language to the package name. The source package should still be python-graph-tool really. Unless it's a standalone application on its own, it helps to keep things tidy. That's a point. All right. Or you stick to your original source package name graph-tool which sounds fine for an application package. As an additional hint: The package sounds like interesting for the Debian Science project. Please check whether it might fit into one or more tasks out of http://blends.debian.org/science/tasks/ Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150406065532.gd29...@an3as.eu
Processed: wine-gecko can be built on any architecture with gcab and msitools
Processing control commands: block 738368 by 757007 Bug #738368 [src:wine-gecko-2.21] wine-gecko-2.21: FTBFS: unable to find wine executable: the wine32 package probably needs to be installed. Bug #768734 [src:wine-gecko-2.21] wine-gecko-2.21: FTBFS in jessie: mcom_db.h:41:21: fatal error: prtypes.h: No such file or directory 738368 was not blocked by any bugs. 738368 was not blocking any bugs. Added blocking bug(s) of 738368: 757007 768734 was not blocked by any bugs. 768734 was not blocking any bugs. Added blocking bug(s) of 768734: 757007 -- 738368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738368 768734: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b738368.142832215922835.transcr...@bugs.debian.org
Bug#782009: ITP: python-gwebsockets -- websocket server written in Python
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: python-gwebsockets Version : 0.4 Upstream Author : Daniel Narvaez dwnarv...@gmail.com * URL : https://github.com/dnarvaez/gwebsockets * License : Apache-2.0 Programming Lang: Python Description : websocket server written in Python gwebsockets is a websocket server written in python. . It uses GIO for network communication and hence easily integrates with the GLib mainloop. Packaging will be maintained in the OLPC team. Package is needed by recent sugar-* (binary package python-jarabe-*). -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVIneQAAoJECx8MUbBoAEhT80P/1aOqvFI2DAecFnUnHiVlV4T klyQ7FFIqY9IbbaOHZK+62RYJ8riWdARg90ivyO6m5Ac5d09UC/G2sE/GBHYymBS H4Dn6GKjkymEJEjST780GOnOehm1eDUkELG7ZARrCzCbNvlt1DGWpo2NpNjz0Ttm 28QSNj4M/tiLjmI5LOWC48/HyTWaj9EOTO9lxw2Y3WRiZV+XdZIijfSWy37kyQxu VedN72XXbqasCCClD+XnEzCErhDFKWw/mQjazvRMuoUp4UXr5/tGkKH4z9oEfH0B Z5N1+jR2GXyqOJ+xwIpDXJQ2c4JxmIvt97gyCLI5ObByEWfNtCwz4yd0o72Xnx3g xIL6IyaUrmeqaXKG80uzq2RaCSSNkE8FLWG6iH/BQ5S2HXxucMItAksixKJUJkfN zXFshpTCgTVmltGOVpqEb7XtvchjpyWF8JDiCg/ML6cia0vrWbKrnB5q5OIpm7Jp z/DLmXTIMgXDr/51fFCz0m5Z8MerEaQgPETrvSzRUMwgKLFjjE3/xVJq1P4rRtJz LgTqvI3CoaQmcEzxLuMYPolBQWka2WtfUwrx6Tkk2tDoQ4Wyc71L6HFSXrzdhvsd 6XfuIaKmq43kuHyFQm+l87Dsl7RfeD3fixceC9XNr8A2wbQoInArKNDFcbCSkiHs nPfRdGJf8+XcMT+w6ei3 =QCMg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150406120955.28216.86537.report...@bastian.jones.dk
Bug#772086: linrad (was Re: Self Introduction: Iain R. Learmonth)
Hi Leif, On Mon, Apr 06, 2015 at 04:58:07AM +0200, Leif Asbrink wrote: I am the developer of Linrad, a multi-OS package (originally Linux only) that provides a SDR (software defined radio) that can be used with a large number of hardware. I do not know what might be required for a software to be acceptable to become a package in Fedora (or Debian) and my feeling is that Linrad might not be acceptable today. Awesome! I came across linrad when looking for new software to include in Debian. I filed a RFP (request for package) bug there and this bug has been adopted already. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772086 When this is packaged in Debian, I would be happy to take a look at porting the package to Fedora. I am however working on making it independent of other packages by having libraries loaded at run-time. This means that Linrad would always work, but if the user asks for some particular hardware, there would be an error message telling what package to install to get access to the hardware. Many such packages have to be installed from source, but some of them are in the repos of the main Linux distros. I would avoid putting messages into your code that talk about specific distributions. A message to tell you what is missing, and maybe a link to a webpage that explains where the package can be found for different distributions would be better. We don't want to make it harder for other distributions to package your code and a webpage can be easily updated with contributions from others after the package is released. Do make sure the URL can stay the same for a long time though. Linrad has a reputation of being difficult to install, which is utterly false! Using it properly is non-trivial however since the user needs some knowledge of radio although many seem to think they need computing skils. I've not actually used linrad myself, so I can't comment on any experiences, but one of the aims of packaging is to remove the need for users to have to go through the installation themselves. Sane defaults are compiled in and the package should be ready to use once it is installed. At the moment I am working on the transmit side. The Linrad speech processor runs with a delay of about 50ms from microphone to antenna and then there is about 20 ms from antenna to loudspeaker. The total is less than 100 ms which makes it possible to use single frequency duplex, listen between words in ssb mode. This sounds really cool! Another line of development is by Jürgen Kahrs who is developing software to move FFT computations to OpenCL to use GPUs for faster processing. This also sounds really cool! You can read about linrad here (and find a link to videos) http://www.sm5bsz.com/linuxdsp/linrad.htm This is good. That's the URL I had on the RFP bug so I know we're both looking at the same thing. There is a repo. Download like this: svn checkout https://svn.code.sf.net/p/linrad/code/trunk linrad Ok, cool. We normally aim to base our packages on releases, but having a link to the upstream development codebase is always useful so we can check to see if you've already fixed things if we find things are broken. In case you think Linrad could qualify for a Fedora package, please tell me what might be necessary to change. Today Linrad comes in several flavours: linrad, xlinrad, flinrad, linrad64, xlinrad64, flinrad64 and clinrad. This will be changed. In a longer time-scale there is no need to support 32 bit code on 64 bit platforms. The three different flavours for each platform will be merged to a single program with a user option to select what kind of screen he wants (x11, svgalib or fbdev) to the extent they are available. This means there would be just one executable - although different on different platforms like clinrad which currently works with X11 only on the platform where it was compiled with cmake. So, on the website it says Linrad and watzo are free software. They are free for anyone to use for any purpose. which worried me slightly, but I see there is a LICENSE file in the Subversion repository. Does this license apply to all files in the source repository? The reason that worried me is that for Debian and Fedora we require not only that software is free to use, but also other rights such as distribution, modification, etc. * http://www.debian.org/social_contract#guidelines (for Debian) * https://fedoraproject.org/wiki/Licensing:Main#SoftwareLicenses (for Fedora) Licensing is one of the bigger problems we can have when it comes to packaging new software, but as long as that is not a problem then all it needs is some effort. It does also help that you are interested in the software being packaged. (: Dear Iain, if you find the Linrad project interesting and if you or someone you know is interested in helping to make it fit to become a Fedora (or Debian or whatever) package, please have a look at the repo and tell me what would
