Bug#685605: marked as done (qa.debian.org: Would be great if the PTS could provide RDF descriptions of packages)

[Olivier Berger]

Hi.

FTR, any further discussions should now happen on
debian-metad...@lists.debian.org.

Thanks Iain for having taken this issue forward.

Best regards,

Debian Bug Tracking System  writes:

> Your message dated Fri, 11 Dec 2015 11:45:19 +
> with message-id <2015124519.ga12...@shiftout.net>
> and subject line Re: qa.debian.org: Would be great if the PTS could provide 
> RDF descriptions of packages
> has caused the Debian Bug report #685605,
> regarding qa.debian.org: Would be great if the PTS could provide RDF 
> descriptions of packages
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> -- 
> 685605: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685605
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#685605: porting the RDF generation to tracker.debian.org

[Olivier Berger]

"Iain R. Learmonth"  writes:

>
> Ok. Currently I've got Turtle, then RDF/XML, then HTML+RDFa. It stops at the
> first one it finds in the Accept header. JSON-LD support currently is not
> included in rdflib and I don't want to add third-party libraries into the
> mix until I've got the basics working.
>
>> That sounds like a perfect way to go : I'm quite busy at the moment
>> (recent parent of twins ;), so I can't dedicate much effort on that for
>> the coming months, but I'm glad to help.
>
> I haven't got stuck yet, so no effort required on your part so far. (:
>
> I'll keep this bug updated as progress happens.
>

Thanks for the progress update.

Here are a few comments :
- the HTML preview may point to the RDF variants with an alternative
  link header ()
- the Turtle contains lots of prefixes that seem unused. For example :
  $ curl -s -L -H 'Accept: text/turtle' http://rdf.debian.net/project/apache2 
2>&1 | grep '@prefix' | grep "http://rdf.debian.net/package/"; | wc -l
  2151
- some maintainer URIs seem strange :
 ns22:apache2 a admssw:SoftwareProject ;
doap:description "Maintenance of the apache2 source package in Debian" ;
doap:developer ns2178:debian.org,
ns2179:p12n.org,
ns2176:debian.org,
ns2173:debian.org,
ns2171:debian.org,
ns2177:debian.org ;
doap:download-page ns1:apache2 ;
doap:homepage ns7:apache2 ;
doap:maintainer ns2174:lists.debian.org ;
doap:name "Debian apache2 packaging" ;
doap:platform "dpkg" ;
doap:release ns2172:squeeze11,
ns2172:squeeze12,
ns2172:squeeze14,
ns2175:deb7u3,
ns2175:deb7u4,
ns6:apache2_2.4.10-10,
ns6:apache2_2.4.10-11 ;
doap:repository ns4:apache2 ;
doap:screenshots ns2:apache2 .

I would expect all identifiers @debian.org to derive to the same prefix
: some quoting/encoding issue probably. Still rapper seems to like it :

$ rapper -i turtle http://rdf.debian.net/project/apache2 -o turtle

ns22:apache2
doap:description "Maintenance of the apache2 source package in Debian" ;
doap:developer <http://rdf.debian.net/maintainer/arno%40debian.org>, 
<http://rdf.debian.net/maintainer/peter%40p12n.org>, 
<http://rdf.debian.net/maintainer/sesse%40debian.org>, 
<http://rdf.debian.net/maintainer/sf%40debian.org>, 
<http://rdf.debian.net/maintainer/tfheen%40debian.org>, 
<http://rdf.debian.net/maintainer/thom%40debian.org> ;
doap:download-page ns1:apache2 ;
doap:homepage ns7:apache2 ;
doap:maintainer 
<http://rdf.debian.net/maintainer/debian-apache%40lists.debian.org> ;
doap:name "Debian apache2 packaging" ;
doap:platform "dpkg" ;
doap:release ns2172:squeeze11, ns2172:squeeze12, ns2172:squeeze14, 
ns2175:deb7u3, ns2175:deb7u4, 
<http://rdf.debian.net/package/apache2_2.4.10-10>, 
<http://rdf.debian.net/package/apache2_2.4.10-11> ;
doap:repository ns4:apache2 ;
doap:screenshots ns2:apache2 ;
a admssw:SoftwareProject .

Keep up the good work.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d238mado@inf-11879.int-evry.fr

Bug#685605: porting the RDF generation to tracker.debian.org

[Olivier Berger]

Hi.

"Iain R. Learmonth"  writes:

> Hi Oliver,
>
> On Mon, Sep 22, 2014 at 10:23:46AM +0200, Olivier Berger wrote:
>> Thanks for your interest and noticing the need for a port of that
>> feature.
>
> I've started looking at this.
>

Great :-)

>> FYI, I had started some work on this (see https://trello.com/c/4v0AlQse
>> ) but haven't had the time to move on and won't probably have in the
>> coming months.
>
> My goal is essentially to port the existing functionality from the
> packages.qa.debian.org to tracker.debian.org, but in a way that it could be
> extended later.
>

:-)

> I plan to use python-rdflib quite extensively in this.
>
> I'll admit I don't share your views on linkage with upstream/downstream, but
> that doesn't mean I won't consider these during the implementation.

In the case that would help, please note that I've re-published a
"richer" version of our paper that describes the work, as :

http://www-public.telecom-sudparis.eu/~berger_o/papier-oss2013/

You'll see that it embeds some Linked Data too, reusing the Linked
Research approach [2] (and check the JS menu for better output).

Btw, the ADMS.SW format has seen some later revisions in the form of
Application Profiles of ADMS. For instance, the Joinup platform now
expects things more in-line with the rest of the ADMS specs [1], which
has led me to work on a light adaptation of the ADMS.SW output of
FusionForge (which is deployed on Alioth.debian.org) [0]. The latest
version has been deployed for tests on
https://adullact.net/plugins/admssw/index.php if you're curious.

The differences aren't big, but some choices are probably better. But
for a start, porting in an "exact" way may be the safer bet, until some
consumer complains about the lack of certain details.

> My main motivation is to have some easily parseable outputs in a known
> format for tools to look at Debian package metadata. I plan to have
> outputs in RDF/XML, Turtle and JSON-LD.

I think the order of priority could be Turtle, the JSON-LD and finally
RDF/XML if need be, nowadays. But we lack statistics on the popularity.

>
>> Anyone interested can still probe me for advice if needed.
>
> If you're not currently looking at this, I can just get going, and I'll
> probe you when I get stuck.
>

That sounds like a perfect way to go : I'm quite busy at the moment
(recent parent of twins ;), so I can't dedicate much effort on that for
the coming months, but I'm glad to help.

> Thanks for your work on packages.qa.debian.org, I hope my work can live up
> to the same standards for tracker.debian.org.
>

Thank you very much, and good luck.

Best regards,

[0] 
https://fusionforge.org/tracker/index.php?func=detail&aid=755&group_id=6&atid=114
[1] 
https://joinup.ec.europa.eu/asset/adms/asset_release/adms-application-profile-joinup
[2] https://github.com/csarven/linked-research
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv8cwh2y@inf-11879.int-evry.fr

Bug#762952: debsources: Produce RDF meta-data interlinked with the PTS'

[Olivier Berger]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: debsources

Hi.

(Transfering a previous item on the TODO list to a debbugs ticket)

* TODO Produce RDF meta-data interlinked with the PTS'
The idea would be to generate machine parseable meta-data, as RDF,
through content-negociation which would allow to interlink source
package descriptions with those generated by the PTS 

I'm refering to the "old" PTS and not distro tracker, unless it is enhanced to 
include RDF production (see #685605 for more details).


Here's a more elaborate discussion (reused from a thread started off from my 
TODO addition) :

The idea would be that some informations (meta-data) about the source
packages (and why not other contents of the package sources) can be
accessed from the pages of sources.debian.net.

One basic use case could be : "How can I know which version of
the upstream archive, Debian used for package X that I can find on
sources.debian.net. Is it the same as the .tgz I've just found on my
machine ?"


For instance, say a user is interested in the libjaxen-java package. She
may be browsing
http://sources.debian.net/src/libjaxen-java/1.1.6-1. From there she may
deduce that this version 1 of the Debian package of version 1.1.6 of the
upstream program, and then turn to the PTS at
http://packages.qa.debian.org/libjaxen-java and look for details about
that version in the PTS.

My point is that if you need to discover such meta-data programatically,
you may either use some dedicated APIs, or some machine-readable version
of the same URL, typically using content-negociation on the same URL as
the human readable version.

There is such a machine readable standard, RDF, which is used by the RDF
interface of the PTS [0]. 

So, you may try 
 $ curl -L -H 'Accept: text/turtle' http://packages.qa.debian.org/libjaxen-java

And get something like :

   
   a admssw:SoftwareRelease ;
   admssw:includedAsset 
 .

   
   a admssw:SoftwareRelease ;
   admssw:package 
 .

   
   a admssw:SoftwarePackage ;
   dcterms:description "Upstream source archive for libjaxen-java version 
1.1.6-1 (potentially re-archived by Debian)" ;
   schema:downloadUrl 

 ;
   schema:fileSize "292815" ;
   spdx:checksum [
 spdx:algorithm 
 ;
 spdx:checksumValue "8ea1a25eaa0d09213f8d794b232e6619"
   ] ;
   admssw:status  .

This excerpt, for instance exhibits the pointer to the downloadable
version of the upstream .orig source archive, and some traceability
about it (md5sum).

This allows, in principle, to match a version downloaded from upstream
to the one used by Debian and displayed by debsources.

So, either the debsources could provide such meta-data directly, or
point back at the meta-data published by the PTS.

[0] https://wiki.debian.org/qa.debian.org/pts/RdfInterface


-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), 
(500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140926134043.12258.86720.report...@inf-11879.int-evry.fr

Bug#685605: The PTS now produces Turtle RDF meta-data alongside HTML and RDF/XML - Was: Re: Some issues with the RDF export

[Olivier Berger]

Control: tags -1 + help

Hi.

Paul Wise  writes:

> Control: reassign -1 tracker.debian.org
>
> On Fri, Feb 01, 2013 at 10:59:33AM +0100, Olivier Berger wrote:
>
>> FYI, The PTS now implements an RDF export in the Turtle format which
>> should be more easy to use that the XML variant that had been added
>> previously.
>
> The code you have written needs to be rewritten for the new distro
> tracker site, which is written in django and will replace the PTS.
>
> https://tracker.debian.org/docs/contributing.html
>

Thanks for your interest and noticing the need for a port of that
feature.

FYI, I had started some work on this (see https://trello.com/c/4v0AlQse
) but haven't had the time to move on and won't probably have in the
coming months.

Anyone interested can still probe me for advice if needed.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnq8cbcd@inf-11879.int-evry.fr

New format for full Turtle RDF dump of the PTS

[Olivier Berger]

Hi.

FYI, I've just committed to the QA SVN a few changes to the scripts
generating the RDF of the PTS, so that the full dump is no longer a huge
Turtle RDF document, but is now a .tar.bz2 archive which contains
sub-documents (still Turtle) for every "hash" of the package names (a,
b, liba, libb, etc.).

This should make it much more easy to consume by RDF clients, as
individual files to parse become a bit smaller.

Hope this doesn't break anyone's plans... AFAIK, I'm the only one trying
to consume this (see for instance [3]).

No hurry for deploying the commits (I have a local copy).

Best regards,

Olivier Berger  writes:

> Hi.
>
> I'm working on the PTS RDF meta-data generation [0].
>
> I've changed (in my tree [1], not yet in production) the generation
> process so that the XSL stylesheets will produce Turtle RDF documents,
> and then these will be converted to RDF/XML.
>
> Turtle [2] should then be the reference format, as it is meant to be
> both human and machine readable, whereas RDF/XML is XML ;)
>

[3] 
http://www-public.telecom-sudparis.eu/~berger_o/weblog/2013/07/08/experimenting-with-linked-open-data-about-floss-projects-matching-debian-upstream-projects/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3kwyypg@inf-8657.int-evry.fr

Re: Porting Ubuntu's "Developer Advisory Team" tools to Debian; looking for mentors to work with

[Olivier Berger]

Hi.

This seems interesting, but I haven't quite found a way to understand
more of what it is... is there some kind of docs / user screenshots, etc
?

It seems I have to create an Ubuntu one account to access
http://greenhouse-daveeloo.dotcloud.com/, which I'm not sure I want to
do just in order to know more.

Can you try and post somewhere some description of features, use case,
and maybe underlying technology ?

Thanks in advance.

Best regards,

David Lu  writes:

> Hi everyone,
>
> I'm Dave, a Google Summer of Code student working with OpenHatch. I'm part
> of the Greenhouse development team along with Paul Tagliamonte <
> paul...@debian.org> and Asheesh Laroia . We are
> working on a project called Greenhouse to track new open source
> contributors. The basic premise is that there are stages from when someone
> shows up in an open source community to becoming a full fledged maintainer.
> For example, Judy might show up to file a bug or request a feature, end up
> contributing documentation, decide to submit a patch, and then finally
> become a project maintainer. Many people drop out of the pipeline in the
> earlier stages before reaching the end and becoming a full maintainer.
> Greenhouse is meant to track new contributors through the pipeline and help
> them reach the end. The code is based on Ubuntu's Developer Advisory Team (
> https://launchpad.net/dat-overview). For those concerned about privacy, we
> only aggregate publicly available data, and the tool is currently private
> to the Greenhouse development team and Debian developers who ask for
> permission.
>
> Your help is critical at this point! For our initial prototype we are
> tailoring the system to the Debian community. We are looking for Debian
> mentors to give us feedback on the UI and what features would be helpful to
> this process. If there is a particular workflow you like or a feature you
> need, this is the point in time where it is most likely to make it into the
> project!
>
> The best way to help and/or request features it to introduce yourself on on
> our mailing list at http://lists.openhatch.org/mailman/listinfo/greenhouse and
> join the discussion. I will also join #debian-mentors  and #debian-qa and
> be reachable there, but the best way to reach me is my nickname daveeloo at
> #openhatch on freenode or email me at davee...@gmail.com.
>
> Also, we have a prototype available at
> http://greenhouse-daveeloo.dotcloud.com/. To login you have to be part of
> the Greenhouse team on Launchpad, which can be joined here:
> https://launchpad.net/~greenhouse (we are only using Launchpad temporarily
> for the prototype because the original Ubuntu DAT code uses it). We look
> forward to hearing from you!

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87li5dxw6j@inf-8657.int-evry.fr

Re: Guidance required for GSoC project PTS rewrite in Django

[Olivier Berger]

Hi.

Pankaj Kumar Sharma  writes:

> For the record, I am a GSoC aspirant interested in project PTS rewrite in
> Django [
> https://wiki.debian.org/SummerOfCode2013/Projects#PTS_rewrite_in_Django]
>
> Looking forward to get some ideas!
>

In addition to elements already added by the previous responses, let me
add a few items :

The PTS should continue provide Web interfaces for publishing different
contents depending on the client connecting through content-negociation.

Currently, it provides (static) documents either as HTML, for regular
browsing by humans, or (static too) RDF meta-data for machine
consumption [0] (all generated by XSLT stylesheets).

I'm not sure Django integrates much REST support and content
negociation, but I guess the publication of pages should obey a kind of
MVC, with potentially many different Views for a single object.

So for instance, a Source Package should be rendered either as (X)HTML
or, through content-negociation [1], as Turtle, or RDF+XML, or whatever
other formats are interesting for interoperability reasons (JSON for
inclusion in other portals or Web 3 apps, etc.)

I guess HTML is of course a priority (hence Web templates alread
mentioned), but other formats may require more structured
"serialisation", maybe quite close to the underlying Model of the Python
objects handled by the core of the PTS. 

I imagine that only the content-negociation evaluation algorithm
(checking contents of the provided Accept HTTP header) would really be
dynamic, the rest could just be publishing pre-rendered static pages.

Note that Apache already does this ConNeg currently, and there may not be
much need for delegating this to Django AFAICT.


I imagine that some dynamicity could be helpful in the case of different
contents published whether the connection is authentified or not, for
instance to reveal security issues details to maintainers only, or
people's addresses, or other sensitive informations... but I'm not so
sure this is so much a requirement...

I hope this makes sense.


Also, should this be of any help, the ADMS.SW ontology which I used to
implement the RDF output by the PTS [2] proposes an OO model for
describing links between packages and their releases, which could be
reused for inspiration in implementing the Model part / Python classes
for the Django rewrite.

Don't hesitate to check [2] for more details (slightly outdated, but
cUrl is your friend to go check the live version on the PTS ;-).


Also, regarding dynamic vs static pages, is i18n of the Web pages a goal
of the rewrite ?


Maybe I've missed something, but I think I heard that there was a
tentative rewrite of the Mentors.Debian.[net|org] site with
Django... and it could also be interesting to investigate in more
details the potential cooperation/reuse, for instance in terms of Auth
mechanics relying on the Debian LDAP, or other sources, etc.

It would be sad to see concurrent yet incompatible implementations in 2
Django apps ;-)


I'm looking forward to see your progress, and maybe helping on this
project, if possible.


