Re: What is the best place for package meta-data ?

[Charles Plessy]

Le Thu, Aug 06, 2009 at 09:17:22PM +0200, Paul Wise a écrit :
> 
> I'd put the homepage in a "user" category and the VCS URLs in a
> "developer" category.
> 
> The data in that database is gathered from .changes files and binary
> and source packages uploaded to ftp-master, except for debtags and
> translated descriptions (IIRC, not sure how those get in). Re-using
> that workflow for meta-data updates, say, by uploading metadata
> updates in .changes files instead of full packages could be useful.

Interesting idea…

I was about to propose to put all upstream-related metadata in a YAML-encoded
file, but if a .changes file is to be generated, the Debian control format may
be preferrable. Anyway, this would only make a difference if there were
multi-line field contents. Here is an example:

aqwa『debian-med』$ cat samtools/debian/upstream-metadata.yaml 
DOI: 10.1093/bioinformatics/btp352
Homepage: http://samtools.sourceforge.net
PMID: 19505943
Reference: |
 @article{HengLi06082009,
 author = {Li, Heng and Handsaker, Bob and Wysoker, Alec and Fennell, Tim and 
Ruan, Jue and Homer, Nils and Marth, Gabor and Abecasis, Goncalo and Durbin, 
Richard and 1000 Genome Project Data Processing Subgroup,  },
 title = {{The Sequence Alignment/Map (SAM) Format and SAMtools}},
 journal = {Bioinformatics},
 volume = {},
 number = {},
 pages = {btp352},
 doi = {10.1093/bioinformatics/btp352},
 year = {2009},
 URL = {http://bioinformatics.oxfordjournals.org/cgi/content/abstract/btp352v1},
 eprint = {http://bioinformatics.oxfordjournals.org/cgi/reprint/btp352v1.pdf}
 }
Repository: https://samtools.svn.sourceforge.net/svnroot/samtools

The advantage of yaml format is that it is trivial to parse using existing 
libraries:

aqwa『debian-med』$ perl -MYAML -e '$/=""; my($fields) = Load();  print 
$fields->{'DOI'}' < samtools/debian/upstream-metadata.yaml 
10.1093/bioinformatics/btp352

I am unsure if it is a good idea to manage multi-line upstream meta-data
anyway. Are there other opinions on this ?

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540458: ITP: eiskaltdc -- Direct Connect protocol client (Valknut fork)

[Tataranovich Andrey]

Package: wnpp
Severity: wishlist
Owner: Tataranovich Andrey 

* Package name: eiskaltdc
  Version : 0.5a
  Upstream Author : Mathias Küster 
* URL : http://sourceforge.net/projects/eiskaltdc/
* License : GPL, LGPLv3
  Programming Lang: C++
  Description : Direct Connect protocol client (Valknut fork)

EiskaltDC++ is a program that uses the Direct Connect protocol.
It is compatible with other DC clients, such as the original DC
from Neomodus, DC++ and derivatives. EiskaltDC++ also interoperates
with all common DC hub software.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#540332: ITP: at-spi2-core -- Assistive Technology Service Provider Interface (Core) - dbus

[Ray Wang]

Oh yes, you're right,  I didn't notice there were already preliminary
packages for new at-spi, since they are just released recently.
I'm terribly sorry to duplicate your jobs. I think I should close this
bug, but how? :)

Sorry again, please ignore my reports.  :)

On Fri, Aug 7, 2009 at 6:37 PM, Cyril Brulebois wrote:
> Ray Wang  (07/08/2009):
>> Package: wnpp
>> Severity: wishlist
>> Owner: Ray Wang 
>>
>>
>> * Package name    : at-spi2-core
>>   Version         : 0.1.0
>>   Upstream Author : Mike Gorse 
>>                     Mark Doffman 
>> * URL             : https://projects.codethink.co.uk/index.php/p/at-spi2
>> * License         : LGPL
>>   Programming Lang: C
>>   Description     : Assistive Technology Service Provider Interface (Core) - 
>> dbus
>>
>> This library, based on ATK, is a general interface for applications to
>> make use of the accessibility toolkit.  This version is based on dbus.
>
> Hi,
>
> it was mentioned by Mario in [1]. I guess it'd be nice for you to
> coordinate with “us” (-accessibility) for the packaging of at-*
> packages, Mario already has spent some time diving into this set of
> packages.
>
>  1. <871vnukw3s@x2.delysid.org>
>
> Thanks for considering.
>
> (No need to Cc me if you keep -devel or -accessibility in the loop.)
>
> Mraw,
> KiBi.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkp8BAUACgkQeGfVPHR5Nd2kYACgjGt07A8Ur+celdlyiJ7aJXBb
> CXYAnji7tzwVYLiXlpqHYUpQfNVlOK/s
> =nJb9
> -END PGP SIGNATURE-
>
>



