On Feb 09, Steve Langasek wrote:
> I think there are pretty solid benefits to proceeding with a dpkg that
> allows sharing files across M-A: same packages.
Agreed. Fix the tools instead of breaking the standard to adapt to
broken tools.
Myself, I like the idea of the implicit Replaces.
--
ciao
On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote:
> In practice, the only compressor we need to care is gzip, which is
> not actively maintained upstream[0]. Chances that a new version of
> it will break large number of packages are minute.
That assumes that we will never want to switch to a
On Wed, 2012-02-08 at 15:14:35 -0800, Steve Langasek wrote:
> So I had a look at the Ubuntu archive, which already has a large collection
> of packages converted to Multi-Arch: same, to provide some hard facts for
> this discussion.
>
> - 2197 files are shipped in /usr/share by these packages, ou
+++ Russ Allbery [2012-02-08 13:47 -0800]:
> Neil Williams writes:
> > Russ Allbery wrote:
>
> Oh, good point, I'd forgotten that for multiarch the symlink is
> architecture-dependent. So yes, the -dev package is inherently
> architecture-dependent.
>
> > I would drop the .a but that doesn't m
Steve Langasek writes:
> On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
>> Steve Langasek writes:
>>> The unfounded assumption here is that you will always install a
>>> foreign-arch M-A: same package together with the native-arch version.
>>> If I install libaudio2:i386 because I
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
>
> > The unfounded assumption here is that you will always install a
> > foreign-arch M-A: same package together with the native-arch version.
> > If I install libaudio2:i386 because I want to play a game that
Steve Langasek writes:
> The unfounded assumption here is that you will always install a
> foreign-arch M-A: same package together with the native-arch version.
> If I install libaudio2:i386 because I want to play a game that's only
> available as a 32-bit binary and has this lib as a dependency,
Le Wed, Feb 08, 2012 at 07:54:47PM +, Roger Leigh a écrit :
>
> Relating to binNMU changelogs: do they really serve any purpose? There
> are no source changes, so is there any real need for a changelog change
> at all? AFAICT the only reason we do for historical reasons, it being
> the only
On Wed, Feb 08, 2012 at 08:03:27PM +, Roger Leigh wrote:
> An alternative would be for an existing Essential package such as
> base-files to provide the Depends, which would save the need for
> a separate base-init package. Is there any reason this would be
> undesirable? (I note that it curr
On Wed, Feb 08, 2012 at 10:22:17AM +, Neil Williams wrote:
> After all, this is how cross/foreign architecture packages have
> *always* been handled in Debian via dpkg-cross. Nothing in /usr/share/
> matters for a cross package created by dpkg-cross (with the possible
> exception of /usr/share
On Wed, Feb 08, 2012 at 11:56:06AM -0800, Russ Allbery wrote:
> Riku Voipio writes:
> > On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
> >> The same principle that applies to all dpkg output to avoid ambiguity
> >> would apply everywhere, whenever there's a “Multi-Arch: same” pack
Neil Williams writes:
> Russ Allbery wrote:
>> There are two main cases for libfoo-dev that I think cover most such
>> packages:
>>
>> 1. The header files are architecture-dependent (definitions of data member
>>sizes, for example), in which case they need to be arch-qualified
>>anyway
Am 08.02.2012 22:28, schrieb Michael Biebl:
Could you give a short example how postinst would look like for the case
that package foo is split int foo in version 1.0-1
Making the example a bit more verbose:
before the split:
binary package foo:
/bin/foo
/bin/bar
/etc/foo.conf
/etc/bar.conf
Hi,
Am 08.02.2012 08:27, schrieb Raphael Hertzog:
What's difficult in implementing this?
I haven't found cocumentation how to correctly move conffiles from one
package to another. Neither at [1] nor the dpkg-maintscript-helper man page.
As mentioned, a simple Replaces in the newly split-off
On 2012-02-08, Russ Allbery wrote:
> There are two main cases for libfoo-dev that I think cover most such
> packages:
3) to ensure that things can keep working on slow archs while they build
a new edition of src:foo
/Sune
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
On Wed, Feb 08, 2012 at 09:49:26PM +0100, Sven Joachim wrote:
> On 2012-02-08 21:03 +0100, Roger Leigh wrote:
>
> > This is regarding Bug #645540 ("Essential" package conflict between
> > sysvinit and systemd-sysv).
> >
> > sysvinit is currently Essential. In order to permit the replacement
> > o
* Guillem Jover , 2012-02-08, 21:02:
Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
sid generating a reproducible output across all current architectures.
Time passes, compressor version N (and even O and P and Q etc) gets
uploaded, which starts producing new ouput (on e
On Wed, Feb 08, 2012 at 09:02:43PM +0100, Guillem Jover wrote:
> Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
> sid generating a reproducible output across all current architectures.
> Time passes, compressor version N (and even O and P and Q etc) gets
> uploaded, which st
On 2012-02-08 21:03 +0100, Roger Leigh wrote:
> This is regarding Bug #645540 ("Essential" package conflict between
> sysvinit and systemd-sysv).
>
> sysvinit is currently Essential. In order to permit the replacement
> of sysvinit with an alternative init system, I'd like to propose the
> creati
* Ben Hutchings , 2012-02-08, 20:23:
Relating to binNMU changelogs: do they really serve any purpose?
There are no source changes, so is there any real need for a changelog
change at all? AFAICT the only reason we do for historical reasons,
it being the only way previously to effect a version
On Wed, 2012-02-08 at 11:56:06 -0800, Russ Allbery wrote:
> Riku Voipio writes:
> > That is a major waste of space of having multiple copies of identical
> > files with different arch-qualified names. Is that really better
> > architecture to have multiple copies of identical files on user systems
On Wed, Feb 08, 2012 at 07:54:47PM +, Roger Leigh wrote:
> On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
> > Guillem Jover writes:
> > > On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > > And while the binNMU changelog issues might seem like a corner case,
> > > it'
Joey Hess writes:
> pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required
> to always produce the same compressed file for a given input file, and I
> can tell you from experience that there is a wide amount of
> variation. If multiarch requires this, then its design is at worst
On Wed, 08 Feb 2012 11:56:06 -0800
Russ Allbery wrote:
> There are two main cases for libfoo-dev that I think cover most such
> packages:
>
> 1. The header files are architecture-dependent (definitions of data member
>sizes, for example), in which case they need to be arch-qualified
>any
Roger Leigh writes:
> On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
>> Also true. In fact, it's something that's been bothering me for a long
>> time with linked doc directories. I'd like to prohibit them in more
>> cases so that we get the binNMU changelogs on disk.
> Relating
Guillem Jover writes:
> Let's assume compressor (gzip/bzip2/xz/etc) version M gets uploaded to
> sid generating a reproducible output across all current architectures.
> Time passes, compressor version N (and even O and P and Q etc) gets
> uploaded, which starts producing new ouput (on each of th
This is regarding Bug #645540 ("Essential" package conflict between
sysvinit and systemd-sysv).
sysvinit is currently Essential. In order to permit the replacement
of sysvinit with an alternative init system, I'd like to propose the
creation of a new Essential package "base-init", with a Depends
On Wed, 2012-02-08 at 11:25:28 -0800, Don Armstrong wrote:
> On Wed, 08 Feb 2012, Neil Williams wrote:
> > I don't get it. That would only affect packages which were built
> > during the time that a new upload of gzip is made and all the
> > buildd's making that new version available. Now, if there
Riku Voipio writes:
> On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
>> The same principle that applies to all dpkg output to avoid ambiguity
>> would apply everywhere, whenever there's a “Multi-Arch: same” package
>> name that needs to be unambiguous, it just always gets arch-qua
On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
> Guillem Jover writes:
> > On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > And while the binNMU changelog issues might seem like a corner case,
> > it's just a symptom of something that's not quite right.
>
> Also true.
Guillem Jover writes:
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
>> Well, it does mean that you might be lacking important information
>> because the other changelog wouldn't be present on the system.
> While the implicit Replaces seems the easy way out, it just seems even
> more
On Wed, 08 Feb 2012, Neil Williams wrote:
> I don't get it. That would only affect packages which were built
> during the time that a new upload of gzip is made and all the
> buildd's making that new version available. Now, if there is a
> binNMU after a new version of gzip is uploaded, yes it is p
On Wed, 8 Feb 2012 17:13:20 +0100
Guillem Jover wrote:
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > Well, it does mean that you might be lacking important information
> > because the other changelog wouldn't be present on the system.
> Instead of this, I'd rather see the shared
On Thu, Feb 9, 2012 at 01:35, Simon McVittie wrote:
> On 08/02/12 17:22, Aron Xu wrote:
>> Some packages come with data files that endianness matters, and many
>> of them are large enough to split into a separate arch:all package if
>> endianness were not something to care about. AFAIK some mainta
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
> On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
> > If you remove the shared files approach, how do you handle files like
> > lintian overrides, reportbug presubj and scripts, etc. ?
>
> The same principle that applies to al
On 08/02/12 17:22, Aron Xu wrote:
> Some packages come with data files that endianness matters, and many
> of them are large enough to split into a separate arch:all package if
> endianness were not something to care about. AFAIK some maintainers
> are not aware of endianness issues in their packag
Ian Jackson wrote:
> Another relevant question is whether there are other files that are
> shared, and which don't want to move, besides ones in /usr/share/doc.
One example is header files in /usr/include, from -dev packages. In
the simple examples I've seen, putting them in /usr/include/,
works
I want to speak up about endianness of data files, this is a
suggestion but not a flaw which I just want to discover the
possibility of improvement to current status by the chance of
implementing Multi-Arch in Debian.
Some packages come with data files that endianness matters, and many
of them are
Guillem Jover writes ("Re: Please test gzip -9n - related to dpkg with
multiarch support"):
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > One thing which no-one yet seems to have suggested is to have
> > multiarch:same packages put the changelog in a filename which is
> > distinct
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
> If you remove the shared files approach, how do you handle files like
> lintian overrides, reportbug presubj and scripts, etc. ?
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's
[Moving a non-Debian Med related issue to debian-devel. (reply-to set)
The relevant part of this thread starts at
http://lists.debian.org/debian-med/2012/02/msg00074.html
and might be interesting for people building R packages. ]
On Wed, Feb 08, 2012 at 09:37:12AM -0600, Dirk Eddelbuettel wr
On Wed, Feb 08, 2012 at 05:13:20PM +0100, Guillem Jover wrote:
> On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> > Well, it does mean that you might be lacking important information
> > because the other changelog wouldn't be present on the system.
>
> While the implicit Replaces seems
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
> Well, it does mean that you might be lacking important information
> because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just seems even
more fragile than the shared files a
On Wed, 8 Feb 2012 15:06:46 +0100
Adam Borowski wrote:
> On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
> > For those not subscribed to that bug, how to reproduce[1] and possible
> > fix[2] are available now. There might be other places where buffers are
> > reused, I only spent
On Wed, Feb 08, 2012 at 02:32:07PM +, Alastair McKinstry wrote:
> Hi Francesco,
>
> Do you recommend that we build the next NetCDF from 4.1.1 or should we
> use the 4.1.3 from experimental as the base?
>
> Regards
> Alastair
>
AFAIK Sylvestre is going to reset the dependencies chain in hdf5
On Wed, Feb 08, 2012 at 11:33:37AM +0100, Bernhard R. Link wrote:
> On the other hand most uncompressors silently ignore unexpected
> data after end of file markers. So the compressed file is even more
> easily tempered with (especially as debsums only stores md5 without
> size and md5 does not inc
Hi Francesco,
Do you recommend that we build the next NetCDF from 4.1.1 or should we
use the 4.1.3 from experimental as the base?
Regards
Alastair
On 2012-02-07 13:17, Francesco P. Lovergine wrote:
> On Tue, Feb 07, 2012 at 09:28:00AM +, Alastair McKinstry wrote:
>> On 2012-02-02 01:43, Ste
Il 2012-02-08 15:23 Josselin Mouette ha scritto:
GConf is deprecated, but it is still maintained. It is still used
e.g.
by evolution.
I don’t see the point of renaming it, starting another daemon, and
whatnot, if you provide the same functionality. If you want to keep
maintaining GConf for long
On Wed, February 8, 2012 15:00, Thomas Goirand wrote:
> On 02/08/2012 12:50 AM, Filipus Klutiero wrote:
>> Thankfully there's a page being built to track problems in packages
>> that contain PHP code: http://wiki.debian.org/PHP/54Transition
>>
> This is very nice, but how come PHP Lint isn't in Deb
Le mercredi 08 février 2012 à 14:52 +0100, Stefano Karapetsas a écrit :
> GConf is deprecated. MateConf is born to have a temporary solution
> until
> we choose the replacement for it.
GConf is deprecated, but it is still maintained. It is still used e.g.
by evolution.
I don’t see the point of
On 02/08/2012 12:50 AM, Filipus Klutiero wrote:
> Thankfully there's a page being built to track problems in packages
> that contain PHP code: http://wiki.debian.org/PHP/54Transition
>
This is very nice, but how come PHP Lint isn't in Debian?
It seems to be shipped under a BSD license, so it should
On Wed, 8 Feb 2012 14:14:22 +0100
Cyril Brulebois wrote:
> Neil Williams (07/02/2012):
> > I'd like to ask for some help with a bug which is tripping up my tests
> > with the multiarch-aware dpkg from experimental - #647522 -
> > non-deterministic behaviour of gzip -9n.
>
> For those not subscr
Il 2012-02-08 14:41 Josselin Mouette ha scritto:
Le mercredi 08 février 2012 à 14:05 +0100, Stefano Karapetsas a écrit
:
Yeah. In our roadmap there is the dismissal of the obsolete
libraries,
like the replacement of MateConf (the fork of GConf) with GSettings,
and
so on.
Sorry but what is the
Wouter Verhelst wrote:
> On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
> > Maybe the way to solve this properly is to remove compression from the
> > uniqueness check - compare the contents of the file in memory after
> > decompression. Yes, it will take longer but it is only neede
On Wed, Feb 08, 2012 at 02:14:22PM +0100, Cyril Brulebois wrote:
> For those not subscribed to that bug, how to reproduce[1] and possible
> fix[2] are available now. There might be other places where buffers are
> reused, I only spent a few minutes on this during my lunch break.
>
> 2. http://bug
On Wed, 8 Feb 2012 08:59:30 +1100, Karl Goetz wrote:
> I don't know anything about waf not mentioned in this thread, but
> would it be possible to patch the package to work with a packaged waf
> instead?
> thanks,
> kk
>
See the reasons for removal previously referenced by Alexander:
http://list
Il 2012-02-08 14:23 Mehdi Dogguy ha scritto:
I saw some gnome design team mockups of all applications, and I find
its far from GNOME2.
Then, why don't you help them? (It is easier than re-packaging and
maintaining Gnome2).
Regards,
I just answered before. GNOME3 is a completely different desk
Le mercredi 08 février 2012 à 14:05 +0100, Stefano Karapetsas a écrit :
> Yeah. In our roadmap there is the dismissal of the obsolete libraries,
> like the replacement of MateConf (the fork of GConf) with GSettings,
> and
> so on.
Sorry but what is the point of *forking* GConf? What does it bri
Russ Allbery writes ("Re: Please test gzip -9n - related to dpkg with multiarch
support"):
> Another possible solution is to just give any package an implicit Replaces
> (possibly constrained to /usr/share/doc) on any other package with the
> same name and version and a different architecture. Th
On Wed, Feb 08, 2012 at 11:51:50AM +, Jon Dowland wrote:
> On Wed, Feb 08, 2012 at 10:47:13AM +0100, Alexander Reichle-Schmehl wrote:
> > I have no idea, but I'm not really sure if it's a good idea to remove
> > samba either...
> Absolutely not. They might be persuade-able away from waf though
On 08/02/12 14:05, Stefano Karapetsas wrote:
I saw some gnome design team mockups of all applications, and I find
its far from GNOME2.
Then, why don't you help them? (It is easier than re-packaging and
maintaining Gnome2).
Regards,
--
Mehdi
--
To UNSUBSCRIBE, email to debian-devel-requ...@l
Il 2012-02-08 11:44 Mehdi Dogguy ha scritto:
On 08/02/12 09:55, Josselin Mouette wrote:
MATE introduces a lot of code duplication, which is considered bad
in Debian, and is based on obsolete technologies - not just GTK2,
which will of course remain for a long time, but also things like
Bonobo w
(Dropping everyone but dd@.)
Wouter Verhelst (08/02/2012):
> As an additional benefit, this will also allow those among us (like me)
> who hate having to use 'gunzip -c /usr/share/doc/foo/bar.pdf.gz >
> /tmp/bar.pdf; xpdf /tmp/bar.pdf' in order to be able to read some
> documentation, to just req
Neil Williams (07/02/2012):
> I'd like to ask for some help with a bug which is tripping up my tests
> with the multiarch-aware dpkg from experimental - #647522 -
> non-deterministic behaviour of gzip -9n.
For those not subscribed to that bug, how to reproduce[1] and possible
fix[2] are available
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
> Maybe the way to solve this properly is to remove compression from the
> uniqueness check - compare the contents of the file in memory after
> decompression. Yes, it will take longer but it is only needed when the
> md5sum (which alre
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: idm-console-framework
Version : 1.1.7
Upstream Author : Red Hat, Inc.
* URL : http://directory.fedoraproject.org/sources
* License : LGPL
Programming Lang: Java
Description : IDM Cons
On Wed, 2012-02-08 at 07:57 +, Lars Wirzenius wrote:
> On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
> > But it's worse than this: even if dpkg decompresses before comparing,
> > debsums won't (and mustn't, for backward compatibility). So it's
> > potentially necessary to fix
On Wed, Feb 08, 2012 at 10:47:13AM +0100, Alexander Reichle-Schmehl wrote:
> I have no idea, but I'm not really sure if it's a good idea to remove
> samba either...
Absolutely not. They might be persuade-able away from waf though.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.o
On 08/02/12 10:22, Neil Williams wrote:
> Nothing in /usr/share/ matters for a cross package created by
> dpkg-cross (with the possible exception of /usr/share/pkg-config
> which was always anachronistic).
I'd understood that /usr/share/pkgconfig should be used for the
sort of packages that would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/2012 11:04 PM, Neil Williams wrote:
> I'm not convinced that this is fixable at the gzip level, nor is it
> likely to be fixable by the trauma of changing from gzip to
> something else.
while the original point of not considering compressors
On Wed, 8 Feb 2012 21:54:30 +1100
Russell Coker wrote:
> On Wed, 8 Feb 2012, Neil Williams wrote:
> > > Expecting that the compression gives the smallest file every time is
> > > reasonable.
> >
> > By a single byte - I've not seen file size changes beyond that range.
>
> It's a matter of pri
On Wed, 8 Feb 2012, Neil Williams wrote:
> > Expecting that the compression gives the smallest file every time is
> > reasonable.
>
> By a single byte - I've not seen file size changes beyond that range.
It's a matter of principle. A compression program is supposed to reliably
compress data.
* Lars Wirzenius [120208 08:58]:
> On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
> > But it's worse than this: even if dpkg decompresses before comparing,
> > debsums won't (and mustn't, for backward compatibility). So it's
> > potentially necessary to fix up the md5sums file for
On 08/02/12 09:55, Josselin Mouette wrote:
Le mercredi 08 février 2012 à 00:53 +0100, Stefano Karapetsas a écrit
:
Many users are using it well. Now that this is enough stable, I
begun the process for ask the inclusion in Debian. The first
package is mate-common.
http://bugs.debian.org/cgi-bin/b
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: libapache2-mod-nss
Version : 1.0.8
Upstream Author : Red Hat, Inc.
* URL : http://directory.fedoraproject.org/sources/
* License : GPL-2, Apache-2.0
Programming Lang: C
Description :
On Wed, 8 Feb 2012 02:52:52 +0200
Riku Voipio wrote:
> If it turns out not reasonable to expect the compression results to be
> identical, we should probably look into using dpkg --path-exclude= with
> /usr/share/{doc,man,info}/* when installing foreign-architecture packages.
That would be a sui
Hi!
Am 08.02.2012 09:02, schrieb Jon Dowland:
> Do we have any idea how many packages in Debian currently use waf?
Well, we opened about 55 bugs see
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=waf-unpack;users=ftpmas...@debian.org
(The list was created by searching for "waf" files in all so
On Wed, 8 Feb 2012 12:05:44 +1100
Russell Coker wrote:
> On Wed, 8 Feb 2012, Riku Voipio wrote:
> > If it turns out not reasonable to expect the compression results to be
> > identical
>
> It was reported that sometimes the size differs. Surely if nothing else
> having gzip sometimes produce a
Le mercredi 08 février 2012 à 00:53 +0100, Stefano Karapetsas a écrit :
> Many users are using it well. Now that this is enough stable, I begun
> the process for ask the inclusion in Debian.
> The first package is mate-common.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658783 (ITP)
> http
Do we have any idea how many packages in Debian currently use waf?
Is waf growing in popularity?
After reading [1] I get the impression it should die and we should
try to hasten that outcome.
[1] http://lists.debian.org/debian-devel/2010/02/msg00714.html
--
Jon Dowland
--
To UNSUBSCRIBE, e
80 matches
Mail list logo
