gmane.linux.debian.devel.general

Re: amd64 as default architecture

Philipp Kern — 2012-05-23T09:58:16

We're building with linux32 on those architectures. If some chroot (or
buildd/arch) is missing the correct setup, please drop us a mail.

Kind regards
Philipp Kern, with a wb-team hat

Bug#674135: ITP: spglib -- Crystal Symmetry Library

Michael Banck — 2012-05-20T18:35:54

Package: wnpp
Severity: wishlist
Owner: DebiChem Project <debichem-devel< at >lists.alioth.debian.org>


* Package name    : spglib
  Version         : 1.0.8
  Upstream Author : Atsushi Togo <atz.togo< at >gmail.com>
* URL             : http://spglib.sourceforge.net
* License         : BSDish
  Programming Lang: C
  Description     : Crystal Symmetry Library

Spglib is a library to find and handle crystal symmetries.
.
Features include:
.
 * Identify space-group type
 * Find symmetry operations
 * Find a primitive cell
 * Search irreducible k-points
 * Refine crystal structure
 * Wyckoff position assignment

Re: amd64 as default architecture

Julien Cristau — 2012-05-23T09:12:44

When is vm86 mode ever a fast path?

FWIW X used to have a way to build both vm86 and x86emu backends, and
fall back to x86emu if it got -ENOSYS.  Now it just uses x86emu.

Cheers,
Julien

Bug#674123: ITP: libdata-util-perl -- selection of utilities fordata and data types

Salvatore Bonaccorso — 2012-05-23T08:22:38

Package: wnpp
Owner: Salvatore Bonaccorso <carnil< at >debian.org>
Severity: wishlist
X-Debbugs-CC: debian-devel< at >lists.debian.org,debian-perl< at >lists.debian.org

* Package name    : libdata-util-perl
  Version         : 0.59
  Upstream Author : Goro Fuji(gfx) <gfuji(at)cpan.org>.
* URL             : http://search.cpan.org/dist/Data-Util/
* License         : Artistic or GPL-1+
  Programming Lang: Perl
  Description     : selection of utilities for data and data types

Data::Util provides utility functions for data and data types,
including functions for subroutines and symbol table hashes (stashes).

The implementation of this module is both Pure Perl and XS, so if
you have a C compiler, all the functions this module provides are
really faster.

This is a new dependency for libsvn-hooks-perl.

Re: Apologies, false alarm

Thomas Koch — 2012-05-23T06:02:02

Tomas Fasth:

I'm sorry. Please accept my appologies for this false alarm!

Thomas Koch, http://www.koch.ro

Re: zlib and biarch/triarch

Steve Langasek — 2012-05-23T00:06:25


zlib is rather low in the stack, so is going to be one of the last packages
to drop biarch support.  Currently, ia32-libs, wine, lsb,
nvidia-graphics-drivers, and zsnes all depend on biarch zlib packages.

Of course, all of these packages appear to be specific to amd64, so I don't
know why Mark would be adding new biarch packages for s390.  You should
probably ask him.

Re: amd64 as default architecture

Charles Plessy — 2012-05-22T23:16:03

Le Tue, May 22, 2012 at 04:01:29PM +0100, Ben Hutchings a écrit :

Obviously, if there are no skilled volunteers to maintain the current i386
kernel, there is no way to support it.  But in case the user base is too large
compared to the developer base, perhaps users can self-organise and gather
donations to pay for the work ?  I would definitely prefer to spend the price
of a new hardware as ~5 years of donations instead of replacing it as long as
it is performant enough for its task (I bought mine a few months ago).  What do
you think would be the cost to keep a good-shaped i386 kernel package in
wheezy+2 ?

Have a nice day,

