From: Danny Milosavljevic <dannym@scratchpost.org>
To: zimoun <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Release v1.2 timetable
Date: Wed, 7 Oct 2020 18:29:18 +0200 [thread overview]
Message-ID: <20201007182918.57a95718@scratchpost.org> (raw)
In-Reply-To: <20201007173944.779a51e9@scratchpost.org>
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
Hi zimoun,
On Wed, 7 Oct 2020 17:39:44 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:
> > BTW, is this Bug #43720 [5] blocking for the release too?
> >
> > Well, what is the status and the plan about this armhf topic?
The short term plan is to only build 32 bit releases on 32 bit machines and
64 bit releases on 64 bit machines (I chose my words very carefully here.
I mean exactly that. To be clear, do not build armhf on x86_64, do not
build armhf on aarch64, and best also do not build i686 on x86_64).
If there are already substitutes built that way, make sure to take those
offline.
This is not a fix but only a workaround--see table [1]. It IS perfectly
possible and easy for a 32 bit kernel to return a 64 bit value to userspace.
And then userspace can fail--or worse, not fail but still have an error.
Long term, I am fixing it in guix branch wip-file-offset-bits-64-sledgehammer
by enabling large file support. That means that off_t will be 64 bits on all
architectures (including 32 bits). Once off_t is the same size on all
architectures, an architecture-dependent off_t size mismatch can't happen,
now can it?
All the 32 bit distributions I know how enabled large file support decades
ago--so it should work fine by now.
[1] http://issues.guix.gnu.org/issue/43591#30
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-10-07 16:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 12:16 Release v1.2 timetable zimoun
2020-09-29 15:07 ` Danny Milosavljevic
2020-10-07 14:51 ` zimoun
2020-10-07 15:39 ` Danny Milosavljevic
2020-10-07 15:56 ` Weird things found while fixing basic Guix packages Danny Milosavljevic
2020-10-12 11:53 ` Ludovic Courtès
2020-10-07 16:29 ` Danny Milosavljevic [this message]
2020-10-12 11:52 ` 32-bit builds on 64-bit hardware/VMs Ludovic Courtès
2020-10-12 12:06 ` Andreas Enge
2020-10-13 13:54 ` Ludovic Courtès
2020-10-07 16:31 ` Release v1.2 timetable Danny Milosavljevic
2020-10-05 10:18 ` pelzflorian (Florian Pelz)
2020-10-05 11:16 ` Julien Lepiller
2020-10-05 12:38 ` Miguel Ángel Arruga Vivas
2020-10-05 13:50 ` Julien Lepiller
2020-10-05 13:48 ` Ludovic Courtès
2020-10-05 21:17 ` zimoun
2020-10-06 6:57 ` Mathieu Othacehe
2020-10-07 14:36 ` zimoun
2020-10-21 9:14 ` Ludovic Courtès
2020-10-22 7:55 ` Mathieu Othacehe
2020-10-23 8:39 ` zimoun
2020-10-26 22:52 ` Ludovic Courtès
2020-10-06 6:59 ` Efraim Flashner
2020-10-06 7:05 ` Mathieu Othacehe
2020-10-06 7:26 ` Efraim Flashner
2020-10-06 7:57 ` Mathieu Othacehe
2020-10-07 14:39 ` zimoun
2020-10-09 18:25 ` Andreas Enge
2020-10-09 18:37 ` Danny Milosavljevic
2020-10-12 11:47 ` Shipping more installer images? Ludovic Courtès
2020-10-12 13:48 ` Danny Milosavljevic
2020-10-13 13:51 ` Ludovic Courtès
2020-10-13 14:19 ` Mathieu Othacehe
2020-10-13 21:23 ` Ludovic Courtès
2020-10-13 16:29 ` Danny Milosavljevic
2020-10-13 15:07 ` Efraim Flashner
2020-10-13 21:25 ` Ludovic Courtès
2020-10-19 15:17 ` Update on the timeline for the release v1.2 zimoun
2020-10-19 18:26 ` Miguel Ángel Arruga Vivas
2020-10-19 19:27 ` pelzflorian (Florian Pelz)
2020-10-19 21:57 ` Julien Lepiller
2020-10-21 12:44 ` Ludovic Courtès
2020-10-21 14:14 ` zimoun
2020-10-21 15:57 ` Ludovic Courtès
2020-10-21 18:03 ` Julien Lepiller
2020-10-21 21:27 ` Marius Bakke
2020-10-21 22:16 ` Ludovic Courtès
2020-10-21 22:23 ` zimoun
2020-10-21 22:36 ` zimoun
2020-10-26 22:44 ` Ludovic Courtès
2020-10-31 2:41 ` Maxim Cournoyer
2020-10-31 22:28 ` Branching for v1.2? Ludovic Courtès
2020-11-01 2:21 ` Miguel Ángel Arruga Vivas
2020-11-02 16:56 ` Ludovic Courtès
2020-11-02 8:43 ` zimoun
2020-11-02 13:20 ` Miguel Ángel Arruga Vivas
2020-11-02 15:00 ` Julien Lepiller
2020-11-02 17:56 ` pelzflorian (Florian Pelz)
2020-11-03 12:51 ` Tobias Geerinckx-Rice
2020-11-03 13:46 ` pelzflorian (Florian Pelz)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201007182918.57a95718@scratchpost.org \
--to=dannym@scratchpost.org \
--cc=guix-devel@gnu.org \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).