Best regards,

[0] http://packages.qa.debian.org/common/RDF.html
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
[2] http://www-public.telecom-sudparis.eu/~berger_o/papier-swese2012/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ip39k7xm@inf-8657.int-evry.fr

Supporting semantic formats for meta-data would be interesting - Was: Re: [GSoC] Using a messaging system to interface the different parts of Debian infrastructure

[Olivier Berger]

Hi.

(As I'm not following discussion outside of debian-qa, CC-ing all
parties... sorry for duplicates)

Nicolas Dandrimont  writes:

>
> One of the key outcomes of getting such a system in place, is that everyone,
> everywhere, can start listening to the messages and using them, opening up 
> lots
> of doors for people to make amazing services based on Debian.
>
> A few ideas:
>  - getting a signal from the archive on an accepted package (I'm confusing
>binaries and sources for the sake of brevity):
>→ Trigger a piuparts run
>→ Trigger lintian checks
>→ Let any derivative intent a rebuild
>→ Signal ports to rebuild
>→ Trigger a jenkins job on specific package uploads
>→ Post to pump.io/identi.ca/twitter
>→ get a notification on your desktop
>→ ...
>  - one of your pet packages gets a git commit
>→ try a rebuild
>→ run QA checks
>→ ...
>
> (boy, that escalated quickly)

Great ideas.

Let me add a few comments.

I'm not sure how data circulates on those systems (and have probably
been sleeping during the Lightning Talk last week when Michael Scherrer
introduced FedMesg...).

I think that it would be great, for maximum interoperability (derivative
distros, upstreams, others), if the data about Debian artifacts could be
using semantic formats such as the one I've tried to add to the PTS [0].

So in addition to offering anyone (inside or outside Debian) the
possibility to interface with the events happening in that
infrastructure, it would convey non-ambiguous semantics out of the box.

So, instead of mentioning an upload about "apache2" (a string that is
supposed to deal represent a source package of the Apache 2 HTTP
server), a message could reference
<http://packages.qa.debian.org/apache2#project> which is a
dereferenceable URI (see http://packages.qa.debian.org/a/apache2.ttl)
where meta-data about that source package is available.

(Note that URI conventions could be changed of course, i.e. for
shortening purposes, but the idea is to have something accessible,
parseable, semantic and auto-described along the principles of Linked
Data).

With a tiny extra burden (encoding meta-data as RDF, for instance as
Turtle), it may save the cost of convertors / translators for those
wishing to interface with it.

See my presentation at [1] for more details (hopefully a video capture
will be uploaded soon).


Feel free to ask if that doesn't sound crystal clear.

Best regards,

[0] http://packages.qa.debian.org/common/RDF.html
[1] https://distro-recipes.org/en/lightning/metadata-and-traceability/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hajeboum@inf-8657.int-evry.fr

Bug#694009: qa.debian.org: Please include suite version information in RDF meta data

[Olivier Berger]

Hi.

Olivier Berger  writes:

>
> Do you know an existing ontology that could be used to link this version
> information to the existing RDF content ?
>
> I'd suggest a Turtle example (see
> http://www-public.telecom-sudparis.eu/~berger_o/weblog/2012/08/29/debian-package-tracking-system-now-produces-rdf-description-of-source-packages/
> for details on how to generate one using rapper) for the sake of readability.
>

I've implemented this feature the following way (example for apache2) :

 <http://www.debian.org/releases/stable#distribution>
admssw:includedAsset 
<http://packages.qa.debian.org/apache2#apache2_2.2.16-6+squeeze10> .
  
 <http://www.debian.org/releases/security-stable#distribution>
admssw:includedAsset 
<http://packages.qa.debian.org/apache2#apache2_2.2.16-6+squeeze10> .
  
 <http://www.debian.org/releases/testing#distribution>
admssw:includedAsset 
<http://packages.qa.debian.org/apache2#apache2_2.2.22-12> .
  
 <http://www.debian.org/releases/unstable#distribution>
admssw:includedAsset 
<http://packages.qa.debian.org/apache2#apache2_2.2.22-12> .
  
 <http://www.debian.org/releases/experimental#distribution>
admssw:includedAsset 
<http://packages.qa.debian.org/apache2#apache2_2.4.2-2> .


For now, admssw:includedAsset seems the perfect fit according to the
specs, at least :
https://joinup.ec.europa.eu/svn/adms_foss/adms_sw_v1.00/adms_sw_v1.00.htm#Software%20Release%20-%20included%20asset

I hope this will suit most people's needs.

The code is in the SVN, pending deployment.

Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqtw2q9p@inf-8657.int-evry.fr

Re: Double Maintainer: headers in Sources file

[Olivier Berger]

Paul Wise  writes:

> Sounds like a bug, I would suggest filing some.
>

It looks all the bugs had been filed already.

Thanks for the feedback.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5egr2dq@inf-8657.int-evry.fr

Double Maintainer: headers in Sources file

[Olivier Berger]

Hi.

While working on my webid.debian.net experiment [0], I've noticed that
the Sources and Packages files sometimes contain entries like :

Maintainer: Maintainer: Debian Science Maintainers 

Maintainer: Maintainer: Jonas Smedegaard 
Maintainer: Maintainer: Debian QA Group 

It looks like a big to me, but I'd prefer a second opinion.

Any clues ?

Best regards,

[0] http://wiki.debian.org/WebIDDebianNet
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bobdo0ul@inf-8657.int-evry.fr

Bug#698161: [PTS] RDF descriptions point to broken archive links in some cases

[Olivier Berger]

Hi.

On Mon, Jan 14, 2013 at 11:47:46AM -0600, Raphael Geissert wrote:
> 
> Hi,
> 
> Some RDF descriptions contain broken downloadUrl links. E.g.
> http://packages.qa.debian.org/s/s-http-server.rdf
> 
> Links to:
> http://http.debian.net/debian//s-http-
> server_20080228.orig.tar.gz
> 
> Which doesn't exist.
> 

In this respect, it's no better than the HTML page at 
http://packages.qa.debian.org/s/s-http-server.html which points to the .dsc 
file at 
http://http.debian.net/debian/pool/main/s/s-http-server/s-http-server_20080228-1.dsc

> From a quick look at a couple of such issues it seems that it is limited to 
> packages which only "exist" in oldstable.
> 
> P.S. needless to say, even if the pool directory was right, the files are no 
> longer there in the mirrors. Perhaps the code should be aware of archived 
> releases and use http://http.debian.net/debian-archive/debian/ as the base 
> URL.
> 

I think it's not so much a big deal, but needs a fix. There are probably higher 
priorities on my TODO, though. So, any patch is much welcome.

Thanks for reporting.

Best regards,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130202144028.GA16558@inf-8657

The PTS now produces Turtle RDF meta-data alongside HTML and RDF/XML - Was: Re: Some issues with the RDF export

[Olivier Berger]

Hi.

FYI, The PTS now implements an RDF export in the Turtle format which
should be more easy to use that the XML variant that had been added
previously.

Turtle is supposed to be the best option for implementing Semantic Web
and Linked Data applications nowadays.

As an example, see for instance
http://packages.qa.debian.org/a/apache2.ttl (or :
 $ curl -L -s -H "Accept: text/turtle" http://packages.qa.debian.org/apache2 )

For more details, see also my blog post on the subject :
http://www-public.telecom-sudparis.eu/~berger_o/weblog/2013/02/01/the-debian-package-tracking-system-now-publishes-turtle-rdf-meta-data/

In addition to the default format change, the contents of the meta-data
has been improved too, including some of the suggested improvements made
by Kjetil.

I hope this will be inspirational for other uses of Turtle in Debian
(instead of YAML, for instance).

Any comments, bug reports or feature requests most welcome.

Best regards,

Olivier Berger  writes:

> Hi.
>
> Kjetil Kjernsmo  writes:
>
>> Hi there!
>>
>> It is really nice to see that Debian exports RDF! Great work! I was just 
>> made aware of it by Jonas Smedegaard, who have packaged most of the 
>> Perl+RDF stack as well as other semweb packages.
>>
>
> Glad you find it interesting :-)
>
>> I have some comments, most pertaining to this small excerpt:
>>
>> <http://packages.qa.debian.org/librdf-linkeddata-perl>
>> a admssw:SoftwareProject;
>> doap:description "Debian librdf-linkeddata-perl source packaging";
>> doap:homepage "http://packages.debian.org/src:librdf-linkeddata-perl";;
>>
>>
>>
>> 1) Shouldn't the subject URI be to something else than the QA package? I 
>> don't think the QA page itself is a SoftwareProject, the latter is an 
>> abstract thing. So, it should IMHO be something like 
>>
>> <http://packages.qa.debian.org/librdf-linkeddata-perl#project>
>
> It could be done like this, but on the other hand, the URI is
> dereferenceable as RDF/XML to retrieve the RDF document... and the
> "packaging project" behind every source package isn't so much an
> abstract thing ?
>
> But, yes, maybe the document should be distinguished from the
> resource. That would also allow documenting the retrieval date for
> indexers, etc.
>
> But in such case, we have the RDF documents at URLs like
> http://packages.qa.debian.org/libr/librdf-linkeddata-perl.rdf if need
> be...
>
> I'm not so sure what's the best option.
>
>>
>> The same goes for all the other mentions of admssw:SoftwareProject in the 
>> document.
>>
>
> Other SoftwareProject (upstream projects) are already fragment-ed : 
>
>> 2) DOAP has a doap:shortdesc property. I suggest using that for the current 
>> description, and perhaps use doap:description for the full
>> description?
>
> We could, but my prority was to implement ADMS.SW 1.0, which is
> implemented using doap:description.
>
> admssw:SoftwareProject is a subClass of doap:Project, so nothing forbids
> having both... so if I can get the full description from the XSLT
> stylesheet used by the PTS, I could add doap:shortdesc (not sure if it
> is available though).
>
>>
>> 3) doap:homepage shouldn't be a literal, it should be a URI, so pointy 
>> brackets, not quotes. There seems to be the same for all the doap:homepage.
>>
>
> Indeed : doap:homepage doesn't seem to force that, but inherits from
> foaf:homepage that seems to be referencing a foaf:Document, ok, then.
>
>> 4) Finally, to really make it linked data, it would be cool to add links to 
>> e.g. upstream where it exists. For all the Perl packages, there exists URIs 
>> for everything on CPAN. The upstream URI of this package is 
>>
>> http://purl.org/NET/cpan-uri/dist/RDF-LinkedData/project
>
> Great :-)
>
> OK, so for RDF::Trine, it's :
> http://purl.org/NET/cpan-uri/dist/RDF-Trine/project
>
> Very interesting. I wonder if ADMS.SW is in the radar of the creator of
> this (are you ?)...
>
> There are also Apache DOAP files (of which I couldn't match URLs of
> homepages), and Gnome ones (currently trying to see if matches
> apply). Clearly, promoting DOAP and its publishing is something
> important, IMHO. I've worked on adding DOAP/ADMS.SW generation for
> FusionForge too.
>
>>
>> Some heuristics could probably done to add this, but perhaps a field in the 
>> package description would be better?
>
> Yes, that's clearly one of the goals to be able to do that, but
> unfortunately, we don't necessarily have such information in the
> debian/c

Request for update of the PTS from SVN - Was: Re: Request for installation of rapper on packages.q.d.o

[Olivier Berger]

Hi.

May I now (that the kind Peter Palfrader has installed raptor-utils for
me) ask some qa member to deploy what I've committed in the SVN [3] to
enable the switch from RDF/XML to Turtle ?

AFAIU, it would require an svn update (inside
quantz:/srv/packages.qa.debian.org/www), and to apply the *changes to the
apache config* [4] so that the Turtle can be made accessible on the PTS

Expect a relatively busy next generation of the PTS pages, while all
.ttl and .rdf files will be regenerated.

Hope this will work smoothly.

Thanks in advance.

Best regards,

Olivier Berger  writes:

> Hi.
>
> I'm working on the PTS RDF meta-data generation [0].
>
> I've changed (in my tree [1], not yet in production) the generation
> process so that the XSL stylesheets will produce Turtle RDF documents,
> and then these will be converted to RDF/XML.
>
> Turtle [2] should then be the reference format, as it is meant to be
> both human and machine readable, whereas RDF/XML is XML ;)
>
> The conversion from RDF/XML to Turtle would require /usr/bin/rapper from
> raptor2-utils.

SNIP

>
> [0] http://packages.qa.debian.org/common/RDF.html
> [1] 
> http://anonscm.debian.org/gitweb/?p=users/obergix/qa.git;a=shortlog;h=refs/heads/turtle
> [2] http://www.w3.org/TR/turtle/

[3] http://anonscm.debian.org/viewvc/qa?view=revision&revision=2926
[4] 
http://anonscm.debian.org/viewvc/qa/trunk/pts/apache.conf?r1=2926&r2=2925&pathrev=2926
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3qtcsep@inf-8657.int-evry.fr

Request for installation of rapper on packages.q.d.o

[Olivier Berger]

Hi.

I'm working on the PTS RDF meta-data generation [0].

I've changed (in my tree [1], not yet in production) the generation
process so that the XSL stylesheets will produce Turtle RDF documents,
and then these will be converted to RDF/XML.

Turtle [2] should then be the reference format, as it is meant to be
both human and machine readable, whereas RDF/XML is XML ;)

The conversion from RDF/XML to Turtle would require /usr/bin/rapper from
raptor2-utils.


May a qa team member please ask DSA for installation of raptor2-utils
and dependencies on packages.qa.debian.org ?


Many thanks in advance.

Best regards,


[0] http://packages.qa.debian.org/common/RDF.html
[1] 
http://anonscm.debian.org/gitweb/?p=users/obergix/qa.git;a=shortlog;h=refs/heads/turtle
[2] http://www.w3.org/TR/turtle/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwvpcy1e@inf-8657.int-evry.fr

Advocating the use of RDF and Turtle (standards) - Was: Re: [DEP 12] Mapping debian/upstream fields to established formats or ontologies.

[Olivier Berger]

:homepage <http://packages.debian.org/src:umegaya> ;
doap:release <http://packages.qa.debian.org/umegaya#umegaya_0.12> ;
schema:contributor [
a foaf:OnlineAccount ;
foaf:accountName "Charles Plessy" ;
foaf:accountServiceHomepage 
<http://qa.debian.org/developer.php?login=ple...@debian.org>
] .

<http://packages.qa.debian.org/umegaya#umegaya_0.12>
a admssw:SoftwareRelease ;
rdfs:label "umegaya 0.12" ;
doap:revision "0.12" ;
dcterms:description "Debian umegaya source package version 0.12" ;
admssw:project <http://packages.qa.debian.org/umegaya> ;
admssw:package <http://packages.qa.debian.org/umegaya#umegaya_0.12.dsc>, 
<http://packages.qa.debian.org/umegaya#umegaya_0.12.tar.gz> ;
dcterms:relation <https://launchpad.net/ubuntu/+source/umegaya/0.12> .

[...]

So, a DEP-12 file like upstream.ttl could contain :

<http://packages.qa.debian.org/umegaya#usptream-meta-data>
a dep12:UpstreamMetadata ;
dep12:sourcePackage <http://packages.qa.debian.org/umegaya> ;
dep12:publication <http://example.com/bibloentry/123> .

for instance, if the goal is to relate the paper
<http://example.com/bibloentry/123> to the umegaya source package (where
http://example.com/bibloentry/123 would ideally contain bibliographic
meta-data as RDF of some sort) ...


Hope this makes sense, and welcome to the Semantic Web ;)

Best regards,

[0] http://linkeddata.org/
[1] http://packages.qa.debian.org/common/RDF.html, 
http://wiki.debian.org/qa.debian.org/pts/RdfInterface
[2] 
http://anonscm.debian.org/gitweb/?p=users/obergix/qa.git;a=shortlog;h=refs/heads/turtle
[3] 
http://www-public.telecom-sudparis.eu/~berger_o/presentation-MiniDebconf-Paris-2012.pdf
[4] http://www-public.it-sudparis.eu/~berger_o/papier-swse2012.old/
[5] http://www.w3.org/TR/turtle/
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehh61z60@inf-8657.int-evry.fr

Slides of my RDF work on the PTS and a quick update

[Olivier Berger]

Hi.

I've made a short presentation at the Paris mini-debconf yesterday about
the work I've done on the RDF production for the PTS :

http://www-public.telecom-sudparis.eu/~berger_o/weblog/2012/11/25/presented-generating-linked-data-descriptions-of-debian-packages-in-the-debian-pts-at-the-paris-mini-debconf/


I've also started reworking the XSLT stylesheet to generate Turtle [0]
instead of RDF/XML, which should make it easier to read by both humans
and machines, as it is text based.

As a comparison, the attached file is the result for apache2's
description in Turtle, whereas [1] was the current output as RDF/XML.

I've not yet tried and deploy it, as I'll also work on adding some more
meta-data to the generated Linked Data. It's committed/pushed in my
'turtle' git branch (cloned with git-svn) at [2], for the moment.

Stay tuned for more details.

