Re: Bits from the release team: Release goals, schedule, state of the union

[Steffen Joeris]

On Wed, 26 Aug 2009 04:58:24 pm Andreas Barth wrote:
> * Steffen Joeris (steffen.joe...@skolelinux.de) [090826 08:53]:
> > For kernel-security support, we have Dann Frazier in the security team,
> > who is also working in the kernel team (and of course other kernel team
> > members might help on security behind the curtain).
>
> So your basic concern is: Who will support the kbsd-specific packages
> (kernel plus kernel-near userland)? (The other packages shouldn't be
> an issue, or?)
Yeah basically, I mean they should be supported from within the security team, 
but I was wondering, whether we have a particular individual appointed for it 
(like for the linux kernel) or how the details should look like.

I just reread my first response to Marc and saw that it could have been read as 
very sarcastic and rude, my apologies that wasn't the intention I wrote that 
sentence in a hurry.

Cheers
Steffen

P.S. The comments/ideas/questions in this thread are my own, not the view of 
the security team.

P.P.S. We could probably drop -devel from this thread.


signature.asc
Description: This is a digitally signed message part.

Re: Bits from the release team: Release goals, schedule, state of the union

[Hector Oron]

Hello,

2009/8/25 Marc 'HE' Brockschmidt :
> Release Goals
> =
> We have now reviewed the list of release goals [RT-Goals] and have
> ACKed most of the proposed things. A short overview:
>
>  - multiarch
>    We hope to allow our users to install binaries for several
>    architectures on a single machine in Squeeze.

Just as a minor correction, the goal is to install shared libraries
and include files for several architectures, instead binaries, that
might be done at squeeze+1, but the picture has not been drawn yet.

Have a nice day !

-- 
 Héctor Orón


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

Re: Serious problem with geoip - databases could not be build from source

[Giacomo A. Catenazzi]

Patrick Matthäi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

MJ Ray schrieb:

Patrick Matthäi  wrote:

GeoIP is a quite usefull library for geolocation.
It has got a stable ABI/API and upstream is normaly very helpfull with
patches and issues.

[...]

Currently I see only three options:
1) upstream decides to open his build system
2) we move it to contrib with all consequences
3) we leave it as it is

4) we deduce the build system by looking at the CSVs and how the
library uses the binary dat files, then junk the upstream-built
dat files.  I've no idea if this is feasible, but it's another
option.


5) We create a new free database.

I don't think is too difficult, and I think we would have support
also at high level.
But it needs a lot of communication works: the term of service of
IANA and the RIRs (Regional Internet Registry) forbid to spider and
publish data. OTOH I really think they will make an exception for
us, or in general for such good networking data.

Somebody would help me contacting and convincing the RIRs about
a free geoIP database?

ciao
cate


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

Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs

[Felipe Sateler]

Steve Langasek wrote:

> On Wed, Aug 26, 2009 at 02:08:40AM -0400, Felipe Sateler wrote:
>> But this will cause trouble anyway. Imagine this case: glib changes
>> SONAME, both app and library depend on glib. app is recompiled, gtk isn't
>> yet.So then app NEEDED libglib-2.0.so.1, gtk NEEDED libglib-2.0.so.0.
>> Kaboom! The only real solution is to make gtk's SONAME dependent on
>> glib's, eg libgtk- x11-2.0.so.0-glib-1 (a la boost upstream with gcc
>> versions).

I think I should have added that the app does not have to link directly with 
glib.

> 
> That's what symbol versioning is for.

>From /u/i/g/g/gtktextchild.h:

struct _GtkTextChildAnchor
{
  GObject parent_instance;

  gpointer GSEAL (segment);
};

You lost anyway. If GObject or gpointer changes, symbol versioning doesn't 
save you because _GtkTextChildAnchor is a public type (granted, GObject or 
gpointer aren't likely to change incompatibly, but I'm sure you can find 
other examples where changes are more likely).

Saludos,
Felipe Sateler


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

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Ben Finney]

Raphael Hertzog  writes:

> On Wed, 26 Aug 2009, Ben Finney wrote:
> > A minor point: If we're going to refer to the standard for these
> > fields, then RFC 2822 is obsoleted by the current draft standard,
> > RFC 5322 http://tools.ietf.org/html/rfc5322>.
>
> Shall we do this even if it's “only” a draft standard?

I'm not sure. The specific maturity levels of IETF standards (detailed
in RFC 2026) give high importance to a Draft Standard, so the IETF
demonstrate high confidence that RFC 5322 will become a standard and
recommend serious production-level implementation of it. On the other
hand RFC 5322 isn't yet assigned a STD number, and STD 11 is still
associated with RFC 2822.

> > I would prefer if the ‘Origin’ field was recommended (or even
> > required?) for every patch by this specification. What would an
> > appropriate value for this field be in this example [where the patch
> > originates with the Debian package maintainer and exists only in the
> > package]?
>
> Well, I'm not going to make it required when previous discussions lead
> to waive this requirement in specific cases (and this sample
> demonstrates such a case).

Fair enough, I'm not about to open that up again. I see that the current
draft says “required except if Author is present”, which meets my
concerns adequately.

> Origin is best used with an URL and it's not always practical to
> provide one if you authored the patch and have not posted it anywhere.

The absence of an ‘Origin’ field simply leads the reader to too many
possible explanations, including “the writer of this patch header could
have said where this patch came from but neglected to say”.

In other words, I disagree with the current draft's assertion:

If the Author field is present, the Origin field can be omitted and
it’s assumed that the patch comes from its author.

I think the ‘Origin’ field is important for being explicit about the
provenance of the patch, even if its location online can't be pointed to
by URL.

> In the sample above, if I wanted to add the Origin field I would do
> something like this:
> Origin: vendor: written by maintainer, see Author

I think that either of ‘Origin: vendor’ (for a patch created by the
package maintainer) or ‘Origin: other’ would be better than omitting the
field. I'd like to see the examples recommend its use in these cases.

-- 
 \   “It is the mark of an educated mind to be able to entertain a |
  `\ thought without accepting it.” —Aristotle |
_o__)  |
Ben Finney


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

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Wed, 26 Aug 2009, Ben Finney wrote:
> > In the sample above, if I wanted to add the Origin field I would do
> > something like this:
> > Origin: vendor: written by maintainer, see Author
> 
> I think that either of ‘Origin: vendor’ (for a patch created by the
> package maintainer) or ‘Origin: other’ would be better than omitting the
> field. I'd like to see the examples recommend its use in these cases.

I don't share this opinion, let's see if we can have some more feedback.

While I would like to have the vendor|other info for stats purpose,
discussions have made it clear that they are not worth the addition of a
supplementary field. Furthermore, vendor and other were meant as prefix,
which they are not in your samples. That would make another special case
to explain.

Cheers,
-- 
Raphaël Hertzog


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

Re: Where should DLL files go?

[Jakub Wilk]

* Sam Morris , 2009-08-25, 21:48:

The gcc-mingw32 package provides GCC configured to target Microsoft
Windows. The executables built by GCC will pick up a dependency on
libgcc_s_sjlj-1.dll; the question of where that file should be placed on
a Debian system has arisen.


FYI, there is another DLL that is required by some programs compiled 
with (gcc-)mingw32: mingwm10.dll. See  
for an unfruitful discussion on where the DLL should go.


--
Jakub Wilk


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

Re: Release goal: Getting rid of unneeded *.la / emptying dependency_libs

[Josselin Mouette]

Le mardi 25 août 2009 à 23:24 -0700, Russ Allbery a écrit : 
> That's what symbol versioning is for, in the general case.  Provided that
> each library provides its own functions for accessing its own objects and
> doesn't let you look under the hood into objects that are directly based
> on underlying library ABIs, this normally works.  The specific case of gtk
> and glib is incestuous in ways that makes it hard to come up with a robust
> solution.

This is the reason why GLib/GObject has the strongest API/ABI stability
requirements of all libraries from the GNOME platform. When it changes
in an incompatible way, we will need new versions for all libraries
using the GLib types or GObject system.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Where should DLL files go?

[Rene Engelhard]

Hi,

On Wed, Aug 26, 2009 at 10:20:25AM +0200, Jakub Wilk wrote:
> * Sam Morris , 2009-08-25, 21:48:
>> The gcc-mingw32 package provides GCC configured to target Microsoft
>> Windows. The executables built by GCC will pick up a dependency on
>> libgcc_s_sjlj-1.dll; the question of where that file should be placed on
>> a Debian system has arisen.
>
> FYI, there is another DLL that is required by some programs compiled  
> with (gcc-)mingw32: mingwm10.dll. See   
> for an unfruitful discussion on where the DLL should go.

Note that there's also the infamous unowinreg.dll:

$ dpkg -L openoffice.org-dev | grep dll
/usr/lib/openoffice/basis3.1/sdk/classes/win/unowinreg.dll

(So far in that sdk/classes directly as it's part of the Java stuff of the
SDK. But when we decide on a proper location we of course could move/symlink
it)

Grüße/Regards,

Rene
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70


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

Re: Bits from the release team and request for discussion

[Stefano Zacchiroli]

On Tue, Aug 25, 2009 at 03:29:07PM -0500, Manoj Srivastava wrote:
> Thanks for the git repo pointer. I appreciate the opportunity to
>  look at the kinds of changes you have needed, and  will see if I can
>  incorporate them into the next version of devotee I am (stalled on)
>  writing. 

That's cool. I've tried to make reasonably self-contained commits,
with explanations that show what is general purpose and what is
not. All in all, the most stuff I added has been in the direction of
easing (i.e. make it quicker for non devotee-gurus) the setup and tear
down of polls. I believe this stuff is useful also for the devotee
main line.

If you need info about specific commits feel free to contact me in
private.

> Hmm? The last vote I ran, I thought I was in sync between my git
>  version and the code that ran. Perhaps there have been changes made on
>  vote.d.o; I'll see if I can merge those back when I  have time to work
>  on devotee.

Well, I don't even know how do you check that the code is in sync. The
working dir on master is not a Git checkout and I haven't find a .git/
dir anywhere there. Did you use to manually apply changes retrieve
manually from the Git repo?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Python 2.6? A Python transition?

[Josselin Mouette]

Le mardi 25 août 2009 à 10:10 -0700, Russ Allbery a écrit : 
> I have a few packages that build either Python modules or that embed
> Python.  I see that for the one that builds Python modules (remctl),
> Ubuntu has patched it for a Python 2.6 transition using new makefile
> machinery that I don't entirely understand but which seems reasonably
> straightforward.  However, I don't know if Debian is doing the same thing
> and if just applying that patch would be useful.  For the package that
> embeds Python (gnubg), I'm not sure what I'm supposed to be doing.

There are two problems with adding Python 2.6 to the supported versions.

First, the installation path changed from site-packages to
dist-packages. This means that most Python packages will need two
changes: 
  * passing --install-layout=deb to setup.py 
  * fixing paths from site-packages to *-packages (since the path
now depends on the Python version, yay)
This transition should have happened much earlier and was managed very
badly, but well, now it is here and we have to deal with it. I’m in the
process of evaluating the number of affected packages; it’s probably
huge, but can be reduced using the cdbs hack from Ubuntu.

Second, the maintainer stated on IRC he doesn’t want to upload it to
unstable until the packaging helpers are rewritten *again*, with a
proposal that has some advantages but that clearly lose when compared to
the amount of work it implies. Given that so far only Piotr has
volunteered to work on it (the maintainer won’t do it himself), that
leaves us with no reasonable chance to have python2.6 in the squeeze
timeframe unless he is convinced to delay this rewrite.

(Of course, this was not a requirement for uploading it in Ubuntu.)

> Is there a best practice guide somewhere, and if we are doing a
> transition, a guide for those of us who only have ancillary involvement in
> Python packaging telling us what to do?

To put it simply: 
  * Most packages using cdbs should be safe. 
  * Some packages using dh (most of those building only one binary
package) should be safe. 
  * All the rest needs updating, at least for the new setup.py
option.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Stefano Zacchiroli]

On Wed, Aug 26, 2009 at 01:56:35AM +0200, Raphael Hertzog wrote:
> I made some last changes to the DEP following round 4. You'll find them below.
> I plan to switch the DEP's status to CANDIDATE since it's about time to start
> using this new format to try it out. Once I've done this, I'll announce it on
> d-d-a to encourage people to start using it.
> 
> Current version: http://dep.debian.net/deps/dep3/

Thanks for giving a very good example of leading a DEP discussion!

I'd like to take this occasion to remind you all that
http://dep.debian.net has been revamped and that now contains both
more info about what DEPs are and a (hopefully) up to date index.

As a procedural heads up, please update also the index.mdwn file when
you switch the state of the DEP to CANDIDATE. [1]

Cheers

[1] for all the people wondering: no, we don't have yet a mechanism to
update automagically the index

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Python 2.6? A Python transition?

[Bernd Zeimetz]

Josselin Mouette wrote:
> There are two problems with adding Python 2.6 to the supported versions.
> 
> First, the installation path changed from site-packages to
> dist-packages. This means that most Python packages will need two
> changes: 
>   * passing --install-layout=deb to setup.py 
>   * fixing paths from site-packages to *-packages (since the path
> now depends on the Python version, yay)

Also see /usr/share/python/python.mk for some good ideas on how to handle this.
If you need some examples - look into the python-modules team svn, some of the
packages have been changed for Python 2.6 already.


Cheers,

Bernd

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

Re: Python 2.6? A Python transition?

[Luca Falavigna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ Allbery ha scritto:
> Is there a best practice guide somewhere, and if we are doing a
> transition, a guide for those of us who only have ancillary involvement in
> Python packaging telling us what to do?

Some references can be found here (and in follow-ups):
http://lists.debian.org/debian-devel/2009/02/msg00431.html
http://lists.debian.org/debian-python/2009/03/msg00091.html
https://lists.ubuntu.com/archives/ubuntu-devel/2009-May/028266.html

Regards,

- --

  .''`.
 : :' :   Luca Falavigna 
 `. `'
   `-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqU94cACgkQnXjXEYa8KlD/mgCgnyVOIUQbbQs5X66Bj5p94Ium
xGwAn1OIoZnanQJW59owXVhaLGUrX2zb
=Unfy
-END PGP SIGNATURE-


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

Re: Serious problem with geoip - databases could not be build from source

[Bjørn Mork]

"Giacomo A. Catenazzi"  writes:

> 5) We create a new free database.
>
> I don't think is too difficult, and I think we would have support
> also at high level.
> But it needs a lot of communication works: the term of service of
> IANA and the RIRs (Regional Internet Registry) forbid to spider and
> publish data. OTOH I really think they will make an exception for
> us, or in general for such good networking data.
>
> Somebody would help me contacting and convincing the RIRs about
> a free geoIP database?

I believe such usage can be considered within the RIRs AUPs, provided
that you follow their guidelines for bulk downloads and only
redistribute a small subset of the data (i.e. only the country attribute
of the inetnum objects).

You are aware of the GPLv3 licensed database at
http://software77.net/geo-ip/ ?

This database is used by Geo::IPfree, and probably other applications
already part of Debian.

Or did you want to provide more precise mapping than just IP to country?
If so, then I'm afraid the RIRs won't help you much anyway.  They don't
collect that sort of geographic detail.


Bjørn


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

Bug#543636: ITP: pyside -- Python bindings for Qt4 framework.

[Didier Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier Raboud 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Package name: pyside
  Version : 0.1.4.5
  Upstream Author : Nokia and OpenBossa
Anderson Lizardo (lizardo) 
Bruno Araujo (baraujo) 
Hugo Parente Lima (hlima) 
Lauro Moura (lmoura) 
Luciano Miguel Wolf (luck) 
Marcelo Lira (setanta) 
Renato Araujo Oliveira Filho (renatofilho) 

… and others.
.
The Nokia contact person for PySide is
Matti Airas (mairas) .
  URL : http://www.pyside.org/
  License : LGPL 2.1
  Programming Lang: C++, Python
  Description : Python bindings for Qt4 framework.

PySide is an open source sofware project providing Python bindings for the Qt
framework. Combining the power of Qt and Python, PySide provides the wealth of
Qt framework for developers writing software in Python and presents a
first-class rapid application development platform purported to be available on
all major operating systems.

I intend to prepare an initial package within the Python-Modules team and seek
co-maintainers there.

Best regards, 

OdyX

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10rc1 (GNU/Linux)

iJwEAQECAAYFAkqU+N8ACgkQ884eR6Y9JhRM6AP/eG/2CXIQv99C+raMT972XSNG
mwwTn0t/7bRmpEOZJIV0OB7kwWULBTY5yyAph9kUyhuhS+t4Nk71f6QgiT+0sR27
R8sh124q5WswOwd9emqEhTOOzXoNtplEB5jyDQyFSApw7V/7OgUkIS+AwT6MHKYK
A1ROGcBogvHTr2R2ZPc=
=iHRW
-END PGP SIGNATURE-



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

Re: Bits from the release team: Release goals, schedule, state of the union

[Petr Salinger]

 - kFreeBSD:
Debian 6.0 Squeeze should be the first Debian release shipping with
a non-Linux kernel.

Out of curiosity, how is security support working for this and who is
providing it?


The upstream provides their own security advisories, see

http://security.freebsd.org/
http://security.freebsd.org/advisories.html

They could be reused.

Petr


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

Re: Python 2.6? A Python transition?

[Michal Čihař]

Hi

Dne Wed, 26 Aug 2009 11:00:40 +0200
Josselin Mouette  napsal(a):

> To put it simply: 
>   * Most packages using cdbs should be safe. 
>   * Some packages using dh (most of those building only one binary
> package) should be safe. 
>   * All the rest needs updating, at least for the new setup.py
> option.

Well for most packages it just means merging back Ubuntu changes ...
just if maintainer would be notified about them, it would make it much
easier.

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Bits from the release team: Release goals, schedule, state of the union

[Goswin von Brederlow]

Hector Oron  writes:

> Hello,
>
> 2009/8/25 Marc 'HE' Brockschmidt :
>> Release Goals
>> =
>> We have now reviewed the list of release goals [RT-Goals] and have
>> ACKed most of the proposed things. A short overview:
>>
>>  - multiarch
>>    We hope to allow our users to install binaries for several
>>    architectures on a single machine in Squeeze.
>
> Just as a minor correction, the goal is to install shared libraries
> and include files for several architectures, instead binaries, that
> might be done at squeeze+1, but the picture has not been drawn yet.
>
> Have a nice day !

Both statements are ambigious.

Correct me if I'm wrong but the plan is to allow installing of
multiple architectures of the same shared library in parallel and
installing binaries from different architectures but never the same
binary from multiple architectures in parallel.

So far there is no plan at all at allowing multiple architectures for
the same binary to be installed in parallel other than individual
packages using alternatives or a common wrapper script where it is
really needed.


At least that is my understanding of the proposaland surrounding
discussions.

MfG
Goswin


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

Bug#543642: ITP: apiextractor -- Library headers parser that creates an abstract representation of an API

[Didier Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier Raboud 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Package name: apiextractor
  Version : 0.2
  Upstream Author : Nokia and OpenBossa
Anderson Lizardo (lizardo) 
Bruno Araujo (baraujo) 
Hugo Parente Lima (hlima) 
Lauro Moura (lmoura) 
Luciano Miguel Wolf (luck) 
Marcelo Lira (setanta) 
Renato Araujo Oliveira Filho (renatofilho) 

… and others.
.
The Nokia contact person for PySide is
Matti Airas (mairas) .
  URL : http://www.pyside.org/home-binding/api-extractor/
  License : GPL 2
  Programming Lang: C++
  Description : Library headers parser that creates an abstract 
representation of an API

The API Extractor library is used by the binding generator to parse headers
of a given library and merge this data with information provided by
typesystem (XML) files, resulting in a representation of how the API should be
exported to the chosen target language. The generation of source code for the
bindings is performed by specific generators using the API Extractor library.

I intend to prepare an initial package within the Python-Modules team and seek
co-maintainers there.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10rc1 (GNU/Linux)

iJwEAQECAAYFAkqVDIcACgkQ884eR6Y9JhQCkwQAoRftsf2G/O8yX7gYXN5gKq5q
KYGKeR8qu1+JUNxi87uCko4NyQi6OPzDTLtglNeqszLJE+wBUg/mnBEByazlJlQU
f2kc4ne24GUYD/cXVsxcOls1Ezr65j8C8IkCg5rEndyNL6jpdhhCAUpezubx0kmY
52JPJYClWYGaNjPx9So=
=qcob
-END PGP SIGNATURE-



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

Re: Serious problem with geoip - databases could not be build from source

[Marco d'Itri]

On Aug 26, "Giacomo A. Catenazzi"  wrote:

> 5) We create a new free database.
> I don't think is too difficult, and I think we would have support
Sure, a database which can associate an IP address with a country 90% of
the time will be easy to create and if widely used in a few years maybe
will be precise enough. More than this requires serious money, both for
maintenance and to buy the data from ISPs and online merchants.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Serious problem with geoip - databases could not be build from source

[Josselin Mouette]

Le mercredi 26 août 2009 à 11:09 +0200, Bjørn Mork a écrit : 
> You are aware of the GPLv3 licensed database at
> http://software77.net/geo-ip/ ?

Woohoo, nice. Combine this with Julien’s idea to implement support for a
new database format, and I think you have the correct solution.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Bits from the release team: Release goals, schedule, state of the union

[Hector Oron]

Hello,

2009/8/26 Goswin von Brederlow :
> Hector Oron  writes:
>> Just as a minor correction, the goal is to install shared libraries
>> and include files for several architectures, instead binaries, that
>> might be done at squeeze+1, but the picture has not been drawn yet.
>
> Both statements are ambigious.
>
> Correct me if I'm wrong but the plan is to allow installing of
> multiple architectures of the same shared library in parallel and
> installing binaries from different architectures but never the same
> binary from multiple architectures in parallel.

ATM, that's the plan.

> So far there is no plan at all at allowing multiple architectures for
> the same binary to be installed in parallel other than individual
> packages using alternatives or a common wrapper script where it is
> really needed.

Right, this plan needs to be written (as an extension to current spec)
and it needs to be taken under consideration but not for squeeze
release, but for squeeze+X release.

Kind regards,
--  Héctor Orón


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

Re: Python 2.6? A Python transition?

[Bernd Zeimetz]

Michal Čihař wrote:
> Hi
> 
> Dne Wed, 26 Aug 2009 11:00:40 +0200
> Josselin Mouette  napsal(a):
> 
>> To put it simply: 
>>   * Most packages using cdbs should be safe. 
>>   * Some packages using dh (most of those building only one binary
>> package) should be safe. 
>>   * All the rest needs updating, at least for the new setup.py
>> option.
> 
> Well for most packages it just means merging back Ubuntu changes ...
> just if maintainer would be notified about them, it would make it much
> easier.

Unfortunately the transition was messed up in Ubuntu at too many places.
Including disabling unit tests to make the package "build" with Python 2.6. You
need to make sure that the Ubuntu patches really do what you expect them to do.

In a lot of cases it may be easier to migrate to dh :)


-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

Bug#543644: ITP: libwww-mechanize-gzip-perl -- Perl module to fetch webpages with gzip compression

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: libwww-mechanize-gzip-perl
  Version : 0.12
  Upstream Author : Peter Giessner 
* URL : http://search.cpan.org/dist/WWW-Mechanize-GZip
* License : Perl (Artistic | GPL-1+)
  Programming Lang: Perl
  Description : Perl module to fetch webpages with gzip compression

 The WWW::Mechanize::GZip module tries to fetch a URL by requesting
 gzip-compression from the webserver.
 .
 If the response contains a header with 'Content-Encoding: gzip', it
 decompresses the response in order to get the original (uncompressed)
 content.
 .
 This module will help to reduce bandwith fetching webpages, if supported
 by the webeserver. If the webserver does not support gzip-compression,
 no compression will be used.
 .
 This modules is a direct subclass of WWW::Mechanize and will therefore
 support any methods provided by WWW::Mechanize.
 .
 The decompression is handled by Compress::Zlib::memGunzip.



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

Bug#543648: ITP: prophet -- distributed database system

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: prophet
  Version : 0.70
  Upstream Author : Jesse Vincent 
* URL : http://syncwith.us/
* License : Perl (Artistic | GPL-1+)
  Programming Lang: Perl
  Description : distributed, peer to peer replicated database system

 Prophet is a new kind of database designed for the post Web-2.0 world.
 It's made to let you collaborate with your friends and coworkers without
 needing any kind of special server or internet provider.
 .
 Prophet's buzzword-laden pitch reads something like this:
 .
 A grounded, semirelational, peer to peer replicated, disconnected,
 versioned, property database with self-healing conflict resolution. 
 .
 What that really means is that Prophet keeps your data in your control,
 not on a server in a cloud, is designed for online and offline use,
 syncs changes peer to peer in any way you can think of, and has a
 pluggable conflict resolution system that allows application writers to
 decide how to resolve conflicts during synchronization, using Prophet's
 algorithm or any other.
 .
 If you're not a programmer, you likely want an end-user application
 build on top of Prophet, rather than this package.



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

Bug#543650: ITP: sd -- peer to peer bug tracker

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: sd
  Version : 0.70
  Upstream Author : Jesse Vincent 
* URL : http://syncwith.us/sd/
* License : MIT
  Programming Lang: Perl
  Description : peer-to-peer bug tracking system

 SD is a peer-to-peer bug tracker that's built for sharing and use both
 online and offline. With SD, you can sync your bugs back and forth
 between other instances of SD, and even between SD and other bug
 trackers that SD supports. Since SD does not require a network
 connection for use and stores bug information locally, you can always
 access your bugs, no matter where you are.
 .
 Currently, SD supports syncing between SD and RT, Hiveminder,
 Trac, GitHub, Google Code, and Redmine (read-only).
 .
 SD is built on top of Prophet, a distributed database system.



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

Bug#543678: ITP: minidjvu -- bitonal DjVu encoder/decoder

[Jakub Wilk]

Package: wnpp
Severity: wishlist
Owner: Jakub Wilk 

* Package name: minidjvu
  Version : 0.7
  Upstream Author : Ilya Mezhirov
* URL : http://minidjvu.sourceforge.net/
* License : GPLv2
  Programming Lang: C++
  Description : bitonal DjVu encoder/decoder

minidjvu encodes and decodes single page black-and-white DjVu files, and 
can compress multiple pages, taking advantage from similarities between 
pages.


--
Jakub Wilk



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

RE: Serious problem with geoip - databases could not be build from source

[Patrick Matthäi]

Le mercredi 26 août 2009 à 11:09 +0200, Bjørn Mork a écrit : 
> You are aware of the GPLv3 licensed database at 
> http://software77.net/geo-ip/ ?

>Woohoo, nice. Combine this with Julien’s idea to implement support for a new 
>database format, and I think you have the correct solution.

And who ports it to this database format (they are incompatible) and maintains 
it in the future?

I think this job may be as hard as reverse eng. it, or?

Cheers.

Bug#543688: ITP: rainbow -- a Bitfrost isolation shell

[Luke Faraone]

Package: wnpp
Severity: wishlist
Owner: Luke Faraone 

* Package name: rainbow
  Version : 0.8.4
  Upstream Author : Michael Stone  
* URL : http://wiki.laptop.org/go/Rainbow
* License : Three-clause MIT
  Programming Lang: Python
  Description : a Bitfrost isolation shell

Rainbow is an isolation shell based on the Bitfrost threat model, as
used in the OLPC and elsewhere.

At the moment, Rainbow only knows how to provide the same primitive form
of filesystem and signal isolation that competent sysadmins provide to
users of multi-user Unix shell servers. 

-- System Information:
Debian Release: 5.0
Architecture: i386 (i686)



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

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

[Vincent Danjean]

peter green wrote:
>> So, what do you suggest for this? Of course, this file _is_ a conffile
>> (i.e. should never be automatically overwritten, so just moving it
>> over to /var/lib is not just compiling with a different path set). If
>> I don't automatically upgrade the file, users will end up with a
>> confused daemon unable and unwilling to move on. How should I proceed
>> with this?
> 
> My understanding is in this situation the correct soloution is not to
> ship the file in the package at all and then have the maintainer scripts
> create/edit it on install/upgrade.

ucf can be a great help for this.

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


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

Bug#543719: ITP: boostpythongenerator -- Binding source code generator

[Didier Raboud]

Package: wnpp
Severity: wishlist
Owner: Didier Raboud 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Package name: boostpythongenerator
  Version : 0.2
  Upstream Author : Nokia and OpenBossa
Anderson Lizardo (lizardo) 
Bruno Araujo (baraujo) 
Hugo Parente Lima (hlima) 
Lauro Moura (lmoura) 
Luciano Miguel Wolf (luck) 
Marcelo Lira (setanta) 
Renato Araujo Oliveira Filho (renatofilho) 

… and others.
.
The Nokia contact person for PySide is
Matti Airas (mairas) .
  URL : http://www.pyside.org/home-binding/binding-generator/
  License : GPL v2
  Programming Lang: C++
  Description : Binding source code generator

The Binding Generator is a utility that parses the headers for a given C/C++
library and modifies this data with the information and guides from XML files
(called typesystem files) containing complementar semantic information,
modifications, renamings, etc, in order to generate binding source code (or
documentation, or anything you want) for the target language for which it was
written.

I intend to prepare an initial package within the Python-Modules team and seek
co-maintainers there.

Regards, 

OdyX

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10rc1 (GNU/Linux)

iJwEAQECAAYFAkqVV7kACgkQ884eR6Y9JhTEqQP/Wdhvv1iokEZwwV30/+BJRgDI
/4Bs5G9pUYc5UtOBQCY1jm/+ZW34bWoAAlzcpxqZnfTNbzBDAz+Id475oRHMleir
NgDfhcOVb36FqpuNrI3rjvTK02cExK4TonqaICGp8qQ29+jD+y66nBrU6ptn7L40
QrJKhAwjFkmTPayCkpA=
=6AUe
-END PGP SIGNATURE-



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

Re: Where should DLL files go?

[Steve Langasek]

On Tue, Aug 25, 2009 at 09:48:56PM +0100, Sam Morris wrote:
> Although on Debian, the same shared library files (libfoo.so) are used
> by both compilers to link against, and ld-linux (what is that thing
> called? The "loader"? The "linker"?) to satisfy runtime dependencies,

Mm, not exactly.  At build time you use libfoo.so; at runtime you use
libfoo.so.VER.  It just happens that the ELF version of "stubs" is trivial
(a symlink).

> From a multiarch point of view, perhaps the DLL could go
> in /usr/lib/i586-mingw32msvc?

Cf. bug #542865 - in the future we might actually have a "mingw32"
mini-architecture, at which point these files would cause a package
conflict.  Maybe use /usr/i586-mingw32msvc/lib for now (the cross-build
directory)?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[gregor herrmann]

On Wed, 26 Aug 2009 10:13:58 +0200, Raphael Hertzog wrote:

> On Wed, 26 Aug 2009, Ben Finney wrote:
> > I think that either of ‘Origin: vendor’ (for a patch created by the
> > package maintainer) or ‘Origin: other’ would be better than omitting the
> > field. I'd like to see the examples recommend its use in these cases.
> I don't share this opinion, let's see if we can have some more feedback.

I prefer to omit Origin and interpret a
missing-Origin-with-Author-present as a Debian patch.

Adding a URL (pointing where - to a webinterface of a VCS?) seems
cumbersome, and just stating in some way that the origin is Debian or
the person who wrote the patch/put in into the package seems like a
duplication of information and effort.
 
Cheers,
gregor 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Queen: Innuendo


signature.asc
Description: Digital signature

ceza ödemeyin

[Vira Motorlu Araclar]

iyi günler,
 Eğer aracınızın muayenesi yoksa ve trafik kontrolune yakalanırsanız;
  1  Araç ruhsatı sizin adına değilse otomobiliniz direk parka çekilir
  2  Ruhsat sahibi sizseniz önce 62 tl ceza öderseniz sonra 15 günlük muayene 
müsade belgesi alarak muayenenizi aylık  % 5 ceza ile yaptırısınız.
 Özet olarak siz uğraşmayın gelin bizhalledelim.
Ankara'nın muayene merkezi   bizhalledelim.com adresten alıp adrese teslim 
hizmet. 

ÖNEMLİ NOT : Eğer araç veya araçlarınızın birikmiş vergi borcu varsa ,lpg 
montajı yaptıracaksanız hatta sadece muayene işleminiz bile varsa hepsini vade 
farkını ödeyerek kredi kartınıza 24 aya kadar taksitlendirebilirsiniz.

Saygılar
Güven NOYAN
0 312 442 19 20
0 554 385 1900
i...@bizhalledelim.com
www.bizhalledelim.com
www.viraoto.com.tr

Bug#543755: ITP: libtext-multimarkdown-perl -- Convert MultiMarkdown syntax to (X)HTML

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtext-multimarkdown-perl
  Version : 1.0.26
  Upstream Author : Tomas Doran 
* URL : http://search.cpan.org/dist/Text-MultiMarkdown/
* License : BSD
  Programming Lang: Perl
  Description : Convert MultiMarkdown syntax to (X)HTML

 Markdown is a text-to-HTML filter; it translates an easy-to-read /
 easy-to-write structured text format into HTML. Markdown's text format is
 most similar to that of plain text email, and supports features such as
 headers, *emphasis*, code blocks, blockquotes, and links.
 .
 Markdown's syntax is designed not as a generic markup language, but
 specifically to serve as a front-end to (X)HTML. You can use span-level HTML
 tags anywhere in a Markdown document, and you can use block level HTML tags
 (like  and  as well).
 .
 Text::MultiMarkdown implements the MultiMarkdown markdown syntax extensions
 from:
 .
 http://fletcherpenney.net/multimarkdown/

IMPORTANT NOTE: this module was previously part of the
libtext-markdown-perl package, which was recently split out upstream.



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

FSF Guidelines for Free System Distributions (was: Release goal for Squeeze)

[Ben Finney]

(The ‘debian-release’ forum is for coordination of the release of
Debian. This discussion about release goals should better take place on
the ‘debian-devel’ forum.)

Praveen P  writes:

> I would like to see squeeze released 100% free at par with "Guidelines
> for Free System Distributions" by FSF.

I assume you're referring to the guidelines documented here
http://www.gnu.org/philosophy/free-system-distribution-guidelines.html>.

In your assessment, what specific, measurable goals would the Debian
project need to set in addition to those already announced for Squeeze
http://lists.debian.org/debian-announce/2009/msg00010.html>?

> I am using gnewsense also. It is very difficult to get quality free
> softwares to replace the proprietary ones now.

Note that, unlike the FSF, the Debian project does not distinguish
between programs and non-programs for free software; per our Social
Contract, all software works in Debian need to meet the Debian Free
Software Guidelines regardless of how their bits might be interpreted.

This is in contrast to the FSF “Guidelines for Free System
Distributions” which makes special mention for different freedoms for
each of programs, documentation, and “non-functional data”, without
guidelines for works that may defy pre-hoc classification or straddle
those boundaries.

Do you see these differing standards of freedom being in conflict? How
would you suggest they be resolved?

> The condition will go worse with the advancement of time. So this is
> my request and suggestion for debian developers.

You're welcome to suggest specific, measurable release goals. As it
stands, your suggestion doesn't give much to aim for more than what
the Debian project is already committed to for Squeeze.

-- 
 \ “Nature hath given men one tongue but two ears, that we may |
  `\  hear from others twice as much as we speak.” —Epictetus, |