-- 
Ray Wang
 - Free As In Freedom


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540513: ITP: stxxl -- C++ Standard Template Library (STL) for extra large datasets

[d.haley]

Package: wnpp
Severity: wishlist
Owner: "d.haley" 


* Package name: stxxl
  Version : 1.2.1
  Upstream Author : Andreas Beckmann 
* URL : http://stxxl.sourceforge.net 

* License : Boost Software License - Version 1.0 - August 17th, 2003 
  Programming Lang: C++ 
  Description : C++ Standard Template Library (STL) for extra large datasets

 Stxxl provides an STL replacement using an abstraction layer to
 storage devices to allow for the optimal layout of data structures. This
 allows for multi-terabyte datasets to be held and manipulated in standard
 C++ data structures, whilst abstracting the complexity of managing this
 behaviour efficiently. stxxl utilises multi-disk I/O to speed up
 I/O bound calculations. STXXL has been developed at the University
 of Karlsruhe.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: piuparts-MBF: overwriting other packages files

[Manoj Srivastava]

On Fri, Aug 07 2009, Holger Levsen wrote:

> On Freitag, 7. August 2009, Manoj Srivastava wrote:
>> While it is good to discover these bugs, is puiparts the correct
>>  place to do this check? Won't puiparts only report on packages
>>  installed on the machine on which the test is run, and thus miss any
>>  conflicts on packages not currently installed?

> The piuparts tests on piuparts.d.o are run in clean chroots. 
> http://piuparts.debian.org has more info on the setup.

So am I correct in my assumption that only file conflicts with
 packages installed on the once-clean chroot would be detected by the
 test? Or am I missing something?

> Yes, the results of that are available at 
> http://edos.debian.net/missing-conflicts/ ;-)

Oh, cool, all of these are already reported as bug. Thanks for
 the work, whoever is to blame.

manoj
-- 
All programmers are playwrights and all computers are lousy actors.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540545: ITP: grads -- Grid Analysis and Display System for earth science data

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: grads
  Version : 2.0
  Upstream Author : NASA Advanced Information Systems Research Program
* URL : http://www.iges.org/grads/
* License : GPL
  Programming Lang: C
  Description : Grid Analysis and Display System for earth science data

The Grid Analysis and Display System (GrADS) is an interactive desktop tool 
that is used for easy access, manipulation, and visualization of earth 
science data. The format of the data may be either binary, GRIB, NetCDF, or 
HDF-SDS (Scientific Data Sets). GrADS has been implemented worldwide on a 
variety of commonly used operating systems and is freely distributed over the 
Internet.

GrADS uses a 4-Dimensional data environment: longitude, latitude, vertical 
level, and time. Data sets are placed within the 4-D space by use of a data 
descriptor file. GrADS interprets station data as well as gridded data, and the 
grids may be regular, non-linearly spaced, gaussian, or of variable 
resolution. Data from different data sets may be graphically overlaid, with 
correct spatial and time registration. Operations are executed 
interactively by entering FORTRAN-like expressions at the command line. A rich 
set of built-in functions are provided, but users may also add their own 
functions as external routines written in any programming language.

Data may be displayed using a variety of graphical techniques: line and bar 
graphs, scatter plots, smoothed contours, shaded contours, streamlines, 
wind vectors, grid boxes, shaded grid boxes, and station model plots. Graphics 
may be output in PostScript or image formats. GrADS provides 
geophysically intuitive defaults, but the user has the option to control all 
aspects of graphics output.