Best regards,

[0] http://en.wikipedia.org/wiki/Turtle_%28syntax%29
[1] http://packages.qa.debian.org/a/apache2.rdf
[2] 
http://anonscm.debian.org/gitweb/?p=users/obergix/qa.git;a=shortlog;h=refs/heads/turtle



apache2.ttl
Description: Binary data

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#694009: qa.debian.org: Please include suite version information in RDF meta data

[Olivier Berger]

Hi.

Arno Töll  writes:


> The RDF pages for a package in the BTS contains lots of

You mean PTS, right ?

> machine-readable information about the package. However, it misses the
> information from the versions column (i.e. the current version of a
> package told apart per suite). It would be super handy to have that
> information encoded in XML as well.

What kind of use case do you have ? I have thought about adding these
kind of meta-data, but haven't yet tackled the problem.

Do you know an existing ontology that could be used to link this version
information to the existing RDF content ?

I'd suggest a Turtle example (see
http://www-public.telecom-sudparis.eu/~berger_o/weblog/2012/08/29/debian-package-tracking-system-now-produces-rdf-description-of-source-packages/
for details on how to generate one using rapper) for the sake of readability.

>
> This should be a fairly simple patch for those of whom the PTS code is not a
> complete mystery (like it is for me). Essentially this would mean, that we'd 
> have
> a (somewhat) easy readable method to retrieve the most current version of a
> package in our suites.

Depending on the use case, you may be interested in the SOAP interface
of the PTS also : see http://packages.qa.debian.org/common/index.html
for pointers.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obiok01x@inf-8657.int-evry.fr

Re: [PTS] Factorizing common bits between pts.xsl and admssw.xsl

[Olivier Berger]

Hi.

Stefano Zacchiroli  writes:

> On Fri, Aug 31, 2012 at 12:57:25PM +0200, Olivier Berger wrote:
>> In building the RDF export for the PTS I've reused variables and some
>> templates code in the new admssw.xsl. I had initially copied these.
>
> Bad Olivier, bad! :-)

For such a first big hack, I prefered not to break the PTS... I tend to
need it sometimes ;)

>
>> I suggest that from now on a common xsl include handles these common
>> objects, so that changes get applied to both simultaneously.
>
> A long time ago, when I was active on PTS development, I did quite a bit
> of factorization (although "reorganization" would be more correct, as
> there wasn't multiple code "clients" back then). For one thing, I
> created pts-issues.xsl as an XSL template 'library', which is used by
> pts.xsl.  Any similar factorization effort is welcome.
>

Sure. Even though it probably requires XSLT talent to make it beautiful,
and I'm afraid most of my code could be rewritten in much more elegant
ways... but eh, it kinda works for the moment.

I may have to switch to a more classical (Python) program some day, as
there may need to integrate things into a much richer RDF model, but
that may not necessarily happen on the PTS service...

> In fact, for future development I'd prefer if we could first do the
> needed refactoring. That would be to copy/paste templates because, say,
> if you lose interest in this, the copy/paste code will remain with us,
> like, forever.
>

That'd be better, yes... but in the meantime, let's do it incrementally.

Btw, I've made sure that changes made to the includes get noticed to
trigger regeneration.

> Thanks for working on this!

It's been a while since I first met you at Paris 7 to discuss RDF,
interoperability, etc. ... and looks like I'm delivering a bit in
Debian, finally, what... 4/5 years later ? ;)

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nnjjkqe@inf-8657.int-evry.fr

[PTS] Factorizing common bits between pts.xsl and admssw.xsl

[Olivier Berger]

Hi.

In building the RDF export for the PTS I've reused variables and some
templates code in the new admssw.xsl. I had initially copied these.

I suggest that from now on a common xsl include handles these common
objects, so that changes get applied to both simultaneously.

Any objections before I commit the change (provided that XSL includes
are much like other languages') ?

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gsfjpm2@inf-8657.int-evry.fr

Re: Some issues with the RDF export

[Olivier Berger]

Hi.

Kjetil Kjernsmo  writes:

> Hi there!
>
> It is really nice to see that Debian exports RDF! Great work! I was just 
> made aware of it by Jonas Smedegaard, who have packaged most of the 
> Perl+RDF stack as well as other semweb packages.
>

Glad you find it interesting :-)

> I have some comments, most pertaining to this small excerpt:
>
> <http://packages.qa.debian.org/librdf-linkeddata-perl>
> a admssw:SoftwareProject;
> doap:description "Debian librdf-linkeddata-perl source packaging";
> doap:homepage "http://packages.debian.org/src:librdf-linkeddata-perl";;
>
>
>
> 1) Shouldn't the subject URI be to something else than the QA package? I 
> don't think the QA page itself is a SoftwareProject, the latter is an 
> abstract thing. So, it should IMHO be something like 
>
> <http://packages.qa.debian.org/librdf-linkeddata-perl#project>

It could be done like this, but on the other hand, the URI is
dereferenceable as RDF/XML to retrieve the RDF document... and the
"packaging project" behind every source package isn't so much an
abstract thing ?

But, yes, maybe the document should be distinguished from the
resource. That would also allow documenting the retrieval date for
indexers, etc.

But in such case, we have the RDF documents at URLs like
http://packages.qa.debian.org/libr/librdf-linkeddata-perl.rdf if need
be...

I'm not so sure what's the best option.

>
> The same goes for all the other mentions of admssw:SoftwareProject in the 
> document.
>

Other SoftwareProject (upstream projects) are already fragment-ed : 

> 2) DOAP has a doap:shortdesc property. I suggest using that for the current 
> description, and perhaps use doap:description for the full
> description?

We could, but my prority was to implement ADMS.SW 1.0, which is
implemented using doap:description.

admssw:SoftwareProject is a subClass of doap:Project, so nothing forbids
having both... so if I can get the full description from the XSLT
stylesheet used by the PTS, I could add doap:shortdesc (not sure if it
is available though).

>
> 3) doap:homepage shouldn't be a literal, it should be a URI, so pointy 
> brackets, not quotes. There seems to be the same for all the doap:homepage.
>

Indeed : doap:homepage doesn't seem to force that, but inherits from
foaf:homepage that seems to be referencing a foaf:Document, ok, then.

> 4) Finally, to really make it linked data, it would be cool to add links to 
> e.g. upstream where it exists. For all the Perl packages, there exists URIs 
> for everything on CPAN. The upstream URI of this package is 
>
> http://purl.org/NET/cpan-uri/dist/RDF-LinkedData/project

Great :-)

OK, so for RDF::Trine, it's :
http://purl.org/NET/cpan-uri/dist/RDF-Trine/project

Very interesting. I wonder if ADMS.SW is in the radar of the creator of
this (are you ?)...

There are also Apache DOAP files (of which I couldn't match URLs of
homepages), and Gnome ones (currently trying to see if matches
apply). Clearly, promoting DOAP and its publishing is something
important, IMHO. I've worked on adding DOAP/ADMS.SW generation for
FusionForge too.

>
> Some heuristics could probably done to add this, but perhaps a field in the 
> package description would be better?

Yes, that's clearly one of the goals to be able to do that, but
unfortunately, we don't necessarily have such information in the
debian/control files yet, so the PTS may not know, at least in the context
where I'm generating the current RDF files.

I'd like to investigate possible ways on doing such interlinking with
all interested parties.

This needs to be discussed together with other upstream metadata
collection, in line with work already started like :
http://wiki.debian.org/UpstreamMetadata

We just have to find a way to discuss that with the different Debian
contributors interested (and probably other parties, like upstream
projects).

I'd welcome all sugestions on how to proceed (some previous discussions
have happened on -project or -devel lists... I'm not sure where to
continue...).

In any case, thanks for your comments. I'll try and fix some bits for
next runs.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/873934tttd@inf-8657.int-evry.fr

Started adding ADMS.SW RDF descriptions of source packages to the PTS

[Olivier Berger]

Hi.

As previously announced on debian-qa (and following past discussions on
RDF in Debian on -project)...

Olivier Berger  writes:

> I've started working on #685605, i.e. adding some RDF+XML documents
> generated for the PTS static pages.
>
> Appologies for those not Semantic Web aware in advance ;-) I hope the
> code and following example can help illustrate my goal, still, beyond
> the jargon.
>

This means that the PTS [0] will progressively produce, alongside HTML pages
meant for humans, RDF pages meant for Linked Data [1] / Semantic Web aware
applications.

You can see an example in trying (with 'raptor2-utils' installed):
 $ rapper -o turtle http://packages.qa.debian.org/apache2

If you prefer more visual/navigatable versions, use one of the browsers
referenced in [2] or see the output of the W3C RDF validator [5].

for more details about the underlying format :
$ curl -L -v -H 'Accept: application/rdf+xml'  
http://packages.qa.debian.org/apache2


The main objective is to try and produce (closest as possible from the
source) an authoritative description of Debian's packages in an
interoperable format (RDF using ADMS.SW 1.0 ontology [3])

Thus, each package in Debian can be identified with a unique URI like
<http://packages.qa.debian.org/apache2>, which is dereferenceable as
RDF.

Any Semantic Web application can then reference that resource, which
becomes part of the Linked Open Data cloud [4].

There are probably lots of uses that could emerge from this, but the
immediate I can think of is the matching of Debian packages with other
packages/projects (upstream, downstream, other dists) in an
interoperable way (see other projects like distromatch, etc.).

AFAICT, this is the first large deployment of an ADMS.SW 1.0
implementation.

Thanks to Raphaël (buxy) for his kind assistance in deploying this new
feature on the PTS. 

Btw, the RDF (static) pages generation is still in progress, so don't
complain if your preferred source package isn't already available.


Questions, comments, suggestions, bugfixes welcome.

Best regards,

[0] http://packages.qa.debian.org/
[1] http://en.wikipedia.org/wiki/Linked_data
[2] http://en.wikipedia.org/wiki/Linked_data#Browsers
[3] http://joinup.ec.europa.eu/asset/adms_foss/description
[4] http://linkeddata.org/
[5] http://ur1.ca/a1yd7


P.S.: there's the begining of interlinking Debian packages with Ubuntu
ones in the output... hoping that the design decision I've made for that
relation doesn't connotate it in a too trollish way ;)
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vcxzth7@inf-8657.int-evry.fr

How to deploy changes to the PTS ? Re: Adding ADMS.SW RDF descriptions of source packages to the PTS

[Olivier Berger]

Hi.

What's the process to try and have changes deployed to
packages.qa.debian.org ?

Maybe no one cares, but at least I've received to negative comments on
my proposal on generating RDF pages for the packages on the PTS, so I'd
like to roll out these changes so that it goes live on p.q.d.o.

What's the process I should follow ?

Thanks in advance.

Best regards,

Olivier Berger  writes:

> Hi.
>
> I've started working on #685605, i.e. adding some RDF+XML documents
> generated for the PTS static pages.
>

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mx1f4eqe@inf-8657.int-evry.fr

Re: Adding ADMS.SW RDF descriptions of source packages to the PTS

[Olivier Berger]

Olivier Berger  writes:
>
> It seems no one complained, so lemme go forward one more step.
>
> The latest commit in SVN now implements the generation of such metadata
> about apache2 (this time in turtle format, less verbose than RDF, once
> converted from the generated RDF+XML output, in attachment).
>

Better with the attachment.

Regards,



apache2.rdf
Description: application/rdf

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: Adding ADMS.SW RDF descriptions of source packages to the PTS

[Olivier Berger]

Hi.

Olivier Berger  writes:

> Hi.
>
> I've started working on #685605, i.e. adding some RDF+XML documents
> generated for the PTS static pages.
>
> Appologies for those not Semantic Web aware in advance ;-) I hope the
> code and following example can help illustrate my goal, still, beyond
> the jargon.
>

It seems no one complained, so lemme go forward one more step.

The latest commit in SVN now implements the generation of such metadata
about apache2 (this time in turtle format, less verbose than RDF, once
converted from the generated RDF+XML output, in attachment).

I add some comments below for documentation

@base <http://packages.qa.debian.org/apache2> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix admssw: <http://purl.org/adms/sw/> .
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix schema: <http://schema.org/> .
@prefix spdx: <http://www.spdx.org/rdf/terms#> .
@prefix : <http://www.w3.org/1999/xhtml> .
@prefix str: <http://exslt.org/strings> .

#
# First the packaging project for apache2 in Debian
#

# <http://packages.qa.debian.org/apache2> resource :
<>
a admssw:SoftwareProject ;
doap:name "apache2" ;
doap:description "Debian apache2 source packaging" ;
doap:homepage "http://packages.debian.org/src:apache2"; ;
schema:contributor [
a foaf:OnlineAccount ;
foaf:accountName "Debian Apache Maintainers" ;
foaf:accountServiceHomepage 
<http://qa.debian.org/developer.php?login=debian-apa...@lists.debian.org>
], [
a foaf:OnlineAccount ;
foaf:accountName "Stefan Fritsch" ;
foaf:accountServiceHomepage 
<http://qa.debian.org/developer.php?login=s...@debian.org>
], [
a foaf:OnlineAccount ;
foaf:accountName "Steinar H. Gunderson" ;
foaf:accountServiceHomepage 
<http://qa.debian.org/developer.php?login=se...@debian.org>
], [
a foaf:OnlineAccount ;
foaf:accountName "Arno Töll" ;
foaf:accountServiceHomepage 
<http://qa.debian.org/developer.php?login=a...@debian.org>
] ;
# pointer to the release in the different suites :
doap:release , , 
 .

#
# Now the different debian package source releases
#

# <http://packages.qa.debian.org/apache2_2.2.16-6+squeeze7> resource

a admssw:SoftwareRelease ;
rdfs:label "apache2 2.2.16-6+squeeze7" ;
admssw:project <> ;
dcterms:description "Debian apache2 source package version 
2.2.16-6+squeeze7" ;
doap:revision "2.2.16-6+squeeze7" .

# This one is the reference version for the PTS as in unstable, so
# contains more details than the others

a admssw:SoftwareRelease ;
rdfs:label "apache2 2.2.22-11" ;
admssw:project <> ;
dcterms:description "Debian apache2 source package version 2.2.22-11" ;
doap:revision "2.2.22-11" ;
# this release contains two components
admssw:includedAsset , 
 ;
# this release can be downloaded as one package (with dget)
admssw:package  ;
# it also has a related release somewhere else
dcterms:relation 
<https://launchpad.net/ubuntu/+source/apache2/2.2.22-6ubuntu2> .


a admssw:SoftwareRelease ;
rdfs:label "apache2 2.4.2-2" ;
dcterms:description "Debian apache2 source package version 2.4.2-2" ;
admssw:project <> ;
doap:revision "2.4.2-2" .

# Then the .dsc file for the current unstable version

a admssw:SoftwarePackage ;
dcterms:description "Debian source package descriptor file for apache2 
version 2.2.22-11" ;
schema:downloadUrl 
"http://cdn.debian.net/debian/pool/main/a/apache2/apache2_2.2.22-11.dsc"; ;
schema:fileSize "2885" ;
spdx:checksum [
a spdx:Checksum ;
spdx:algorithm <#checksumAlgorithm_md5sum> ;
spdx:checksumValue "d7d03719b9f6432beeecd3aa04f7b22c"
] .


#
# Then the upstream project
#


a admssw:SoftwareProject ;
doap:description "The apache2 upstream project" ;
# either its name or homepage can be matched against other ADMS.SW
# or DOAP descriptors
doap:name "apache2" ;
doap:homepage "http://httpd.apache.org/"; .

# And a upstream release 2.2.22


a admssw:SoftwareRelease ;
rdfs:label "Upstream apache2 release 2.2.22" ;
dcterms:description "Upstream source release for apache2 version 2.2.22" ;
doap:revision "2.2.22" ;
admssw:project  ;
# and a link to the upstream source tarball's description
admssw:package  .

# no

Adding ADMS.SW RDF descriptions of source packages to the PTS

[Olivier Berger]

tions and the
PTS' so that one can "navigate" the Linked Open Data cloud between
versions of packages cross project and cross distros without any
converter involved, as everyone would compatible formats, based on
ADMS.SW, SPDX or likes. That's a great TODO ahead of me/us... but I
should find a way to be paid to continue that work ;)