_o__)  _Fragments_ |
Ben Finney


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

Bug#543765: ITP: gnome-js-common -- Common modules for GNOME JavaScript interpreters

[Josselin Mouette]

Package: wnpp
Severity: wishlist
Owner: Josselin Mouette 

* Package name: gnome-js-common
  Version : 0.1.1
  Upstream Author : Robert Carr   
Tim Horton
* URL : http://ftp.gnome.org/pub/gnome/sources/gnome-js-common
* License : MIT, BSD, GPLv3
  Programming Lang: JavaScript
  Description : Common modules for GNOME JavaScript interpreters

 This package contains some JavaScript modules for use by GNOME
 JavaScript extensions, namely GJS and Seed.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling



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

Bug#543766: ITP: h5py is a general-purpose Python interface to hdf5

[Soeren Sonnenburg]

Package: wnpp
Severity: wishlist
Owner: Soeren Sonnenburg 

* Package name: python-h5py
  Version : 1.2.0
  Upstream Author : Andrew Collette 
* URL : http://code.google.com/p/h5py/
* License : BSD
  Programming Lang: C, Python
  Description : h5py is a general-purpose Python interface to hdf5

HDF5 for Python (h5py) is a general-purpose Python interface to the
Hierarchical Data Format library, version 5. HDF5 is a versatile, mature
scientific software library designed for the fast, flexible storage of
enormous amounts of data. 