GrADS has a programmable interface (scripting language) that allows for 
sophisticated analysis and display applications. Use scripts to display buttons 
and dropmenus as well as graphics, and then take action based on user 
point-and-clicks. GrADS can be run in batch mode, and the scripting language 
facilitates using GrADS to do long overnight batch jobs. 

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

[ Moving to debian-policy ]

Manoj Srivastava wrote:
> On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote:
> 
>> Manoj Srivastava wrote:
>>> We do not want to have different helper package start inventing
>>>  a helper specific way of building  ddebs, with no clear standard tha
>>>  they are following.
>>> While archive coverage is nice, ensuring  that a ddeb is
>>>  properly defined, and that all the different ways of creating ddebs are
>>>  consistent, should happen first.
>> OK, so you mean I should document the ddeb format (which is that of
>> .deb packages) and possibly include it in policy? That makes sense, if
>> you want that I'll propose a patch for policy (note that udebs are not
>> documented though).
> 
> But regular packages are not creating udebs; and the whole idea
>  behind "automated" ddeb creation is that the ./debian/rules file
>  optionally creates ddebs. Since this affects the majority of packages,
>  I think we need to be clear up front about ddeb creation.

I've documented the .ddeb format in the wiki page [1] ("DDeb Format", which is
short since the format is basically that of .debs). Do we really need this to be
documented in policy?

Also, does anybody see a problem with adding .ddebs to the .changes file (in
Files and *-Checksums), when they are not in debian/control? It seems to me like
that's not a policy violation, but I could be wrong.

Best regards,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:

> [ Moving to debian-policy ]
>
> Manoj Srivastava wrote:
>> On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote:
>> 
>>> Manoj Srivastava wrote:
 We do not want to have different helper package start inventing
  a helper specific way of building  ddebs, with no clear standard tha
  they are following.
 While archive coverage is nice, ensuring  that a ddeb is
  properly defined, and that all the different ways of creating ddebs are
  consistent, should happen first.
>>> OK, so you mean I should document the ddeb format (which is that of
>>> .deb packages) and possibly include it in policy? That makes sense, if
>>> you want that I'll propose a patch for policy (note that udebs are not
>>> documented though).
>> 
>> But regular packages are not creating udebs; and the whole idea
>>  behind "automated" ddeb creation is that the ./debian/rules file
>>  optionally creates ddebs. Since this affects the majority of packages,
>>  I think we need to be clear up front about ddeb creation.
>
> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
> which is short since the format is basically that of .debs). Do we
> really need this to be documented in policy?

Not if that is all that is. So ddebs are just  -dbg packages
 renamed to foo_version_arch.ddeb (you do not need ddeb in the name
 since they are called .ddebs.)

The wiki does not seem to impose any additional rules on the
 ddebs (I assume that all the restrictions on a normal package still
 apply).

Seems like then all that is needed is to build the package as
 normal, and after the dpkg invocation to build the package, one just
 adds a call to mv. This is simple.

manoj

The link to the wiki page was missing
 http://wiki.debian.org/AutomaticDebugPackages

-- 
The meek shall inherit the earth, but not its mineral rights. Paul Getty
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> which is short since the format is basically that of .debs). Do we
>> really need this to be documented in policy?
> 
> Not if that is all that is. So ddebs are just  -dbg packages
>  renamed to foo_version_arch.ddeb (you do not need ddeb in the name
>  since they are called .ddebs.)

dpkg doesn't know about filenames AFAICS. So you can't coinstall
foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the -ddeb 
suffix.

> The wiki does not seem to impose any additional rules on the
>  ddebs (I assume that all the restrictions on a normal package still
>  apply).

Right.

> Seems like then all that is needed is to build the package as
>  normal, and after the dpkg invocation to build the package, one just
>  adds a call to mv. This is simple.

You can build a .ddeb manually, yes. However for some cases (e.g. packages using
debhelper and building ELF binaries) a .ddeb will be automatically created (if
none is created manually) and detached debugging symbols will be put there. I'll
try to automatize other languages too, so that having full archive coverage is
as simpler as possible.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:

