15:00:00 <bowlofeggs> #startmeeting FESCO (2018-07-23)
15:00:00 <zodbot> Meeting started Mon Jul 23 15:00:00 2018 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is bowlofeggs. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'fesco_(2018-07-23)'
15:00:00 <bowlofeggs> #meetingname fesco
15:00:00 <zodbot> The meeting name has been set to 'fesco'
15:00:00 <bowlofeggs> #chair nirik, maxamillion, jsmith, jwb, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:00:00 <zodbot> Current chairs: bowlofeggs contyk jsmith jwb maxamillion nirik sgallagh tyll zbyszek
15:00:00 <bowlofeggs> #topic init process
15:00:09 <maxamillion> .hello2
15:00:10 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:00:14 <zbyszek> .hello2
15:00:15 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:00:15 <sgallagh> .hello2
15:00:15 <sgallagh> I'm here for 30 minutes
15:00:18 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:00:19 <contyk> .hello psabata
15:00:21 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:33 <nirik> morning
15:00:50 <bowlofeggs> whoah weird - my IRC client is making it look like messages that you all are sending came from about 1.5 minutes ago
15:01:02 <bowlofeggs> but timestamps on my messages match my WM's clock
15:01:17 <bowlofeggs> super weird
15:01:29 <bowlofeggs> my WMs clock seems to match my phone's clock so i think it's doing NTP
15:01:38 <bowlofeggs> is freenode not doing NTP?
15:01:53 <zbyszek> I see correct timestamps
15:02:05 <sgallagh> bowlofeggs: https://www.youtube.com/watch?v=umj0gu5nEGs
15:02:35 <maxamillion> correct timestamps here as well
15:02:41 <contyk> here as well
15:03:17 <bowlofeggs> well we have quorum in any case
15:03:20 <bowlofeggs> let's start this party
15:03:28 <bowlofeggs> #topic #1922 Support for i686 on critical path packages
15:03:28 <bowlofeggs> .fesco 1922
15:03:31 <zodbot> bowlofeggs: Issue #1922: Support for i686 on critical path packages - fesco - Pagure - https://pagure.io/fesco/issue/1922
15:04:57 <bowlofeggs> so for this one we need to sort out more detail in our policy re 686 breaking?
15:05:08 <zbyszek> Hmm, I wonder if we need to do anything if the kernel-headers split is implemented
15:05:20 <bowlofeggs> jforbes, jcline: you might be interested in this topic
15:05:38 <jforbes> I am here
15:05:59 <sgallagh> Honestly, I think I'd just prefer to trust labbott, jforbes and jcline to make good choices and grant them carte blanche on this.
15:06:31 <nirik> having the split kernel-headers should reduce dependence on kernel itself on i686...
15:06:53 <bowlofeggs> sgallagh: yeah i could see an argument for that as a policy - not unlike trusting other SIGs
15:06:54 <jforbes> Right, so we don't intend to disable the arch until kernel-headers is split out, that spec should be posted for review today
15:07:25 <zbyszek> Do you intend to disable it once that's done?
15:08:20 <bowlofeggs> <crickets>
15:08:31 <jforbes> Well, we don't intend to, but if there is a build issue, we would
15:08:44 <bowlofeggs> jforbes: do you think the split headers package will solve the issue at hand?
15:08:53 <jforbes> Note, build issues are extremely rare
15:09:20 * nirik notes if there's no i686 kernel, that also means no i686 deliverables/images.
15:09:32 <bunny__> I'm here, but just watching
15:09:34 <jforbes> bowlofeggs: it would solve it for the majority of userspace packages, there are still a couple which depend on the kernel itself, though very few
15:10:20 <maxamillion> I'd rather just end i686 all together ...
15:10:27 <bowlofeggs> so i can think of two proposals: 0) sgallagh's above re letting kernel SIG make their own decisions, 1) see how the split package goes
15:10:33 <maxamillion> but that's not really the discussion here
15:10:35 <bowlofeggs> or i guess maxamillion's :)
15:10:43 <contyk> maxamillion: ha, +1 ;)
15:10:43 <jforbes> nirik: sure, the idea is that the SIG fixes the build issue and it gets re-enabled.  Until such time that the SIG doesn't care enough or isn't functional enough to do so. At which point, FESCo would need to re-evaluate their status
15:11:21 <zbyszek> jforbes: that's problematic, because doing a kernel build with an arch disabled cascased into multiple other packages
15:11:24 <bowlofeggs> do we believe that the x86 SIG acted reasonably in this case?
15:11:32 <nirik> jforbes: completely fair.
15:11:33 <sgallagh> Yeah, I think over time, we asymptotically approach maxamillion's proposal :-|
15:11:43 <jforbes> zbyszek: That's why we are breaking out kernel-header
15:12:17 <jforbes> bowlofeggs: no, but perhaps this issue lit a fire and they will next time
15:12:24 <zbyszek> jforbes: what packages depend on the kernel even with kernel-headers split out?
15:12:40 <bowlofeggs> jforbes: is this "strike 1" for that sig, or have their been other problems?
15:12:42 <jforbes> zbyszek: I think a couple of virt packages
15:13:09 <bowlofeggs> (sorry for the american baseball reference - in baseball 3 strikes means you are out [your turn at bat is over])
15:13:14 <sgallagh> bowlofeggs: This is the first time it's made it up to FESCo, so I'd call that "strike 1"
15:13:48 <jforbes> bowlofeggs: well, they haven't done much, but this has been the first real issue that was "critical"  The fact that F28 shipped not booting on targeted hardware (P III) and no one noticed until after it shipped seems a fail
15:14:18 <zbyszek> So... considering that a) disabling an arch breaks at least some packages, b) the only thing that is needed is a successful build, and the kernel doesn't even need to boot, I think disabling an arch should be done lightly, i.e. without at least some delay for the arch SIG to react
15:14:35 <zbyszek> *not be done
15:14:58 <jforbes> zbyszek: That can create a problem, particularly during the merge window in being able to track down other issues impacting users.
15:15:35 <bowlofeggs> proposal: let's see how the split kernel-headers package does and let's notify the x86 SIG that they are at risk of losing i686 if more events like this occur
15:15:35 <nirik> there may be a difference here between rawhide and stable releases too...
15:16:33 <jforbes> We build daily, those virt packages don't even build weekly, so if the SIG acts in some reasonable manner, the odds are good that dependent packages wouldn't even notice.  Now, with missing headers, this wasn't the case
15:16:45 <nirik> bowlofeggs: sure, +1
15:17:00 <jforbes> nirik: Yes, this is pretty much entirely around rawhide.
15:17:07 <zbyszek> bowlofeggs: ok, +1
15:17:22 <contyk> bowlofeggs: +1
15:17:56 <bowlofeggs> jforbes: your feedback on the proposal is of course welcome too :)
15:18:11 <jforbes> A patch that introduced a build regression in stable releases would be much easier to track down if it even made it.
15:18:17 <jforbes> bowlofeggs: +1
15:18:31 <bowlofeggs> sgallagh, maxamillion: ?
15:20:34 <bowlofeggs> hmm looks like we lost both of them just now
15:20:42 <bowlofeggs> that was a ping timeout, not a net split?
15:20:47 <bowlofeggs> we no longer have quorum
15:21:17 <contyk> :(
15:21:33 <bowlofeggs> i will wait for a few minutes to see if either of them comes back. sgallah did say he could only do 30 min today
15:21:38 <contyk> seems people are back
15:21:58 <bowlofeggs> weird, i don't see messages about them rejoining in my client
15:22:09 <bowlofeggs> maxamillion, sgallah: ?
15:22:41 <contyk> well, not the two, but some of the people who also dropped
15:22:41 <bowlofeggs> is freenode broken? maybe it's related to the weird timestamps i was seeing…
15:22:44 <bowlofeggs> ah
15:23:00 <bowlofeggs> maxamillion: you are back!
15:23:08 <maxamillion> split?
15:23:22 <bowlofeggs> maxamillion: the current proposal: let's see how the split kernel-headers package does and let's notify the x86 SIG that they are at risk of losing i686 if more events like this occur
15:23:32 <bowlofeggs> we are at +4
15:23:53 <maxamillion> +1
15:24:09 <bowlofeggs> #agreed let's see how the split kernel-headers package does and let's notify the x86 SIG that they are at risk of losing i686 if more events like this occur (+5, 0, -0)
15:24:14 <contyk> \o/
15:24:19 <bowlofeggs> alright, next topic. thanks for coming jforbes!
15:24:29 <jforbes> Thanks
15:24:29 <bowlofeggs> #topic #1942 F29 System Wide Change: Remove Excessive Linking
15:24:29 <bowlofeggs> .fesco 1942
15:24:30 <zodbot> bowlofeggs: Issue #1942: F29 System Wide Change: Remove Excessive Linking - fesco - Pagure - https://pagure.io/fesco/issue/1942
15:25:05 <zbyszek> proposal: accept for F30
15:25:06 <bowlofeggs> ignatenkobrain: ^
15:25:06 <contyk> the thing that worries me about this one is all the autogenerated dependencies we're going to lose
15:25:21 <contyk> yet we still need them in practice, so maintainers will have to add them manually
15:25:31 <contyk> unless I'm misunderstanding the whole thing
15:25:56 <zbyszek> contyk: can you explain? I would think that if A needs B, and B needs C, then A.rpm will need B.rpm which will need C.rpm
15:26:17 <ignatenkobrain> hello
15:26:20 <ignatenkobrain> I'm here
15:26:55 <bowlofeggs> i can't remember the various IRC nicks that ngompa uses - if someone knows which he's using right now please ping him :)
15:26:56 <contyk> is that the only case that's going to be affected?
15:27:12 <maxamillion> alright, sorry .. was fighting with NickServ
15:27:16 <ignatenkobrain> contyk: no, we are not going to loose anything *necessary**
15:27:52 * zbyszek thinks it's one of those cases where we have to try and see
15:28:11 <ignatenkobrain> so imagine that you want to use gtk+-3.0, but you are using just one function from there (e.g. gtk_init), the pkg-config --libs gtk+-3.0 will link your binary against gtk, gd, gdk_pixbuf and a lot of other stuff which you don't need
15:28:53 <nirik> so what other distros have already done this?
15:28:59 <ignatenkobrain_> they have done it
15:29:13 <ignatenkobrain_> opensuse, mageia, ubuntu use it for years
15:29:16 <ignatenkobrain_> not sure for ubuntu though
15:29:32 <bowlofeggs> if i'm summarizing this correctly in my mind, it sounds like all the examples of this breaking things have been defended against in the ticket, so i see no reason not to try it for f30
15:30:13 <contyk> what issues did they face when they started using it?
15:30:14 <ignatenkobrain_> the real case, /usr/bin/rpm is linked against libbz2, libzstd, liblua and such stuff, but it doesn't use any of those, it's librpm.so who should be (and is) linked against those libs
15:30:57 <ignatenkobrain_> contyk: well, some of the badly written software started to fail. e.g. if you forget to add -lm somewhere and your dependency drops that, you will get undefined error
15:31:03 <ignatenkobrain_> but most of the stuff should be fine nowadays
15:31:24 <contyk> I see
15:31:35 <zbyszek> contyk: meson uses --as-needed by default, so it's getting common upstream too
15:31:40 <nirik> is there a way we could try adding this and do a test rebuild and see how much more breaks?
15:31:55 <ignatenkobrain_> nirik: the problem is that you would need to do not scratch rebuild
15:31:57 <zbyszek> in the sense that many projects will turn it on anyway
15:32:02 <bowlofeggs> i'm +1 to accepting for F30, which i think brings the count to +3 (including sgallah's in-ticket vote)
15:32:08 <ignatenkobrain_> nirik: because this way you wouldn't detect errors
15:32:11 <nirik> ignatenkobrain_: yeah, would need copr or something like it.
15:32:21 <ignatenkobrain_> nirik: rebuilding whole distro in COPR will take... year?
15:32:22 <ignatenkobrain_> ;)
15:32:27 <nirik> yeah, a while.
15:32:34 <ignatenkobrain_> I was building redhat-rpm-config recently and it took 40 hours :D
15:32:47 <bowlofeggs> i assume a build wouldn't highlight breakage in itself - you would need to run the programs too
15:34:07 <contyk> well, issues can always be reported and fixed
15:34:13 <bowlofeggs> gentoo has a script called revdep-rebuild that scans libs/executables for broken linking and can rebuild - we might be able to adapt that to test the rebuilt packages
15:34:21 <ignatenkobrain_> bowlofeggs: that's also true, usually people use -Wl,--no-undefined to make sure all stuff is defined
15:34:31 <ignatenkobrain_> this is something what I want to propose for F31 or smth like that ;)
15:34:41 <bowlofeggs> yeah that sounds useful too
15:35:01 <nirik> anything that dlopens could well break here right?
15:35:48 <contyk> yes
15:36:01 <contyk> but that's probably going to be a minority of cases
15:37:41 <bowlofeggs> contyk, nirik, maxamillion: care to vote on the proposal or counter-propose?
15:37:49 <bowlofeggs> (or more discussion needed?)
15:37:57 <contyk> bowlofeggs: can you re-state the proposal?
15:38:12 <nirik> I'm prety leary of this given the tools folks reluctance...
15:38:13 <bowlofeggs> proposal: approve for F30, after F29 branches
15:38:34 <contyk> +1
15:38:48 <bowlofeggs> nirik: so you are -1?
15:38:56 <ignatenkobrain_> we can always revert if something goes wrong
15:39:09 <bowlofeggs> nirik: is jakub the "tools folks"?
15:39:44 <bowlofeggs> jakub didn't reply to zbyszek's question about whether there were other examples of breakage
15:40:00 <nirik> well, he's the main gcc maintainer...
15:40:03 <bowlofeggs> ah
15:40:16 <nirik> I guess I'm a 0 now, lets let it pass and see how it does. ;)
15:40:35 <bowlofeggs> we could postpone voting and see if we can get him to come to a future fesco meeting to discuss with us
15:41:11 <bowlofeggs> i think i'd like him to answer zbyszek's question given that he's "tool folks"
15:41:20 <nirik> whats the vote at?
15:41:20 <maxamillion> I'm -1 until the gcc maintainer gives a +1
15:41:21 <bowlofeggs> i didn't realize that he was an expert
15:41:33 <bowlofeggs> nirik: i think +3 and -1, not counting you
15:41:56 <nirik> I also just found the gentoo and magea pages on this.
15:42:08 <bowlofeggs> i think i wouldn't mind getting more info from jakub about this either
15:42:33 * bowlofeggs runs gentoo but doesn't mess with the flags very much
15:43:07 <nirik> can't seem to find a suse one
15:43:17 <bowlofeggs> proposal: defer this ticket until a future fesco meeting when jakub can attend to discuss with us
15:43:27 <maxamillion> +1
15:43:35 <nirik> so yeah, more time would be helpfull to me.
15:43:57 * nirik is sorry he didn't dig more on this before meeting. My fault for not being prepared.
15:44:21 <bowlofeggs> it's alright, i didn't realize i should have weighed @jakub's feedback more heavily either :)
15:44:36 <zbyszek> +1 to deferring
15:44:49 <bowlofeggs> and yeah, it'd be good to have solid info about which other distros do this, or what they've documented about it
15:45:18 <bowlofeggs> counting nirik as a +1 we are at +4. contyk?
15:45:22 <nirik> opensuse has since 11.2 apparently, but I can't find much more info from them than that
15:45:39 <ignatenkobrain_> nirik: that's like RHEL5?
15:45:39 <contyk> bowlofeggs: ok, let's defer
15:45:53 <nirik> ignatenkobrain_: a while back for sure.
15:46:21 <bowlofeggs> #agreed defer this ticket until a future fesco meeting when jakub can attend to discuss with us (+5, 0, -0)
15:46:25 <bowlofeggs> ok, last issue
15:46:33 <bowlofeggs> #topic #1951 gcc/g++ and python related build failures in F29 mass rebuild
15:46:33 <bowlofeggs> .fesco 1951
15:46:36 <zodbot> bowlofeggs: Issue #1951: gcc/g++ and python related build failures in F29 mass rebuild - fesco - Pagure - https://pagure.io/fesco/issue/1951
15:46:56 <bowlofeggs> ignatenkobrain_, pviktori: ^
15:47:06 <ignatenkobrain_> so as I mentioned in the ticket, I've linked most of the gcc/gcc-c++ related issues to the tracker bug
15:47:10 <ignatenkobrain_> and going to autofix them
15:47:13 <ignatenkobrain_> https://bugzilla.redhat.com/show_bug.cgi?id=1551327
15:47:52 <mhroncok> hi
15:47:56 <bowlofeggs> greetings!
15:48:05 <bowlofeggs> ignatenkobrain_: cool yeah autofixing them sounds good to me
15:48:17 <ignatenkobrain_> that's 797 bugs
15:48:25 <ignatenkobrain_> and around 50-100 of them are closed
15:48:25 <nirik> that would be lovely. note that some may already be fixed?
15:48:30 <nirik> yeah
15:48:32 <bowlofeggs> ignatenkobrain_: maybe you will get a badge for "most fixed bugs 2018"
15:48:41 <ignatenkobrain_> bowlofeggs: hehe
15:48:45 <zbyszek> Yeah, I think the situation is pretty clear now, so we can close the fesco ticket
15:49:19 <bowlofeggs> ah ok - so nothing for us to discuss?
15:49:30 <bowlofeggs> everybody's happy with the situation?
15:49:36 * ignatenkobrain_ is also going to create grep-ftbfs tool into tibbs' random fedora tools repo ;)
15:50:04 <contyk> happy!
15:50:37 <nirik> is there also mass change plans for %{python_site* ? or let those just get fixed by maintainers?
15:50:37 <bowlofeggs> i'll give 2 more minutes for objections to just closing this ticket
15:51:04 <bowlofeggs> nirik: i think the suggestion in ticket is to just let them FTBFS
15:51:11 <bowlofeggs> and let that process do what it does
15:51:15 <mhroncok> nirik: I've posted an answer to that into the ticket
15:51:25 <ignatenkobrain_> I'm also going to backport zbyszek' PR for RPM into fedora
15:51:45 <ignatenkobrain_> https://github.com/rpm-software-management/rpm/pull/469
15:51:47 <ignatenkobrain_> this one
15:51:50 <mhroncok> ignatenkobrain_: thanks. yet the fdamage is already done
15:52:05 <nirik> ah yeah, thanks.
15:53:08 <bowlofeggs> ok let's just say this is solved
15:53:20 <bowlofeggs> #action bowlofeggs will close this ticket because it is resolved
15:53:34 <bowlofeggs> #topic Next week's chair
15:53:44 <bowlofeggs> who's up for some fun?
15:53:51 <contyk> I haven't done it yet
15:53:53 * zbyszek might miss next weeks meeting because of travel
15:54:06 <bowlofeggs> contyk: excellent, tag, you're it!
15:54:18 <bowlofeggs> contyk: https://fedoraproject.org/wiki/FESCo_meeting_process is docs on what to do
15:54:24 <contyk> thanks
15:54:25 <bowlofeggs> #action contyk will chair next week's meeting
15:54:31 <bowlofeggs> #topic Open floor
15:55:58 <nirik> I'd like fesco members to ponder our python2 endgame and chime in on the thread on devel.
15:56:35 <ignatenkobrain_> nirik: zbyszek: what would be the easiest way to close ftbfs tickets?
15:56:37 * bowlofeggs is waaaaay behind on reading devel list due to long PTO :)
15:56:47 <ignatenkobrain_> is there some script which checks if package was rebuilt → close ticket?
15:57:11 <zbyszek> ignatenkobrain_: yes, I have a script for that
15:57:12 <nirik> I don't have one off hand I'm afraid... releng might have something in their repo?
15:57:18 <nirik> ah cool.
15:57:29 <zbyszek> I used it for the ftbfs process before the mass rebuild
15:57:33 <ignatenkobrain_> zbyszek: mind sharing? I would like to close all fixed bugs before autofixing them
15:57:38 <ignatenkobrain_> so that I don't double-fix packages
15:58:01 <zbyszek> ignatenkobrain_: https://pagure.io/ftbfs/blob/master/f/ftbfs.py
15:58:21 <zbyszek> I might need to add some docs ;)
15:58:38 <bowlofeggs> what happens if the ftbfs.py script fails to build from source itself?
15:58:41 <bowlofeggs> (lol)
15:58:57 <zbyszek> bowlofeggs: it's not packaged, so that's just fine
15:59:04 <bowlofeggs> hehe
15:59:37 <zbyszek> ignatenkobrain_: I'll push a readme to that repo later today, ping me if anything is unclear
15:59:53 <bowlofeggs> cool. anything else? closing in 3 min if not.
16:02:53 <bowlofeggs> #endmeeting