We could also think about providing other RDF representations like
turtle (easy : just adding some rapper processing) or JSON (JSON-LD
if/when it's standardize and we have conversion tools).

But before going much further, I thought I would ask for opinions from
other PTS maintainers or QA people first.

Thanks in advance for your feedback.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87393esirm@inf-8657.int-evry.fr

Bug#585740: qa.debian.org: Would be great if the PTS could provide RDFa metadata

[Olivier Berger]

On Sun, Jun 13, 2010 at 03:52:55PM +0200, Olivier Berger wrote:
> 
> Along the lines described in http://www.asheesh.org/note/debian/rdfa-pts, it 
> would be great if the PTS provided RDFa metadata.
> 

Btw, there could be interest for other flavours of RDF, so I've just filed a 
wishlist in the more general sense of RDF as #685605.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120822134335.GA3007@inf-8657

Bug#585740: qa.debian.org: Would be great if the PTS could provide RDFa metadata

[Olivier Berger]

On Fri, Jun 03, 2011 at 06:42:47PM +0200, Olivier Berger wrote:
> On Sun, Jun 13, 2010 at 03:52:55PM +0200, Olivier Berger wrote:
> > 
> > Maybe this ontology : 
> > http://github.com/nbarrientos/steamy/blob/master/ontologies/debian.owl 
> > could be a good candidate for representing package metadata in RDF.
> 
> I think SPDX (http://spdx.org) would be an even better standard for package 
> identification. This would be natively linked to DEP5 efforts, as SPDX is 
> standardizing a lot on this (see http://dep.debian.net/deps/dep5/).
> 

ADMS.SW may provide useful ontology for Software Repository / Project / Package 
/ Release description too, FWIW.

HtH.

[0] http://joinup.ec.europa.eu/asset/adms_foss/description
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120822122422.GA16466@inf-8657

Bug#685605: qa.debian.org: Would be great if the PTS could provide RDF descriptions of packages

[Olivier Berger]

Package: qa.debian.org
Severity: wishlist

Hi.

There exist a few specification addressing the need of standardization of RDF 
descriptions for Software Packages, like SPDX [0] or ADMS.SW [1].

I guess it would be great if the PTS could export on the Linked Open Data graph 
/ Semantic Web, descriptions of the Debian packages, using RDF, with the 
aforementioned standards.

This would enable future discovery of links between projects, packages, 
releases and such by machines exploiting such self descriptive documents.

A classical form of such publishing could be achieved through content 
negociations of URLs of the PTS in order to access RDF+XML or JSON 
representations instead of HTML ones.

At least for consuming / GET access, this would provide an alternative to the 
SOAP interface.

A variant could be to embed RDFa inside the HTML, as previously proposed in 
#585740

Hope this helps.

Best regards,

[0] http://spdx.org
[1] https://joinup.ec.europa.eu/asset/adms_foss/description

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120822123340.16524.77980.report...@inf-8657.int-evry.fr

Re: Fwd: Today the public review period for ADMS.F/OSS v0.3 began

[Olivier Berger]

Hi.

Enrico Zini  writes:

> On Fri, May 11, 2012 at 02:25:13PM +0200, Olivier Berger wrote:
>
>> You may be interested in knowing that a draft of a vocabulary intended
>> to be used for describing software developped in forges, or listed in
>> catalogues has been published by a working group attached to the
>> European Commission (ISA programme), for review by the public.
>> 
>> I imagine it could well be used some day to publish metadata about
>> Debian distributions and or software packaged in Debian on the Semantic
>> Web (for instance to interlink records of an upstream software, some
>> user reviews, its debian packages, and other distributions', etc.).
>
> I'm sorry I don't have the time to participate personally, but should
> you need something to complement Trove categories, there are several
> facets in Debtags that are pretty well defined and useful.
>
SNIP

FYI and for reference, your response has been pointed to from the
comments forum at :
https://joinup.ec.europa.eu/asset/adms_foss/issue/consider-use-debtags-alternative-trove-classification-system-software

>
> If you need anything debtags-related, you know where to find me: I hope
> I'll be able to respond in a timely manner.
>

We'll see how things are moving for the next steps of ADMS.F/OSS, but I
do hope interoperability with Debian metadata, like debtags will be one
of the ideas implementation-wise.

Thanks for the feedback.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa16oj3b@inf-8657.int-evry.fr

Fwd: Today the public review period for ADMS.F/OSS v0.3 began

[Olivier Berger]

Hi.

Sorry in advance for cross-posting / duplicate.


You may be interested in knowing that a draft of a vocabulary intended
to be used for describing software developped in forges, or listed in
catalogues has been published by a working group attached to the
European Commission (ISA programme), for review by the public.


I imagine it could well be used some day to publish metadata about
Debian distributions and or software packaged in Debian on the Semantic
Web (for instance to interlink records of an upstream software, some
user reviews, its debian packages, and other distributions', etc.).


I'm participating to the working group, not with any official Debian
developer role there (and probably more with my FusionForge contributor
hat on), but still, I'm trying to keep things reasonably compliant to
what I imagine could benefit Debian in the end.


Don't hesitate to provide your comments, so that we can improve the
vocabulary, and match your organisation's needs in the future steps.

More details at :
https://joinup.ec.europa.eu/asset/adms_foss/news/vocabulary-software-metadata-released-public-review

Best regards,


---

Dear all,

On May 2 2012, the public review period for the ADMS.F/OSS v0.3 [1] 
metadata vocabulary has started. 

ADMS.F/OSS is a metadata vocabulary to describe free and open-source 
software (F/OSS) assets, making it possible to more easily explore, find, 
and link software assets on the Web by interlinking software forges.  The 
work has been initiated by the Interoperability Solutions for European 
Public Administrations (ISA) [2] Programme of the European Commission and 
was carried out from January till April 2012 by a multi disciplinary 
Working Group  [3] of 45 people from 14 different countries. ADMS.F/OSS 
aims at maximally reusing existing specifications, such as DOAP [4], ADMS 
[5], and the Trove software map [6]. 
The process and methodology followed in the development of ADMS.F/OSS is 
set out in detail in the document ?Process and Methodology for Developing 
Core Vocabularies?. Further background is available in the studies "Vision 
for an enhanced software description metadata schema and software 
catalogue for e-Government? and ?Report on existing Software Forges? which 
offers an overview and context for the work. 
ADMS.F/OSS v0.3 is open for public comments until June 2 2012. During this 
period, members of the public are invited to download the specification 
and share their public review by posting comments to the forum. 
How can you help?
We kindly invite you to contribute to this specification by submitting 
your comments on the ADMS.F/OSS Specification v0.3:
1. Download the ADMS.F/OSS v0.3 [1] specification; and
2. Comment* the ADMS.F/OSS v0.3 Specification by using the ADMS.F/OSS 
public review forum topic  [8] (registration on Joinup [9] required).

What happens with your feedback?
All comments and feedback received will be registered as issues and 
discussed with the Working Group in June. Resolutions of those issues will 
be shared on Joinup, and will lead to a final version of the specification 
that will be submitted for endorsement by the EU Member States.
[1] https://joinup.ec.europa.eu/asset/adms_foss/release/03
[2] http://ec.europa.eu/isa/ 
[3] https://joinup.ec.europa.eu/asset/adms_foss/wiki/admsf/oss-working-group
[4] http://github.com/edumbill/doap
[5] https://joinup.ec.europa.eu/asset/adms/description
[6] 
http://sourceforge.net/apps/trac/sourceforge/wiki/Software%20Map%20and%20Trove
[8] 
https://joinup.ec.europa.eu/asset/adms_foss/topic/public-comments-admsf/oss-v03
[9] https://joinup.ec.europa.eu/user/register


-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871umqykeu@inf-8657.int-evry.fr

Re: DEP-2: Debian Package Maintenance Hub

[Olivier Berger]

Hi again.

On Fri, 27 Jan 2012 07:49:40 +0100, Raphael Hertzog  wrote:
> 
> PS: I start the discussion within the QA team but once the proposal is
> better formalized, I'll move the discussion to a wider audience (i.e.
> -devel or -project).
> 

I haven't checked for the rules of DEP elaboration, but may I suggest to
add a notice in http://dep.debian.net/deps/dep2/ about where it is being
discussed / how to provide feedback ?

My 2 cents,

Best regards,

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wr86ilp9@inf-8657.int-evry.fr

Interoperability with forges - Was: Re: DEP-2: Debian Package Maintenance Hub

[Olivier Berger]

Hi.

On Mon, 30 Jan 2012 09:18:20 +0100, Raphael Hertzog  wrote:
> On Sun, 29 Jan 2012, Charles Plessy wrote:
> 
> > Lastly, perhaps the DEP can discuss brifely why a new development is 
> > necessary,
> > compared to using or extending existing tools, such as Launchpad or other
> > forges.
> 
> Do you feel like suggesting a text for this? To me it seems obvious that
> there's not much in common with Launchpad or a forge and that we're
> building an infrastructure tailored to the very specific use case of the
> Debian project.
> 

Since alioth is used by quite a lot of Debian teams of individual
maintainers, it seems to me that it would be great if the new system and
alioth projects could be integrated somehow. 

If we consider Continuous Integration scenari, for instance, it would be
great to have the possibility to build and prepare packages from alioth
projects, and run tests before being able to upload them.

Of course, SSO would be a plus between both tools.

Also, reusing existing solutions to avoid having to develop some
low-level components.

I think the code of FusionForge is a bit too old to be reused
efficiently, though.

LaunchPad seems to closed to me too.

Maybe Allura [0], the new AGPL software used by SourceForge could be a
candidate, as it seems much more modern, Python based, and seems to have
been developped with performance / distribution constraints in mind.

It seems to be quite modular, but I haven't been able to conduct a
thoroughful enough study of it.

Will provide other comments in separate emails.

Best regards,

[0] http://sourceforge.net/p/allura/wiki/Allura%20Wiki/


-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa52k1wl@inf-8657.int-evry.fr

Re: DEP-2: Debian Package Maintenance Hub

[Olivier Berger]

Hi.

On Fri, 27 Jan 2012 07:49:40 +0100, Raphael Hertzog  wrote:
> Hello,
> 
> I would like to design a new infrastructure that would replace the DDPO
> and the PTS, fix many current problems, and enable us to introduce new
> features to help package maintainers.
> 

Here are a few comments on this very interesting proposal.

Do you intend to have such a system usable by / integrated with
derivative distributions ?

I'm also thinking at the usefulness of it for mentors or PPA like
package managing services.


Maximizing interoperability with other software / package tools (outside
the only pure "Debian" scope) should be an important goal IMHO, in
particular in seeking standards to rely on in order to facilitate
development of complementary tools (client side), and integration with
other distributions, upstream/downstreams.

Among these, I'd suggest that REST [0] APIs would be very much
interesting IMHO, in particular if the exchanges with it can be RDF [1]
encoded as JSON, to provide compatibility with standards like OSLC [2],
SPDX [3] or ADMS.F/OSS [4]. I'm not sure if your initial technology
candidates (Django) can provide this upfront, though.

I'll describe quickly the benefits of these standards or specifications:
- REST : building on Web in R+W modes as much as possible is the current
  trend, and provides out of the box content-negociated publication of
  data under different formats with the right underlying frameworks
- RDF : the standard for extensible representation of meta-data. I know
  lots of Debian geeks like YAML, but RDF is a Web standard, and when
  written as turtle/ N3 or JSON, doesn't bring much burden (unlike
  RDF/XML). Debian meta-data about software, packages, maintaners, bugs,
  etc. could be much better interlinked with their counterparts in other
  projects Distros living on the Web through RDF representations (see
  SPDX and ADMS.F/OSS below)
- OSLC : a proposed standard for interoperability of development
  tools. It could be the building block for integrating Eclipse or
  various IDE and client tools (or other server tools) with the Debian
  tools using a standard, and not yet another "proprietary" (meaning
  original) set of SOAP, XMLRPC or whatever APIs.
- SPDX : a proposed meta-data representation standard for copyright
  licenses and such properties of packages (cross distro work ongoing)
- ADMS.F/OSS : an early initiative to standardize software / software
  project descriptions for forges / software catalogues

I hope these are useful contributions.

Best regards,

[0] http://en.wikipedia.org/wiki/Representational_state_transfer
[1] http://en.wikipedia.org/wiki/Resource_Description_Framework
[2] http://open-services.net/specifications/
[3] http://spdx.org/
[4] http://joinup.ec.europa.eu/asset/adms_foss/home/

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762fqk10f@inf-8657.int-evry.fr

Bug#585740: qa.debian.org: Would be great if the PTS could provide RDFa metadata

[Olivier Berger]

On Sun, Jun 13, 2010 at 03:52:55PM +0200, Olivier Berger wrote:
> 
> Maybe this ontology : 
> http://github.com/nbarrientos/steamy/blob/master/ontologies/debian.owl could 
> be a good candidate for representing package metadata in RDF.

I think SPDX (http://spdx.org) would be an even better standard for package 
identification. This would be natively linked to DEP5 efforts, as SPDX is 
standardizing a lot on this (see http://dep.debian.net/deps/dep5/).

Hope this helps.

Best regards,



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110603164247.GA22449@inf-8657

Bug#628066: /usr/bin/uscan: uscan suddenly giving error 404 for SF redirector

[Olivier Berger]

On Thu, May 26, 2011 at 07:37:27PM -0400, James Vega wrote:
> On Fri, May 27, 2011 at 02:26:31AM +0530, Onkar Shinde wrote:
> > Uscan has suddenly started failing for me since today for watch files that 
> > use SF redirector. It was working till yesterday.
> > 
> > Following is the error seen for 'uscan --verbose --report' in cdk source 
> > package.
> > 
> > onkar@iBook:~/programs/cdk-1.2.8$ uscan --verbose --report
> > -- Scanning for watchfiles in .
> > -- Found watchfile in ./debian
> > -- In debian/watch, processing watchfile line:
> >http://sf.net/cdk/ cdk-(1\.[2468]\.[\d\.]+)\.tar\.gz debian uupdate
> > uscan warning: In watchfile debian/watch, reading webpage
> >   http://qa.debian.org/watch/sf.php/cdk/ failed: 404 File Not Found
> > -- Scan finished
> 
> $ curl -I http://qa.debian.org/watch/sf.php/cdk/
> HTTP/1.1 404 File Not Found
> Date: Thu, 26 May 2011 23:31:56 GMT
> Server: Apache
> X-Powered-By: PHP/5.3.3-7+squeeze1
> Vary: Accept-Encoding
> Content-Type: text/html
> 
> This is happening for every project I tried.
> 

Could this be related to #626254 ?

Hope this helps.

My 2 cents,




-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110527110314.GA7124@inf-8657

Bug#626756: "Watch" column is all empty -- seems that uscanning is broken

[Olivier Berger]

On Sat, May 14, 2011 at 09:57:17PM -0400, Yaroslav Halchenko wrote:
> 
> Looked at qa Packages overview and Watch columns are all empty, where
> before they functioned just fine and informed me about existing new upstream
> versions.
> 
> Cheers,
> 

IMHO, this seems to be related to problems with DEHS. For instance, see also 
#626254.

Hope this helps.

Best regards,



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110515095913.GA6905@inf-8657

Bug#626254: qa.debian.org: DEHS Division by zero in ...

[Olivier Berger]

Package: qa.debian.org
Severity: normal

FYI, http://dehs.alioth.debian.org/no_watch.html displays :
Total source packages without watch file: 0 Total source packages: 0 Share: 
Warning: Division by zero in 
/srv/alioth.debian.org/chroot/home/groups/dehs/dehs_prj/trunk/www/no_watch.php 
on line 64 0.00%

I believe there's something broken there.

Hope this helps.

Best regards,

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'stable'), (250, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110510095728.15061.5.report...@inf-8657.int-evry.fr

Bug#623209: qa.debian.org: [PTS] shows incorrect unstable version for package fusionforge in versions block

[Olivier Berger]

Package: qa.debian.org
Severity: normal

Currently, I can see in http://packages.qa.debian.org/f/fusionforge.html that 
"[2011-04-15] Accepted 5.0.3-1 in unstable (low) (Roland Mas)", however, the 
versions block only shows :

stable 5.0.2-5 
testing 5.0.2-5 
unstable 5.0.2-5 

Hope this helps.

Best regards,


-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110418114340.22214.11781.report...@inf-8657.int-evry.fr

Re: [UDD] Improved link between LP bug tasks watching Debian bugs and debbugs ids

[Olivier Berger]

Le mardi 10 août 2010 à 10:43 +0200, Lucas Nussbaum a écrit :
> On 04/08/10 at 19:28 +0200, Andreas Tille wrote:
> > On Wed, Aug 04, 2010 at 06:29:02PM +0200, Olivier Berger wrote:
> > > I'd suggest to add a table like :
> > > 
> > > CREATE TABLE whatever AS
> > > SELECT bug, int4(substring(watch from 
> > > 'http://bugs.debian.org/cgi-bin/bugreport\\.cgi\\?bug=(\\d+)')) as 
> > > debian_bugid
> > > FROM ubuntu_bugs_tasks WHERE
> > > watch LIKE 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%';
> > > 
> > > ...
> > > 
> > > Any comments ?
> > 
> > Sounds reasonable
> 
> Couldn't this be simply done as a VIEW ? Or is it too
> performance-critical?

I guess a view could do it, but I'm afraid the regex consumes quite some
CPU, and thus doesn't help creating joins between ubuntu tasks and
debian bugs.

So probably a table would be better. Sorry, I can't do any measurements
on performance between the two options, being on vacation ATM.

Best regards,

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1281534115.32080.1.ca...@inf-8657.int-evry.fr

[UDD] Improved link between LP bug tasks watching Debian bugs and debbugs ids

[Olivier Berger]

Hi.

Working on the D2R RDF exporter for UDD [0], I noticed that it could be
practical to record a link between LP tasks ('ubuntu_bugs_tasks' table)
that correspond to Debian bugs and the Debian bugs counterparts (in
table 'bugs') : in the 'ubuntu_bugs_tasks.watch' column contains bugs
from their CGI URLs
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=).

I'd suggest to add a table like :

CREATE TABLE whatever AS
SELECT bug, int4(substring(watch from 
'http://bugs.debian.org/cgi-bin/bugreport\\.cgi\\?bug=(\\d+)')) as debian_bugid
FROM ubuntu_bugs_tasks WHERE
watch LIKE 'http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%';


It'd then look like :

bug debian_bugid 
3080 449983
3198 457997
3611 134346
3804 265443
4844 423748
5385 298691
5608 378454
6707 502927
...

Any comments ?

Best regards,

[0]: 
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1280939342.3633.15.ca...@inf-8657.int-evry.fr

Bug#585740: See our D2R wrapper for UDD that provides RDF for Debian artifacts

[Olivier Berger]

Le vendredi 30 juillet 2010 à 17:06 -0400, Don Armstrong a écrit :
> On Fri, 30 Jul 2010, Olivier Berger wrote:
> > On Fri, Jul 30, 2010 at 11:31:55AM +0200, Olivier Berger wrote:
> > > It would be great if bug lists or bug pages could include RDFa
> > > content.
> > > 
> > > Such content could be basic bug description.
> > 
> > For an example of what kind of RDF metadata could be obtained for
> > Debian bugs, here's a server we have setup, which provides some RDF
> > descriptions of bugs out of what is contained in the UDD database :
> > http://testforge.int-evry.fr/d2r-server/
> > 
> 
> Sounds interesting; just for my priority, etc, do you have an idea of
> how this information that you collect is going to be used eventually?
> 

Many ideas ;)

Mainly in providing lists of bugs that relate to same people or same
packages. Such lists could be semantic feeds, to which people and apps
could subscribe in other apps and/or desktop environments (semantic
desktop, etc.)

Imagine such meta-data repositories for many distributions bugtrackers,
where one can query for instance bugs on same sets of packages or bugs
he/she submitted in all these, using the same query language (SPARQL +
same ontologies)

For instance, upstream maintainers could monitor bugs on the packages
for their programs in various downstream package bugtrackers.

Provided that such information is in RDF and using compatible
ontologies, it becomes semantically interoperable... that's the end
goal. 

All this will require using DOAP to describe upstream projects, and a
common ontology for packages, and a common ontology for links betw. bugs
and packages... that's things we're working on, and our D2R server is
meant to help test these.

You may refer to a paper of ours for the general picture : "Weaving a
Semantic Web Across OSS Repositories: Unleashing a New Potential for
Academia and Practice" [0] (preprint available on demand).

> [I'm also interested in trying to make sure that whatever
> inter-bug-tracker formats we settle on exporting are more widely
> supported, as my time to understand and implement format translators
> is relatively limited.]

OSLC-CM V2's ChangeRequest specs [2] could be a valid candidate for
encoding bug properties, either as RDFa or for plain RDF documents.

Here I'm speaking only about the static dimention of OSLC-CM (RDF
descriptions of bugs/change requests), not the REST protocol part,
discussed in #565513.

But OSLC lacks things like relations between bugs and packages, and
that's what we're trying to work on in drafting a compatible ontology
[1].

It's not all completely finished and our demonstrator is here to try and
verify if our ontology choices are compatible with applications.

Of course, when things clarify, it would be great to implement such
extractors on debbugs side directly instead on separate converters ;)

> 
> 
> Don Armstrong

Best regards,

[0] 
http://www-public.it-sudparis.eu/~berger_o/weblog/2010/07/29/weaving-a-semantic-web-across-oss-repositories-unleashing-a-new-potential-for-academia-and-practice-published/
[1] 
http://sourceforge.net/apps/wordpress/heliosplatform/2010/06/04/first-draft-of-helios_bt-bug-ontology-request-for-comment/
[2] 
http://open-services.net/bin/view/Main/CmSpecificationV2#CM_Resource_Definitions

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)




