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
Hi,
The problem here is that `xml2-config --libs`'s output isn't identical across
different architectures, especially differ from Linux to other
platforms. On Linux, normally only -lxml2 will be the output, but
-L{libdir} -lxml2 on others. I'm thinking about fixing libxml2 now,
and will upload a
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
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
Hi,
True, but seems to be a problem for other paties involved to M-A, for
example the buildd binNMU and dpkg handling. I'll clone this bug for
them.
Yeah, binNMU and MA don't seem to combine well so far.
For libxslt, I'll make an upload soon when I come back - roughly after
12th, to try to
* 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
severity 676686 serious
thanks
On Sat, Jun 9, 2012 at 6:07 AM, Ralf Jung p...@ralfj.de wrote:
Package: libxslt1.1
Version: 1.1.26-12+b1
Severity: important
Dear Maintainer,
libxslt1.1 can no longer be installed in several architectures at once.
Installation shows the following error:
Hi list,
It seems M-A:same packages are not binNMU safe, even when requested on
all archs because every arch uses its own copy of debian/changelog
item.
Does this mean M-A:same packages should be prevented from being
binNMUed, but only source upload can be accepted?
On Sat, Jun 9, 2012 at 4:24
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
20 matches
Mail list logo