>From a Python programmer's perspective, HDF5 provides a robust way to
store data, organized by name in a tree-like fashion. You can create
datasets (arrays on disk) hundreds of gigabytes in size, and perform
random-access I/O on desired sections. Datasets are organized in a
filesystem-like hierarchy using containers called "groups", and accessed
using the tradional POSIX /path/to/resource syntax. 
A generic NumPy interface to HDF5 data

H5py provides a simple, robust read/write interface to HDF5 data from
Python. Existing Python and Numpy concepts are used for the interface;
for example, datasets on disk are represented by a proxy class that
supports slicing, and has dtype and shape attributes. HDF5 groups are
presented using a dictionary metaphor, indexed by name.



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

Bug#543783: ITP: douf00 -- fat free presentations

[Bernd Zeimetz]

Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz 

* Package name: douf00
  Upstream Author : natano (Martin Ptacek) 
* URL :  http://github.com/natano/presentation/
* License : MIT
  Programming Lang: Python
  Description : fat free presentations

There is no real description yet, it will be added as soon as upstream finished
to write the documentation :)
DouF00 is a really awesome tool to do presentations, it was written to make all
these things right which are annoying with software like OOo. It is fast, easy
to use and is just what you need at the next conference.



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

Bug#543791: ITP: libnet-rendezvous-publish-backend-avahi-perl -- Perl module to publish zeroconf data with the Avahi library

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: libnet-rendezvous-publish-backend-avahi-perl
  Version : 0.03
  Upstream Author : Jack Bates 
