Hi!
The latest sid upgrades produce dependencies on:
ii libc6-dev-x322.17-5
i386 Embedded GNU C Library: X32 ABI Development Libraries for
AMD64
ii libc6-x322.17-5
On Thu, Jun 06, 2013 at 10:23:14AM +0200, Thorsten Glaser wrote:
> tglase@tglase:~ $ fgrep X32 /boot/config-3.9-1-amd64
> # CONFIG_X86_X32 is not set
See http://wiki.debian.org/X32Port and
http://lists.debian.org/debian-devel/2013/05/msg00355.html
Helmut
--
To UNSUBSCRIBE, email to debian-deve
Helmut Grohne subdivi.de> writes:
> http://lists.debian.org/debian-devel/2013/05/msg00355.html
Ah okay. That one got lost in GMane’s threading because the original
mail wasn’t posted in this newsgroup.
I still think it schizo that x32 is only halfway in and the Linux
kernel Debian team mostly s
On Thu, Jun 06, 2013 at 11:27:15AM +0200, Helmut Grohne wrote:
> On Thu, Jun 06, 2013 at 10:23:14AM +0200, Thorsten Glaser wrote:
> > tglase@tglase:~ $ fgrep X32 /boot/config-3.9-1-amd64
> > # CONFIG_X86_X32 is not set
>
> See http://wiki.debian.org/X32Port and
> http://lists.debian.org/debian-dev
On 2013-06-06 15:35, Thorsten Glaser wrote:
I still think it schizo that x32 is only halfway in and the Linux
kernel Debian team mostly sends signals that it wants to block the
architecture altogether. And the multilibs thing… nobody seems to
have commented on it either.
Sometimes it helps if e
Thorsten Glaser writes:
> No complaints against x32 per sé, I want to crossgrade there once it’s
> in, but for as long as it’s broken like this, it doesn’t make it look
> good.
Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect
SUBSTANTIAL porting of packages to be require
On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote:
> Thorsten Glaser writes:
>
> > No complaints against x32 per sé, I want to crossgrade there once it’s
> > in, but for as long as it’s broken like this, it doesn’t make it look
> > good.
>
> Be aware that x32 has sizeof(time_t) > size
On Thu, Jun 6, 2013 at 22:01:48 +0200, Adam Borowski wrote:
> It was Linus' decree that no new ABI is allowed to suffer from the Y2k38
> bug even if its word size is 32 bit, and I'd say he's right. This means
> that this problem will bite us the next time another 32 bit arch comes,
> so there's
Adam Borowski writes:
> On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote:
>> It's not quite as bad as the porting required for large file support,
>> but the consequences of not porting are worse.
> How come? I don't think runtime bugs that are not some kind of a Y2k38
> bug are lik
On Thu, 2013-06-06 at 22:40 +0200, Julien Cristau wrote:
> On Thu, Jun 6, 2013 at 22:01:48 +0200, Adam Borowski wrote:
>
> > It was Linus' decree that no new ABI is allowed to suffer from the Y2k38
> > bug even if its word size is 32 bit, and I'd say he's right. This means
> > that this problem
Russ Allbery debian.org> writes:
> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect
So has MirBSD/i386 (since 2004-06-19) and NetBSD (since roughly a year).
Most frequent thing is format specifiers when struct tm.tm_year is time_t
instead of long (which is a requirement
(Sorry about the lack of threading... for some reason I'm unable to find the
links to download mbox archives for replying to the messages.)
In response to Adam's comments about debootstrap not working because findutils
FTBFS: Yes, I'm aware of that, and for now you have to include "unreleased" a
On Fri, Jun 07, 2013 at 09:49:00AM +, Thorsten Glaser wrote:
> Russ Allbery debian.org> writes:
>
> > Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect
>
> So has MirBSD/i386 (since 2004-06-19) and NetBSD (since roughly a year).
>
> Most frequent thing is format spec
Kurt Roeckx dixit:
>tm_year should be an int, not a time_t or long. Note that it
POSIX says it “must” be a long…
>counts in years, and so even a 16 bit int isn't going to cause
>much problems for tm_year.
… but I disagree. All time_t seconds-since-the-epoch values
need (in practice) to round-t
On Fri, Jun 07, 2013 at 09:37:45PM +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
>
> >tm_year should be an int, not a time_t or long. Note that it
>
> POSIX says it "must" be a long...
It doesn't say so here. It has it as an int.
Also note that time_t didn't have a requirement to be an i
Kurt Roeckx dixit:
>If you add that requirement, it can be upto 24 bit smaller than
>time_t. But as far as I know, there is no such requirement. In
Sure. As I was saying, software in practice wants that,
such as the mktime test from gnulib.
bye,
//mirabilos
--
“It is inappropriate to require
On Fri, 2013-06-07 at 22:41 +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
>
> >If you add that requirement, it can be upto 24 bit smaller than
> >time_t. But as far as I know, there is no such requirement. In
>
> Sure. As I was saying, software in practice wants that,
> such as the mktime
On Fri, Jun 7, 2013 at 11:03 PM, Daniel Schepler wrote:
> (Sorry about the lack of threading... for some reason I'm unable to find the
> links to download mbox archives for replying to the messages.)
The Debian HTML archives list message-ids and have mailto: reply links
that include References/In
On Fri, Jun 07, 2013 at 10:41:47PM +, Thorsten Glaser wrote:
> Kurt Roeckx dixit:
>
> >If you add that requirement, it can be upto 24 bit smaller than
> >time_t. But as far as I know, there is no such requirement. In
>
> Sure. As I was saying, software in practice wants that,
> such as the
Daniel Schepler gmail.com> writes:
> (Sorry about the lack of threading... for some reason I'm unable to find
the
> links to download mbox archives for replying to the messages.)
https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/getarticle?rev=HEAD
Just call that with either the Message-ID sans
On 06/06/13 21:10, Adam Borowski wrote:
> On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote:
>> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect
>> SUBSTANTIAL porting of packages to be required. Particularly since that
>> arrangement is explicitly unsupported b
On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote:
> On 06/06/13 21:10, Adam Borowski wrote:
> > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote:
> >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect
> >> SUBSTANTIAL porting of packages to be required. Parti
On Tue, Jun 11, 2013 at 10:36:48PM +0100, Ben Hutchings wrote:
> On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote:
> > On 06/06/13 21:10, Adam Borowski wrote:
> > > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote:
> > >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you sh
Am 11.06.2013 16:09, schrieb Thorsten Glaser:
> Daniel Schepler gmail.com> writes:
>
>> (Sorry about the lack of threading... for some reason I'm unable to find
> the
>> links to download mbox archives for replying to the messages.)
>
> https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/getarticl
Matthias Klose wrote:
>Multi-Arch isn't there yet. And even if it is, the multilib builds should be
>kept for some more releases. There is a lot to do on the Debian side, and on
>the upstream side. So maybe it helps your understanding to get the required
>patches upstream to get multilib working
On Wed, Jun 12, 2013 at 09:59:31AM +0200, Matthias Klose wrote:
> > Why is gcc built multi-lib anyway?
>
> because developers expect to work it. there is a lot of code which just uses
> -m32/-m64 which should not deliberately broken.
This explains i386/amd64 multilib, which, while an ugly thing t
On Wed, Jun 12, 2013 at 09:45:21AM -0700, Daniel Schepler wrote:
> Matthias Klose wrote:
> >Multi-Arch isn't there yet. And even if it is, the multilib builds should be
> >kept for some more releases. There is a lot to do on the Debian side, and on
> >the upstream side. So maybe it helps your und
Adam Borowski wrote:
> Wouldn't it be easier to have lib32gcc1:amd64 merely depend on libgcc1:i386?
> It'd save a massive amount of complexity.
But that reintroduces the problem which convinced me there's a reason to keep
lib32gcc1 in the first place: suppose libgcc1:i386 and libgcc1:amd64 get ou
Am 12.06.2013 19:18, schrieb Adam Borowski:
> On Wed, Jun 12, 2013 at 09:59:31AM +0200, Matthias Klose wrote:
>>> Why is gcc built multi-lib anyway?
>>
>> because developers expect to work it. there is a lot of code which just uses
>> -m32/-m64 which should not deliberately broken.
>
> This explai
Am 12.06.2013 19:25, schrieb Adam Borowski:
> On Wed, Jun 12, 2013 at 09:45:21AM -0700, Daniel Schepler wrote:
>> Matthias Klose wrote:
>>> Multi-Arch isn't there yet. And even if it is, the multilib builds should be
>>> kept for some more releases. There is a lot to do on the Debian side, and
>>
30 matches
Mail list logo
