On Tue, Sep 22, 2009 at 12:36:09PM +0200, Josselin Mouette wrote:
> Done, omitting a reported false positive and a few packages fixed in the
> meantime.
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=python2.6
Thanks.
Question: why the severity is only "im
Stefano Zacchiroli wrote:
> On Tue, Sep 22, 2009 at 12:36:09PM +0200, Josselin Mouette wrote:
>> Done, omitting a reported false positive and a few packages fixed in the
>> meantime.
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=python2.6
>
> Thanks.
>
>
Hi,
with an increasing number of packages providing introspection data for
Gobject, each one doing things its own way, it’s starting to be a big
mess. I’d like to fix this mess before we have a hundred different
packages, all behaving differently.
Which is why I’m proposing a Gobject-introspectio
On Fri, Sep 25, 2009 at 13:32:54 +0200, Josselin Mouette wrote:
> 2. Naming scheme
>
> The package should be named gir1.0-foo-X.Y. For example, the package
> containing WebKit-1.0.gir will be named gir1.0-webkit-1.0.
>
> Giant repositories of dozens of unrelated introspection data should be
> av
Le vendredi 25 septembre 2009 à 13:44 +0200, Julien Cristau a écrit :
> On Fri, Sep 25, 2009 at 13:32:54 +0200, Josselin Mouette wrote:
>
> > If, alternatively, the introspection data belongs in the same source
> > package as the library it references, it can be put in the same binary
> > package
[Reply-To set to debian-devel because this topic belongs here.]
On Fri, Sep 25, 2009 at 12:58:00PM +0200, Manuel Prinz wrote:
>
> Yes. I like the idea but we simply can't rebuild everything from the
> task pages of these blends since there are also tools from KDE or GNOME
> which would mean to ba
On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> 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.
Sh
On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > 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 st
Andreas Tille wrote:
> IMHO this problem is not really Debian Science or Blends related and the
> idea to handle backports analog to non-free autobuilds sounds quite
> reasonable - but in this case we *really* make it analog tp non-free which
> works with a debian/control field
>
> XS-Autobui
On Fri, Sep 25, 2009 at 04:39:20PM +0200, Rene Engelhard wrote:
> Hi,
>
> On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> > On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > > So in short: we should choose the "well-defined" subset of packages
> > > which are candid
Hi,
On Fri, Sep 25, 2009 at 04:06:15PM +0200, Mike Hommey wrote:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > So in short: we should choose the "well-defined" subset of packages
> > which are candidates for autobackporting according to their feature to
> > be buildable insi
* Mike Hommey [090925 16:06]:
> On Fri, Sep 25, 2009 at 03:56:00PM +0200, Andreas Tille wrote:
> > 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 fiel
Le jeudi 24 septembre 2009 11:46:54, Bastien ROUCARIES a écrit :
> Hi,
>
> According to Paul Wise:
> >The Adobe CMap resources are now free software and licensed under the
> >
> >BSD license. More information about this can be found here:
> >>http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-fr
On Sat, Sep 12 2009, Petter Reinholdtsen wrote:
> [Michael Biebl]
>> Would be interesting to have a before and after bootchart so this
>> regression can be investigated.
>
> Yes, definitely. Would also be interesting to know what kind of
> hardware you got (CPU, harddrive), and if you enabled read
[Manoj Srivastava]
> So, on deeper inspection, I have to recant: setting concurrency to
> makefile in /etc/default/rcS does not in fact change the
> timing. Which made me wonder why I thought it did, and it might be
> that I removed but not purged a package, and that might have made
> inserv
Hi,
I've recently done a little survey about the fields used in our control files
(*_Release files excluded). Currently there are ~80 different fields [1] used
in
testing and unstable, which basically fall into these groups:
1) listed in debian policy and accompanied sub-policies (like Python
On Fri, Sep 25, 2009 at 2:55 PM, George Danchev wrote:
> I've recently done a little survey about the fields used in our control files
> (*_Release files excluded). Currently there are ~80 different fields [1] used
> in
> testing and unstable, which basically fall into these groups:
>
> 1) listed
George Danchev wrote:
> I've recently done a little survey about the fields used in our control
> files (*_Release files excluded). Currently there are ~80 different
> fields [1] used in testing and unstable, which basically fall into these
> groups:
Looks like you did not include udebs in your s
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 personally, I think
> George Danchev wrote:
> > I've recently done a little survey about the fields used in our control
> > files (*_Release files excluded). Currently there are ~80 different
> > fields [1] used in testing and unstable, which basically fall into these
> > groups:
>
> Looks like you did not include u
George Danchev wrote:
> You are correct, I missed these either because dpkg-scanpackages has not
> been invoked with -tudeb or udebs are not built for the official
> archive.
They are in the official archive, but in separate sections (with their own
Packages files): '.../main/debian-installer/bin
> George Danchev wrote:
> > You are correct, I missed these either because dpkg-scanpackages has not
> > been invoked with -tudeb or udebs are not built for the official
> > archive.
>
> They are in the official archive, but in separate sections (with their own
> Packages files): '.../main/debian
Frank Küster wrote:
> For some teTeX (or older TeXLive?) packages, I've used a
> "sarge-backport" (or whatever the stable version was) target in
> debian/rules. It added a changelog entry with backport version number,
> and it switched some patches and build-deps (in particular, poppler
> wasn't a
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/girepository-1.0/Foo-X.Y.typelib.
>
> The packages should be architecture
24 matches
Mail list logo
