On Wed, Jul 29, 2015 at 10:45:01AM -0700, Nikolaus Rath wrote:
> The only think it doesn't yet do is that if
>
> - a is automatically installed
> - b is automatically installed
> - c is manually installed and depends on a|b
>
> Either a or b can be removed. But I don't think apt* handled that eit
Hi,
Quoting Nikolaus Rath (2015-07-30 06:04:39)
> I haven't found any sbuild mailing list, so I'm hoping someone here is able
> to help.
sbuild is team maintained now by buildd-tools-de...@lists.alioth.debian.org
which is probably also the mailing list you might want to contact about this.
> I'm
❦ 30 juillet 2015 01:09 +0100, Ian Jackson :
>> There is a patch management system but I think that most people (at
>> least me) are just using gbp with plain/normal quilt.
>
> Do your published git branches contain the patches-applied or
> patches-unapplied tree ?
Without using "gbp pq", the p
Hi!
On Wed, 2015-05-13 at 14:21:54 +0200, Guillem Jover wrote:
> On Tue, 2015-05-12 at 10:02:27 +0100, Jonathan Dowland wrote:
> > On Mon, May 11, 2015 at 08:40:16PM +0200, Guillem Jover wrote:
> > > $ make -jN -f debian/rules build
> > >
> > > and
> > >
> > > $ DEB_BUILD_OPTIONS=parallel=N debi
Hello,
I haven't found any sbuild mailing list, so I'm hoping someone here is
able to help.
I'm trying to build a debian package with sbuild, but when running it
just hangs:
,
| $ sbuild
| [...]
|
╔══╗
| ║ python-ll
Hi Nikolaus,
On Wed, Jul 29, 2015 at 08:12:57PM -0700, Nikolaus Rath wrote:
> I'm at a loss how to best use debbugs, I hope someone can offer some
> advice / best practices.
> I'm looking at the bug overview page for src:python3-llfuse
> (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=python-l
Nikolaus Rath writes:
> I'm looking at the bug overview page for src:python3-llfuse
> (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=python-llfuse). The
> first thing it lists is the apparently nasty grave bug #775056.
> However, this bug only exists in wheezy, it's fixed in both jessie and
Hello,
I'm at a loss how to best use debbugs, I hope someone can offer some
advice / best practices.
I'm looking at the bug overview page for src:python3-llfuse
(https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=python-llfuse). The
first thing it lists is the apparently nasty grave bug #775056.
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> Yes ish, but with the orig/diff structure the way it is, the preferred
> form for modifying a non-native Debian package seems to be the tree
> representing the unpacked package, plus the orig tarball (or enough
picca writes ("Re: Re: RE:RE:Ad-hoc survey of existing Debian git integration
tools"):
> It seems to me but I can be wrong that the dgit informations stored
> under .git/dgit are sort of meta data which point to git ref
> corresponding to packages uploaded into Debian.
Don't look in .git/dgit. T
Antonio Diaz Diaz writes:
> IMHO, if two options are equally good for the Debian use case but one of
> them is better for most of the users, Debian should choose the one that
> is better for most of the users. Else, what is the use of the social
> contract?
That may be a worthwhile factor to tak
Vincent Bernat writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> There is a patch management system but I think that most people (at
> least me) are just using gbp with plain/normal quilt.
Do your published git branches contain the patches-applied or
patches-unapplied tree
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> "gbp buildpackage" can work either way, but I think most gbp users
> consider a patches-unapplied tree to be what they normally work with
> (for instance that's what the pkg-perl team uses).
Right.
(dgit need
Package: wnpp
Severity: wishlist
Owner: "Kenneth J. Pronovici"
* Package name: cedar-backup3
Version : 3.0.0
Upstream Author : Kenneth J. Pronovici
* URL : https://bitbucket.org/cedarsolutions/cedar-backup3
* License : GPL v2
Programming Lang: Python 3
Des
On Wed, Jul 29, 2015 at 12:21:54AM +0200, Antonio Diaz Diaz wrote:
> If there is just the excrement of a fly adhered to a corner of the
> envelope (a null byte appended to an otherwise intact file, for
> example), xz will report that the data is corrupt and will not
> deliver the message. This test
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-functools32
Version : 3.2.3.2
Upstream Author : ENDOH takanao
* URL : https://github.com/MiCHiLU/python-functools32
* License : PSF-2
Programming Lang: Python
Description : B
Thanks for the detailed explanations.
Russ Allbery wrote:
Inversely, by not accepting .lz source tarballs Debian is sending the
message that lzip is not a good format to use,
While it's possible that people may decide to read such messages into our
decisions, that's not really something we hav
Package: wnpp
Severity: wishlist
Owner: Stein Magnus Jodal
* Package name: mopidy-tunein
Version : 0.2.2
Upstream Author : Nick Steel
* URL : https://github.com/kingosticks/mopidy-tunein
* License : Apache-2.0
Programming Lang: Python
Description : Mop
* Josh Triplett [150729 17:18]:
> Ole Streicher wrote:
> > Other packages will never depend on this metapackage; they will rather
> > depend on the individual programs.
>
> Other packages *in Debian* will not. I actually build a pile of
> personal metapackages to set up systems, and many of thei
Ole Streicher wrote:
> Other packages will never depend on this metapackage; they will rather
> depend on the individual programs.
Other packages *in Debian* will not. I actually build a pile of
personal metapackages to set up systems, and many of their dependencies
are metapackages. If metapack
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: python-skbio
Version : 0.2.3
Upstream Author : gregcapor...@gmail.com
* URL : https://github.com/biocore/scikit-bio
* License : BSD
Programming Lang: Python
Description : Python data
On 29/07/15 13:48, Ian Jackson wrote:
> I got the impression that gbp normally works with a patches-unapplied
> tree. Is that correct ? If so then an additional gbp step may be
> needed, to convert the tree to patches-applied.
"gbp buildpackage" can work either way, but I think most gbp users
co
Package: wnpp
Severity: wishlist
Owner: Victor Seva
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: lua-lanes
Version : 3.10.0
Upstream Author : Benoit Germain
* URL : https://github.com/LuaLanes/lanes/
* License : MIT/X
Programming Lang: C,
On Jul 28 2015, Ole Streicher wrote:
> Ben Hutchings writes:
>> Installation of a package from the 'metapackages' section does *not*
>> mark its dependencies as automatically installed.
>
> Really? So, if someone would install a metapackage (for a test), and
> then later uninstall it, its depende
On 29/07/15 15:00, Ian Jackson wrote:
> Are you saying that your source packages contain things that your git
> repositories don't ? This comes up occasionally, and I will say again
> what I have said before: I think this is wrong.
Perhaps it is; but if so, then any conventional Autotools project
Hello
> > Yes and it is nice to have meta data (the dgit things) rerpresenting
> > the packages which can be shared between derivatives.
> I don't understand what you are referring to here.
It seems to me but I can be wrong that the dgit informations stored under
.git/dgit
are sort of meta data
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-bioc-aroma.light
Version : 2.4.0
Upstream Author : Henrik Bengtsson
* URL :
http://www.bioconductor.org/packages/release/bioc/html/aroma.light.html
* License : GPL
Programming Lang: R
Hi,
On Wed, Jul 29, 2015 at 05:30:07PM +0200, Ole Streicher wrote:
> Andreas Tille writes:
> > On Wed, Jul 29, 2015 at 04:11:12PM +0200, Ole Streicher wrote:
> >> Marvin Renich writes:
> >> > A metapackage should not be used as a bat to beat users into installing
> >> > ALL of something. It sho
Andreas Tille writes:
> On Wed, Jul 29, 2015 at 04:11:12PM +0200, Ole Streicher wrote:
>> Marvin Renich writes:
>> > A metapackage should not be used as a bat to beat users into installing
>> > ALL of something. It should be a tool to help users install all of
>> > something if they wish, but us
Package: wnpp
Severity: wishlist
Owner: Tobias Frost
* Package name: darkradiant
Version : 2.0.2
Upstream Author : OrbWeaver and others
* URL : http://darkradiant.sourceforge.net/
* License : GPL2+
Programming Lang: C++
Description : Level design toolc
On Wed, Jul 29, 2015 at 04:11:12PM +0200, Ole Streicher wrote:
> Marvin Renich writes:
> > A metapackage should not be used as a bat to beat users into installing
> > ALL of something. It should be a tool to help users install all of
> > something if they wish, but users should still have as much
❦ 29 juillet 2015 13:48 +0100, Ian Jackson :
>> > If you are an NMUer or a downstream using dgit, you should usually
>> > make plain git commits (with no changes to the patch stack). dgit
>> > will generate a separate patch for each of your commits. You should
>> > leave rebasing/squashing/ref
Marvin Renich writes:
> A metapackage should not be used as a bat to beat users into installing
> ALL of something. It should be a tool to help users install all of
> something if they wish, but users should still have as much control as
> is reasonable to pick and choose a partial subset if it w
* Simon McVittie [150728 08:55]:
> On 28/07/15 13:08, Marvin Renich wrote:
> > There is no downside to using Recommends and no upside to using Depends
> > for metapackages.
>
> I don't think it's that simple; it comes down to a question of what the
> metapackage "means", which is a design questio
PICCA Frederic-Emmanuel writes ("RE:RE:Ad-hoc survey of existing Debian git
integration tools"):
> > dgit is a step in this direction.
>
> Yes and it is nice to have meta data (the dgit things) rerpresenting
> the packages which can be shared between derivatives.
I don't understand what you are
* Andreas Tille [150729 04:14]:
> On Tue, Jul 28, 2015 at 10:51:02AM -0700, Russ Allbery wrote:
> > > I'm sure this is personal taste, and in the end it won't matter for most
> > > people (except folks who don't install Recommends, but they're going to
> > > break their system regardless),
> >
>
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: python-burrito
Version : 0.9.1
Upstream Author : burrito development team
* URL : https://github.com/biocore/burrito
* License : BSD
Programming Lang: Python
Description : Python fra
Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On 29 July 2015 at 07:34, Ian Jackson wrote:
> > If you are an NMUer or a downstream using dgit, you should usually
> > make plain git commits (with no changes to the patch stack). dgit
> > will generate a se
Package: wnpp
Owner: Filip Hroch
Severity: wishlist
X-Debbugs-Cc:debian-devel@lists.debian.org,debian-as...@lists.debian.org
* Package name: rawtran
Version : 0.3.3
Upstream Author : Filip Hroch
* URL : http://integral.physics.muni.cz/rawtran/
* License : GPL-
On 29 July 2015 at 07:34, Ian Jackson wrote:
>
> Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
> tools"):
> > On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> > > That is, the dgit git tree contains the patches in debian/patches/ but
> > > also contains the
> dgit is a step in this direction.
Yes and it is nice to have meta data (the dgit things) rerpresenting the
packages which can be shared between derivatives.
> I'm not sure I entirely understand your situation, but:
Yes I was a bit laid at this moment :)
> If you are a downstream, there is no
PICCA Frederic-Emmanuel writes ("RE:Ad-hoc survey of existing Debian git
integration tools"):
> It seems to me that Debian should propose a sort of decentralized
> github which should allow upstream to setup within a minute a 'PPA'
> which can be naturally connected and beneficiate of the buildd,
Felipe Sateler writes ("Re: Ad-hoc survey of existing Debian git integration
tools"):
> On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> > That is, the dgit git tree contains the patches in debian/patches/ but
> > also contains the implied changes in the main source code. If you add
> > c
Quoting Adam D. Barratt (2015-07-28 20:02:39)
> On Tue, 2015-07-28 at 17:22 +0200, Jonas Smedegaard wrote:
>> Quoting Ole Streicher (2015-07-28 16:33:17)
>>> Ben Hutchings writes:
Installation of a package from the 'metapackages' section does
*not* mark its dependencies as automatically
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: python-xstatic-angular-gettext
Version : 2.1.0.1
Upstream Author : Thai Tran
* URL : https://github.com/stackforge/xstatic-angular-gettext
* License : Expat
Programming Lang: Python
Des
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: libjs-angular-gettext
Version : 2.1.0
Upstream Author : Ruben Vermeersch
* URL : https://github.com/rubenv/angular-gettext
* License : Expat
Programming Lang: Javascript
Description
Neil Williams writes:
> Ole Streicher wrote:
>> There are no things "that the metapackage is for": The package just
>> collects a number of programs that belong to the same author and are
>
> The "same author" bit is a bit odd, there needs to be some common
> purpose in aggregating a list of pack
On Tue, Jul 28, 2015 at 10:51:02AM -0700, Russ Allbery wrote:
> > I'm sure this is personal taste, and in the end it won't matter for most
> > people (except folks who don't install Recommends, but they're going to
> > break their system regardless),
>
> I've had Recommends disabled for something
On Tue, 28 Jul 2015 16:30:29 +0200
Ole Streicher wrote:
> There are no things "that the metapackage is for": The package just
> collects a number of programs that belong to the same author and are
The "same author" bit is a bit odd, there needs to be some common
purpose in aggregating a list of
On Tue, Jul 28, 2015 at 05:22:35PM +0200, Jonas Smedegaard wrote:
> Quoting Ole Streicher (2015-07-28 16:33:17)
> > Ben Hutchings writes:
> >> Installation of a package from the 'metapackages' section does *not*
> >> mark its dependencies as automatically installed.
> >
> > Really? So, if someone
50 matches
Mail list logo