* URL :
http://search.cpan.org/dist/Net-Rendezvous-Publish-Backend-Avahi
* License : Perl (Artistic | GPL-1+)
  Programming Lang: Perl
  Description : Perl module to publish zeroconf data with the Avahi library

 Net::Rendezvous::Publish::Backend::Avahi publishes zeroconf data via
 the Avahi library. It is a backend for the Net::Rendezvous::Publish module.



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

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Paul Wise]

On Thu, Aug 27, 2009 at 1:14 AM, gregor herrmann wrote:
> On Wed, 26 Aug 2009 10:13:58 +0200, Raphael Hertzog wrote:
>
>> On Wed, 26 Aug 2009, Ben Finney wrote:
>> > I think that either of ‘Origin: vendor’ (for a patch created by the
>> > package maintainer) or ‘Origin: other’ would be better than omitting the
>> > field. I'd like to see the examples recommend its use in these cases.
>> I don't share this opinion, let's see if we can have some more feedback.
>
> I prefer to omit Origin and interpret a
> missing-Origin-with-Author-present as a Debian patch.
>
> Adding a URL (pointing where - to a webinterface of a VCS?) seems
> cumbersome, and just stating in some way that the origin is Debian or
> the person who wrote the patch/put in into the package seems like a
> duplication of information and effort.

