On Sep 25, Julien Cristau wrote:
> Doesn't this break co-installability of libfoo2.0-X and libfoo2.0-Y, if
> both install Foo-2.0.gir?
And what about multiarch?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sat, Sep 26, 2009 at 09:24:46AM +0100, Stephen Gran wrote:
> Sounds like you think it's a good idea. Why not do it and let us know
> how you get on?
One point for you beeing the first raising this killer argument. ;-)
Andreas.
--
http://fam-tille.de
Klarmachen zum Ändern!
--
To UNSUBSCRI
This one time, at band camp, Andreas Tille said:
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way.
Sounds like you
Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit :
> Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:
> > 1. Package layout
> >
> > GObject-introspection packages provide introspection data
> > in /usr/share/gir-1.0/Foo-X.Y.gir, and the
> > optional /usr/lib/gir
After an insightful discussion with Sebastian, and taking into account
other suggestions from the list, here is a new proposal.
1. Directory layout
GObject-introspection data is generally provided in two formats:
* XML format in /usr/share/gir-1.0/Foo-X.Y.gir
* binary format in /u
Package: wnpp
Severity: wishlist
Owner: fabien
* Package name: librrdtool-oo-perl
Version : 0.25
Upstream Author : Mike Schilli
* URL : http://search.cpan.org/~mschilli/RRDTool-OO-0.25/
* License : (PERL)
Programming Lang: (Perl)
Description : Object-
On Sat, 26 Sep 2009, Rene Engelhard wrote:
> > Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> > And if it doesn't build that way, I'd say there's a bug in the package
> > anyways, because it should bump some build dependencies.
>
> build-deps are not necessarily runtime
Hi,
Please give me a contact phone number in case I need to find you on Monday.
Please send me the confirmed list of names by Sunday evening, too.
Thanks,
Ping
2009/9/18 :
> We have added a day trip to the Taiwan Mini-DebConf program, to visit
> the Google Corporation, in Taipei 101, the world
Hello,
following the recent comments on DEP-3 concerning its usage with git
format-patch I modified it (the patch is below). The resulting version
is on http://dep.debian.net/deps/dep3/. Feel free to comment if you see
further improvements.
--- a/web/deps/dep3.mdwn
+++ b/web/deps/dep3.mdwn
@@ -3,
On Sat, 26 Sep 2009, Russell Coker wrote:
> On Mon, 7 Sep 2009, Gabor Gombas wrote:
> > The original announcement said that Fedora is already using upstart.
> > AFAIK Fedora is also commited to using SELinux. Do they use a similar
> > patch? Can they help convincing upstream?
>
> In terms of the
Am Samstag, den 26.09.2009, 11:54 +0200 schrieb Josselin Mouette:
> Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit :
> > Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:
> > > 1. Package layout
> > >
> > > GObject-introspection packages provide introspection d
Le samedi 26 septembre 2009 à 13:12 +0200, Sebastian Dröge a écrit :
> > There is no “build time” for interpreters. What do you mean exactly?
>
> Interpreters should use the typelib file and not the GIR file. The GIR
> file is meant for generating bindings (like the current Python/C++/C#
> bindin
On Mon, 7 Sep 2009, Gabor Gombas wrote:
> The original announcement said that Fedora is already using upstart.
> AFAIK Fedora is also commited to using SELinux. Do they use a similar
> patch? Can they help convincing upstream?
Sorry for the delay in responding.
In terms of the upstream SE Linux
> George Danchev writes:
>
> > So, the question being: from where to start documenting and sorting
> > these out: policy, dpkg/doc/, devref, wiki, blogs ;-), somewhere else.
>
> Standardized fields should be documented in Policy. Patches and
> contributions are definitely welcome. (And person
George Danchev writes:
> Okay, that sounds reasonable, provided all non-user-defined fields are
> standard, or otherwise illegal. Another standard field (i.e. non-X[BSC]
> ) I found is `Bugs'; seems they are hinting someone or something like
> BTS or LP, though I'm not exactly sure if it is good
Hmm, in the examples, I would expect that the Origin/Bug/Bug-Debian
fields would be before the Subject field. If they aren't then I would
have thought they were part of the long description.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.de
2009/9/26 Josselin Mouette :
> 1. Directory layout
>
> GObject-introspection data is generally provided in two formats:
> * XML format in /usr/share/gir-1.0/Foo-X.Y.gir
> * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
...
> 6. Example
>
> Suppose that libfoo-2.0 is an API b
On Sun, Sep 27, 2009 at 3:26 AM, Russ Allbery wrote:
> Bugs is sort of an interesting case since there's no reason to ever
> include it in a Debian package, but it's part of the package format and
> people making packages for non-Debian distributions should be aware of
> it. reportbug honors it
Paul Wise writes:
> Sounds like it should be something documented in policy.
> lintian already complains about it:
> http://lintian.debian.org/tags/redundant-bugs-field.html
> I'm wondering why it is overriden by dpkg, any ideas?
> dpkg also overrides the Origin field, which is also strange.
> George Danchev writes:
>
> > Okay, that sounds reasonable, provided all non-user-defined fields are
> > standard, or otherwise illegal. Another standard field (i.e. non-X[BSC]
> > ) I found is `Bugs'; seems they are hinting someone or something like
> > BTS or LP, though I'm not exactly sure if
George Danchev writes:
> Candidates for policy so far:
> http://people.debian.org/~danchev/survey/sorted/4policy
> (Multi-Arch field added)
Oh, good, that's less than I thought there would be. We should probably
add Origin as well.
> The rest are user-defined fields (X[SBC]) which are possible
> George Danchev writes:
>
> > Candidates for policy so far:
> > http://people.debian.org/~danchev/survey/sorted/4policy
> > (Multi-Arch field added)
>
> Oh, good, that's less than I thought there would be.
IMO, standardized fields (non-XBSC) are quite well documented in policy, and I
didn't
George Danchev writes:
>> Autobuild should probably go into Policy. It's used for non-free
>> packages to indicate that it's legal for the buildds to build the
>> packages.
>>
>> Original-Maintainer is odd -- Ubuntu uses that for packages imported
>> and modified in Ubuntu, but I'm not sure wha
> George Danchev writes:
>
> >> Autobuild should probably go into Policy. It's used for non-free
> >> packages to indicate that it's legal for the buildds to build the
> >> packages.
> >>
> >> Original-Maintainer is odd -- Ubuntu uses that for packages imported
> >> and modified in Ubuntu, but
24 matches
Mail list logo
