Le Wed, Mar 28, 2012 at 09:10:53AM +0200, Andreas Tille a écrit :
When looking briefly at the code seems the spacy package names
(ncbi-blast , feel , gtk 3.0, getfem ) will also end up
in the umegaya database itself because you are using $package as
key. Can you verify this?
Hi Andreas,
On Wed, Mar 28, 2012 at 03:55:42PM +0900, Charles Plessy wrote:
The names in packages-metadata should be source package names, and I have
improperly used binary package names when parsing the blends task files.
One more item to add the TODO list...
I found another instance (besides probably
Le Thu, Mar 29, 2012 at 04:02:18PM +0200, Andreas Tille a écrit :
On Wed, Mar 28, 2012 at 03:55:42PM +0900, Charles Plessy wrote:
The names in packages-metadata should be source package names, and I have
improperly used binary package names when parsing the blends task files.
One more
On Thu, Mar 29, 2012 at 04:02:18PM +0200, Andreas Tille wrote:
On Wed, Mar 28, 2012 at 03:55:42PM +0900, Charles Plessy wrote:
The names in packages-metadata should be source package names, and I have
improperly used binary package names when parsing the blends task files.
One more item
On Thu, Mar 29, 2012 at 04:51:51PM +0200, Michael Banck wrote:
What if you want to have different publication data for different binary
packages, or exclude some binary packages from publication data?
Point in case would be openbabel, where the python bindings had a
dedicated publication, or
On Wed, Mar 28, 2012 at 10:30:59AM +0900, Charles Plessy wrote:
All of this is complicated and will be un-necessary once I have corrected the
bugs that lead to created the bogus files. If you prefer, please just ping me
once you finished your corrections, and I will push the update
After
Le Wed, Mar 28, 2012 at 08:36:02AM +0200, Andreas Tille a écrit :
After todays checkout at least those fixes I pushed yesterday where in. The
only thing I'm curious about is:
$ find packages-metadata -name *qtl.* | grep -v 'svn/'
packages-metadata/r/r-cran-qtl.upstream
On Wed, Mar 28, 2012 at 03:55:42PM +0900, Charles Plessy wrote:
The files q/qtl.* are outdated and I can not see how we can make them
vanish.
Oops, that is a bug.
The names in packages-metadata should be source package names, and I have
improperly used binary package names when parsing
Hi,
On Tue, Mar 20, 2012 at 11:17:07PM +0900, Charles Plessy wrote:
I agree with your propositions, but I would like to remind that roughly you an
me contribute the most to the upstream files, so let's agree that we can
revert
changes in a later phase where we have extended feedback.
As far
Le Tue, Mar 27, 2012 at 10:57:30PM +0200, Andreas Tille a écrit :
I moved your suggested Definition of the Reference field to the Wiki and
added the keys of the mapping (basically leaving out the Reference-).
I would suggest to call Reference-key from the list of supported
fields. Is this
On Sat, Mar 17, 2012 at 12:18:06AM +0900, Charles Plessy wrote:
Reference is not a field in the current specification. I think that this
illustrates well the current confusion about the format. In that sense, it is
not possible to answer to your question of what breaks by using nested
Le Tue, Mar 20, 2012 at 01:32:27PM +0100, Andreas Tille a écrit :
So we should go on with specifying it and I guess with this specification you
mean describing it at
http://wiki.debian.org/UpstreamMetadata
Hi Andreas,
I agree with your propositions, but I would like to remind that
Le Mon, Mar 12, 2012 at 05:11:00PM +0100, Andreas Tille a écrit :
I took the Reference field for granted because it was used heavily in
practice.
Hi Andreas,
Reference is not a field in the current specification. I think that this
illustrates well the current confusion about the format. In
On Tue, Mar 13, 2012 at 08:41:09AM +0900, Charles Plessy wrote:
I did not have time to read the rest, but I just checked the Git repository
and
I do not see your changes.
Sorry, writing mail *and* commiting stuff made me forgetting `git push`. This
weak is a bit short on time ...
It seems
Hi Charles,
just a short notice because I was quite occupied today!
On Sun, Mar 11, 2012 at 11:33:29PM +0900, Charles Plessy wrote:
According to http://wiki.debian.org/UpstreamMetadata, the two following
files would be equivalent:
---
Reference-PMID: 19854763
Contact: Manolo Gouy
Le Mon, Mar 12, 2012 at 05:11:00PM +0100, Andreas Tille a écrit :
I pushed the preliminary + untested code into
git://git.debian.org/git/users/plessy/umegaya.git
Hi Andreas,
I did not have time to read the rest, but I just checked the Git repository and
I do not see your changes. It
On Sun, Mar 11, 2012 at 12:42:38PM +0900, Charles Plessy wrote:
in the first round where I wrote the UDD importer you accepted the format I
proposed. Writing this importer by myself took me countless hours, as I did
not know Python programming, and as the handling of Unicode in the UDD was not
Hi again,
I am really frustrated. You pointed at problems, I worked to solve them, and
now you come again and again with the same story that the system is not
reliable. Please remember that 1) the bugs you report can be fixed and 2) no
program is ever prefect from the first release.
It is the
Hi Charles,
I'm very sorry that my work caused frustration on your side. This was
absolutely not intended. I strongly believed I would work on the same
goal as you and following your plan. Obviosely e-mails do not work
out as deescalation means and so I'm for the moment delaying my answer.
Le Sun, Mar 11, 2012 at 03:04:49PM +0100, Andreas Tille a écrit :
Hi Charles,
I'm very sorry that my work caused frustration on your side. This was
absolutely not intended. I strongly believed I would work on the same
goal as you and following your plan. Obviosely e-mails do not work
out
On Sat, Mar 10, 2012 at 02:37:43PM +0900, Charles Plessy wrote:
I agreed to provide flat files in a way that they can be parsed by anybody,
because I agree that such a repository has some value, especially since it
includes the copyright files as well.
Fully ACK.
But for feeding the UDD with
Hi Andreas,
in the first round where I wrote the UDD importer you accepted the format I
proposed. Writing this importer by myself took me countless hours, as I did
not know Python programming, and as the handling of Unicode in the UDD was not
so intuitive. Then you found bugs and decided to
On Fri, Mar 09, 2012 at 09:37:08AM +0900, Charles Plessy wrote:
I think that we need to discuss the general syntax of the file.
Initially, I thought it as limited to name: value fields like in Debian
control
data files. Then after adding many Reference-* fields, I found that syntax
boring
Just a short question regarding this job.
I followed quickly the mails regarding this task but what I'd like to
know is where will appear the bibtex/citation when everything is done?
Thanks
Olivier
--
gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4
6F83 D3B9 5204 6335
On Fri, Mar 09, 2012 at 09:33:29AM +0100, Olivier Sallou wrote:
Just a short question regarding this job.
I followed quickly the mails regarding this task but what I'd like to
know is where will appear the bibtex/citation when everything is done?
My main goal is to replace the citation
Hi,
On Thu, Feb 23, 2012 at 04:19:53PM +0100, Andreas Tille wrote:
May be I'm doing some to strong simplification - I just wanted to save
time and kept it short. But as I said we can work on the collecting
upstream files completely independently from the task to import those
files into UDD.
Le Thu, Mar 08, 2012 at 09:03:16PM +0100, Andreas Tille a écrit :
I just want to let you know that I wrote some code to parse upstream
files stored in the proposed directory layout and move references into a
UDD table featuring a rank column - so at least we can store more than
one
Le Fri, Mar 09, 2012 at 09:06:14AM +0900, Charles Plessy a écrit :
For adding a rank to the references, this may be a good idea, but how do you
propose to implement this in YAML ? Perhaps it would be simpler to keep
a single reference broken in YAML fields as it is now, and dump the rest in
On Fri, Mar 09, 2012 at 09:06:14AM +0900, Charles Plessy wrote:
On my side I made a first push to the collab-qa Subversion repository.
http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/
Great.
Still, I am disappointed that you ignore the rest of my work. I spent a lot
of
Le Thu, Feb 23, 2012 at 08:45:00AM +0100, Andreas Tille a écrit :
From my perceptions this case is one more prove for the fact that
debcheckout for our purpose is weaker than directly inspecting VCS
content.
Hi Andreas,
the two approaches have symmetrical flaws:
- VCS URLs may be wrong,
On Thu, Feb 23, 2012 at 05:51:59PM +0900, Charles Plessy wrote:
the two approaches have symmetrical flaws:
- VCS URLs may be wrong, causing some packages to be missed.
Currently we have a difference of about 30% missing upstream files and
we have not yet developed means to verify the
Hello Andreas!
I can not go into the technical details of this - it is beyond how much I can
commit now. And obviously you have to strike a balance between the
effort spent on this and its usefulness.
* I think I can live with only one reference per package. But this seems to be
a rather
Le Tue, Feb 21, 2012 at 05:23:47PM +0100, Andreas Tille a écrit :
Just to make sure I understood the suggestion correctly: You want to
create a Git repository keeping *copies* of the debian/upstream files
which are stored currently in VCSes of packages? Yes, this would very
easily solve my
On Fri, Feb 24, 2012 at 08:26:54AM +0900, Charles Plessy wrote:
perhaps surprisingly, I am considering Subversion in collab-maint for the
task.
I really like the svn cat command, that fetches a file without needing a
checkout or a web frontend, and in that case it may be useful sometimes.
Le Sat, Feb 18, 2012 at 07:40:41PM +0100, Andreas Tille a écrit :
On Sat, Feb 18, 2012 at 04:53:40PM +0100, Andreas Tille wrote:
I noticed this. I just verified the current data in UDD and noticed
that some packages are lacking information even if the upstream file
just has it (for
On Thu, Feb 23, 2012 at 09:55:55AM +0900, Charles Plessy wrote:
Further example: pynast is also lacking reference information.
$ debcheckout -d pynast
type svn
url svn://svn.debian.org/debian-med/trunk/packages/python-nast/trunk/
Should be:
[Laszlo explicitely in CC because I do not know whether you followed this
longish mails]
Hi,
On Mon, Feb 20, 2012 at 10:08:20PM -0500, Yaroslav Halchenko wrote:
The alternative approach could perfectly be to seek for files matching
/usr/share/doc/*/upstream
and do the BibTeX
Published-Authors: Alois Schlögl, Clemens Brunner
Published-DOI: 10.1109/MC.2008.407
Published-In: Computer, 41(10): 44-50
Published-Title: BioSig: A Free and Open Source Software Library for BCI
Research
Published-URL:
On Tue, Feb 21, 2012 at 08:56:13AM -0500, Yaroslav Halchenko wrote:
Published-Authors: Alois Schlögl, Clemens Brunner
Published-DOI: 10.1109/MC.2008.407
Published-In: Computer, 41(10): 44-50
Published-Title: BioSig: A Free and Open Source Software Library for BCI
Research
This might be a working idea - at least in principle. We can drop the
Published- prefix which was used in tasks pages but this system should
be replaced and I would like to focus on debian/upstream issues only.
In this scope it woul rather be:
Reference-Key
rright!
My problem by using
Hi Andreas and Yaroslav,
I started to write an answer this morning, but I can not keep up the rythm of
the discussion ! Below I wrap up what I drafted, and the summary is that I
will work on gathering the debian/upstream files in a single VCS on
collab-maint as well.
I will then focus on the
just a minor comment/thought:
The alternative is to store the data in a file outside the package. This is
what we do with our tasks files and the price to pay is that it is very
difficult to manage the package lists.
We could have an accessory file in
collab-maint for instance. Or a
On Tue, Feb 21, 2012 at 09:58:27AM -0500, Yaroslav Halchenko wrote:
For the task pages, you can indeed take the first or the last entry
I would like to drop the injection of references inside the tasks pages
at all in favour of debian/upstream.
IMHO it is well worth keeping references
Hi Charles,
On Wed, Feb 22, 2012 at 12:03:59AM +0900, Charles Plessy wrote:
I started to write an answer this morning, but I can not keep up the rythm of
the discussion !
:-)
I will then focus on the other points of the disucsion, in particular the
possible integration with Debhelper and
Hi Yaroslav,
On Tue, Feb 21, 2012 at 10:45:11AM -0500, Yaroslav Halchenko wrote:
now I started to wonder if debian/blends for blends-inject tool could be
somehow absorbed within debian/control,upstream tandem. For
not-yet-existing packages we just kept those blends files under
I wonder now, if I move blends listing into debian/control (e.g.
X-Blend-Tasks), then I think the rest of debian/blends is pretty
much the core for debian/upstream...
I feel that your suggestion has some potential but I fear I do not
understand your proposal. Could you provide some
On Tue, Feb 21, 2012 at 11:53:18AM -0500, Yaroslav Halchenko wrote:
e.g. ATM we have
$ cat brian/debian/blends
Source: brian
Tasks: debian-science/neuroscience-modeling
Depends: python-brian
Published-Authors: Goodman D.F. and Brette R.
Published-Title: Brian: a simulator for spiking
little clarification:
I agree this makes sense (even if I would prefer a s#/#,# to comply with
the usual komma separated syntax in debian/control files. However I have
no good idea about implementation.
komma is there to separate multiple task pages, e.g.
Tasks:
On Tue, Feb 21, 2012 at 12:23:00PM -0500, Yaroslav Halchenko wrote:
little clarification:
I agree this makes sense (even if I would prefer a s#/#,# to comply with
the usual komma separated syntax in debian/control files. However I have
no good idea about implementation.
komma is there
Le Mon, Feb 20, 2012 at 09:43:09AM +0100, Andreas Tille a écrit :
there are tools which assemble informations for Sources.gz files - I guess
this could be implemented if say 20% of the packages will contain such a
file.
In such a model, the packages need to be uploaded so that Sources.gz
dh_bibref
which turns debian/upstream data into a usable BibTeX database on the
users system. This is technically definitely not hard - it just needs
to be *done*.
The challenge will be to have it ran by default by Debhelper. But
I think that indeed it is the good direction. In
Hi Charles,
On Tue, Feb 21, 2012 at 01:00:51AM +0900, Charles Plessy wrote:
there are tools which assemble informations for Sources.gz files - I guess
this could be implemented if say 20% of the packages will contain such a
file.
In such a model, the packages need to be uploaded so that
On Mon, Feb 20, 2012 at 01:48:16PM -0500, Yaroslav Halchenko wrote:
dh_bibref
which turns debian/upstream data into a usable BibTeX database on the
users system. This is technically definitely not hard - it just needs
to be *done*.
The challenge will be to have it ran by
http://git.debian.org/?p=pkg-exppsy/debian-bibliography.git;a=blob;hb=HEAD;f=tools/dbib_collect
and make it do the extraction/conversion from /upstream (which will be
under /usr/doc/PACKAGE/, right?)
Ahhh, this assumes that reference information is kept in
debian/changelog, right?
that
Le Sat, Feb 18, 2012 at 04:53:40PM +0100, Andreas Tille a écrit :
I noticed this. I just verified the current data in UDD and noticed
that some packages are lacking information even if the upstream file
just has it (for instance mira-assembler has only DOI in UDD). May be
we could track
On Sun, Feb 19, 2012 at 06:52:16PM +0900, Charles Plessy wrote:
The Umegaya gatherer is not actively monitoring our repositories. I do not
know how much it would load the Alioth machines. The way Umegaya works is
that
when it is queried, it tries to refresh its information if it is older
Le Sun, Feb 19, 2012 at 03:13:19PM +0100, Andreas Tille a écrit :
I somehow assumed that if
I'm editing a debian/upstream file and commit it to our Vcs after some
delay (say 1 day) this change would be reflected in Umegaya and (in the
worst case one day later) the UDD bibref gatherer would
Hi Andreas,
I have a working implementation as a Debian package that will allow us to
transfer easily the Umegaya gatherer for bibliographic information to
debian-med.debian.net. I do not remember if I have the root access to
that machine... Can you add me to the sudo group ?
Once installed
Hi Charles,
On Sun, Feb 19, 2012 at 12:25:17AM +0900, Charles Plessy wrote:
I have a working implementation as a Debian package that will allow us to
transfer easily the Umegaya gatherer for bibliographic information to
debian-med.debian.net. I do not remember if I have the root access to
On Sat, Feb 18, 2012 at 04:53:40PM +0100, Andreas Tille wrote:
I noticed this. I just verified the current data in UDD and noticed
that some packages are lacking information even if the upstream file
just has it (for instance mira-assembler has only DOI in UDD). May be
we could track this
Hi,
as I said previousely the tasks pages were broken since the
description-less Packages files were introduced. I detected this when
beeing in Southport but needed to sort out things first. I also tested
the new code for one week and now pushed it to debian-med.debian.net
(before finally using
61 matches
Mail list logo