I disagree, imagine the situation where Fedora imports some patches
from Debian and then the Debian maintainer looks at Fedoras patches.
In that case I, as the Debian maintainer would want to know which
patches come from Debian so I can ignore them or check if they are
modified from Debian.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Thu, 27 Aug 2009, Paul Wise wrote:
> On Thu, Aug 27, 2009 at 1:14 AM, gregor herrmann wrote:
> > I prefer to omit Origin and interpret a
> > missing-Origin-with-Author-present as a Debian patch.
> >
> > Adding a URL (pointing where - to a webinterface of a VCS?) seems
> > cumbersome, and just stating in some way that the origin is Debian or
> > the person who wrote the patch/put in into the package seems like a
> > duplication of information and effort.
> 
> I disagree, imagine the situation where Fedora imports some patches
> from Debian and then the Debian maintainer looks at Fedoras patches.
> In that case I, as the Debian maintainer would want to know which
> patches come from Debian so I can ignore them or check if they are
> modified from Debian.

Ideally Fedora adds the missing URL in the Origin field
since they also want to be able to verify what happened to the patch.

Maybe that expectation should be documented in the DEP.

Cheers,
-- 
Raphaël Hertzog


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

Re: RFC round 5: DEP-3: Patch Tagging Guidelines

[Mike Hommey]