--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1280526331.3864.32.ca...@inf-8657.int-evry.fr

Re: UDD export as RDF data through D2R and a corresponding mapping definition

[Olivier Berger]

Hi

FYI, here's the return of our tool to do some UDD facts export as RDF.

Here's a server we have setup, which provides some RDF descriptions of
bugs out of what is contained in the UDD database :
http://testforge.int-evry.fr/d2r-server/

This is work in progress and not meant for end-users. For reference on
how we installed D2R to deploy this :
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF


One will find metadata about bugs, but also some metadata about Debian
packages (minimal), or Debbugs users (bug submitters), and Debian
developers (out of carnivore), as SIOC and FOAF bits.


Given one bug number, one may get an XML/RDF version using :
 curl -H 'Accept: application/rdf+xml'  
http://testforge.int-evry.fr/d2r-server/data/debbugs/585740

or the N3 version with :
 curl -H 'Accept: text/rdf+n3'  
http://testforge.int-evry.fr/d2r-server/data/debbugs/585740


Btw, on our D2R server, one can also query custom searches using SPARQL. For 
instance :
http://testforge.int-evry.fr/d2r-server/snorql/?query=SELECT+DISTINCT+*+WHERE+{%0D%0A++%3Fs+%3Fp+%3Fo.%0D%0A++%3Fs+owl%3AsameAs+%3Chttp%3A%2F%2Fbugs.debian.org%2F585740%3E.%0D%0A}%0D%0ALIMIT+10
 which will search bug properties for bug #585740 :
 SELECT DISTINCT * WHERE {
  ?s ?p ?o.
  ?s owl:sameAs <http://bugs.debian.org/585740>.
 }
 LIMIT 10


About people, for an example, here's my FOAF profile :
http://testforge.int-evry.fr/d2r-server/resource/foafcarnivore/6688a14521cd97db162af8f9757f2e2232300e50

Given one's email address, it's easy to access one's FOAF profile there
with for instance :
 curl -H 'Accept: application/rdf+xml'  
