Re: Request for increased awareness: Open Source FPGA acceleration
Sounds really epic! I'm looking forward to check it out properly. Long live FPGAs! (Btw, aren't there any interesting news also about NoCs?) Matus On 2016-09-02 10:18, Steffen Möller wrote: Hi all, Those who participated in our past Sprint in Lyngby have met Ruben. He is the one who kindly packaged all that needed to be packaged for the first and yet only completely Open Source toolchain for FPGA computing. Details are on http://wiki.debian.org/FPGA/Lattice . Ruben started that page which takes you by the hand to get some LEDs blinking on a 20something $/€ device that attaches to your USB port. It features a series of I/O ports to do just about anything or just compute (i.e. accelerate) on the device itself. I got a "thank you for that page"-email yesterday (Ruben started it, I just added some references). It is about the first time this ever happened to me :o) Anyway, so it seems like there is some accumulating momentum and people are kind of uncertain about what to do. I tell you: There is no risk in spending those 25 $/€, which actually should be some 80 $/€ for a better performing 8K device. While I have little doubt that both for Xilinx and Altera we will also see something evolving in the near future (anybody tried to get a free webpack license for the only Spartan-6 compatible older ISE tools? something needs to happen on that front). The yosys/arachne-pnr/icetools packages of the free pipeline instantaneously sky rocketed to almost 140 users. Anyway - I think we are on the forefront of a significant movement here. This combination of free programming tools and cheap devices for programmable hardware is completely new. Please keep your eyes and ears open. There are closed-source implementations of Smith-Waterman on FPGA out there, not so much on BLAST. Those first devices do not have the memory to help much with accelerating sequence comparison - the usb port is too lame and there is not enough memory on the device to keep the data. But this is all just a matter of time. Hack along! And maybe make some noise with your engineers on site for whom a PCI/USB3 card with such an FPGA and a couple of gigs of memory on board is likely little more than a master thesis away. Cheers, Steffen
Re: Upgrading kissplice (Was: [med-svn] r22737 - trunk/packages/kissplice/trunk/debian)
Hi Andreas, Thank you for the swift answer and for your remarks. I will get to the upstream team to handle this python 2/3 issue and I'll look into autopkgtest next time. I also duly noted the use of cme fix dpkg-control I think in the end I will use a plain sid for packaging purposes Thanks again, David On 02/09/16 11:21, Andreas Tille wrote: Hi David, On Thu, Sep 01, 2016 at 03:19:14PM +0200, David Parsons wrote: I've just bumped kissplice to the latest version. Thanks for the update. It's been a long time since I last did any packaging so I may have forgotten some stuff, please feel free to yell at me ;-) Well, I interpret "yelling" as writing in public at the mailing list. ;-) I think what you mainly forgot is that we are doing public conversation which became even more important since we have more people than just me doing the sponsoring. For the actual packaging: * There was a d/changelog paragraph with a change but it was set to "UNRELEASED". I moved the change to the new paragraph. * It would be good if you would use the latest lintian from unstable which would have told you that the package should be conform to the latest Debian Policy version 3.9.8. So bumping the Standards-Version would have solved this. The recommended way is to do cme fix dpkg-control (Please see Debian Med policy document what packages to install to run cme successfully) * I added hardening+=all to deal with lintian infos In general I think I missed two issues in the initial packaging. While you added python3 to the Build-Depends and uses --with=python3 in d/rules this is useless since kissplice is not compatible with Python3. It would be good to do this Python3 conversion upstream - 2to3 could help in doing so. I also moved /usr/bin/kissplice to /usr/share/kissplice/kissplice.py and just set a symlink to /usr/bin. This enables the Python helper to create pyc bytecode at installation time and is the suggested method by the Debian Python team. I did all these changes and uploaded. One thing I would like to be added is an autopkgtest. While you are doing build time tests this is nice but it would be good to do this test separately from the build as well to test the actual package. It would be great if you would consider this for the next package. Kind regards Andreas.
Upgrading kissplice (Was: [med-svn] r22737 - trunk/packages/kissplice/trunk/debian)
Hi David, On Thu, Sep 01, 2016 at 03:19:14PM +0200, David Parsons wrote: > I've just bumped kissplice to the latest version. Thanks for the update. > It's been a long time since I last did any packaging so I may have forgotten > some stuff, please feel free to yell at me ;-) Well, I interpret "yelling" as writing in public at the mailing list. ;-) I think what you mainly forgot is that we are doing public conversation which became even more important since we have more people than just me doing the sponsoring. For the actual packaging: * There was a d/changelog paragraph with a change but it was set to "UNRELEASED". I moved the change to the new paragraph. * It would be good if you would use the latest lintian from unstable which would have told you that the package should be conform to the latest Debian Policy version 3.9.8. So bumping the Standards-Version would have solved this. The recommended way is to do cme fix dpkg-control (Please see Debian Med policy document what packages to install to run cme successfully) * I added hardening+=all to deal with lintian infos In general I think I missed two issues in the initial packaging. While you added python3 to the Build-Depends and uses --with=python3 in d/rules this is useless since kissplice is not compatible with Python3. It would be good to do this Python3 conversion upstream - 2to3 could help in doing so. I also moved /usr/bin/kissplice to /usr/share/kissplice/kissplice.py and just set a symlink to /usr/bin. This enables the Python helper to create pyc bytecode at installation time and is the suggested method by the Debian Python team. I did all these changes and uploaded. One thing I would like to be added is an autopkgtest. While you are doing build time tests this is nice but it would be good to do this test separately from the build as well to test the actual package. It would be great if you would consider this for the next package. Kind regards Andreas. -- http://fam-tille.de
Request for increased awareness: Open Source FPGA acceleration
Hi all, Those who participated in our past Sprint in Lyngby have met Ruben. He is the one who kindly packaged all that needed to be packaged for the first and yet only completely Open Source toolchain for FPGA computing. Details are on http://wiki.debian.org/FPGA/Lattice . Ruben started that page which takes you by the hand to get some LEDs blinking on a 20something $/€ device that attaches to your USB port. It features a series of I/O ports to do just about anything or just compute (i.e. accelerate) on the device itself. I got a "thank you for that page"-email yesterday (Ruben started it, I just added some references). It is about the first time this ever happened to me :o) Anyway, so it seems like there is some accumulating momentum and people are kind of uncertain about what to do. I tell you: There is no risk in spending those 25 $/€, which actually should be some 80 $/€ for a better performing 8K device. While I have little doubt that both for Xilinx and Altera we will also see something evolving in the near future (anybody tried to get a free webpack license for the only Spartan-6 compatible older ISE tools? something needs to happen on that front). The yosys/arachne-pnr/icetools packages of the free pipeline instantaneously sky rocketed to almost 140 users. Anyway - I think we are on the forefront of a significant movement here. This combination of free programming tools and cheap devices for programmable hardware is completely new. Please keep your eyes and ears open. There are closed-source implementations of Smith-Waterman on FPGA out there, not so much on BLAST. Those first devices do not have the memory to help much with accelerating sequence comparison - the usb port is too lame and there is not enough memory on the device to keep the data. But this is all just a matter of time. Hack along! And maybe make some noise with your engineers on site for whom a PCI/USB3 card with such an FPGA and a couple of gigs of memory on board is likely little more than a master thesis away. Cheers, Steffen
Re: otb is marked for autoremoval from testing
On Fri, Sep 02, 2016 at 08:32:07AM +0100, Ghislain Vaillant wrote: > > I sent one to Andreas (via email, cc'd) on the 25th when the bug was > originally submitted. I had commited it to SVN at this time. > It appears he has yet to submit a new release of the package. I can > prepare it if time is an issue on his end. pbuilder job is running while writing this. I just took your fix and did not inspected the one from Bas. Sorry Bas to steal your time by not tagging as pending properly (my tagpending failed due to a broken SMTP setup). Thanks for your offer anyway. Same as I wrote to Bas is true for you - simply team upload or NMU. Kind regards Andreas. -- http://fam-tille.de
Re: otb is marked for autoremoval from testing
On Fri, Sep 02, 2016 at 08:01:28AM +0200, Sebastiaan Couwenberg wrote: > > Debian Med, can someone fix the libminc RC bug regardless, I submitted a > patch for it recently because the same issue affected netcdf & pdal. > ismrmrd (#835679) has the same issue, and I've submitted a patch for it too. It was on my todo list for today. In case I will not manage please either NMU or team upload. Bas, as a general remark: If it happens you find a bug in a Debian Med package and have a fix for it, please simply commit it to VCS (any DD has write permissions) and either do a team upload or a NMU. That's more than welcome. Kind regards Andreas. -- http://fam-tille.de
Re: otb is marked for autoremoval from testing
On 02/09/16 07:01, Sebastiaan Couwenberg wrote: On 09/02/2016 06:39 AM, Debian testing autoremoval watch wrote: otb 5.6.1+dfsg-1 is marked for autoremoval from testing on 2016-10-08 It (build-)depends on packages with these RC bugs: 835400: libminc: FTBFS: convert.c:13:18: fatal error: hdf5.h: No such file or directory This makes no sense. otb doesn't have libminc in it's dependency chain, it does have insighttoolkit4 in its dependency chain which has its own RC bug: #835761 Debian Med, can someone fix the libminc RC bug regardless, I sent one to Andreas (via email, cc'd) on the 25th when the bug was originally submitted. It appears he has yet to submit a new release of the package. I can prepare it if time is an issue on his end. Cheers, Ghis
Re: Fix autopkgtest for fastqc
On Fri, Sep 02, 2016 at 12:03:49AM +0200, Dylan wrote: > I also pushed my change which should fix the test. Could someone > upload it to unstable? I'll do. Thanks for the fix, Andreas. -- http://fam-tille.de
Re: [outreachy] [profphd] Fwd: on Debian "profphd' upstream ChangeLog's entry
Hi Tanya, On Thu, Sep 01, 2016 at 11:21:24PM +0300, merlettaia wrote: > I've committed recent changes in profphd package. The work still in > progress, OK, so I will not upload yet. > I fixed patch because of following reason: $tmplen which is not initialized > might be undefined, and this causes error. > Initialization >$#tmpend=$#tmplen=1; > seems to eliminate the problem in correct way. > I took a small portion of perl code and wrote tiny and ugly script to see > this problem: In general it could be a good idea to discuss on Debian Perl list since problems like this might have been solved there before. > P.S. - Sorry if I wrote unclear, but my flight is postponed for the second > time and it makes me little nervous. Hope you had a good flight. ;-) > I described how I understand this > problem for now. I've also fixed small warning (several from other package > are left) and started to fix autopkgtest. For now basic tests should work > (I used profphd's script with some tests - but it seems to be outdated, and > I started to change it to separate autopkgtest instead). Just let me know if you consider the package ready for upload. Kind regards Andreas. -- http://fam-tille.de