On Thu, Aug 27, 2009 at 01:23:40PM +0800, Paul Wise wrote:
> On Thu, Aug 27, 2009 at 1:14 AM, gregor herrmann wrote:
> > On Wed, 26 Aug 2009 10:13:58 +0200, Raphael Hertzog wrote:
> >
> >> On Wed, 26 Aug 2009, Ben Finney wrote:
> >> > I think that either of ‘Origin: vendor’ (for a patch created by the
> >> > package maintainer) or ‘Origin: other’ would be better than omitting the
> >> > field. I'd like to see the examples recommend its use in these cases.
> >> I don't share this opinion, let's see if we can have some more feedback.
> >
> > I prefer to omit Origin and interpret a
> > missing-Origin-with-Author-present as a Debian patch.
> >
> > Adding a URL (pointing where - to a webinterface of a VCS?) seems
> > cumbersome, and just stating in some way that the origin is Debian or
> > the person who wrote the patch/put in into the package seems like a
> > duplication of information and effort.
> 
> I disagree, imagine the situation where Fedora imports some patches
> from Debian and then the Debian maintainer looks at Fedoras patches.
> In that case I, as the Debian maintainer would want to know which
> patches come from Debian so I can ignore them or check if they are
> modified from Debian.

Relying on patch headers for that is the best way to get inaccurate
information because other parties are pretty much likely to not modify
the headers even when they modify the patch. Or remove them. Which means
you still need to do the research, and the patch header is of no use for
that.

Mike


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