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 a package
> installed for multiple archit
On Wed, 08 Feb 2012, Michael Biebl wrote:
> >> error: Unable to migrate to dependency based boot sequencing.
> >> error: Problems detected: package initscripts left obsolete init.d script
> >> behind, package initscripts left obsolete init.d script behind, package
> >> initscripts left obsolete ini
Your message dated Tue, 24 Jan 2012 21:02:57 +
with message-id
and subject line Accepted libswe 1.77.00.0004-1 (source all i386)
has caused the Debian Bug report #635672,
regarding ITP: libswe -- Swiss Ephemeris
to be marked as done.
This means that you claim that the problem has been dealt w
Riku Voipio writes:
> 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.
I believe the only packages that pose a problem are
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 an unnecessarily large file is a bug!
Expecting that the compression
On Tue, Feb 07, 2012 at 10:13:01PM +, Neil Williams wrote:
> On Tue, 7 Feb 2012 14:01:57 -0800
> Steve Langasek wrote:
> > At this stage, I have no reason to think that's not achievable, though no
> > one seems to have dived very deep into the bug yet. And whether gzip
> > upstream agrees thi
[taking this to debian-devel]
On 08.02.2012 01:12, Roger Leigh wrote:
> On Wed, Feb 08, 2012 at 04:23:01AM +0530, Lone Learner wrote:
>> I am not able to switch to dependency based boot. Here is the relevant
>> output.
>>
>> debian:/boot/grub# dpkg-reconfigure sysv-rc
>> info: Checking if it is saf
On Tue, 07 Feb 2012, Roger Leigh wrote:
> While the waf behavour does sound quite awful, is this really
> any different than the current behaviour of the autotools? The
That is one of the reasons why you are supposed to retool on distro builds.
Retooling the entire build system as part of the "re
Hi,
I am a developer of MATE Desktop Environment
(http://www.mate-desktop.org), a fork of GNOME2 started in June 2011.
Currently MATE has a little team of developers and contributors, and
many users thanks to ready packages for some distributions (Debian,
Ubuntu, Arch, Fedora) and thanks to th
On Tue, 07 Feb 2012, Jonathan Nieder wrote:
> Henrique de Moraes Holschuh wrote:
> > Maybe you can switch to sha256 and add the new functionality while at
> > it? Detect which mode (md5sum raw, sha256 uncompress) by the size of
> > the hash. Old debsums won't work with the new files, but is that
Henrique de Moraes Holschuh wrote:
> Maybe you can switch to sha256 and add the new functionality while at
> it? Detect which mode (md5sum raw, sha256 uncompress) by the size of
> the hash. Old debsums won't work with the new files, but is that really
> a problem? That's what stable updates and
On Tue, 07 Feb 2012, 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
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256 unc
On Tue, 07 Feb 2012, Marco d'Itri wrote:
> On Feb 07, Thomas Goirand wrote:
> > Are you trying to make the point that, with containers,
> > you wouldn't need ssh, and you would with VMs? If so,
> With *OpenVZ* I do not need sshd, ftpd and cron in the guest because
> I can use the one in the host.
Neil Williams writes:
> 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 already exists) doesn't match.
Another pos
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
> On Tue, 07 Feb 2012 19:11:16 +0100
> Michael Biebl wrote:
>
> > On 07.02.2012 18:07, Joey Hess wrote:
> > > Neil Williams wrote:
> > >> I'd like to ask for some help with a bug which is tripping up my tests
> > >> with the multiarch
On Tue, 7 Feb 2012 13:16:01 +
Ian Jackson wrote:
> Michael Biebl writes ("Doesn't contain source for waf binary code"):
> > as this issue affects quite a few packages, I'd like to bring this
> > up for wider discussion.
> >
> > The issue basically is, that the waf build system uses a python
On Tue, 7 Feb 2012 14:01:57 -0800
Steve Langasek wrote:
> There are various ways to meet both the multiarch constraints and the policy
> requirements, including shipping an arch:all common package that will
> contain the changelog for each multiarch library, which then ships just a
> symlink. Bu
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl wrote:
> On 07.02.2012 18:07, Joey Hess wrote:
> > Neil Williams wrote:
> >> 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
Hi Joey,
On Tue, Feb 07, 2012 at 01:07:11PM -0400, Joey Hess wrote:
> Neil Williams wrote:
> > 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.
> pristine-tar hat tri
Le Tuesday 7 February 2012 03:52:33, Henrique de Moraes Holschuh a écrit :
> On Mon, 06 Feb 2012, Ben Hutchings wrote:
> > > > arbitrarily large files (in my workflow, 5-100 GB) in /tmp, which is
> > > > on the root filesystem.
And swap as hell and kill interactivity
>
> Well, that is Seriously B
Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen
* Package name: 389-adminutil
Version : 1.1.15
Upstream Author : Red Hat inc.
* URL : http://directory.fedoraproject.org/
* License : LGPL-2.1
Programming Lang: C
Description : Utility library for 38
Package: wnpp
Owner: gregor herrmann
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libmodule-implementation-perl
Version : 0.03
Upstream Author : Dave Rolsky
* URL : http://search.cpan.org/dist/Module-Imple
On 08/02/2012 02:05, Andrey Rahmatullin wrote:
> On Tue, Feb 07, 2012 at 09:47:06AM -0800, Russ Allbery wrote:
> While the waf behavour does sound quite awful, is this really any
> different than the current behaviour of the autotools? The
> "configure" script is an unreadable mess gen
Martin Eberhard Schauer wrote:
The changes have ill side-effects:
[...]
- These (untranslated) one-liners is what one gets visiting (2), e.g. (3).
Oh-oh. This was reported as #657557:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657557
- There are no new Translation-xx files (4).
Co
Alexander Reichle-Schmehl writes ("Re: Doesn't contain source for waf binary
code"):
> However, regarding that specific point: waf once was packaged in
> Debian. See <20100227195857.07540195@utumno>
> (http://lists.debian.org/debian-devel/2010/02/msg00714.html) for details
> about the removal.
On 07.02.2012 18:07, Joey Hess wrote:
> Neil Williams wrote:
>> 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.
>
> pristine-tar hat tricks[1] aside, none of gzip, bzip
On Tue, Feb 07, 2012 at 06:09:40PM +0100, Vincent Bernat wrote:
[...]
> It applies. The major point is that with containers, RAM is shared
> accross containers (the same kernel is used for all containers). If one
> container needs for a few seconds 200 MB, it can just use them. No
> me
On Tue, Feb 07, 2012 at 09:47:06AM -0800, Russ Allbery wrote:
> >>> While the waf behavour does sound quite awful, is this really any
> >>> different than the current behaviour of the autotools? The
> >>> "configure" script is an unreadable mess generated by the expansion of
> >>> macros in the au
Andrey Rahmatullin writes:
> On Tue, Feb 07, 2012 at 09:12:37AM -0800, Russ Allbery wrote:
>>> While the waf behavour does sound quite awful, is this really any
>>> different than the current behaviour of the autotools? The
>>> "configure" script is an unreadable mess generated by the expansion
On Tue, Feb 07, 2012 at 09:12:37AM -0800, Russ Allbery wrote:
> > While the waf behavour does sound quite awful, is this really any
> > different than the current behaviour of the autotools? The "configure"
> > script is an unreadable mess generated by the expansion of macros in the
> > autotools
On 02/07/2012 05:19 PM, Ian Jackson wrote:
Michael Biebl writes ("Re: Doesn't contain source for waf binary code"):
The waf-unpack tagged bug reports refer to the Debian wiki with
instructions how to ship the waf script in unpacked form [2].
This is, unfortunately, not sufficient.
I assume th
Roger Leigh writes:
> While the waf behavour does sound quite awful, is this really any
> different than the current behaviour of the autotools? The "configure"
> script is an unreadable mess generated by the expansion of macros in the
> autotools packages; it too bears little relation to the or
OoO En ce début d'après-midi nuageux du mardi 07 février 2012, vers
14:00, Thomas Goirand disait :
>> With vservers and OpenVZ you can run each service in its own container
>> with a small memory footprint. With Xen/KVM, you will need to allocate
>> at least 128 MB for each container.
>>
Neil Williams wrote:
> 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.
pristine-tar hat tricks[1] aside, none of gzip, bzip2, xz are required
to always produce the same c
On Feb 07, Thomas Goirand wrote:
> Are you trying to make the point that, with containers,
> you wouldn't need ssh, and you would with VMs? If so,
With *OpenVZ* I do not need sshd, ftpd and cron in the guest because
I can use the one in the host.
It's a custom environment, but I have no way to d
Package: wnpp
Severity: wishlist
Owner: ivo Maintz
* Package name: r-cran-deal
Version : 1.2.34
Upstream Author : Susanne Gammelgaard Bottcher
* URL : http://cran.r-project.org/web/packages/deal/index.html
* License : GPL2
Programming Lang: C, R
Descriptio
On 2012-02-04 14:16, Ondřej Surý wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fellow developers,
this is just a heads up that we will upload php version 5.4 into
unstable very soon. It is currently in RC phase and we spoke to PHP
upstream and both parties think this is a good idea to i
Sorry, this message was meant for an other threat.
On 07/02/12 17:33, Jerome BENOIT wrote:
Hello List:
what is the status of an orphaned package but that is waiting for an sponsor to
be uploaded ?
Thanks,
Jerome
On 03/02/12 20:33, Michael Biebl wrote:
Hi,
as this issue affects quite a few
On Tue, Feb 07, 2012 at 01:16:01PM +, Ian Jackson wrote:
> Michael Biebl writes ("Doesn't contain source for waf binary code"):
> > as this issue affects quite a few packages, I'd like to bring this up
> > for wider discussion.
> >
> > The issue basically is, that the waf build system uses a p
Michael Biebl writes ("Re: Doesn't contain source for waf binary code"):
> The waf-unpack tagged bug reports refer to the Debian wiki with
> instructions how to ship the waf script in unpacked form [2].
This is, unfortunately, not sufficient.
> I assume the FTP team at least considers this approa
Hello List:
what is the status of an orphaned package but that is waiting for an sponsor to
be uploaded ?
Thanks,
Jerome
On 03/02/12 20:33, Michael Biebl wrote:
Hi,
as this issue affects quite a few packages, I'd like to bring this up
for wider discussion.
The issue basically is, that the w
Hi!
Am 07.02.2012 14:16, schrieb Ian Jackson:
> * Upstream waf should be packaged somehow. Upstream's declared
>policy of asking packages to ship a copy of waf suggests that there
>won't be much API stability so we will need to encode the waf
>version number in the package name, an
On 07.02.2012 14:16, Ian Jackson wrote:
> I compared the tarball in waf in postler 0.1.1-1.1 with the upstream
> code as obtained from "git clone https://code.google.com/p/waf/";. It
> turns out that the tarball embedded in the "waf" script is not the
> original "waf" source distribution. It con
Package: wnpp
Severity: normal
I intend to orphan the bochs package. I've uploaded what I had pending
in my git tree for bochs 2.4.6 to unstable, and the pending changes I
had for the new upstream release 2.5.1 to experimental, because the
latter gets random freezes at least on the wxWidgets GUI,
On Wed, 8 Feb 2012, Thomas Goirand wrote:
> With Etch, 48 MB was enough. With Lenny, 64 MB was enough.
> With Squeeze, 96 MB is enough (the minimum is between 64 and
> 96 MB, I didn't care investigating). And with 96 MB, you can already
> run a DNS server, OpenVPN, or a (very basic) mail server. T
On Wed, Feb 01, 2012 at 07:43:31PM -0600, Steve M. Robbins wrote:
> >
> > The solution is having upstream adopting a sane naming scheme for
> > mpi-enabled
> > flavor libraries instead of using always the same names for all.
>
> Francesco, please clarify: are you speaking of the hdf5 upstream or
On Tue, Feb 07, 2012 at 09:28:00AM +, Alastair McKinstry wrote:
> On 2012-02-02 01:43, Steve M. Robbins wrote:
> > Hi,
> >
> > I'd like to contribute towards a solution for this. I'm forwarding to
> > debian-devel to get some others' ideas.
> > Naively, I don't understand why netcdf can't offe
Michael Biebl writes ("Doesn't contain source for waf binary code"):
> as this issue affects quite a few packages, I'd like to bring this up
> for wider discussion.
>
> The issue basically is, that the waf build system uses a python script,
> which embeds a bz2 tarball containing further python so
On 02/03/2012 08:53 PM, Adam Borowski wrote:
>> ssh works.
>>
> It triples the memory footprint of an empty Debian container (init + syslogd +
> cron[1]), and adds a new daemon that can be potentially subverted.
>
> Of course, usually sshd is strongly preferred (so much better than needing
> n
On 02/03/2012 01:55 AM, Vincent Bernat wrote:
> With vservers and OpenVZ you can run each service in its own container
> with a small memory footprint. With Xen/KVM, you will need to allocate
> at least 128 MB for each container.
>
NO ! The limit isn't that great.
With Etch, 48 MB was enoug
On 07.02.2012 10:59, Neil Williams wrote:
>
> It would be a very laborious task to check the md5sums of every .gz file
> in /usr/share/doc in every MultiArch: same package across all
> architectures and the Contents-* files on the mirrors don't contain the
> filesize of the listed files. Does anyo
Package: wnpp
Severity: wishlist
Owner: Ole Streicher
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org
* Package name: slalib
Version : 2.5.4
Upstream Author : Pat Wallace :
* URL : http://starlink.jach.hawaii.edu/starlink
* Lic
On Mon, 6 Feb 2012 08:31:15 +0100
Raphael Hertzog wrote:
> If you discover any bug in dpkg's multiarch implementation, please
> report it to the BTS (against the version 1.16.2~wipmultiarch).
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg fro
On 2012-02-02 01:43, Steve M. Robbins wrote:
> Hi,
>
> I'd like to contribute towards a solution for this. I'm forwarding to
> debian-devel to get some others' ideas.
> Naively, I don't understand why netcdf can't offer multiple variants,
> just as hdf5 does. Or, at least, one package libnetcdf-m
[CCing you since I'm not sure you are subscribed]
On Tue, Feb 7, 2012 at 3:09 PM, Андрей Гаврилин wrote:
> I have changed Linux detection and I have added *BSD detection. We
> will use It for Mandriva/ROSA.
Please report a bug against the os-prober package:
http://www.debian.org/Bugs/Reporting
55 matches
Mail list logo
