The following commit has been merged in the master branch:
commit f7946eda042307afd5688cda355069ee3dcc285d
Author: Christian PERRIER bubu...@debian.org
Date: Tue Feb 14 19:22:42 2012 +0100
French translation update
1946 translated messages, 95 fuzzy translations, 23 untranslated
The following commit has been merged in the master branch:
commit 71d5f43adcd808e2348324f2718b6db70f2982de
Author: Guillem Jover guil...@debian.org
Date: Tue Feb 14 20:05:59 2012 +0100
man: Fix markup typo in French translation causing build failures
Regression introduced in commit
On 2012-02-14 07:43, Russ Allbery wrote:
[...]
* Lintian should recognize arch-qualified override files, and multiarch:
same packages must arch-qualify their override files. debhelper
assistance is desired for this.
[...]
I have no problem with Lintian accepting arch-qualified
On Fri, 2012-02-10 at 01:56:02 +0100, David Kalnischkies wrote:
Sometimes packages change their arch from arch:any to arch:all (or v.v.).
This used to be no problem for packages where any was the native arch and
this is still the case, but if it is a foreign arch dpkg refuses to install
the
On Tue, 14 Feb 2012, Philipp Kern wrote:
On 2012-02-14, Raphael Hertzog hert...@debian.org wrote:
Somehow my suggestion is then to extend dpkg-parsechangelog to provide
the required logic to split the changelog in its bin-nmu part and its
usual content.
dpkg-parsechangelog
On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote:
If this is comprehensive, then I propose the following path forward, which
is a mix of the various solutions that have been discussed:
* dpkg re-adds the refcounting implementation for multiarch, but along
with a Policy requirement
Le lundi 13 février 2012 à 22:43 -0800, Russ Allbery a écrit :
There's been a lot of discussion of this, but it seems to have been fairly
inconclusive. We need to decide what we're doing, if anything, for wheezy
fairly soon, so I think we need to try to drive this discussion to some
concrete
* Raphael Hertzog hert...@debian.org, 2012-02-14, 14:17:
dpkg-buildpackage --binary-version ver --binary-changelog 'foo' could
create debian/changelog.build with the given changelog version and
changelog entry.
dpkg-parsechangelog could be taught to read debian/changelog.build
before
On 2012-02-14 15:28 +0100, Ian Jackson wrote:
Guillem Jover writes:
This still does not solve the other issues I listed, namely binNMUs
have to be performed in lock-step, more complicated transitions /
upgrades.
I don't think I see where this is coming from. Are you talking about
Hi,
On Tue, 14 Feb 2012, Guillem Jover wrote:
* All packages that want to be multiarch: same have to move all generated
documentation into a separate package unless the maintainer has very
carefully checked that the generated documentation will be byte-for-byte
identical even across
On Tue, 14 Feb 2012, Jakub Wilk wrote:
Are we sure than no existing package uses debian/changelog.build for
their own purposes?
No, but with debian/changelog.dpkg-build we should be safe.
Are we sure that all existing packages (and helpers) that parse
debian/changelog use
On Tue, 14 Feb 2012, Guillem Jover wrote:
Known deficiency; the code was not being uploaded because the
implementation was not right nor finished, as stated on the changelog...
It would help if you could put your list of known deficiency
somewhere... on a wiki page, in a regular mail on
On Tue, 14 Feb 2012, Raphael Hertzog wrote:
It would help if you could put your list of known deficiency
somewhere... on a wiki page, in a regular mail on debian-dpkg, in commit
logs if you prefer.
But it's pretty disheartening to learn that you know of problems but that
you hide them so
On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote:
Guillem Jover writes (Re: Multiarch file overlap summary and proposal (was:
Summary: dpkg shared / reference counted files and version match)):
On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote:
* The binNMU process is changed
See http://jenkins.grml.org/job/dpkg-binaries/./architecture=i386/192/
--
[...truncated 926 lines...]
g++ -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\
-DADMINDIR=\/var/lib/dpkg\ -DLIBDIR=\/usr/lib/dpkg\
-DLOCALLIBDIR=\/usr/local/lib/dpkg\ -idirafter
See http://jenkins.grml.org/job/dpkg-binaries/./architecture=amd64/192/
--
[...truncated 924 lines...]
g++ -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/share/locale\
-DADMINDIR=\/var/lib/dpkg\ -DLIBDIR=\/usr/lib/dpkg\
-DLOCALLIBDIR=\/usr/local/lib/dpkg\ -idirafter
See http://jenkins.grml.org/job/dpkg-binaries/./architecture=amd64/193/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
See http://jenkins.grml.org/job/dpkg-binaries/./architecture=i386/193/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
reassign 659782 dpkg
found 659782
retitle 659782 dpkg -L does not work for multi-arch foreign packages.
tags 659782 + experimental
quit
On Tue, Feb 14, 2012 at 09:21:47AM +0100, Raphael Hertzog wrote:
Hi,
On Mon, 13 Feb 2012, Philipp Kern wrote:
So are you suggesting that dpkg should use
On Tue, 2012-02-14 at 14:28:58 +, Ian Jackson wrote:
I think the refcounting approach is very worthwhile because it
eliminates unnecessary work (by human maintainers) in many simple
cases.
Aside from what I said on my other reply, I just wanted to note that
this seems to be a recurring
Guillem Jover wrote:
Aside from what I said on my other reply, I just wanted to note that
this seems to be a recurring point of tension in the project when it
comes to archive wide source package changes, where supposed short
term convenience (with its usually long term harmful effects)
Joey Hess jo...@debian.org writes:
Anyway, my worry about the refcounting approach (or perhaps M-A: same in
general) is not the details of the implementation in dpkg, but the added
mental complexity of dpkg now being able to have multiple distinct
packages installed under the same name. I had
On Tue, 14 Feb 2012, Guillem Jover wrote:
I've never proposed to arch-qualify the filename for the stuff under
/usr/share/doc/pkgname/, I've proposed to arch-qualify the pkgname in
the path (/usr/share/doc/pkgname:arch/), but only for M-A:same packages,
which are the only ones needing the
Processing commands for cont...@bugs.debian.org:
reassign 659782 dpkg
Bug #659782 [popularity-contest] does not cope with multiarch packages being
installed
Bug reassigned from package 'popularity-contest' to 'dpkg'.
Bug No longer marked as found in versions popularity-contest/1.53.
found
24 matches
Mail list logo
