On Thu, Jun 25, 2009 at 11:33:12PM +0100, Roger Leigh wrote:
> I often have branches for:
> - unstable
> - experimental
> - stable
> - backports
> and there may be others of course. Each of these may be branched
> off the upstream stable/development branches at the appropriate
> points. This allo
On Thu, Jun 25, 2009 at 07:23:58PM -0700, Russ Allbery wrote:
> > My question is, does anyone know of cases where a given operating
> > system and architecture does not constitute a valid platform (ie,
> > Architecture in the d/control file sense).
> armel and lpia are special cases and don't comb
Hi all:
If the architecture-restricted dependency is part of a set of
alternatives using |, that alternative is ignored completely on
architectures that do not match the restriction. For example:
Build-Depends: foo [!i386] | bar [!amd64]
is equivalent to bar on the i386 architecture, to foo
Jonathan Yu writes:
> Does that mean we should be able to just pick something from both
> lists, and turn that into a valid string to put in the Architecture
> field?
>
> solaris-armel, for example.
I think you have to distinguish between syntax and semantics here.
Syntactically, such as from th
Hi everyone:
I'm mailing this to both debian-policy and debian-devel, because I'd
like to get the perspective from both sides -- the policy one, and the
"in practice" thinking.
Currently architectures are defined as a string which contains two
parts, an operating system name, and a microprocessor
On Fri, Jun 26, 2009 at 01:04:49AM +0200, Raphaël Hertzog wrote:
> Package: debian-policy
> Version: 3.8.2.0
> Severity: normal
>
> Since the upload of install-info to sid, packages installing info
> documentation should no more call install-info in their postinst.
> It is now automatically done b
On Fri, 26 Jun 2009, Bill Allombert wrote:
> > Since the upload of install-info to sid, packages installing info
> > documentation should no more call install-info in their postinst.
> > It is now automatically done by the file trigger provided by the
> > install-info package.
>
> What about parti
Processing commands for cont...@bugs.debian.org:
> clone 534638 -1 -2
Bug#534638: debian-policy: Section about Info documents needs to be updated
Bug 534638 cloned as bugs 534639-534640.
> reassign -1 debhelper 7.2.16
Bug#534639: debian-policy: Section about Info documents needs to be updated
Bug
Package: debian-policy
Version: 3.8.2.0
Severity: normal
Since the upload of install-info to sid, packages installing info
documentation should no more call install-info in their postinst.
It is now automatically done by the file trigger provided by the
install-info package.
You should however ex
Pour être sûr de recevoir tous nos emails, ajoutez-nous à votre carnet
d'adresses.
Si ce mail ne s'affiche pas correctement, suivez ce lien (
http://www.omkg.net/D1/Q22j5jQ/QhyE37rUq/Qnfx0qoTsh2.aspx )
MISTERBABEL.COM
Offre estivale
Summer special offer
Oferta de verano
Zomeraanbod
On Thu, Jun 25, 2009 at 01:49:17PM +0200, Raphael Hertzog wrote:
> On Thu, 25 Jun 2009, Julien Cristau wrote:
> > On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
> >
> > > As far as branches are concerned, the default branch should point to
> > > the debian packaging branch and that
Steve Langasek writes:
> On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
>> If one is using a tool such as git-buildpackage, the "debian" and
>> "upstream" branches are the *minimum* required information however.
> That sounds to me like a defect in git-buildpackage, then.
All git-
Raphael Hertzog writes:
> As far as branches are concerned, the default branch should point to
> the debian packaging branch and that's it. Then if you have the need
> to encode more about how the repo is used, it should be somewhere in a
> supplementary file in debian/source/. And that's what I
Steve Langasek writes:
> On Wed, Jun 24, 2009 at 10:56:58AM -0700, Russ Allbery wrote:
>> I don't much like the word either, but at this point it's an IEEE and
>> ISO standard (IEEE 1541-2002). My feeling is that standards are more
>> important than aesthetics and we should generally follow esta
On Thu, 25 Jun 2009, Steve Langasek wrote:
> On Thu, Jun 25, 2009 at 01:49:17PM +0200, Raphael Hertzog wrote:
> > On Thu, 25 Jun 2009, Julien Cristau wrote:
> > > On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
>
> > > > As far as branches are concerned, the default branch should po
On Thu, Jun 25, 2009 at 01:49:17PM +0200, Raphael Hertzog wrote:
> On Thu, 25 Jun 2009, Julien Cristau wrote:
> > On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
> > > As far as branches are concerned, the default branch should point to
> > > the debian packaging branch and that's i
On Thu, 25 Jun 2009, Julien Cristau wrote:
> On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
>
> > As far as branches are concerned, the default branch should point to
> > the debian packaging branch and that's it.
>
> And how do you do that, when the debian and upstream repos are
On Thu, Jun 25, 2009 at 09:20:51 +0200, Raphael Hertzog wrote:
> As far as branches are concerned, the default branch should point to
> the debian packaging branch and that's it.
And how do you do that, when the debian and upstream repos are the same?
That seems to be a fairly arbitrary limitatio
On Thu, Jun 25, 2009 at 01:04:59AM -0700, Steve Langasek wrote:
> On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
> > If one is using a tool such as git-buildpackage, the "debian" and
> > "upstream" branches are the *minimum* required information however.
>
> That sounds to me like a
On Thu, Jun 25, 2009 at 01:04:59AM -0700, Steve Langasek
wrote:
> On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
> > If one is using a tool such as git-buildpackage, the "debian" and
> > "upstream" branches are the *minimum* required information however.
>
> That sounds to me like
On Thu, Jun 25, 2009 at 01:06:54AM +0100, Roger Leigh wrote:
> If one is using a tool such as git-buildpackage, the "debian" and
> "upstream" branches are the *minimum* required information however.
That sounds to me like a defect in git-buildpackage, then.
--
Steve Langasek Gi
On Wed, 24 Jun 2009, Jonathan Yu wrote:
> I don't really think that each version control system should have its
> own field, like Vcs-Mtn, Vcs-Svn, Vcs-Git etc, because it's simply not
> very future proof in my opinion. On the other hand we've got
> situations where there are lots of Version Contro
On Wed, Jun 24, 2009 at 10:56:58AM -0700, Russ Allbery wrote:
> Bill Allombert writes:
> > I would prefer if the word kibibyte was not used in policy, so I would
> > strike '(in other words, the size in kibibytes)'.
> I don't much like the word either, but at this point it's an IEEE and
> ISO st
23 matches
Mail list logo
