Bug#723160: ITP: libcatmandu-rdf-perl -- serialize RDF data for Catmandu framework
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libcatmandu-rdf-perl Version : 0.02 Upstream Author : Jakob Voß * URL : https://github.com/nichtich/Catmandu-RDF * License : Artistic or GPL-1+ Programming Lang: Perl Description : libcatmandu-rdf-perl Catmandu provides a suite of Perl modules to ease the import, storage, retrieval, export and transformation of metadata records. . Catmandu::RDF contains modules for handling RDF data within the Catmandu framework. -- 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/20130917000446.20661.56692.report...@auryn.jones.dk
Bug#723158: ITP: libplack-middleware-assets-railslike-perl -- bundle and minify JavaScript and CSS files
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libplack-middleware-assets-railslike-perl Version : 0.12 Upstream Author : Yoshihiro Sasaki * URL : https://github.com/ysasaki/p5-plack-middleware-assets-railslike * License : Artistic or GPL-1+ Programming Lang: Perl Description : bundle and minify JavaScript and CSS files Plack::Middleware::Assets::RailsLike is a middleware to bundle and minify JavaScript and CSS (including Sass and LESS) files like Ruby on Rails Asset Pipeline. -- 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/20130916235422.20619.68157.report...@auryn.jones.dk
Re: Biological data being used by an unpublished research paper is considered proprietary
Jeff Epler writes: > Under US law, it may be the case that violating website terms of > service is a felony crime with jail time attached. The USA Federal courts have made it clear that this is not the case. As far as I know there have been no convictions or even prosecutions under this theory. A casual reading of the legislative history of this (execrable) law indicates that it was not the intent of Congress to criminalize such things as violation of TOS. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- 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/87li2wyeuh@thumper.dhh.gt.org
Re: detecting autopkgtest
On Mon, Sep 16, 2013 at 03:08:12PM +0200, Jakub Wilk wrote: > >But maybe a more polite way would be to ask something like `adt > >--is-running` and let adt implement it as it likes. > > There's a hidden assumption here that adt is the only thing that > will ever run the tests. Correct me if I'm wrong, but given http://dep.debian.net/deps/dep8/ any implementation of DEP8 should define ADTTMP, sadt included. The variable name may be badly chosen, since it is named after a particular test runner. But this seems to be another issue, right? Cheers -- Enrico Tassi -- 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/20130916144224.GA23680@birba.invalid
Re: Biological data being used by an unpublished research paper is considered proprietary
It looks like both you and the site you wish to access are based in France, so please forgive this US-centric intrusion. Under US law, it may be the case that violating website terms of service is a felony crime with jail time attached. https://www.eff.org/deeplinks/2013/01/rebooting-computer-crime-law-part-1-no-prison-time-for-violating-terms-of-service Based on the scenario you describe, and if the communication passed through a system under US jurisdiction, you might be in violation of this stupid law. Jeff signature.asc Description: Digital signature
Re: changes in python packaging
Jakub Wilk wrote: > * Steve Langasek , 2013-09-15, 13:54: >>> I'm having problems with one of my packages that includes a python >>> module. The package is vips. I am not a python person, so this may >>> be simple. >>> >>> The last time I built the package, there were several module binary >>> files that got installed appropriately. For example: >>> >>>% dpkg --listfiles python-vipscc| grep vmaskmodule.a >>>/usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a >>>/usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a >> >> Well, to start off, this doesn't look correct at all. Python >> modules are never .a files; these appear to be spurious static >> builds of the modules because you're using a non-pythonic build >> system that assumes it's appropriate to build both shared and static >> versions of "libraries". But these are not libraries, they're DSOs; >> you should not ship these .a files in your package. > > ACK > > You might want to try out lintian4python, which emits: > > w: python-vipscc: static-extension > usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a > w: python-vipscc: static-extension > usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a > > . . . Good to know about. Thanks. Thanks to both of you for the helpful responses. This makes perfect sense...while I'm not much of a python programmer (I did one decent-sized python project in 1997 or thereabouts), I can see that there would be no use for a .a file by a python program. I already have other stuff in my rules file to get rid of some other files that vips installs that we don't want. I'll just tweak the rule to remove the appropriate .a files as well. -- Jay Berkenbilt -- 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/20130916100632.0254824885.qww314...@jberkenbilt-linux.appiancorp.com
Re: changes in python packaging
* Steve Langasek , 2013-09-15, 13:54: I'm having problems with one of my packages that includes a python module. The package is vips. I am not a python person, so this may be simple. The last time I built the package, there were several module binary files that got installed appropriately. For example: % dpkg --listfiles python-vipscc| grep vmaskmodule.a /usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a /usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a Well, to start off, this doesn't look correct at all. Python modules are never .a files; these appear to be spurious static builds of the modules because you're using a non-pythonic build system that assumes it's appropriate to build both shared and static versions of "libraries". But these are not libraries, they're DSOs; you should not ship these .a files in your package. ACK You might want to try out lintian4python, which emits: w: python-vipscc: static-extension usr/lib/python2.6/dist-packages/vipsCC/vmaskmodule.a w: python-vipscc: static-extension usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a Now when I rebuild the package with no changes at all, I get something like this: % dpkg --contents python-vipscc_7.34.2-1_amd64.deb| grep vmaskmodule.a -rw-r--r-- root/root 1127858 2013-09-15 09:33 ./usr/share/pyshared/vipsCC/vmaskmodule.a lrwxrwxrwx root/root 0 2013-09-15 09:33 ./usr/lib/python2.7/dist-packages/vipsCC/vmaskmodule.a -> ../../../../share/pyshared/vipsCC/vmaskmodule.a Okay, this example shows a newer version of the package, but when I rebuild the exact same version as before, I get the same result. This looks like a change in the python helpers, yes, probably to handle moving/symlinking of files other than .py or .so that some python modules include and expect to be present in their directory. So this is a change from whitelist handling of files with a .py extension, to blacklist handling of files with a .so extension. My understanding is that .a files used to be kept in /usr/lib because their contents varied with Python versions, so they couldn't be shared. Now that only one version of Python is supported, there's nothing to keep them there... The .a files are ending up in the "wrong" place because dh_python isn't treating them specially... because they're not special for python, they're extraneous files to be deleted. ...because they're indeed not special-cased. -- Jakub Wilk -- 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/20130916131831.gb9...@jwilk.net
Re: detecting autopkgtest
* Enrico Tassi , 2013-09-16, 11:20: Looking at the doc of adt-run, the only observable difference seems to be the presence of ADTTMP. Indeed. But maybe a more polite way would be to ask something like `adt --is-running` and let adt implement it as it likes. There's a hidden assumption here that adt is the only thing that will ever run the tests. I, for one, am a happy nonuser of the autopkgtest package. I either run the tests manually or via sadt (see #712095). -- Jakub Wilk -- 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/20130916130812.ga9...@jwilk.net
Re: Biological data being used by an unpublished research paper is considered proprietary
On 16/09/2013 11:31, Faheem Mitha wrote: Hi, This is really not Debian-related, except insofar as the software in question is something that might have been in Debian one day. I talked about that with people on debian-med recently. So, it is technically off-topic. I posted a reply on stackexchange with instructions to get the data from the EBI SRS server. However, I have run into this issue before in the context of biological database entries and Debian so it may be worth discussing here. There were objections to including SwissProt entries in the example data for the EMBOSS package because the licensing of SwissProt does not allow them to be edited. That was resolved by agreeing that scientific facts should not be edited so that the files could be accepted as part of a Debian package even though they could not be changed. A fine compromise I feel. regards, Peter Rice EMBOSS team -- 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/5236f28f.2020...@yahoo.co.uk
Re: Accessing bug archives
On Sun, Sep 15, 2013 at 11:30 PM, Don Armstrong wrote: > > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=sponsorship-requests&archive=both > > lists all of the bugs. The oldest being #657303, and newer ones. > > If you give archive=yes, you only get archived bugs. > > Ok, I've verified that yes + "" = both, so the gap in the data is real. I hadn't realized that the effect of the freeze on unstable was so profound. Thanks for the pointer.
Re: Biological data being used by an unpublished research paper is considered proprietary
I am not a lawyer but I don't think facts are copyrightable. In some jurisdictions there are "database rights" and copyright on collections of facts (like phone books) that could apply here. I suggest you consult the lawyers for your research institute for the legal situation in your jurisdiction. The script thing sounds silly and easy to work-around - fake the user-agent and put a few seconds between requests. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6ets4u6oykxfmoe3u1dofmo8jjehiwu_sgcagv500o...@mail.gmail.com
Biological data being used by an unpublished research paper is considered proprietary
Hi, This is really not Debian-related, except insofar as the software in question is something that might have been in Debian one day. I talked about that with people on debian-med recently. So, it is technically off-topic. However, I thought that maybe people on these lists would have some input on the matter. People in Debian are very experienced in matters of copyright and licensing, and people in debian-med presumably know something about copyright/licensing of biological data. I posted the following to academia.stackexchange.com, http://academia.stackexchange.com/q/12718/285 As I write there is one reply. Summary of my SE question: 1) A distributor of biological data is claiming proprietary ownership of the data. This runs contrary to what I know about such data. Can anyone comment? 2) The distributor also says a script to download the (200) data files is prohibited. Saying I cannot use a script to download the data (curl in my case) is in IMO downright bizarre. Is expecting a user to download 200 files manually reasonable, and how would the server tell the difference anyway? They're all just http requests. Please CC me on any reply. Thanks. Regards, Faheem # http://academia.stackexchange.com/q/12718/285 # This question may be too specialist to be on-topic here. In which case, please feel free to transfer it to another SE site, or close, as appropriate. I am planning to publish an applied statistics paper. This paper develops an algorithm and then applies this algorithm to some data. I obtained most of this data from the site http://www.imgt.org. The data I am using are immunoglobulin and T cell receptor nucleotide sequences, in the form of FASTA files. I'm using around 200 of these. Here is an [random example][1] of the data I am using (click on [6 Sequence (FASTA format)] to get the FASTA file). Now, I have a problem. In [Warranty Disclaimer and Copyright Notice](http://www.imgt.org/Warranty.html), is written The IMGT® software and data are provided as a service to the scientific community to be used only for research and educational purposes. Individuals may print or save portions of IMGT® for their own personal use. Any other use of IMGT® material need prior written permission of the IMGT director and of the legal institutions (CNRS and Université Montpellier 2). I just heard from Prof. Marie-Paule Lefranc and she replied: I have no objection that the data you retrieved for your work from IMGT/LIGM-DB be made available to the reviewers, but unfortunately we cannot authorize a script or a distribution of the IMGT/LIGM-DB files with your code to the users. You can provide the users with the list of the IMGT/LIGM-DB accession numbers you used, with the source of the data clearly identified: (IMGT/LIGM-DB version number) and reference to NAR 2006. Well, this just made my life more difficult. To start with, I'm puzzled by this. Isn't biological data like this public domain? Is it really possible to treat immunoglobulin and T cell receptor nucleotide sequence data as proprietary information? I just wrote back and asked Prof. Lefranc what license the data was published under, which I had not done earlier. Additionally, how does one make data available to reviewers and not to users? That is awkward, to say the least. ##
Re: Accessing bug archives
On Sun, Sep 15, 2013 at 11:16:40AM -0400, Dave Steele wrote: > I was interested in doing some ongoing analysis of historical RFS > processing, and ran into trouble getting the archived bug information. One option I didn't see mentioned in this thread is the rsync method documented here: http://www.debian.org/Bugs/Access (This does mean parsing the raw files yourself.) -- Colin Watson [cjwat...@debian.org] -- 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/20130916102057.ga2...@riva.ucam.org
Re: [PATCH] netplug - Allow to specify custom script file via param '-s'
On Monday 16 September 2013 00:35:52 Paul Tagliamonte wrote: > On Mon, Sep 16, 2013 at 12:15:20AM +0200, Pali Rohár wrote: > > Bump. Is there any problem? > > Hey there Pali, > > First of all, thank you for your hard work and persistence - I > admire that a great deal! Keep that up! > > > One interesting thing with Debian is that DDs can't go into > another maintainer's package and change something (such as a > new feature or upstream release) without the maintainer's > consent. > > If you're able to get the maintainer of this package to sign > off on the patch, and ack a NMU against it, I'm sure any > number of us would be more than happy to sponsor the upload. > > However, doing this is frowned upon without the coordination > of the current maintainer - so that's a pretty needed first > step! > > > Thank you so much for your work! Let's get your changes in the > archive! Paul CCing Philipp Matthias Hahn, maintainer of netplug package. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: detecting autopkgtest
On Mon, Sep 16, 2013 at 11:00:01AM +0200, Niels Thykier wrote: > > I've many packages with a decent "test" target already, run at build > > time. In case this target is run by adt-run I want it to behave in > > a slightly different way. For exmample I don't want to set env > > variables so that non system-wide installed .so files are found, > > something really needed when running the tests at build time. > > Personally, I just added a small sh script to set a few ENV variables > then called the upstream test target (see [1]). I see, of course I could export my own WE_ARE_RUNNING_AUTOPKGTEST variable. But if there is already one that does the job reliably... I could use it, and others could do the same. I guess I'm asking for a standardized way of checking this. Looking at the doc of adt-run, the only observable difference seems to be the presence of ADTTMP. But maybe a more polite way would be to ask something like `adt --is-running` and let adt implement it as it likes. Any autopkgtest devel around? Cheers -- Enrico Tassi -- 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/20130916092047.GA31987@birba.invalid
Re: detecting autopkgtest
On 2013-09-16 10:38, Enrico Tassi wrote: > Hello, is checking for the environment variable ADTTMP the recommended > way to test if a test is being run by adt-run? It seems to work, but > I'd like to know if there is a better way or not. > > I've many packages with a decent "test" target already, run at build > time. In case this target is run by adt-run I want it to behave in > a slightly different way. For exmample I don't want to set env > variables so that non system-wide installed .so files are found, > something really needed when running the tests at build time. > > Cheers > Hey, Personally, I just added a small sh script to set a few ENV variables then called the upstream test target (see [1]). ~Niels [1] http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob;f=debian/tests/testsuite;h=8226c94f18c9007b74205263d0f2c61bcfdaed32;hb=beb1094db955fd99b693fca1e4c87958676dfe74 -- 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/5236c891.8080...@thykier.net
detecting autopkgtest
Hello, is checking for the environment variable ADTTMP the recommended way to test if a test is being run by adt-run? It seems to work, but I'd like to know if there is a better way or not. I've many packages with a decent "test" target already, run at build time. In case this target is run by adt-run I want it to behave in a slightly different way. For exmample I don't want to set env variables so that non system-wide installed .so files are found, something really needed when running the tests at build time. Cheers -- Enrico Tassi -- 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/20130916083857.GA27880@birba.invalid