http://testforge.int-evry.fr/d2r-server/data/foafcarnivore/`echo -n 
"mailto:$DEBEMAIL"; | sha1sum | sed 's/ .*$//'`


FYI, on related topics, I've filed to wishlists, respectively for
debbugs and the PTS :

* #590931: Would be great to integrate RDFa metadata into debbugs pages 

* #585740: Would be great if the PTS could provide RDFa metadata


Any comments welcome.


Le mercredi 18 mars 2009 à 13:28 +0100, Olivier Berger a écrit :

> I've been pursuing previous ideas about the use of Semantic Web
> standards for publication of facts about Debian using the UDD database
> as a source.
> 
> FYI, I have a running prototype (unfortunately only on my laptop at the
> moment, hopefully on the Web some day soon) which uses D2R [1], a server
> which can publish RDBMS tables as RDF documents, using a mapping
> description.
> 
> I'm documenting bits of what I've done in
> https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF
>  should you be interested.
> 
> This first prototype allow to express queries such as :
> SELECT DISTINCT ?b ?s WHERE {
>   ?b vocab:bugs_package <http://localhost:2020/resource/package/sympa>.
>   ?b debbugs:hasSubmitter ?s
> }
> 
> which returns a list of all bugs id and corresponding bug reporters
> "submitters" (From) addresses on the package sympa in the form of links
> to resources like :
> http://localhost:2020/resource/debbug/169102 - 
> http://localhost:2020/resource/foafdebbug/Olivier+Berger+%3Colivier.berger%40it-sudparis.eu%3E
> 
> which each point to different RDF documents like :
> http://localhost:2020/resource/debbug/169102 :
> debbugs:bugUrl <http://bugs.debian.org/169102> 
> debbugs:hasSubmitter 
> db:foafdebbug/Olivier+Berger+%3Colivier.berger%40it-sudparis.eu%3E 
> debbugs:number 169102
> debbugs:summary "sympa: Lack of exim configuration for pipe transport"
> vocab:bugs_arrival "2002-11-14T16:48:05"^^xsd:dateTime
> vocab:bugs_package db:package/sympa 
> vocab:bugs_severity debbugs:Important 
> rdf:type debbugs:Debbug 
> rdfs:label "Debian bug #169102"
> 
> and 
> http://localhost:2020/resource/foafdebbug/Olivier+Berger+%3Colivier.berger%40it-sudparis.eu%3E
>  :
> rdf:type foaf:Person
> foaf:mbox <mailto:olivier.ber...@it-sudparis.eu>
> foaf:mbox_sha1sum "6688a14521cd97db162af8f9757f2e2232300e50"
> foaf:name "Olivier Berger"
>  and with inverse relationships :
> debbugs:hasSubmitter  db:debbug/169102
> debbugs:hasSubmitter db:debbug/208203 
> ...
> 
> This is obtained with a simple mapping of data from the bugs table in
> UDD to several ontologies like "foaf", and "debbugs" (a fictive one).
> 
> When running such sparql queries, or navigating the URLs provided by
> D2R, the mapping is applied and corresponding SQL queries are done on
> the UDD database (like :
> 
> SELECT DISTINCT 1 FROM "d2r_bu

Bug#585740: See our D2R wrapper for UDD that provides RDF for Debian artifacts - Was: Re: Bug#590931: Would be great to integrate RDFa metadata into debbugs pages

[Olivier Berger]

On Fri, Jul 30, 2010 at 11:31:55AM +0200, Olivier Berger wrote:
> 
> Hi.
> 
> It would be great if bug lists or bug pages could include RDFa content.
> 
> Such content could be basic bug description.
> 

For an example of what kind of RDF metadata could be obtained for Debian bugs, 
here's a server we have setup, which provides some RDF descriptions of bugs out 
of what is contained in the UDD database :
http://testforge.int-evry.fr/d2r-server/

This is work in progress and not meant for end-users. For reference on how we 
installed D2R to deploy this : 
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF

One will find metadata about bugs, but also some metadata about Debian packages 
(minimal), or Debbugs users (bug submitters), and Debian developers (out of 
carnivore), as SIOC and FOAF bits.


Given one bug number, one may get an XML/RDF version using :
curl -H 'Accept: application/rdf+xml'  
http://testforge.int-evry.fr/d2r-server/data/debbugs/585740

or the N3 version with :
curl -H 'Accept: text/rdf+n3'  
http://testforge.int-evry.fr/d2r-server/data/debbugs/585740


Btw, on our D2R server, one can also query custom searches using SPARQL. For 
instance :
http://testforge.int-evry.fr/d2r-server/snorql/?query=SELECT+DISTINCT+*+WHERE+{%0D%0A++%3Fs+%3Fp+%3Fo.%0D%0A++%3Fs+owl%3AsameAs+%3Chttp%3A%2F%2Fbugs.debian.org%2F585740%3E.%0D%0A}%0D%0ALIMIT+10
 which will search bug properties for bug #585740 :
 SELECT DISTINCT * WHERE {
  ?s ?p ?o.
  ?s owl:sameAs <http://bugs.debian.org/585740>.
 }
 LIMIT 10


About people, for an example, here's my FOAF profile : 
http://testforge.int-evry.fr/d2r-server/resource/foafcarnivore/6688a14521cd97db162af8f9757f2e2232300e50

Given one's email address, it's easy to access one's FOAF profile there with 
for instance :
curl -H 'Accept: application/rdf+xml'  
http://testforge.int-evry.fr/d2r-server/data/foafcarnivore/`echo -n 
"mailto:$DEBEMAIL"; | sha1sum | sed 's/ .*$//'`

Any comments welcome.

Best regards,



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100730154049.ga9...@inf-8657

Bug#585740: qa.debian.org: Would be great if the PTS could provide RDFa metadata

[Olivier Berger]

On Sun, Jun 13, 2010 at 03:52:55PM +0200, Olivier Berger wrote:
> 
> Hi.
> 
> Along the lines described in http://www.asheesh.org/note/debian/rdfa-pts, it 
> would be great if the PTS provided RDFa metadata.
> 
> I think it lacks just a few modifications in order to provide proper RDFa in 
> the XHTML output, that could be exploited by Semantic Web applications.
> 
> Maybe this ontology : 
> http://github.com/nbarrientos/steamy/blob/master/ontologies/debian.owl could 
> be a good candidate for representing package metadata in RDF.
> 
> Also maybe an interesting pointer : 
> http://www.golden-gryphon.com/blog/manoj/blog/2009/04/22/Ontologies__58___Towards_a_generic__44___distribution_agnostic_tool_for_building_packages_from_a_VCS/
> 
> Hope this helps.
> 
> Best regards,
> 

FYI, I filed a similar wishlist for debbugs : #590931

Best regards,



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100730094207.ga11...@inf-8657

Bug#585740: qa.debian.org: Would be great if the PTS could provide RDFa metadata

[Olivier Berger]

Package: qa.debian.org
Severity: wishlist

Hi.

Along the lines described in http://www.asheesh.org/note/debian/rdfa-pts, it 
would be great if the PTS provided RDFa metadata.

I think it lacks just a few modifications in order to provide proper RDFa in 
the XHTML output, that could be exploited by Semantic Web applications.

Maybe this ontology : 
http://github.com/nbarrientos/steamy/blob/master/ontologies/debian.owl could be 
a good candidate for representing package metadata in RDF.

Also maybe an interesting pointer : 
http://www.golden-gryphon.com/blog/manoj/blog/2009/04/22/Ontologies__58___Towards_a_generic__44___distribution_agnostic_tool_for_building_packages_from_a_VCS/

Hope this helps.

Best regards,

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100613135255.25417.22401.report...@inf-8657.int-evry.fr

Re: retitling old ITA/ITP bugs to O/RFP

[Olivier Berger]

Le lundi 24 mai 2010 à 21:27 +0200, Lucas Nussbaum a écrit :
> Hi,
> 
> David Moreno Garza used to run a script that retitled old ITA/ITP bugs
> to O/RFP. Since this was a useful service, I reimplemented it, and have
> been running it today with fairly conservative settings (18 months of
> inactivity for both ITP and ITA). (the script is available in
> collab-qa/retitle-old-ita-itp -- it's not run by cron yet ; see #501257
> for an example bug modified by the script)
> 
> It seems to me that this 18 months delay is too much. I'm not sure if
> someone has done the data-mining for that, but I think that most
> "successful" ITP/ITA are processed quite fast (in less than a month).
> 
> So, I'd like to run the script with more aggressive settings, like "3
> months of complete inactivity" for both ITP and ITA.
> 
> What do you think?

Maybe just reverting to prior state : if RFP before ITP, then revert to
RFP, otherwise, if direct ITP, then close ...

Just my 2 cents,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1274816776.7248.1.ca...@inf-8657.int-evry.fr

Re: Lots of old .orig.tar.gz in incoming ?

[Olivier Berger]

Le dimanche 04 avril 2010 à 09:53 +0200, Sandro Tosi a écrit :
> Hello Olivier,
> 
> On Sun, Apr 4, 2010 at 09:02, Olivier Berger
>  wrote:
> > Hi.
> >
> > I've had a look at http://incoming.debian.org/?C=M;O=A and notice a lot
> > of old .orig tarballs.
> >
> > Is this on purpose ?
> 
> http://lists.debian.org/debian-devel-announce/2010/04/msg5.html
> 

Uh... yes, I'm well aware of the ries hardware problems... but that
ain't the point I think.

The fact is that there are quite a lot of .orig.tgz without the rest of
the source packages, dating back 1997... so... :-/

Thanks for the pointers, but I'm already subscribed ;)

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1270376027.27439.2.ca...@inf-8657.int-evry.fr

Lots of old .orig.tar.gz in incoming ?

[Olivier Berger]

Hi.

I've had a look at http://incoming.debian.org/?C=M;O=A and notice a lot
of old .orig tarballs.

Is this on purpose ?

Just wondering...

My 2 cents,

Best regards.
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1270364555.27439.0.ca...@inf-8657.int-evry.fr

Retrieving all "forwarded-upstream" Debian bugs ?

[Olivier Berger]

Hi.

Is there a way to retrieve the list of all bugs forwarded upstream in
Debian (and watching its evolution maybe) ?

I was thinking about UDD, but I'm not sure this can be easily retrieved.

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1268819229.8874.246.ca...@inf-8657.int-evry.fr

Re: Gathering package upstream meta-data in the UDD. (was: Re: more formally indicating the registration URL)

[Olivier Berger]

Hi.

(Responding a little late after vacation time.)

Le lundi 26 octobre 2009 à 23:05 +0900, Charles Plessy a écrit :
> > On Thu, Oct 22, 2009 at 12:30:06AM +0900, Charles Plessy wrote:
> > > First of all, let's summarise the situation. We want to integrate some 
> > > metadata
> > > in our 'web sentinels', like 
> > > 'http://debian-med.alioth.debian.org/tasks/bio'.
> 
> Dear Andreas and Olivier,
> 
> thank you for your encouraging comments. 

SNIP

> In parallel, as Olivier suggested, each table could be exprorted in RDF 
> format.
> But I am not sure I undersand it.

What exactly don't you understand ? ;) If you look back at the pointers
I provided in http://lists.debian.org/debian-qa/2009/10/msg00050.html
you'll find an example of using the PRISM and CONNOTEA ontologies for
links with DOI and PUBMED IDs (more details in
http://www.prismstandard.org/resources/mod_prism.html maybe).

>  Olivier, could you suggest a Perl module to
> use?
> 

I suppose that searching for perl+rdf on your preferred search engine
will retrieve useful code ;)

I'm not a perl hacker myself, but as RDF is a standard of the W3C, there
are probably plenty of perl code to produce RDF.

http://search.cpan.org/~mthurn/RDF-Simple-0.415/lib/RDF/Simple/Serialiser.pm 
seems to be a valid candidate for first experiments.

Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Using RDF and ontologies for such metadata (combined DOAP and other ontologies) Was: Re: Gathering package upstream meta-data in the UDD. (was: Re: more formally indicating the registration URL)

[Olivier Berger]

Hi.

(responding with more feedback as I have taken time to dig the
debian-med archives)

If I get it right, you intend to match bibliographic references and
software projects / packages ?

I'd very much suggest adopting a Semantic Web perspective in a way to
provide such links as RDF descriptions that can use ontologies used
already by other applications, hence contributing to LinkedData [0]
(maybe through microformats embedded as RDFa in the current 'web
sentinels' or as specific RDF feeds.

For an example of such application, see :
http://www.connotea.org/rss/search?q=SAMtools
which mixes RSS 1.0 with other ontologies (and exactly the same example
you provided more or less).

Here, you may then link DOAP [1] with existing bibliographic ontologies
like PRISM.

This of course could be provided from UDD also if UDD was to participate
more to the Semantic Web as I proposed in
http://lists.debian.org/debian-qa/2009/02/msg00016.html and further
discussions.

Just my 2 cents,

[0] : http://linkeddata.org/
[1] : http://trac.usefulinc.com/doap

Btw, :

Le jeudi 22 octobre 2009 à 09:49 +0200, Andreas Tille a écrit :

> Alternatively we could do
> 
> CREATE TABLE upstream-metadata (
> package text,
> key text,
> value   text,
> PRIMARY KEY (package,key)
> );

This very much looks like triples of RDF, which could store any metadata
expressed in any RDF ontology, so that might be really useful ;)

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: Gathering package upstream meta-data in the UDD. (was: Re: more formally indicating the registration URL)

[Olivier Berger]

Hi.

(Having read what was forwarded to -qa only)

May I suggest to provide a little bit more details in a wiki page on
wiki.debian.org on this initiative, so that the context is more clear
for everybody potentially interested ?

I think there's probably a lot of interest beyond UDD for such metadata
standardization.

My 2 cents,

Le jeudi 22 octobre 2009 à 09:49 +0200, Andreas Tille a écrit :
> [debian-qa in CC because here we are discussing UDD issues.]
> 
> On Thu, Oct 22, 2009 at 12:30:06AM +0900, Charles Plessy wrote:
> > First of all, let's summarise the situation. We want to integrate some 
> > metadata
> > in our 'web sentinels', like 
> > 'http://debian-med.alioth.debian.org/tasks/bio'.
> 
> I would like to add that most probably there might evolve even other use
> cases for this kind of data.  Keeping this in mind we might consider
> moving the topic to debian-devel in the next stage of development.
> 
> > What I propose is to have a special file in the source packages for 
> > gathering
> > all possible useful informations, debian/upstream-metadata.yaml.
> 

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Bug#551655: UDD: add pseudo-packages information

[Olivier Berger]

Le lundi 19 octobre 2009 à 21:18 +0200, Sandro Tosi a écrit :

>  lucas: hi! is there a place in UDD where pseudo-packages are stored? 
> It doesn't seems so
>  no
>  lucas: do you think a table for them only would be usefult?
>  what's your definition of pseudo-packages?
>  lucas: objects like 'wnpp', 'wiki.d.o' and all the others defined in 
> BTS not present as source/bin packgae
>  lucas: 
> http://bugs.debian.org/pseudopackages/pseudo-packages.description
>  lucas: my need is that querying bugs, they come up, but there's no 
> table describing them
>  ok
>  sounds like a good idea to add such a table
>  maybe directly in the bugs importer
>  lucas: I'm going to report a bug report on this, just to don't 
> forgive about that; I'll try to work on UDD a bit 
> 

Shouldn't this be a property of the packages in their own table instead
of another table ?

My 2 cents,

Regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)




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

Debian bugs (coming from UDD) mentioned in my fetchbugs4.me teaser presentation

[Olivier Berger]

Hi.

Just a quick note to let you know that our attempts to publish Debian
bugs as RDF are moving slowly on.

I have talked at OSDCfr on Staurday about the project fetchbugs4.me
we're developping :
http://blog.fetchbugs4.me/post/2009/10/03/First-public-conference-about-fetchbugs4.me

I have also prepared a webcast (flash, sorry) which illustrates
navigation between Mandriva bugs and Debian bugs :
http://www-public.it-sudparis.eu/~berger_o/weblog/2009/10/03/first-webcast-of-a-demonstrator-of-our-bug-ontologys-use/

The Debian bugs, packages and people are exported from UDD.
The demonstrator may be navigated live if you copy the URL from the
webcast, and if you have the Tabulator plugin, for instance.

I'd like to be able to work on integrating such RDF export tools in the
Debian infrastructure (around UDD, or in debbugs)... if I have enough
time ;)

Any comments welcome.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Bug#547883: qa.debian.org: UDD : error on recreation from dump

[Olivier Berger]

Package: qa.debian.org
Severity: normal

Upon importing the UDD dump, I get :

ERREUR:  la relation « ldap » n'existe pas

(Hope you guys understand french ;-)

This seems to be in :
CREATE VIEW really_active_dds AS
SELECT DISTINCT carnivore_login.id, carnivore_login.login FROM 
carnivore_login, carnivore_keys, ldap WHERE carnivore_keys.id = 
carnivore_login.id) AND (carnivore_keys.key_type = 'keyring'::text)) AND 
(carnivore_login.login = ldap.login)) AND (ldap.activity_pgp > '2009-01-01 
00:00:00+00'::timestamp with time zone));

Hope this helps,

Best regards,

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: First working prototype - Was: Re: Triplification of bugs in UDD

[Olivier Berger]

Le jeudi 03 septembre 2009 à 17:45 +0200, Lucas Nussbaum a écrit :
> > > > 
> > > > So if there's a table that directly maps those SHA1 of the mailto:email
> > > > of the current carnivore_email and of the current bugs:submitter, that
> > > > will be really straightforward to make the query and format the results
> > > > as RDF.
> > > > 

SNIP

> > 
> > Hope this is clearer now.
> 
> OK.
> 

:-)

> Do you want a seperate table with (email, sha1) columns, or _email_sha1
> columns everywhere (e.g maintainer_email_sha1) ?

Dunno what's best when you collect data...

If it's just a matter of an additional join, that's quite easy in either
case.

I think that for carnivore_emails table it should be next to the mail.

Then for the bugs table submitters' emails... well... maybe they should
be added to carnivore somehow, even if we don't have yet a way to tie
them to GPG keys and so on ? But that would be too much integration of
data maybe (an added join betw bugs and carnivore for
non-maintainers ?) ?

Maybe a companion table for the bugs table with distinct emails and
their SHA for all bug submitters ?

It's basically up to you : you probably know much better the way you
separate data ;-)

Hope this helps,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: First working prototype - Was: Re: Triplification of bugs in UDD

[Olivier Berger]

Le jeudi 03 septembre 2009 à 16:33 +0200, Lucas Nussbaum a écrit :
> On 03/09/09 at 15:25 +0200, Olivier Berger wrote:
> > Le jeudi 03 septembre 2009 à 14:29 +0200, Lucas Nussbaum a écrit :
> > > On 28/07/09 at 20:13 +0200, Olivier Berger wrote:
> > > > Only small minor additions to the postgres DB are necessary to make
> > > > triplify work : a sha1 function and a table to match emails to their
> > > > sha1 mailto: hashes.
> > > 
> > > I'm not sure I understand how you plan to use this. If we have a table
> > > with all the sha1 hashes for email addresses in UDD, it will be
> > > straightforward to get the email address for a particular sha1.
> > 
> > IIRC, what we want to do is to use the SHA1(mailto:em...@domain.com)
> > results as components of the Semantic Web resources URIs to easily find
> > person's related facts, with a URI compatible syntax, and both some kind
> > of anonymity.
> > As an example we could imagine something like 
> > <http://udd.debian.org/resources/account/6688a14521cd97db162af8f9757f2e2232300e50>
> >  
> > as being one of my emails/accounts URI to fetch Debian facts about me 
> > (like the bugs I reported, etc.).
> > 
> > So if there's a table that directly maps those SHA1 of the mailto:email
> > of the current carnivore_email and of the current bugs:submitter, that
> > will be really straightforward to make the query and format the results
> > as RDF.
> > 
> > I hope I understood your question and responded to it, although I'm not
> > completely sure (too much brain overload).
> 
> Oh, so the idea is to never export email addresses in RDF, but only sha1
> hashes of email addresses. To make this easier, the DB will contain a
> mapping between emails sha1s.
> 
> Is it really necessary to hide them behind sha1 hashes? If the only
> concern is anonymity, I'm not sure that we should hide email addresses.
> After all, all the information is already public and easy to browse. See
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=lucas%40lucas-nussbaum.net,
> for example.

That's not absolutely necessary, and agree on the fake anonymity, but
that's a usual habit in FOAF instead of plain email :
http://xmlns.com/foaf/spec/#term_mbox_sha1sum

In the absence of an express consent of the Debian reporters to see
their plain emails in such RDF, maybe that's a wise default to use
SHA1... until people complain and plain email seems more useful.

> 
> Regarding URI-compatibility, wouldn't it be possible to use
> lucas%40lucas-nussbaum.net instead of a hash?

I suppose. Maybe once/if this is necessary/allowed only ?

In any case, the SHA1 is useful to match FOAF profiles with bug reports.
So even if you don't know the person's email and they just present their
FOAF "identity" to you : you'll still be able to fetch their bugs anyway
(and know their email, then, but you may not be forced to display it in
such case ;).

Hope this is clearer now.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: First working prototype - Was: Re: Triplification of bugs in UDD

[Olivier Berger]

Le jeudi 03 septembre 2009 à 14:29 +0200, Lucas Nussbaum a écrit :
> On 28/07/09 at 20:13 +0200, Olivier Berger wrote:
> > Only small minor additions to the postgres DB are necessary to make
> > triplify work : a sha1 function and a table to match emails to their
> > sha1 mailto: hashes.
> 
> I'm not sure I understand how you plan to use this. If we have a table
> with all the sha1 hashes for email addresses in UDD, it will be
> straightforward to get the email address for a particular sha1.

IIRC, what we want to do is to use the SHA1(mailto:em...@domain.com)
results as components of the Semantic Web resources URIs to easily find
person's related facts, with a URI compatible syntax, and both some kind
of anonymity.
As an example we could imagine something like 
<http://udd.debian.org/resources/account/6688a14521cd97db162af8f9757f2e2232300e50>
 
as being one of my emails/accounts URI to fetch Debian facts about me 
(like the bugs I reported, etc.).

So if there's a table that directly maps those SHA1 of the mailto:email
of the current carnivore_email and of the current bugs:submitter, that
will be really straightforward to make the query and format the results
as RDF.

I hope I understood your question and responded to it, although I'm not
completely sure (too much brain overload).

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Triplification of UDD : request for comments on live prototype

[Olivier Berger]

Hi.

As you probably know if you've read my messages so far, I've triplified
UDD in order to export facts like :
- bugs
- bug submitters 
- contributors (known in UDD in carnivore tables)
- bugs submitted, by submitter
- bugs by package
etc.

I've installed a demonstration server at :
http://kilauea.int-evry.fr:8081/triplify/UDD/ with the UDD dump I've
just downloaded. I hope the machine won't burn while you query it.

Here's a starting point to navigate the graph :
http://kilauea.int-evry.fr:8081/triplify/UDD/carnivore/949 (use any
number to try accessing other people's FOAF profiles)

You may also try and access UDD/user/XXX with XXX being
your SHA1-ized "mailto:yourm...@youraddress.com";, which is common
practice to represent email addresses on the Semantic Web (lile
foaf:mbox_sha1sum).

Of course the visualization of the RDF triples may be more interesting
with RDF enabled tools like firefox plugin "Tabulator
Extension" (https://addons.mozilla.org/en-US/firefox/addon/5596)

More docs are available at :
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/TriplifyUddToRdf

This still needs some polishing, but I hope it will illustrate some
interesting uses of the Semantic Web with UDD.

I'd like to get your feedback on that prototype.

Ultimately, I'd see something like this running on udd.debian.org using
content negociation, maybe ?

Or, for the bugs, on bugs.debian.org with a RDF output for every bug
queried, depending on content-negociation. For instance, a query asking
for RDF on http://bugs.debian.org/535171 would retrieve a document
similar to : http://kilauea.int-evry.fr:8081/triplify/UDD/issue/535171

Then, the URI http://bugs.debian.org/535171 would make such a bug a real
participant to LinkedData

Again, comments, remarks and critics much welcome.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

First working prototype - Was: Re: Triplification of bugs in UDD

[Olivier Berger]

Hi.

Thanks Lucas, for the changes in the bugs table. 

Now, it's more easy to convert to sioc:User and foaf:Person entities.

You can find an example of what we can achieve with triplify at 
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/TriplifyUddToRdf
 (look at the attachments saved from triplify running on my local machine)

Only small minor additions to the postgres DB are necessary to make
triplify work : a sha1 function and a table to match emails to their
sha1 mailto: hashes.

Next step is to try and make it live on the net.

Comments welcome.

Le vendredi 24 juillet 2009 à 18:43 +0200, Lucas Nussbaum a écrit :
> On 24/07/09 at 18:05 +0200, Olivier Berger wrote:
> > The hard part is the change in the database schema to split the
> > submitters email into name and email, to easily be able to match
> > carnivore entries with bug submitters (for some outdated explanations of
> > the views I used for doing so, see [1]).
> 
> This is now implemented in UDD (also for bug owners, and for the 'done'
> field -- bug closers). The columns should populate during the next run
> of the importers.
> -- 
> | Lucas Nussbaum
> | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
> | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
> 
> 
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

bugs.submitter_email problems Was: Re: Triplification of bugs in UDD

[Olivier Berger]

Hi.

FYI, there are a few bugs whose submitters don't have a valid email
address :
SELECT id, submitter, submitter_email FROM bugs WHERE submitter_email NOT LIKE 
'%...@%'

Some come from the parsing done at injection, and others from bad bug
reports, I suppose.

Maybe you'd like to check these ?

Best regards,

Le vendredi 24 juillet 2009 à 18:43 +0200, Lucas Nussbaum a écrit :
> On 24/07/09 at 18:05 +0200, Olivier Berger wrote:
> > The hard part is the change in the database schema to split the
> > submitters email into name and email, to easily be able to match
> > carnivore entries with bug submitters (for some outdated explanations of
> > the views I used for doing so, see [1]).
> 
> This is now implemented in UDD (also for bug owners, and for the 'done'
> field -- bug closers). The columns should populate during the next run
> of the importers.
> -- 
> | Lucas Nussbaum
> | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
> | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
> 
> 
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Triplification of bugs in UDD

[Olivier Berger]

.1/Person> .
<http://my.test.com/triplify/carnivore/7> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"8d731c75c9cd2894441c406cb846d961976f9dfa" .
<http://my.test.com/triplify/carnivore/7> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"1ff515cbbdc951ea1648666b51600b5065c859b7" .
<http://my.test.com/triplify/carnivore/9> 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://xmlns.com/foaf/0.1/Person> .
<http://my.test.com/triplify/carnivore/9> <http://xmlns.com/foaf/0.1/name> 
"Richard Jones" .
<http://my.test.com/triplify/carnivore/9> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"dee814e3ccf1b4d997bacebd98a37e45e9681f3d" .
<http://my.test.com/triplify/carnivore/11> 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://xmlns.com/foaf/0.1/Person> .
<http://my.test.com/triplify/carnivore/11> <http://xmlns.com/foaf/0.1/name> 
"Nelson A. de Oliveira" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"d42e15e16d7e539a56736a2c1f6bb9f37135c5b7" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/holdsAccount> 
<http://my.test.com/triplify/submitter/6b0bfccaaa1019f67cadc0040e7febfb7c082374>
 .
<http://my.test.com/triplify/carnivore/11> 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://xmlns.com/foaf/0.1/Person> .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/holdsAccount> 
<http://my.test.com/triplify/submitter/5f50d65fa42a1cb9ad0ee5db31916f929728be13>
 .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/holdsAccount> 
<http://my.test.com/triplify/submitter/d3fb5b620cb12d91f5e0cb1ce3ceb3c8c5ae16f0>
 .
<http://my.test.com/triplify/carnivore/11> <http://xmlns.com/foaf/0.1/name> 
"Nelson Antônio de Oliveira" .
<http://my.test.com/triplify/carnivore/11> <http://xmlns.com/foaf/0.1/name> 
"Nelson Antonio de Oliveira" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"e20643146342a85b22c7263f01b9caacc5ccb6f9" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"06478a0bf063694f548f712e8bc5e2030432ad9c" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"cc6802b418ca5b0bab03aa6eefe2b37ad0c81e71" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"6c1a75e152515f2fa6d90741297599343f96f608" .
<http://my.test.com/triplify/carnivore/11> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"1b3c562758d146570521e25361c97c761c73bf11" .
<http://my.test.com/triplify/carnivore/14> 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://xmlns.com/foaf/0.1/Person> .
<http://my.test.com/triplify/carnivore/14> <http://xmlns.com/foaf/0.1/name> 
"David Fernandez Vaamonde" .
<http://my.test.com/triplify/carnivore/14> 
<http://xmlns.com/foaf/0.1/email_sha1sum> 
"c992a0231335e3f24159d7b2bf0f0aa332aa3220" .
...
(in this snippet, you can see that apparently only carnivore person 11
seems to have submitted bugs still present in the 'bugs' table).

and finally :
$ php index.php submitter # outputs n3 RDF for bug submitters (SHA1 encoding of 
the bugs.submitter column)
<http://my.test.com>  "Generated by Triplify V0.5 
(http://Triplify.org)" .
<http://my.test.com> <http://creativecommons.org/ns#license> 
<http://creativecommons.org/licenses/by/3.0/us/> .
<http://my.test.com/triplify/submitter/00024e8d4bb0202f5385cdd81cedc552f40b44d4>
 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://rdfs.org/sioc/ns#User> .
<http://my.test.com/triplify/submitter/000a4f6137284eb2c425be6a7a2aa72d61ef1563>
 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://rdfs.org/sioc/ns#User> .
<http://my.test.com/triplify/submitter/000e3390bc460bd17929f80793956fb19b8875f5>
 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://rdfs.org/sioc/ns#User> .
<http://my.test.com/triplify/submitter/000ec09145f9cedb263c4c264ea71a218af158d2>
 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://rdfs.org/sioc/ns#User> .

So you can see that these RDF entities, put together, would interlink
bugs (issues) to bug submitters (kind of person's accounts) and persons
(when known by carnivore), when these persons have emails that can be
seen in UDD both in bugs.submitter and carnivore_email

As triplify is quite easy to install, it would allow a quick testing on
udd.debian.org ;)

The hard part is the change in the database schema to split the
submitters email into name and email, to easily be able to match
carnivore entries with bug submitters (for some outdated explanations of
the views I used for doing so, see [1]).

Thanks in advance for your comments.

Best regards,

[0]: http://triplify.org/
[1]: 
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: UDD data -> MySQL - Was: Re: Archiving UDD data : FLOSSMole ?

[Olivier Berger]

Le mardi 16 juin 2009 à 12:50 +0200, Andreas Tille a écrit :
> On Tue, Jun 16, 2009 at 09:49:27AM +0200, Stefano Zacchiroli wrote:
> > UDD has some parts that are Postgres specific, in particular it uses
> > the Postgres extension mechanism to internalize Debian version
> > comparison so that it can be exploited in queries. In the beginning,
> > the internalization was done only as an extension function, it might
> > be that now there is even a custom data type where you can use "<" and
> > such, but I'm not sure about that (redirect to Lucas).
> 
> I can confirm that there is a new data type debversion:
> 

SNIP

> which is probably hard to reimplement in MySQL.  There was a thread
> here on this list about this data type and its implementation.
> 

Thanks for these comments.

That's what I had also indentified as PostGres dependant when we
discussed the subject on the ossmole-discuss list.

> > You just need to pay attention (and maybe do some tests) that,
> > migrating away from Postgres, you might loose the ability to reuse the
> > same queries which you can currently use with udd.d.o.
> 
> IMHO it is not a good idea to try to port UDD to a different
> database engine.
> 

I think it depends the kind of analysis people might want to do for
their research in mining the Debian metadata that would be archived in
FLOSSMole, maybe these package versions wouldn't be needed, so strings
without the full arithmetics of versions would be enough ?

In any case, the first idea is to archive data so that it's there for
history, I suppose, then the users will complain eventually, and we
shall see ;)

Thanks again.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

UDD data -> MySQL - Was: Re: Archiving UDD data : FLOSSMole ?

[Olivier Berger]

Hi.

Le mardi 09 juin 2009 à 16:55 +0200, Olivier Berger a écrit :

> It's very likely then, that UDD will start being collected by the
> FLOSSMole team in the future.
> 

Actually, something obvious seems to render things a bit difficult at
first sight : UDD is in PostGres, and FLOSSMole uses MySQL.

We're discussing some options on the ossmole-discuss list to overcome
this difficulty.

My advice is to import in PG on a Debian system with the required
dependencies, create views to be able to convert non standard types to
standard ones, then dump again to SQL, and import to MySQL... any
comments ?

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: Archiving UDD data : FLOSSMole ?

[Olivier Berger]

Le lundi 08 juin 2009 à 14:35 +0200, Olivier Berger a écrit :
> Le dimanche 07 juin 2009 à 08:43 +0200, Stefano Zacchiroli a écrit :
> > 
> > Even though it will not solve that problem, I would very welcome
> > injecting periodically data from UDD to the FLOSSMole guys. The
> > simplest way, currently, seems to be to handing hover the snapshot we
> > periodically release on the web. Have you already asked them if that
> > kind of data would be suitable for them?
> > 
> 
> More or less, orally, and at least Megan Squire was quite receptive (I
> actually wrote my mail during her talk's Q & As). I will try and post to
> their list and report here.
> 
> I'm not exactly sure of all the constraints involved with archiving some
> data at their place, but will try and act as a facilitator, and report
> when I have more details, letting you probably discuss further
> details ;)
> 

Following-up on this, you'll find the thread around
http://sourceforge.net/mailarchive/forum.php?thread_name=94d3bd120906090719p3b1000f2u9d1e160cd1fe064a%40mail.gmail.com&forum_name=ossmole-discuss
 
where the idea seems accepted.

It's very likely then, that UDD will start being collected by the
FLOSSMole team in the future.

I'm staying subscribed both to debian-qa and flossmole-discuss lists to
try and proxy as much information as would be possible, but feel free to
take direct contacts if you see fit ;)

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: Archiving UDD data : FLOSSMole ?

[Olivier Berger]

Le dimanche 07 juin 2009 à 08:43 +0200, Stefano Zacchiroli a écrit :
> 
> Even though it will not solve that problem, I would very welcome
> injecting periodically data from UDD to the FLOSSMole guys. The
> simplest way, currently, seems to be to handing hover the snapshot we
> periodically release on the web. Have you already asked them if that
> kind of data would be suitable for them?
> 

More or less, orally, and at least Megan Squire was quite receptive (I
actually wrote my mail during her talk's Q & As). I will try and post to
their list and report here.

I'm not exactly sure of all the constraints involved with archiving some
data at their place, but will try and act as a facilitator, and report
when I have more details, letting you probably discuss further
details ;)

Btw, I'm not sure if/how we can plan some UDD-related discussions
@debconf... not having participated to debconf earlier... I suppose
we'll manage to find a place with cervesa to do so in last extremity ;)

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

[UDD] mentioned in my talk at WOPDASD 2009

[Olivier Berger]

Hi.

(This I had forgotten to mention in my previous post sent about UDD and
FLOSSMole.)

FYI, I mentioned UDD in the talk I gave @ WOPDASD 2009 workshop :
http://www-public.it-sudparis.eu/~berger_o/weblog/2009/06/06/presentation-at-wopdasd-2009-weaving-a-semantic-web-across-oss-repositories-a-spotlight-on-bts-link-udd-swim/

I illustrated it by "looking for Jesus in Debian"... and the news is
that there are 2 ;)

Joke apart, discovering UDD and its tables like carnivore, was quite
interesting for a few researchers.

So, expect more interest from academic community in Debian through UDD
mining in the future, then... and discussions about privacy issues
maybe...

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Archiving UDD data : FLOSSMole ?

[Olivier Berger]

Hi.

I'm thinking about the providing of facts about Debian which is in UDD,
to the research community studying free software development (projects,
communities, metrics, social networks, quality, etc.).

In particular, these researches are sometimes done on historical data,
which UDD doesn't necessarily provide.

I think maybe it would be interesting to "offer" some data from UDD to
the FLOSSMole research archive at :
http://ossmole.sourceforge.net/ (and
http://code.google.com/p/flossmole/ ). By offering, I mean there may be
some need of synchronisation with the researchers for technical matters
(or others : anonymization, etc.)...

FLOSSMole (partly funded by the US NSF) is already collecting lots of
facts about many development archives of directories, and a recognized
source of Data used by quite a lot researchers already, so I think it
would be quite useful to add Debian facts to that to complement the
vision of the FLOSS ecosystem for these researchers. 
In particular, they're used to archive dumps of forges already (SF,
etc.).

I've raised this idea at the WOPDASD 2009 workshop today
(http://libresoft.es/activities/wopdasd-2009-4th-workshop-on-public-data-about-software-development
 ) and will maybe try and facilitate contacts between the research community 
and Debian if needed...

Will try and point to some slides presenting Flossmole in response to
that mail, later.

Any comments ?

I hope to meet some of you at Debconf to talk to you about that.

Regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: debian/watch sf redirector docs ?

[Olivier Berger]

Le mardi 12 mai 2009 à 11:48 +0200, Cyril Brulebois a écrit :
> Olivier Berger  (12/05/2009):
> > Le lundi 11 mai 2009 à 12:33 +, Bart Martens a écrit :
> > > Not that I know of.  DD's can read the source code.
> > 
> > And non-DDs ? ... something available somewhere in SVN on alioth by any
> > chance ?
> 
> http://svn.debian.org/viewsvn/qa/trunk/wml/watch/
> 

Thanks. 

I've just added a little bit of docs pointing to it in :
http://wiki.debian.org/debian/watch

Regards,

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: debian/watch sf redirector docs ?

[Olivier Berger]

Le lundi 11 mai 2009 à 12:33 +, Bart Martens a écrit :
> On Mon, May 11, 2009 at 12:04:33PM +0200, Olivier Berger wrote:
> > Hi.
> > 
> > Is there any docs about the "Debian qa sf redirector" that can be used
> > in debian/watch (apart from man uscan) ?
> 
> Not that I know of.  DD's can read the source code.
> 

And non-DDs ? ... something available somewhere in SVN on alioth by any
chance ?

> > 
> > I'm looking for a way to state which "package" must be selected...
> > 
> > For instance, for mantis, using
> > "http://sf.net/mantisbt/mantisbt-(.+)\.tar\.gz" would report versions
> > like 1.2.0a3 where as one would like to select only versions among the
> > ones available in package "mantis-stable" as listed in
> > http://sourceforge.net/project/showfiles.php?group_id=14963
> 
> Here's a debian/watch that does that:
> 
> version=3
> opts="uversionmangle=s/(\d)[\-_\.]?(rc\d+|pre-rc\d+|pre\d+a?)$/$1~$2/;s/[\-\.](source|Source|src|orig|unix)$//;s/-(bin|osx)$/~$1/;s/^v(\d)/$1/;"
>  \
> http://sourceforge.net/project/showfiles.php?group_id=14963&package_id=166159 
> .*mantisbt[\-_](v?[\d\.]+(?:rc|rc\d+|pre-rc\d+|pre\d+a?|-unix|-source|-Source|-src|\.src|\.orig|[a-z]|b\d+|beta\d+-src|beta\d+)?)\.t.*
> 
> The trick is to also specify "package_id=".

Yes, that's what I proposed in the fix for #528192 (with much less
regexes).

Thanks.

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: debian/watch sf redirector docs ?

[Olivier Berger]

Le lundi 11 mai 2009 à 15:16 +0200, Cyril Brulebois a écrit :
> Olivier Berger  (11/05/2009):
> > Hi.
> 
> o<
> 
> > Is there any docs about the "Debian qa sf redirector" that can be used
> > in debian/watch (apart from man uscan) ?
> > 
> > I'm looking for a way to state which "package" must be selected...
> > 
> > For instance, for mantis, using
> > "http://sf.net/mantisbt/mantisbt-(.+)\.tar\.gz" would report versions
> > like 1.2.0a3 where as one would like to select only versions among the
> > ones available in package "mantis-stable" as listed in
> > http://sourceforge.net/project/showfiles.php?group_id=14963
> 
> not sure it's feasible. As a quick workaround, since the -devel ones
> seem to always have some letters (a for alpha, or rc), you could
> restrict your pattern to only match digits and dots.

Thanks, but I'm not so sure this is a really valid solution, without a
clear assurance of the numbering scheme upstream :(

As I understand it, the redirector doesn't use the web pages and goes
directly checking the download areas... so no way to detect such
"package" filtering ? :-(

Thanks anyway.

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

debian/watch sf redirector docs ?

[Olivier Berger]

Hi.

Is there any docs about the "Debian qa sf redirector" that can be used
in debian/watch (apart from man uscan) ?

I'm looking for a way to state which "package" must be selected...

For instance, for mantis, using
"http://sf.net/mantisbt/mantisbt-(.+)\.tar\.gz" would report versions
like 1.2.0a3 where as one would like to select only versions among the
ones available in package "mantis-stable" as listed in
http://sourceforge.net/project/showfiles.php?group_id=14963

Thanks in advance.

Best regards,

P.S.: see #528192 for context
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: [UDD] Splitting email phrase and address in bugs.submitter ?

[Olivier Berger]

Le mardi 24 mars 2009 à 17:01 +0100, Olivier Berger a écrit :
> Le samedi 21 mars 2009 à 19:27 +0100, Lucas Nussbaum a écrit :
> 
> > I would prefer to do that at import-time, like it is done for the
> > sources and uploaders table (maintainer being split in maintainer_name
> > and maintainer_email).
> > 
> > The reason it is not done for the bugs importer is just that people have
> > been lazy :-) I would very much appreciate a patch.
> > 
> 
> Will try and do that.
> 

Here's a proposed patch.

I'm no perl hacker, so this may as well be nonsense... and I certainly
didn't test it, having no access to a running UDD (well, the acquisition
part).

Hope this helps anyway.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
Index: sql/setup.sql
===
--- sql/setup.sql	(révision 1421)
+++ sql/setup.sql	(copie de travail)
@@ -103,7 +103,7 @@
 
 CREATE TABLE bugs
   (id int PRIMARY KEY, package text, source text, arrival timestamp, status text,
- severity bugs_severity, submitter text, owner text, done text, title text,
+ severity bugs_severity, submitter text, submitter_name text, submitter_address text, owner text, done text, title text,
  last_modified timestamp, forwarded text, affects_stable boolean,
 affects_testing boolean, affects_unstable boolean,
 affects_experimental boolean);
Index: udd/bugs_gatherer.pl
===
--- udd/bugs_gatherer.pl	(révision 1421)
+++ udd/bugs_gatherer.pl	(copie de travail)
@@ -13,6 +13,7 @@
 use DBI qw{:sql_types};
 use YAML::Syck;
 use Time::Local;
+use Email::Address;
 
 use Debbugs::Bugs qw{get_bugs};
 use Debbugs::Status qw{read_bug get_bug_status bug_presence};
@@ -177,7 +178,7 @@
 	my $location = $src_config{archived} ? 'archive' : 'db_h';
 	$table = $src_config{archived} ? $archived_table : $table;
 	# Read all bugs
-	my $insert_bugs_handle = $dbh->prepare("INSERT INTO $table (id, package, source, arrival, status, severity, submitter, owner, done, title, forwarded, last_modified, affects_stable, affects_testing, affects_unstable, affects_experimental) VALUES (\$1, \$2, \$3, \$4::abstime, \$5, \$6, \$7, \$8, \$9, \$10, \$11, \$12::abstime, \$13, \$14, \$15, \$16)");
+	my $insert_bugs_handle = $dbh->prepare("INSERT INTO $table (id, package, source, arrival, status, severity, submitter, submitter_name, submitter_address, owner, done, title, forwarded, last_modified, affects_stable, affects_testing, affects_unstable, affects_experimental) VALUES (\$1, \$2, \$3, \$4::abstime, \$5, \$6, \$7, \$8, \$9, \$10, \$11, \$12::abstime, \$13, \$14, \$15, \$16)");
 	my $insert_bugs_packages_handle = $dbh->prepare("INSERT INTO ${table}_packages (id, package, source) VALUES (\$1, \$2, \$3)");
 	my $insert_bugs_found_handle = $dbh->prepare("INSERT INTO ${table}_found_in (id, version) VALUES (\$1, \$2)");
 	my $insert_bugs_fixed_handle = $dbh->prepare("INSERT INTO ${table}_fixed_in (id, version) VALUES (\$1, \$2)");
@@ -262,9 +263,20 @@
 			}
 		}
 
+		my ($submitter_name, $submitter_address);
+
+		my $address = ( Email::Address->parse($bug{originator}) )[0];
+		if ($address) {
+		$submitter_name = $address->phrase;
+		$submitter_address = $address->address;
+		} else {
+		$submitter_name = '';
+		$submitter_address = '';
+		}
+
 		# Insert data into bugs table
 		$insert_bugs_handle->execute($bug_nr, $bug{package}, $source, $bug{date}, $bug{pending},
-			$bug{severity}, $bug{originator}, $bug{owner}, $bug{done}, $bug{subject}, $bug{forwarded}, $bug{log_modified},
+			$bug{severity}, $bug{originator}, $submitter_name, $submitter_address, $bug{owner}, $bug{done}, $bug{subject}, $bug{forwarded}, $bug{log_modified},
 			$present_in_stable, $present_in_testing, $present_in_unstable, $present_in_experimental) or die $!;
 
 		my $src;


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: [UDD] Splitting email phrase and address in bugs.submitter ?

[Olivier Berger]

Le samedi 21 mars 2009 à 19:27 +0100, Lucas Nussbaum a écrit :

> I would prefer to do that at import-time, like it is done for the
> sources and uploaders table (maintainer being split in maintainer_name
> and maintainer_email).
> 
> The reason it is not done for the bugs importer is just that people have
> been lazy :-) I would very much appreciate a patch.
> 

Will try and do that.

> > Maybe also linking to the carnivore-related tables for bug reporters who
> > are alread present in carnivore also, then (once the email is splitted
> > apart) ?
> 
> One the email is splitted, joining the data with carnivore is a simple
> JOIN, so I don't think that there's a need to duplicate the
> carnivore_id into the bugs table. Also, that would break the "data from
> different sources must not be inter-dependent in UDD" rule.

We've been working on that a little bit and I hope to be able to provide
a link to a test server in the coming days so that you can test our
graphs.

Thanks for the feedback.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

[UDD] Splitting email phrase and address in bugs.submitter ?

[Olivier Berger]

Hi.

(still not subscribed as interested mostly only in UDD at the moment, so
please CC-me of responses).

In order to test the UDD to RDF export already described, I have had to
split email addresses components in bugs.submitter in order to be able
to extract various components of a foaf:Person, i.e. foaf.name and
foaf.mbox.

I've done that by adding mail-splitting plperl functions to postgres,
used in a view :

# this is needed for use of Email::Address in plperl
$ createlang plperlu UDD

CREATE FUNCTION email_phrase (text) RETURNS text AS $$
use  Email::Address;
my $value = $_[0];
my $address = ( Email::Address->parse($value) )[0];
if ($address) {
return $address->phrase;
} else {return '';};
$$ LANGUAGE plperlu;

CREATE FUNCTION email_address (text) RETURNS text AS $$
use  Email::Address;
my $value = $_[0];
my $address = ( Email::Address->parse($value) )[0];
if ($address) {
return $address->address;
} else {return '';};
$$ LANGUAGE plperlu;

Then :
CREATE VIEW d2r_bugsubmitter AS
SELECT DISTINCT bugs.submitter, email_phrase(bugs.submitter), 
email_address(bugs.submitter)   FROM bugs

Maybe this could be tuned so that such calculations are cached as the
functions results are constant, but at the moment it runs really slow,
and considering there are > 2 bug reporters in UDD... it's not
really efficient.

I'm no postgres expert, and maybe there would be better ways to do
that... but obviously there's at least the possibility to do it as early
as possible, i.e. during UDD bugs table filling.

Do you think that such a change might be done on UDD ?

Maybe also linking to the carnivore-related tables for bug reporters who
are alread present in carnivore also, then (once the email is splitted
apart) ?

Comments ?

Regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

UDD export as RDF data through D2R and a corresponding mapping definition

[Olivier Berger]

Hi.

(not subscribed to debian-qa, please CC: me of any responses)

I've been pursuing previous ideas about the use of Semantic Web
standards for publication of facts about Debian using the UDD database
as a source.

FYI, I have a running prototype (unfortunately only on my laptop at the
moment, hopefully on the Web some day soon) which uses D2R [1], a server
which can publish RDBMS tables as RDF documents, using a mapping
description.

I'm documenting bits of what I've done in
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF
 should you be interested.

This first prototype allow to express queries such as :
SELECT DISTINCT ?b ?s WHERE {
  ?b vocab:bugs_package <http://localhost:2020/resource/package/sympa>.
  ?b debbugs:hasSubmitter ?s
}

which returns a list of all bugs id and corresponding bug reporters
"submitters" (From) addresses on the package sympa in the form of links
to resources like :
http://localhost:2020/resource/debbug/169102 - 
http://localhost:2020/resource/foafdebbug/Olivier+Berger+%3Colivier.berger%40it-sudparis.eu%3E

which each point to different RDF documents like :
http://localhost:2020/resource/debbug/169102 :
debbugs:bugUrl <http://bugs.debian.org/169102> 
    debbugs:hasSubmitter 
db:foafdebbug/Olivier+Berger+%3Colivier.berger%40it-sudparis.eu%3E 
debbugs:number 169102
debbugs:summary "sympa: Lack of exim configuration for pipe transport"
vocab:bugs_arrival "2002-11-14T16:48:05"^^xsd:dateTime
vocab:bugs_package db:package/sympa 
vocab:bugs_severity debbugs:Important 
rdf:type debbugs:Debbug 
rdfs:label "Debian bug #169102"

and 
http://localhost:2020/resource/foafdebbug/Olivier+Berger+%3Colivier.berger%40it-sudparis.eu%3E
 :
rdf:type foaf:Person
foaf:mbox <mailto:olivier.ber...@it-sudparis.eu>
foaf:mbox_sha1sum "6688a14521cd97db162af8f9757f2e2232300e50"
foaf:name "Olivier Berger"
 and with inverse relationships :
debbugs:hasSubmitter  db:debbug/169102
debbugs:hasSubmitter db:debbug/208203 
...

This is obtained with a simple mapping of data from the bugs table in
UDD to several ontologies like "foaf", and "debbugs" (a fictive one).

When running such sparql queries, or navigating the URLs provided by
D2R, the mapping is applied and corresponding SQL queries are done on
the UDD database (like :

    SELECT DISTINCT 1 FROM "d2r_bugsubmitters" WHERE
"d2r_bugsubmitters"."submitter" = 'Olivier Berger
'

SELECT DISTINCT "d2r_bugs"."id" FROM "d2r_bugs" WHERE
"d2r_bugs"."submitter" = 'Olivier Berger
'

Of course, this would be great if such a service was on the (Semantic)
Web, with URI for resources becoming real URLs and which may then be
navigated to discover links to other resources (like my other FOAF
profiles searching for my foaf:mbox_sha1 on the Web, which would return
http://www-public.it-sudparis.eu/~berger_o/foaf.rdf for instance).

I hope this will trigger some interest by UDD maintainers, and maybe we
can continue discussing that, and maybe plan to have a D2R server
alongside UDD on udd.debian.net some day ?

I have some comments on the contents of the UDD databse, btw, which I
will post in another message.

Any comments welcome, of course.

Best regards,

[1] : http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: Semantics of objects in UDD : seeking more standardization, interoperability ?

[Olivier Berger]

Le vendredi 13 février 2009 à 09:51 +0100, Lucas Nussbaum a écrit :
> I obviously don't object to UDD being used for that. 

Great ;)

> How would you like
> to proceed? Would it be enough to add VIEWs to the DB to map Debian
> data
> to standard ontologies?
> 

That might be an option somehow.

Also there are tools like D2R
http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/ that might as well do
the trick... but I haven't checked more that reading its homepage for
the moment.

> I've just made dumps of the DB available (see http://udd.debian.org/),
> so you could use that if you want to work on an offline copy.

Great. Will try to have a look at that.

Btw, until then, the database was only accessible to somehow trusted
users of Debian machines if I'm not mistaken... now that dumps are
public, I'm afraid of the issues of personal data that we've discussed
at the FOSDEM. Maybe some terms of use should be explicitely stated for
such dumps ?

In any case, I'll pass the word to fellow researchers at FLOSSMETRICS
for instance, that may be interested.

Regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: Semantics of objects in UDD : seeking more standardization, interoperability ?

[Olivier Berger]

Le dimanche 15 février 2009 à 16:19 +0100, Stefano Zacchiroli a écrit :
SNIP
> ... nothing forbids you to develop a semantics for UDD (in
> whatever language you want, web-ontologies being just one of the
> possibilities) externally to it. Actually, I'm also personally
> interested in doing that, even though I insist that it is not
> something that should be added *inside* UDD.
> 

Cool ;)

> > I have written a short piece on the subject
> > (http://www-public.it-sudparis.eu/~berger_o/weblog/2009/02/10/udd-swim-flossmetrics-facts-databases-about-libre-software-distributions-going-semantic/)
> > after the FOSDEM, and I'd like to get your comments on these ideas.
> 
> Sorry but I don't have the article with me, but I will reply as soon
> as I've a chance to read it.

Btw, In the meantime, we've been drafting a short paper following such
ideas, that we're submitting to a workshop at the next OSS 2009
conference... might pass a copy to interested folks, while waiting for
peer reviewing.
Note also the new MEPHISTO project :
http://www-public.it-sudparis.eu/~berger_o/weblog/2009/02/18/introducing-mephisto-aka-swim-before/
 and http://code.google.com/p/mephisto/, launched by our Mandriva friends.

SNIP

> Now, back to how do that, I believe the main problem you will face is
> how to identify the objects in UDD, given that they potentially change
> daily and they don't have URIs identifying them. I see various
> possibility to achieve that, the first one is for you to develop some
> URI scheme which internalizes the keys used inside UDD.
> 

>From what I understood of Lucas' presentation, there are no internal
identifiers, nor so many relationships enforced in the DB at the moment,
(foreign keys, etc.) and mostly only string attributes (since there are
inconsistencies that UDD won't try to resolve, among other reasons).
Thus, the URIs can be quite easily constructed from those strings.

I'll probably start by looking at bugs (since this is the goal of the
HELIOS project we're funded to work on ;), although I'd like to extend
the reflection to other kinds of entities also. Bug ids (numbers ranging
from "3170" to "516315" at the time of writing) are pretty stable, and I
assume that URIs ending with them should be quite stable, then. Still we
would ideally need some URIs that are indeed URLs if possible, so maybe
something like http://bugs.debian.org/nn/+rdf or similar REST/URLs
may be usable. I still need to improve my understanding of LinkedData
and other Semantic Web techniques anyway ;-)

> For example, to reference a binary package for a specific arch, you
> can use some URI scheme containing binary package name, version, and
> architecture. You should do something similar for all keys of all
> packages (maybe you can come up with a generic URI scheme also
> including the UDD relation name?).
> 

What d'you mean by all keys of these packages ? 

> Alternatively, we can think together at URIs uniquely identifying
> tuples in each UDD table, and add an extra URI field to each such
> table. De facto, such new field will be a new key for the table, and
> you can use it to state facts (i.e., "triples" in the RDF lingo) about
> such objects.
> 
> I tend to prefer the latter option, how about you?
> 

We have to devise a prototype, test, and validate the real benefits...
but in the meantime, maybe all those questions will be already addressed
in a way that could transferable to Debian, by the SWIM/MEPHISTO guys.

I need to get rid of time consuming things (like writing papers, doing
reporting and having vacation) distracting me from that work, and talk
to my collegues @ Mandriva in Helios, and will surely be able to provide
better hints.

Thanks for the interesting discussion.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Semantics of objects in UDD : seeking more standardization, interoperability ?

[Olivier Berger]

Hi.

(message about UDD, CC-ed to qa list, although I'm not so sure it
belongs here)

I've just already responded (Message-Id:
<123445.7959.46.ca...@hortense>) to Enrico Zini on d...@l.d.o about
the lack of semantics (in the sense of Semantic Web standards used to
convey ontological references, like RDF schema, etc.) in the outputs of
DDE, so this message's subject is quite similar.

I guess the same kind of criticism indeed transitively applies to UDD
(DDE exports UDD data, IIUC).

The meaning of the data in the database comes from the choices done at
database schema design time, and in the code that injects data to UDD
(sometimes not in obvious ways, as it seems there are inconsistencies
preventing links between tables, for good reasons).

I'm thinking about trying to help improve that situation, maybe by
providing some docs first (UML diagrams and more ?). The goal is to
enable the use of "commonly agreed" semantics for representation of some
data, at extraction time, for instance.

For instance, that could imply mapping bug attributes to EvoOnt BOM (or
baetle) ontology (http://www.ifi.uzh.ch/ddis/evo/).

As a (rencent) maintainer of bts-link, and in the frame of project
HELIOS
(https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/) I'm
thinking about mapping Debian "facts" to such standard ontologies. That
would help for instance making semantic links between bugs in different
bugtrackers in a more standard way, which would supposedly enable easier
implementation if all bugtrackers understood the same RDF dialects, for
instance.

We're trying to evaluate the mapping of different bugtracker's data to
EvoOnt at http://code.google.com/p/baetle/wiki/EvoOntBomMappings for
instance (debbugs is on our list).

I have written a short piece on the subject
(http://www-public.it-sudparis.eu/~berger_o/weblog/2009/02/10/udd-swim-flossmetrics-facts-databases-about-libre-software-distributions-going-semantic/)
 after the FOSDEM, and I'd like to get your comments on these ideas.

Of course, more semantics may not be necessary from the strict immediate
needs of Debian-specific tools. But I imagine that using standard
representation formats (for the same semantics of similar objects), QA
tools could be "ported" from distributions to other distributions, and
eventually manage inter-distributions data.

An immedate example would be sharing the "database" of links between
related bugs (forwarded-to like) allover the net between all
distributions bugtrackers, enabling maintainers to explore the graph of
interrelated bugs to ease identification of similar work done by other
maintainers.

Comments, flames much welcome.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: Reusing python-btsutils for bts-link

[Olivier Berger]

Hi Sandro.

Thanks for your mail.

I'm interested in trying to help improve bts-link's code and features in
the frame of the Helios project, but I think I can't help on deciding
what's best as for where bts-link would be maintained.

It would help me to be able to commit to it (maybe in SVN branches),
should Pierre or others accept my contributions (like using python
bugtracker client libs instead of original code, etc.), then of course.

Lookin forward to hearing from you or others gurus ;)

Best regards,

Le mercredi 17 décembre 2008 à 20:27 +0100, Sandro Tosi a écrit :

> First of all, thanks for your interest in bts-link. Some time back
> Pierre looked for an adopter [1] (and follow up on -devel[2]) for
> bts-link (and I have volunteered [3] to integrate it into the QA
> architecture, but I admit I didn't any progress on this :( and I
> noticed you even partecipate to that thread [4] I didn't remember!).
> 
> I still think maintain the service on QA arch is the best solution,
> and (I think) QA team maintain its stuff in its own svn repo only (but
> I'm not sure at all about it), and I'd be happy to maintain that
> service (eventually enhancing and fixing if needed, and help if
> welcome as usual)
> 
> So, if we all agree QA is the way to go, I still volunteer to
> integrate it (and I'll try to follow it up in the next weeks) maybe we
> can merge the code in QA svn repo (but then I don't know the commit
> access policy) or keep the code in git [5] and push it on QA arch
> (better to just give commit access to not the whole QA code, if
> needed).
> 
> Just let me know, and I'll start bothering QA gurus about policies and
> procedures :)

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


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

Re: For those who care about bts-link: call for adoption

[Olivier Berger]

Le mardi 11 novembre 2008 à 08:31 +0100, Christian Perrier a écrit :
> As a package maintainer with a few upstreams having their own bugzilla
> (more particularly samba), bts-link has been an incredibly useful tool
> for me.
> 
> Everybody know that *I* am personnally completely unable to maintain
> such beast but I know there are certainly many people among DD who
> can.
> 

Hi.

FYI, I proposed my help to try and maintain the code (and subscribed to
the bts-link development list, which other interested ones should do
too, of course).

But the most important task is maintaining the *service* from what I
understood of the discussions... and as I'm no DD, I suppose I'm not a
good candidate.

HtH.

Regards,
-- 
Olivier BERGER <[EMAIL PROTECTED]>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#486305: qa.debian.org: PTS subscription to package phpgroupware can't find it as source package

[Olivier Berger]

Package: qa.debian.org
Severity: normal

I subscribed to package phpgroupware from
http://packages.qa.debian.org/p/phpgroupware.html.

I received this email from [EMAIL PROTECTED] :

Processing commands for [EMAIL PROTECTED]:

> Subject: Web subscription for phpgroupware package

> subscribe phpgroupware [EMAIL PROTECTED]
phpgroupware is neither a source package nor a binary package. 
It may be a 'pseudo package' or a mistake...

A confirmation mail has been sent to [EMAIL PROTECTED]

> 

What's strange is that phpgroupware is a source package...

Still, I received the subscription confirmation email, so I suppose that
I'll be subscribed when I respond to the CONFIRM message anyway.

There must be something wrong with the PTS identifying source packages
here.

Best regards,



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]