On Tue, Feb 04, 2020 at 11:03:03AM -0500, Lennart Sorensen wrote:
> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > >default* to use 32-bit time_t to keep compatibility with existing
> > >code. This
On Tue, 2020-02-04 at 11:03 -0500, Lennart Sorensen wrote:
> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > >default* to use 32-bit time_t to keep compatibility with existing
> > >code. This will
Hi!
On Tue, 2020-02-04 at 13:14:10 +, Steve McIntyre wrote:
> The glibc folks have taken an interesting approach.
>
> * 64-bit ABIs/architectures are already using 64-bit time_t
>throughout. The design is sane and so we should already be mostly
>safe here, modulo silly code bugs
On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> >default* to use 32-bit time_t to keep compatibility with existing
> >code. This will *not* be safe as we approach 2038.
> >
> > * 32-bit ABIs/arches *can*
Hi.
On Mon, Feb 03, 2020 at 09:46:09PM +0100, Andreas Jellinghaus wrote:
> I wrote the guide for OdroidHC1, happy to answer any questions.
Thank you for your work. I used that page as a template for two
successful HC2 Debian installations.
> Also the blobs required to boot the device
On Feb 04, Steve McIntyre wrote:
>We'd need to decide exactly which of our 32-bit ports we would want
>to do this path with (probably armhf->arhmft?, maybe
>armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
I agree with Ansgar here: there is no point in rebuilding
> * 32-bit ABIs/arches are more awkward. glibc will continue *by
>default* to use 32-bit time_t to keep compatibility with existing
>code. This will *not* be safe as we approach 2038.
>
> * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>upwards, but this will of
On Tue, 2020-02-04 at 13:14 +, Steve McIntyre wrote:
> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs
Hey folks,
Apologies - I should have sent this mail quite a while back. :-/
Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
the 2038 problem in the Linux world. I've spoken about this before,
e.g. at DebConf17. He's been pushing a lot of updates throughout the
Linux
Hi Paul,
On 2020.02.04 03:09, Paul Wise wrote:
Is there a plan to package edk2-platforms for Debian?
Not that I know of.
We already have
an edk2 package, but it only supports x86/ARM virtual machines. It
would be nice to have open UEFI firmware for ARM platforms available
in Debian.
You
Uwe Kleine-König wrote:
> I don't know the capabilities of the vendor U-Boot, but I already
> installed Debian successfully on some machines by just starting the
> installer via tftp.
unfortunately tftp and usb boot are not (yet) officially working on RPI 4
Hello,
On 2/3/20 9:46 PM, Andreas Jellinghaus wrote:
> The debian installer sounds great in theory, but in practice you install
> from one medium to a second medium. But with the device I have there is
> just a single medium: the sdcard I enter.
I don't know the capabilities of the vendor
12 matches
Mail list logo
