date:20130916

un stand Debian à OWF ?

2013-09-16 Thread Lucas Nussbaum

Hello,

Open World Forum (OWF, http://www.openworldforum.org) a lieu du 3 au 5
octobre à Paris (enfin, Montrouge, mais c'est juste à coté du
périphérique).

L'organisation d'OWF m'a contacté pour proposer un stand à Debian.

Y a-t-il des personnes motivées pour organiser la tenue d'un stand ?

Sylvestre Ledru a proposé de participer à la logistique (ramener les
cartons de Debian France, par exemple), mais ne pourra pas être sur le
stand.

Par le passé, OWF était une conférence très orientée business. Mais ils
cherchent à s'ouvrir vers la communauté, et le programme de cette année
est plutôt intéressant.

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130916143531.ga23...@xanadu.blop.info

detecting autopkgtest

2013-09-16 Thread Enrico Tassi

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

Re: detecting autopkgtest

2013-09-16 Thread Niels Thykier

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

Re: detecting autopkgtest

2013-09-16 Thread Enrico Tassi

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: [PATCH] netplug - Allow to specify custom script file via param '-s'

2013-09-16 Thread Pali Rohár

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: Accessing bug archives

2013-09-16 Thread Colin Watson

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

Biological data being used by an unpublished research paper is considered proprietary

2013-09-16 Thread Faheem Mitha



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: Biological data being used by an unpublished research paper is considered proprietary

2013-09-16 Thread Paul Wise

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

Re: Accessing bug archives

2013-09-16 Thread Dave Steele

On Sun, Sep 15, 2013 at 11:30 PM, Don Armstrong d...@debian.org wrote:



 http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=sponsorship-requestsarchive=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

2013-09-16 Thread Peter Rice


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: detecting autopkgtest

2013-09-16 Thread Jakub Wilk


* Enrico Tassi gareuselesi...@debian.org, 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: changes in python packaging

2013-09-16 Thread Jakub Wilk


* Steve Langasek vor...@debian.org, 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: changes in python packaging

2013-09-16 Thread Jay Berkenbilt

Jakub Wilk jw...@debian.org wrote:

* Steve Langasek vor...@debian.org, 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 q...@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/20130916100632.0254824885.qww314...@jberkenbilt-linux.appiancorp.com

1 2 >

1 - 100 of 111 matches

Mail list logo