#archlinux32 | Logs for 2019-08-05
Back
[00:24:34] -!- charims has quit [Ping timeout: 272 seconds]
[01:06:56] -!- thePiGrepper has joined #archlinux32
[01:46:04] <buildmaster> pentium4/shellcheck is broken (says eurobuild6-3): https://archlinux32.org
[03:26:16] -!- MrBIOS has joined #archlinux32
[05:53:41] -!- MrBIOS has quit [Quit: MrBIOS]
[06:23:32] <buildmaster> pentium4/android-tools are broken (says eurobuild6-1): https://archlinux32.org
[06:34:30] <buildmaster> i686/android-tools are broken (says rechenknecht): https://archlinux32.org
[09:25:21] <buildmaster> i686/android-tools are broken (says eurobuild6-3): https://archlinux32.org
[09:26:20] <buildmaster> pentium4/android-tools are broken (says eurobuild6-6): https://archlinux32.org
[09:57:49] -!- MrBIOS has joined #archlinux32
[10:47:22] -!- thePiGrepper has quit [Ping timeout: 246 seconds]
[10:48:19] <arnd> Has anyone looked into plans for 64-bit time_t support on archlinux32?
[10:48:44] <arnd> I did a lot of the kernel support, and there is a glibc discussion about it at the moment, which will impact all 32-bit distros
[10:49:04] <arnd> the three options I see are
[10:49:52] <arnd> - stay with the current 32-bit time_t and let everything break in 10 to 19 years, as timeouts start crossing the y2038 boundary
[10:50:15] <arnd> - rebuild everything now with 64-bit time_t (once glibc allows that) and deal with the breakage once
[10:51:52] -!- deep42thought has joined #archlinux32
[10:51:53] <buildmaster> Hi deep42thought!
[10:51:53] <buildmaster> !rq deep42thought
[10:51:54] <phrik> buildmaster: <deep42thought> brtln: you're "the arch linux", we're "the other arch linux" and alarm is "arches linux", then?
[10:51:55] <arnd> - slowly migrate to from 32-bit to 64-bit time_t one package at a time to support rolling releases, and add version dependencies or new sonames to prevent breaking binaries when a library API changes
[10:52:22] <deep42thought> what would be the blast radius of such a change?
[10:53:14] <arnd> I think about a third of the libraries (very rough count based on looking at debian source packages) expose interfaces based on time_t
[10:53:40] <arnd> which leads to a very rough upgrade path
[10:54:14] <deep42thought> I think, breaking all at once is the best way
[10:54:15] <arnd> new packages with 64-bit time_t would also depend on at least a linux-5.1 kernel and a new (so far unreleased) glibc
[10:54:37] <deep42thought> which is both not really a problem for arch
[10:54:42] <arnd> ok, great
[10:55:31] <arnd> and the rebuild will break compatibility with most foreign binaries that are built against an old set of libraries
[10:55:42] -!- infides has joined #archlinux32
[10:55:54] <deep42thought> yes, we will need to rebuild almost everything
[10:56:13] <arnd> (of course, not rebuilding would break compatibility with foreign binaries that are built on other distros that did the migration)
[10:56:40] <deep42thought> I think, arch is not expected to be binary compatible in that sense
[10:56:59] <arnd> from talking to Debian folks, my impression was that they would prefer not to changne time_t on their i386 at all, but stop support before it breaks
[10:57:09] <deep42thought> :-D
[10:57:36] <arnd> Debian ARM will likely also change everything over, but it's not clear to me how they would do that given that they try to avoid mass rebuilds
[10:57:37] * deep42thought feels proud proposing to support something which debian consideres dropping support for
[10:58:38] <arnd> Fedora I suspect will just do the mass rebuild, as they do one per release, but they also don't care if their i686 port breaks before 2038
[11:01:55] <arnd> deep42thought: one suggestion I made for glibc was to have an intentionally imcompatible ABI (new soname) for arm32 and possibly for i686, rather than having a glibc that theoretically supports both time32 and time64 but can cause silent data corruption when someone links it the wrong way
[11:02:11] <arnd> is this something you care about one way or another?
[11:02:58] <deep42thought> this means deviation from x86_64, right? We usually try to avoid that
[11:04:24] <arnd> it would likely mean a new configure target architecture name in glibc
[11:05:25] <arnd> the idea would be to avoid having to document all package dependencies, which would be visible to the 64-bit ports
[11:05:47] <arnd> e.g. new bash binary would be incompatible with old readline and vice versa
[11:06:25] <arnd> this might be more important to debian than arch
[11:06:33] <deep42thought> yeah
[11:06:57] <deep42thought> in the end, we mostly have only one set of versions (two if you count packages in [testing], too)
[11:08:09] <deep42thought> to summarize: I'm fine either way (breaking abi or not)
[11:08:15] <arnd> do I understand it right that each package then gets build X ways, optimized for each CPU generation?
[11:08:35] <deep42thought> abaumann: when you're online, maybe, you can drop a few cents, too
[11:08:42] <deep42thought> X=3, yes
[11:08:47] <arnd> ok
[11:10:43] <arnd> so I guess the procedure could be to bootstrap another one that uses time64, get that to work, the add the other two with time64, and then drop the old ones at a convenient time?
[11:12:06] <arnd> or would you do it all in testing, and then move everything to stable at once?
[11:12:13] <deep42thought> I would rather try to bootstrap within one architecture
[11:12:21] <deep42thought> yes, that way, exactly
[11:12:50] <arnd> ok
[11:13:33] <arnd> and do you think the archlinuxarm people would do the same thing, or should I ask them separately (no idea how much you overlap)?
[11:13:49] <deep42thought> please ask them separately
[11:14:00] <deep42thought> we do not have too much in common :-)
[11:15:45] <arnd> ok, will do. thanks a lot for your thoughts so far, I'll also see what abaumann thinks later
[11:17:15] <deep42thought> thanks for asking us :-)
[14:19:34] -!- thePiGrepper has joined #archlinux32
[15:23:15] -!- infides has quit [Ping timeout: 248 seconds]
[16:41:10] -!- thePiGrepper has quit [Ping timeout: 272 seconds]
[16:59:44] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.query.2019-08-05T16:50:00.NO4jkR.stdin"?.
[17:07:07] -!- DCyrax has quit [Ping timeout: 246 seconds]
[17:19:18] * buildmaster resumes sanity.
[17:44:00] -!- MrBIOS has quit [Quit: MrBIOS]
[17:53:58] -!- thePiGrepper has joined #archlinux32
[18:12:55] -!- MrBIOS has joined #archlinux32
[18:17:34] -!- MrBIOS_ has joined #archlinux32
[18:17:44] -!- MrBIOS has quit [Ping timeout: 258 seconds]
[18:17:44] MrBIOS_ is now known as MrBIOS
[19:26:50] -!- infides has joined #archlinux32
[19:51:05] -!- deep42thought has quit [Quit: Leaving.]
[20:31:31] * buildmaster failed to execute a mysql query - can you have a look at "tmp.mysql-functions.query.2019-08-05T20:20:40.Lz7btP.stdin"?.
[21:08:40] -!- DepositePirate has quit [Ping timeout: 260 seconds]
[21:09:20] -!- DepositePirate has joined #archlinux32
[23:42:16] -!- infides has quit [Ping timeout: 246 seconds]