[00:00:00] - {Tageswechsel: Sonntag, 13. Oktober 2024}
[21:00:40] <dilfridge> meeting time
[21:00:42] <dilfridge> !proj council
[21:00:43] <willikins> (council@gentoo.org) arthurzam, dilfridge, mgorny, robbat2, sam, soap, ulm
[21:00:51] <dilfridge> 1) roll call
[21:00:53] -*- ulm here
[21:00:55] -*- arthurzam here
[21:00:55] -*- sam_ here
[21:00:58] -*- dilfridge here
[21:01:00] -*- soap here
[21:01:07] -*- mgorny here
[21:01:07] <robbat2> present
[21:01:16] <dilfridge> excellent, all here
[21:01:24] <dilfridge> 2) apology
[21:01:36] <dilfridge> sorry, I completely forgot about sending out the mails
[21:01:42] <dilfridge> even though arthurzam tried to remind me
[21:02:02] <dilfridge> I think there wasn't much other business that couldve come up though
[21:02:08] <dilfridge> so damage is limited
[21:02:37] <dilfridge> mgorny sent one reply to the thread so this is our one nonstandard agenda item
[21:02:41] <arthurzam> it happens, let's just try to not repeat next time :)
[21:02:49] <dilfridge> 3) time64 
[21:03:13] <dilfridge> mgorny already summarized the situation, there's not much I can add
[21:03:23] <dilfridge> we tried to work with debian, they werent interested
[21:03:31] <dilfridge> now we only get angry wookie noises
[21:03:36] <soap> mgorny: final question, utmp?
[21:03:48] <soap> utmp is the one thing people overlook with time64
[21:03:59] <mgorny> errr, i'm not the person to answer that
[21:04:11] <robbat2> i have another question re the proposal to change chost value
[21:04:11] <mgorny> i'm only doing ground work here
[21:04:36] <sam_> soap: the problem is, the suse guy is sort of leading the charge to just replace it with logind
[21:04:44] <sam_> we haven't got an alternative plan there right now
[21:04:52] <soap> and he's right tbh
[21:05:09] <soap> but ofc the usual crowd will come with non-suggestions
[21:05:25] <mgorny> lemme rephrase: i'm tackling the transition part, not the design of time64 systems per se
[21:05:30] <sam_> "just make it unsigned" (which is not a terrible idea but if we're going to do that, let's just make it a proper 64-bit type anyway, it doesn't have to be time_t)
[21:05:40] <dilfridge> that's happened anyway
[21:05:47] <sam_> i need to reboot, my rendering is broken for a moment
[21:05:48] <dilfridge> I think the code is already in glibc
[21:05:49] <sam_> please hold
[21:05:55] -*- dilfridge holds
[21:06:21] <robbat2> maybe good that I explain my CHOST question while he's rebooting
[21:06:22] <soap> mgorny: the transition needs to account for utmp, since it's still broken, is what I'm saying
[21:06:53] <dilfridge> explain
[21:07:17] <mgorny> also, any ideas?
[21:07:24] <soap> you want to fix the Y2038 problem, but utmp is still broken
[21:07:33] <soap> I agree with the suse guy, dump utmp
[21:07:40] <soap> it's broken by design
[21:07:57] <mgorny> if you want to have a new utmp format, i suppose we could go for changing path too but that's upstream work, not mine
[21:08:22] <mgorny> i'm all for declaring it unsupported
[21:08:22] <soap> the reason they havent changed utmp is because people want to use their 20 year old wtmp DBs
[21:08:27] <soap> since that is so valuable
[21:08:44] <mgorny> tho i think we should start by declaring it unsupported on new systems xD
[21:09:09] <robbat2> i've been around long enough that I experienced the x86 CHOST change of i[45]86-pc-linux-gnu -> i686-pc-linux-gnu; and I recall finding lots of apps that did bad hardcoding or other weird assumptions; 1. how much pain do we expect in Gentoo to identify these source-built packages; 2. how will running pre-built binaries behavior in this? [e.g. I used the Zoom binary client today to offer tech 
[21:09:15] <soap> fine with me, wait for the usual crowd of people to complain
[21:09:15] <robbat2> support to a relative]
[21:09:52] <ulm> robbat2: there's no x86 zoom client?
[21:10:06] <mgorny> robbat2: my random choice of packages found issues with two: ncurses and clang
[21:10:27] <mgorny> there might be more, we need more testing obvsly
[21:10:33] <dilfridge> first of all this affects only i[456]86 (x86), NOT amd64 (x86_64)
[21:10:38] <mgorny> for clang, i've got upstreamable patch that's basically waiting for gentoo to confirm
[21:10:52] <mgorny> for ncurses, they're doing really stupid stuff
[21:11:16] <dilfridge> basically bad stuff happens if you write your own automake
[21:11:27] <robbat2> ulm: there is a 32-bit zoom client specifically
[21:11:47] <ulm> robbat2: there used to be, but no longer
[21:11:50] <mgorny> in the end, some of the stuff already had to become more flexible for *-gnueabi and *-gnueabihf
[21:11:57] <soap> ncurses has a terrible upstream
[21:12:09] <robbat2> thanks; so I probably have to get that relative a newer laptop that isn't 32-bit
[21:12:36] <mgorny> also, i don't think prebuilt binaries care about CHOST much, unless you're asking the wider question of time64 transition
[21:12:41] --> sam__ (~sam@82.8.138.118) hat #gentoo-council betreten
[21:12:51] <sam__> hello, i can't get back to a desktop, here via irssi temporarily
[21:12:55] <sam__> i'll debug it post-meeting
[21:12:58] <dilfridge> ack
[21:12:59] <sam__> can someone tell me what robin's question was?
[21:13:03] <robbat2> some prebuilt binaries really did care about the chost
[21:13:04] <-> sam__ heißt jetzt Guest3800
[21:13:06] <robbat2> sam__: will repeat
[21:13:13] <robbat2> i've been around long enough that I experienced the x86 CHOST change of i[45]86-pc-linux-gnu -> i686-pc-linux-gnu; and I recall finding lots of apps that did bad hardcoding or other weird assumptions; 1. how much pain do we expect in Gentoo to identify these source-built packages; 2. how will running pre-built binaries behavior in this? [e.g. I used the Zoom binary client today to offer tech 
[21:13:19] <robbat2> support to a relative]
[21:13:48] <arthurzam> sam_: https://bpa.st/CBUA
[21:13:59] <mgorny> robbat2: but why do they even know CHOST?
[21:14:10] <mgorny> i mean, it's a build-time property
[21:14:13] <Arsen> and how?  do they run gcc -dumpmachine or something?
[21:14:22] <Guest3800> for 2., I'm not worried about it at all, because they'll be busted in >=2038, they'll also be busted with large inodes often (i.e. we're not worried about keeping legacy apps working, but mgorny's plan does mean we will keep 32-bit libc around AFAIK for easy testing and so on)
[21:14:27] <-> Guest3800 heißt jetzt sam_crashed
[21:14:42] <sam_crashed> like, the whole thing here is "yes, we have to break ABI, so we accept prebuilt stuff won't work"
[21:14:56] <sam_crashed> it's only for 32-bit systems which have a timebomb anyway
[21:15:01] <sam_crashed> for 1., it's a harder problem
[21:15:08] <sam_crashed> we already had ncurses' configure script break because it handrolls the logic
[21:15:09] <dilfridge> as long as some application only uses libc and no other libraries, it will still work 
[21:15:30] <dilfridge> otherwise expect tons of breakage
[21:15:31] <robbat2> mgorny: it was a long time ago that I recall this from; sorry I don't recall the details of how
[21:15:53] <mgorny> dilfridge: work until 2038, then everything will fall apart
[21:16:00] <dilfridge> exactly
[21:16:04] <mgorny> unless you faketime hard
[21:16:16] <ulm> also, we'd still keep some time32 profiles I suppose?
[21:16:22] <mgorny> also faketime is broken on modern glibc, there still haven't been a reply to my bug
[21:16:29] <robbat2> should we even do this work, or just declare end of x86 support entirely in 2028 or something/
[21:16:39] <sam_crashed> yes, we should, because it affects e.g. arm as well
[21:16:42] <dilfridge> ulm: yes, keep a minimal set
[21:16:47] <sam_crashed> also because we already did the hard bit in a sense
[21:16:54] <sam_crashed> (the planning for the transition is the worst of it)
[21:16:57] <dilfridge> it affects all 32bit arches except riscv32
[21:17:13] <sam_crashed> i also think we're sort of the last bastion for these things 
[21:17:19] <dilfridge> this
[21:17:24] <sam_crashed> if we won't do it, nobody will, and it's kind of sad to let it all rot for something where it's actually completely doable
[21:17:38] <sam_crashed> is it hard, yes, but it's not intractable
[21:17:56] <sam_crashed> (but it's a fair question)
[21:18:06] <sam_crashed> we also have people hitting it **now**
[21:18:12] <sam_crashed> so to not do it would essentially mean we're going to drop 32-bit support far sooner
[21:18:24] <sam_crashed> we have python testsuites failing all the time on this because people are e.g. trying to test THEIR y2038 compat (lol)
[21:18:37] <sam_crashed> but there's sometimes more insidious less trivial cases
[21:19:01] <sam_crashed> the ino_t thing actually bites pretty hard as well, because of how various filesystems handle inode recycling 
[21:19:08] <sam_crashed> dilfridge has hit this a lot in releng i think 
[21:19:17] <dilfridge> yes
[21:19:30] <dilfridge> actually because of this we (everyone) carry a nonstandard glibc patchset
[21:19:31] <robbat2> thanks; so we have to do something much sooner :-(
[21:20:32] <dilfridge> ideally we get things migrated soon and keep a few profiles / stage builds for people who need full binary compatibility
[21:21:11] <sam_crashed> for x86 in particular we care about that, for others we probably won't (but open to discussion ofc)
[21:21:17] <dilfridge> yes
[21:21:29] <dilfridge> but once we have handled x86, the rest is boring busywork
[21:21:32] <sam_crashed> yeah
[21:22:00] <dilfridge> and for all the arm gadgets / embedded stuff it's probably useful too
[21:22:13] <dilfridge> dito mips if it exists
[21:22:32] <robbat2> mgorny: what actions do you think the council should take regarding this?
[21:23:00] <mgorny> no real actions today, i'm mostly looking whether we're on the same page wrt *t64 suffix
[21:23:10] <mgorny> so i could merge patches into clang without having to change them later
[21:23:16] <sam_crashed> (as it involves making representations/claims/etc to 3r dparties)
[21:23:21] <dilfridge> I came up with it, so as far as I'm concerned, go with it
[21:23:25] <mgorny> once we have more packages fixed, further testing will be easier
[21:24:38] <dilfridge> any other opinions / statements / questions / wishes?
[21:24:42] <robbat2> thanks to whomever produced the nice summary table on the wiki page; I think the best option from that is "New profiles, new chost"
[21:24:45] <dilfridge> (related to this topic)
[21:24:53] <ulm> so the plan for the triplet is to append t64 to the third field for time64, and keep the existing triplet for time32?
[21:25:01] <dilfridge> yes
[21:25:06] <ulm> k
[21:25:13] <sam_crashed> yes, quite proud of the wiki page
[21:25:35] <dilfridge> (more precisely, on global scale, "keep existing triplet for time32 in gentoo, and anything elsewhere blargh debian)
[21:25:42] <mgorny> ulm: fourth field, i think
[21:25:48] <mgorny> third is "linux"
[21:26:06] <dilfridge> i686-pc-linux-gnut64
[21:26:15] <ulm> why is it called triplet then :)
[21:26:19] <mgorny> don't ask me
[21:26:22] <dilfridge> tuple
[21:26:32] <dilfridge> triplet is without the vendor field
[21:26:32] <mgorny> also *-gnueabit64 and *-gnueabihft64
[21:26:38] <mgorny> for nice pronunciation
[21:26:43] <dilfridge> i686-linux-gnut64
[21:26:54] <sam_crashed> can't be worse than riscv
[21:26:57] <sam_crashed> are we all happy then?
[21:26:58] <dilfridge> ^ this is normalized by config.sub to i686-pc-linux-gnut64
[21:27:17] <sam_crashed> not to rush everyone but i'm sort of nervous of retreading everything given we've sort of been through it a _lot_ internally in toolchain and so on
[21:27:25] <sam_crashed> and i don't want to veer into some option we already discounted
[21:27:39] <dilfridge> yes, it's nice this finally converged somehow
[21:27:51] <dilfridge> so - last chance to object 
[21:27:52] <dilfridge> 10
[21:27:54] <dilfridge> 9
[21:27:55] <dilfridge> 8
[21:27:57] <dilfridge> 7
[21:27:59] <dilfridge> 6
[21:28:00] <dilfridge> 5
[21:28:02] <dilfridge> 4
[21:28:03] <dilfridge> 3
[21:28:04] <robbat2> ship it
[21:28:05] <mgorny> i suppose you're also fine with the plan not to change libdir, break ABI compat, and use libt32 for transition?
[21:28:26] <mgorny> tho ofc it needs more testing
[21:28:34] <sam_crashed> I would like us to, if possible, have a way to keep legacy binaries around for testing (even if we don't use it in the final scheme), but I'm not married to it, and we can talk about that separately
[21:28:43] <dilfridge> mgorny: I'm personally ambivalent, but since you've worked out the plan and it seems to work I'm willing to go with it
[21:28:47] <sam_crashed> yeah
[21:28:50] <robbat2> plz no libt32; the equivilent was mip's n32/n64 era, and it was painful
[21:29:10] <mgorny> robbat2: it's only temporary, and not used by sources
[21:29:12] <dilfridge> the libt32 is only for the duration of the rebuild
[21:29:20] <mgorny> you haven't looked at time64-prep, did you?
[21:29:24] <sam_crashed> tbh actually I sort of withdraw my "I would like to" above, as we can already cross for that
[21:29:43] <dilfridge> sam_crashed: also we can use a t32 stage
[21:29:44] <mgorny> sam_crashed: yeah, i'm afraid i can't see a good way to preserve full binary compat
[21:29:55] <mgorny> the best we can do is switch prebuilt stuff to bundle 32-bit libs
[21:29:59] <soap> you'd need to pull another LFS
[21:30:08] <dilfridge> no no no, not more horror
[21:30:12] <soap> zactly
[21:30:20] <sam_crashed> ok nvm
[21:30:27] <dilfridge> so ship it
[21:30:45] <sam_crashed> yes
[21:30:46] <mgorny> i mean, any attempt at multilib is blocked on ld.so being unable to distinguish binaries
[21:30:53] <sam_crashed> yeah, sorry, I forgot that
[21:30:58] <dilfridge> yes and fixing that is an insane amount of fiddling
[21:31:04] <dilfridge> which noone will be happy about
[21:31:10] <sam_crashed> yes
[21:31:11] <mgorny> it's kinda doable by injecting RUNPATH and so on but meh
[21:31:18] <sam_crashed> ignore me, I sort of forgot about the complexity with our discussion and what we tried
[21:31:20] <dilfridge> ok with that our short agenda is essentially over, so we come to
[21:31:20] <robbat2> time64-prep does have the same problem as the n32/n64 era - dynamically loaded libraries
[21:31:21] <sam_crashed> not worth it
[21:31:24] <dilfridge> 4) open floor
[21:31:26] <dilfridge> anyone?
[21:31:29] <arthurzam> yes
[21:31:33] <robbat2> yes to open floor
[21:31:37] <arthurzam> https://wiki.gentoo.org/wiki/Project:Council/Meeting_logs
[21:31:48] <arthurzam> dilfridge: missing 05 and 06 month
[21:31:58] <mgorny> robbat2: it's as good as it can get us, for the limited risk of time32/time64 mixing
[21:32:07] <dilfridge> ok
[21:32:09] <dilfridge> on it
[21:32:32] <arthurzam> (I remember you said you have time for that in October, so here I remind :)
[21:32:35] <dilfridge> heh
[21:32:37] <ulm> september missing too
[21:33:15] <ulm> soap: ^^
[21:33:26] <mgorny> (i'll merge the clang changes tomorrow, in case they break something)
[21:33:32] <sam_crashed> iirc soap did it all
[21:33:32] <soap> should be up?
[21:33:36] <sam_crashed> maybe need to update wiki
[21:33:39] <mgorny> and ideally there'll be in next 20.x snapshot
[21:33:40] <sam_crashed> but i remember the emails
[21:33:43] <soap> oh yes
[21:33:46] <soap> didnt update the wiki
[21:33:55] <sam_crashed> mgorny: i'll ack them once i fix kwin post-meeting as well
[21:34:09] <ulm> yeah, it's in the repo but not linked from the page
[21:35:36] <arthurzam> ok, done from me for open floor
[21:35:39] <arthurzam> robbat2?
[21:36:04] <robbat2> i want to report that i've had zero progress from SPI's treasurer in getting the updated paypal links created by them
[21:36:21] <dilfridge> ugh
[21:36:37] <robbat2> specifically; this would be paypal links to go on Gentoo's donate page, that ensure the donation is correctly credited to us in SPI's accounting
[21:36:45] <dilfridge> want me to pop up at the next board meeting too?
[21:36:55] <robbat2> i gave them a set of detailed instructions, and offered to do a 1:1 zoom session to show
[21:36:56] <sam_crashed> what's the current situation?
[21:37:01] <sam_crashed> like they go to SPI unmarked? 
[21:37:13] <sam_crashed> or we have to manually xfer from our paypal?
[21:37:18] <robbat2> our donate page still goes to our own account OR you can click through a few levels into their donation system
[21:37:40] <sam_crashed> ok so it could be worse but not good either
[21:37:47] <robbat2> the goal is that you should be able to donate directly from our page: https://www.gentoo.org/donate/
[21:37:54] <robbat2> fill that out, get paypal checkout, done
[21:38:22] <sam_crashed> dilfridge: i think this might be a good idea
[21:38:28] <sam_crashed> from watching the channel it looks like their ticket system loses stuff sometimes
[21:38:33] <sam_crashed> robbat2: thx
[21:38:44] <sam_crashed> (also arthurzam thx for logs earlier, forgive me being scatty, not easy with just text)
[21:39:16] <arthurzam> sam_: it's ok
[21:39:53] <robbat2> i'm going to raise this at their next monthly meeting as well
[21:39:56] <sam_crashed> thanks
[21:40:16] <robbat2> (it's tommorow)
[21:40:28] <robbat2> but I didn't want it to be a surprise to anybody here
[21:40:37] <dilfridge> robbat2: what time?
[21:40:46] <robbat2> 2024/10/14 20:00 UTC
[21:40:52] <dilfridge> ok
[21:41:13] <ulm> thanks, I'll try to be there too
[21:42:00] <robbat2> that's all for me
[21:42:20] <dilfridge> anyone else?
[21:43:13] <dilfridge> seems not
[21:43:15] <dilfridge> then 
[21:43:23] -*- dilfridge bangs the gavel, meeting closed