> You can build a .ddeb manually, yes. However for some cases
> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
> be automatically created (if none is created manually) and detached
> debugging symbols will be put there. I'll try to automatize other
> languages too, so that having full archive coverage is as simpler as
> possible.

Could you explain a bit more about what merits you see in creating
something that we call a different type of package rather than just
listing debug packages in debian/control and building them as we do now
and handling section debug specially in the archive software?  Is it just
the avoiding of the need to add a bunch of debian/control entries?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Manoj Srivastava]

On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:

> Manoj Srivastava wrote:
>> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>>> which is short since the format is basically that of .debs). Do we
>>> really need this to be documented in policy?
>> 
>> Not if that is all that is. So ddebs are just  -dbg packages
>>  renamed to foo_version_arch.ddeb (you do not need ddeb in the name
>>  since they are called .ddebs.)
>
> dpkg doesn't know about filenames AFAICS. So you can't coinstall
> foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
> -ddeb suffix. 

If we are going to enshrine ddebs into policy, we might as well
 teach dpkg about ddebs.

>
>> The wiki does not seem to impose any additional rules on the
>>  ddebs (I assume that all the restrictions on a normal package still
>>  apply).

> Right.

So why are we creating a whole new class of packages which dpkg
 does not know about, and which are substantially the same as the
 current -dbg packages? Is it to just reduce debian/control file bloat?
 Or to create debug packages whether or not the maintainer cooperates?

The result appears to be to create a package automagically (the
 details appear fuzzy to me, perhaps I have not been paying attention),
 and add things to changes files even when the package is unknown to
 debian/control, so it is uploaded and processed by the archive scripts.

All this seems to require large amounts of infrastructure work,
 why not add dpkg to the set of ddeb aware tools?

>> Seems like then all that is needed is to build the package as
>>  normal, and after the dpkg invocation to build the package, one just
>>  adds a call to mv. This is simple.
>
> You can build a .ddeb manually, yes. However for some cases
> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
> be automatically created (if none is created manually) and detached
> debugging symbols will be put there. I'll try to automatize other
> languages too, so that having full archive coverage is as simpler as
> possible.

I don't use helper packages, including debhelper. So far, policy
 has not required me to, so if you want to put anything about ddebs in
 policy, there should be a route for people not using debhelper to
 contribute to debug packages in Debian, and not be relegated to the
 status of second class packages.

manoj
-- 
Tom's hungry, time to eat lunch.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Automatic Debug Packages

[Goswin von Brederlow]

Manoj Srivastava  writes:

> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>
>> Manoj Srivastava wrote:
>>> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
 I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
 which is short since the format is basically that of .debs). Do we
 really need this to be documented in policy?
>>> 
>>> Not if that is all that is. So ddebs are just  -dbg packages
>>>  renamed to foo_version_arch.ddeb (you do not need ddeb in the name
>>>  since they are called .ddebs.)
>>
>> dpkg doesn't know about filenames AFAICS. So you can't coinstall
>> foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
>> -ddeb suffix. 
>
> If we are going to enshrine ddebs into policy, we might as well
>  teach dpkg about ddebs.

Multiarch will require libfoo:i386 and libfoo:amd64 (for example). It
might be simple to teach dpkg to use libfoo:ddeb:i386 and
libfoo:ddeb:amd64 at the same time. Doesn't looks so nice though.

>> You can build a .ddeb manually, yes. However for some cases
>> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> be automatically created (if none is created manually) and detached
>> debugging symbols will be put there. I'll try to automatize other
>> languages too, so that having full archive coverage is as simpler as
>> possible.
>
> I don't use helper packages, including debhelper. So far, policy
>  has not required me to, so if you want to put anything about ddebs in
>  policy, there should be a route for people not using debhelper to
>  contribute to debug packages in Debian, and not be relegated to the
>  status of second class packages.
>
> manoj

He isn't asking you too. He is just saying that those 95% of packages
using debhelper or cdbs or the like the ddeb can be build
automatically without even having to change the source (or with just
adding a single dh_make_ddebs). If you want to do it the hard way you
always can.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org