On Fri, Jun 8, 2012 at 6:17 PM, Philipp Kern wrote:
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
You cannot deprive the Release Team of this tool. Also multiarch bugs
Michael Gilbert mgilb...@debian.org (14/06/2012):
package (version) sid; urgency=low
* Binary-only non-maintainer upload; no source changes.
-- Debian Release Team debian-rele...@lists.debian.org Tue, 05 Jun
2012 16:33:05 +
or some other appropriate binnmu mailing address. This
On Thu, Jun 14, 2012 at 12:40 PM, Cyril Brulebois wrote:
Michael Gilbert mgilb...@debian.org (14/06/2012):
package (version) sid; urgency=low
* Binary-only non-maintainer upload; no source changes.
-- Debian Release Team debian-rele...@lists.debian.org Tue, 05 Jun
2012 16:33:05 +
On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote:
Wouldn't the ideal solution be non-architecture-specific changelogs?
No, that would be very much non-ideal. One should be able to schedule
binNMUs for a subset of archs, and one shouldn't have to look up whether
a package builds
On Thu, Jun 14, 2012 at 1:07 PM, Julien Cristau jcris...@debian.org wrote:
On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote:
Wouldn't the ideal solution be non-architecture-specific changelogs?
No, that would be very much non-ideal. One should be able to schedule
binNMUs for a
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote:
I did not suggest that. Anyway, maybe this will be a bit clearer.
Let's say an existing package is at version +b1 on amd64, and it needs
to get a binnmu, then a +b2 package is built on amd64, its changelog
is taken and stuffed
On Thu, Jun 14, 2012 at 3:43 PM, Philipp Kern wrote:
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote:
I did not suggest that. Anyway, maybe this will be a bit clearer.
Let's say an existing package is at version +b1 on amd64, and it needs
to get a binnmu, then a +b2 package is
On Mon, 2012-06-11 at 11:39:24 +0100, Ian Jackson wrote:
Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1
binNMU broke multi-arch installability):
As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just seems like
On Sun, Jun 10, 2012 at 10:01:29AM +0200, Guillem Jover wrote:
As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just seems like a hack to me. Instead I
think we should consider changelog (and copyright as long as it's in
machine parseable
* Ian Jackson (ijack...@chiark.greenend.org.uk) [120611 13:21]:
Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1
binNMU broke multi-arch installability):
As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just
* Guillem Jover (guil...@debian.org) [120612 09:00]:
I disagree placing it in the dpkg database is not helpful, for a user
or other programs wanting to access that structured package metadata
it's obviously easier and better to do something like
«dpkg --show-changelog foo» or «dpkg-query
Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1
binNMUbroke multi-arch installability):
As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just seems like a hack to me. Instead I
think we should consider changelog
On Sat, 2012-06-09 at 15:26:06 +0200, Andreas Barth wrote:
* Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]:
We'd just have to teach the tool to binNMU all arches when the target
package would need it due to multiarch. Release team requests a binNMU of a
package for some
* Guillem Jover (guil...@debian.org) [120610 10:08]:
As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just seems like a hack to me. Instead I
think we should consider changelog (and copyright as long as it's in
machine parseable format) as dpkg
On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote:
Perhaps we could add the binNMU entry for the moment and fix the rest
later? Or whatever would make you more happy. Just I'd like to be able
to schedule binNMUs again on ma-packages.
There is no such block in place.
Kind regards
* Philipp Kern (pk...@debian.org) [120610 14:06]:
On Sun, Jun 10, 2012 at 01:52:24PM +0200, Andreas Barth wrote:
Perhaps we could add the binNMU entry for the moment and fix the rest
later? Or whatever would make you more happy. Just I'd like to be able
to schedule binNMUs again on
* Henrique de Moraes Holschuh (h...@debian.org) [120609 02:31]:
We'd just have to teach the tool to binNMU all arches when the target
package would need it due to multiarch. Release team requests a binNMU of a
package for some arch, the tool notices it has to do them all because of
multi-arch
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO
at most important, not serious. Possibly we
On Sat, Jun 9, 2012 at 6:17 AM, Philipp Kern pk...@debian.org wrote:
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
You cannot deprive the Release Team of this tool.
On Sat, 09 Jun 2012, Philipp Kern wrote:
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO
On Sat, Jun 9, 2012 at 8:30 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Sat, 09 Jun 2012, Philipp Kern wrote:
On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote:
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be
21 matches
Mail list logo