Assumptions when processing triggers (was [pkg-mono-group]Bug#671711: monodoc-browser: fails to upgrade) from 'testing'

Iain Lane — 2012-05-22T22:37:48

Greetings,

[ I already asked this on d-dpkg, but go no response, so am "re-posting"
  this question to -devel. The original report along with full log is in
  #671711 ]

On Sun, May 06, 2012 at 10:37:53AM +0200, Andreas Beckmann wrote:

It's because libgtk2.0-cil (on which monodoc-browser depends) has been
unpacked but not configured at this point. I thought (from reading
/usr/share/doc/dpkg-dev/triggers.txt.gz):

,----
| Packages in t-awaited and t-pending demand satisfaction of their
| dependencies just like packages in installed.
`----

that I could assume this would be the case when running the trigger, but
apparently not. What am I guaranteed here? I spoke to Colin Watson about
this at UDS and he suggested that perhaps the postinst trigger could
register gtk-sharp into the GAC itself, which would be somewhat
unfortunate but would probably work if it is guaranteed that
libgtk2.0-cil will be unpacked or better when the trigger is activated.

In general, what assumptions is it valid to make about the stat

Re: [MIA?] Tomas Fasth, Maintainer of Termit et al

Tomas Fasth — 2012-05-22T21:57:32

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Koch skrev 2012-05-22 09:18:
Tomas Fasth
of the

Hi Thomas,

I sent you an answer 7th of May, see below.

Regards, Tomas

- -------- Ursprungligt meddelande --------
Ämne:     Re: NMU for termit Debian package?
Datum:     Mon, 07 May 2012 13:58:06 +0200
Från:     Tomas Fasth <tomfado< at >gmail.com>
Svar till:     tomfa< at >debian.org
Organisation:     Debian
Till:     thomas< at >koch.ro
Kopia:     Nobuhiro Iwamatsu <iwamatsu< at >nigauri.org>, Julian Taylor
<jtaylor.debian< at >googlemail.com>, Martintxo <martintxo< at >sindominio.net>,
Tomas Fasth <tomfa< at >debian.org>



Den Mon May  7 06:58:10 2012 skrev Thomas Koch:
issues
point

Hi Thomas,

I don't mind you preparing a NMU at all. I welcome your initiative. As
a matter of fact, I'm considering to put the package out for adoption,
since I have don't have time to actively maintain it. I uploaded the
package at first to bring it into the Debian proper. It deserve a DD
with more time at hand.

Regards

- -- 
Tomas Fasth <tomfa< at >deb

Re: switching from exim to postfix

Jon Dowland — 2012-05-22T21:39:24

PGP/MIME signatures are against the encoded content, not the
decoded content. However, the encoding process moves the mail
down to 7bit.

Re: amd64 as default architecture

Jonathan McDowell — 2012-05-22T21:34:34

...

Which backend to use is a compile time option, so this would be
switching to always use the x86emu backend. Not a big issue if we're
going to drop 32 bit kernels entirely, a performance impact on those
machines if we're not.

J.

Re: amd64 as default architecture

Jon Dowland — 2012-05-22T21:28:39

Are you volunteering to maintain the i386 architecture until 2035, or
volunteering Ben to do it? ☺

Bug#674074: ITP: tinyxml2 -- C++ XML parsing library

Chow Loong Jin — 2012-05-22T21:22:30

Package: wnpp
Severity: wishlist
Owner: Chow Loong Jin <hyperair< at >debian.org>

* Package name    : tinyxml2
  Version         : 0~git20120518.1.a2ae54e
  Upstream Author : Lee Thomason <leethomason< at >gmail.com>
* URL             : http://www.grinninglizard.com/tinyxml2/
* License         : zlib/libpng
  Programming Lang: C++
  Description     : C++ XML parsing library

TinyXML2 is a simple and small C++ XML parser that can be easily integrating
into other programs. It reads XML and creates C++ objects representing the XML
document. The objects can be manipulated, changed, and saved again as XML.
.
TinyXML2 supersedes the previous TinyXML library, with various improvements:
 - Fewer memory allocations (1% - 10% compared to TinyXML)
 - Uses less memory (about 40% of that used by TinyXML)
 - Faster
 - No STL requirement
 - More modern C++, including a proper namespace
 - Proper and useful handling of whitespace

Re: Wheezy release: CDs are not big enough any more...

Thorsten Glaser — 2012-05-22T20:11:48

Guillem Jover dixit:


The problem is that binutils’ ar generates SYSV style filenames
for members since the switch to ELF, while the deb format uses
BSD style filenames. Nowadays, tools like apt-extracttemplates
support both, but it’s not so long it didn’t (e.g. on hardy).

If you use “GNUTARGET=a.out-i386-linux ar rc …” you get a suitable
archive… on an i386 host; on other hosts, the $GNUTARGET to use
differs. (Hence support for BSD/deb(5) style ar(5) archives in
paxtar and, I think I’ve read, (free)bsdtar.)

bye,
//mirabilos

Re: amd64 as default architecture

Ben Hutchings — 2012-05-22T19:51:17

 
So the x86emu backend should be built too if there are any 64-bit
systems that need libx86 - and maybe for other reasons as well.
That's not a big deal, though, surely?

By the way, lack of VM86 mode under Long Mode is a restriction of the
AMD64 architecture definition and not a kernel limitation.

Ben.

Re: amd64 as default architecture

Guillem Jover — 2012-05-22T19:45:15


I disagree that this is a one-time action, people might want to
cross-grade specific packages back and forth, not just the entire
installation. Also unsafe cross-grade does not only affect the
Essential set, it also affects anything involved in the boot process,
if for whatever reason the system crashes and apt would have removed
such package the system would be rendered unbootable.


I guess I don't see the additional complexity in the dpkg specific
case, it just needs the shared libraries to be installed which should
be co-installable anyway, and the rest being M-A:foreign.

regards,
guillem

Re: Wheezy release: CDs are not big enough any more...

Guillem Jover — 2012-05-22T19:36:00

It's not just pseudo-essential, anything pulled into the base set
would be affected. In any case that was where my comment was coming
from (probably not clearly enough though). Whenever something gets
pulled into the base set by something else (another package, an update
to the archive override, etc), then there's going to be a time window
where the priority in the .deb and the archive override will not match,
and the package will need to be modified to accommodate that change.
So such possible conditional handling in dpkg-deb (with which I'm not
comfortable with, because it's encoding non-generic policy into the
tool) would not help anyway, at which point I'd say it makes more
sense to just explicitly call dpkg-deb with -Zgzip for base packages.


I'd say debian-devel, either because most of the time this implies a
Pre-Depends anyway, or because it's just promoting something into the
Essential set.

thanks,
guillem

Re: amd64 as default architecture

Sven Joachim — 2012-05-22T19:18:21


Oh, indeed.


The lrmi backend uses vm86 mode which is not supported under an x86_64
kernel.

Cheers,
       Sven

Re: amd64 as default architecture

Simon McVittie — 2012-05-22T18:40:57

That bug seems to be that the userland and kernel parts of virtualbox
must have the same "width" to work correctly.

In a multiarch world, that at least has a workaround: if your kernel is
amd64 but your default architecture is i386, replace virtualbox/i386
with virtualbox/amd64 and it should be happy again.


Is this the right bug? According to the reporter's reportbug System
Information, he's running libx86/i386 on one of the i386 kernel
flavours, and I don't see any indication that amd64 is involved at all.

    S

Re: amd64 as default architecture

Sven Joachim — 2012-05-22T18:24:06


I don't think so, although those have been quite annoying for me.

The most prominent example is probably virtualbox (#456391), and
anything that uses libx86 won't work either (#492470).

Cheers,
       Sven

Re: Wheezy release: CDs are not big enough any more...

Guillem Jover — 2012-05-22T18:21:45

Using binutils' ar should be considered supported, and works fine with
dpkg-deb and dpkg, the accepted format is documented in deb(5). I'd
consider any program not following that to be either somewhat buggy,
or special purpose (for example dak only accepts a subset of a valid
deb format).

thanks,
guillem