[21:03]  * Pici looks around
[21:03] <topyli> irc council meeting?
[21:03] <topyli> are we here? Pici nhandler jussi01 tsimpson ?
[21:04] <Pici> I suppose
[21:04] <topyli> hi
[21:04] <Pici> I'm not sure if Jussi is going to make it
[21:04] <topyli> i know he's busy, been popping up on irc from time to time
[21:05] <ts2> mostly
[21:05] <topyli> hi ts2
[21:06] <ts2> I wont be too active, as it takes forever to type ;)
[21:07] <topyli> you can say "yeah!" and "no!" and vote :)
[21:07] <ts2> yeah!
[21:07] <topyli> :)
[21:07] <Pici> woo
[21:08] <topyli> i can chair if nobody feels ambitious, but i'll probably only do the chores some time tomorrow
[21:08] <Pici> Fine with me
[21:09] <topyli> okay
[21:09] <topyli> #startmeeting
[21:09] <MootBot> Meeting started at 15:09. The chair is topyli.
[21:09] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:09] <topyli> [TOPIC] Review the Mentoring  page for approval/rejection
[21:09] <MootBot> New Topic:  Review the Mentoring  page for approval/rejection
[21:10] <topyli> i had a look today and fixed a couple of typos. what's the "conclusion" section supposed to contain?
[21:10] <topyli> [LINK] https://wiki.ubuntu.com/IRC/Mentoring
[21:10] <MootBot> LINK received:  https://wiki.ubuntu.com/IRC/Mentoring
[21:10] <ts2> I'm not too sure, i dont think we need it
[21:10] <Pici> I'm not sure, do we even need it?
[21:11] <topyli> i'll be happy enough without it
[21:11] <ts2> it was just there from the first template
[21:11] <Pici> I don't think the page needs any further explanation, its pretty clear without anything else.
[21:12] <ts2> we have used it, and linked to it already
[21:12] <topyli> otherwise, i'm ok if we just bless it, and we can of course modify if needed
[21:12] <topyli> editing out the empty section first of course :)
[21:13] <ts2> if someone wants to action editing it, and then we can approve on merit
[21:14] <topyli> i can edit it
[21:14] <Pici> edited.
[21:14] <topyli> so we vote?
[21:14] <ts2> yeah! ;)
[21:15] <Pici> Sure!
[21:15] <topyli> [VOTE] approve the mentoring page
[21:15] <MootBot> Please vote on:  approve the mentoring page.
[21:15] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[21:15] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[21:15] <Pici> +1
[21:15] <MootBot> +1 received from Pici. 1 for, 0 against. 0 have abstained. Count is now 1
[21:15] <topyli> +1
[21:15] <MootBot> +1 received from topyli. 2 for, 0 against. 0 have abstained. Count is now 2
[21:15] <ts2> +1
[21:15] <MootBot> +1 received from ts2. 3 for, 0 against. 0 have abstained. Count is now 3
[21:15] <topyli> #endvote
[21:15] <topyli> uh
[21:15] <topyli> [ENDVOTE]
[21:15] <MootBot> Final result is 3 for, 0 against. 0 abstained. Total: 3
[21:16] <topyli> Pici: can you edit again, remove the draft label?
[21:16] <Pici> topyli: doing so now.
[21:16] <ts2> Pici: and uncomment the category
[21:16] <topyli> thanks. that's that
[21:17] <topyli> [TOPIC] Burnout strategy for operators
[21:17] <MootBot> New Topic:  Burnout strategy for operators
[21:17] <topyli> this is jussi's item
[21:17] <ts2> this is something we'll find difficult to make policy for
[21:17] <topyli> i agree with that on priciple, but i don't know how to suggest vacations for ops
[21:18] <topyli> i know how to say "you need a time out" but i don't know how to make it official
[21:19] <ts2> well, we can force the "time out", but I'd really hate to do that
[21:19] <Pici> I'd like to think our ops are understanding enough to take the time off when we suggest it to them
[21:19]  * st33med gets out the dunce cap
[21:19] <st33med> Time out!
[21:20] <ts2> we need to create a culture where we trust each other to tell usually when we appear tense
[21:20] <topyli> we could have something on the operator guidelines about monitoring your fellow ops' stress levels
[21:20] <topyli> exactly
[21:22] <Pici> hmm
[21:22] <ts2> it should be a self-enforced thing, where the council would only get involved when extream situations zrise
[21:22] <ts2> *arise
[21:23] <Pici> I'm not so sure about that.  I think that any operator should be free to come to any ircc member with a report if they don't feel comfortable for some reason telling another op about it.
[21:23] <Pici> Stress can make people less receptive to critisim.
[21:23] <ts2> true
[21:24] <ts2> we can always act as a proxy for such things
[21:25] <ts2> it is, after all, our responsibility to maintain the ops team
[21:25] <topyli> but i don't want a policy where we encourage ops to come to the council for everyday troubles. if we write down a standard path like that, people will take it instead of actioning themselves
[21:26] <ts2> i think part of the issue is that -ops is public
[21:26] <ts2> we (ops) cant have a "quite word" easily
[21:26] <Pici> Then we should encourage private messaging these sort of things then.
[21:26] <ts2> -e
[21:27] <topyli> indeed those discussions are better off channel
[21:27] <jussi01> o/
[21:27] <jussi01> sorry Im late
[21:27] <Pici> Hey Jussi
[21:29] <jussi01> one idea I had on this, which may actually be a dud, but still worth thinking about is some sort of "timeout" ever 6/12months.
[21:30] <ts2> because it's such an individual thing, that may be difficult
[21:30] <jussi01> even if you dont think you need it/ dont need it, it still isnt such a bad thing
[21:31]  * Pici hmms
[21:31] <topyli> on the other hand, our real jobs have mandatory vacations you *have* to take, because otherwise some people would never take one and just die at office
[21:31] <jussi01> exactly the concept Im thinking of
[21:31] <Pici> My job doesn't have that.
[21:32] <topyli> oh. it's the law here
[21:32] <Pici> I think we should encourage people to take time off from IRC, but I'm against forcing it.
[21:32] <ts2> personally i think we need a culture change rather thanalysis pure polucy
[21:32] <Pici> ts2: agreed
[21:33] <jussi01> how are you envisioning changing the culture?
[21:33] <ts2> silly auto compleation
[21:34] <jussi01> I dont think it should be pure policy, but I do think policy should be part of it
[21:34] <ts2> jussi01: there is no easy way, but it's the way i think it _should_ be
[21:34] <Pici> Education is a good way to alert people of burnout
[21:34] <jussi01> perhaps it could be a non enforced, but scheduled thing. If we schedule the holidays, and say, that while you dont have to take it, we encourage you too.
[21:34] <ts2> we need some policy to inforce it if absolutely needed
[21:35] <ts2> but pure policy will not work
[21:35] <jussi01> and actually do it ouselves also.
[21:36] <topyli> how about "please take a time out sometimes" in the guidelines, with an addititional "the ircc may enforce a timeout" or something along those lines?
[21:36] <ts2> it'll be difficult to arrange holidays for ops and keep time-zones filled
[21:36] <ts2> at a minimum, a lot more admin
[21:37] <Pici> How do you suppose that we would enforce a timeout? Remove operator privleges? Bans?
[21:37] <Pici> I don't like the sound of it myself.
[21:37] <topyli> jussi01: we have a limited term anyway, ops are theoretically forever
[21:37] <ts2> time out schould be encouraged, right now i think theres a bit of a tabu about it
[21:38] <ts2> which is why i talk about culture
[21:38] <jussi01> ts2: exactly, hence my suggestion of scheduling them, making them somewhat "official"
[21:38] <jussi01> which can be easily managed with a script that interfaces with LP.
[21:39] <Pici> I don't think we need a technical solution for this.
[21:39] <ts2> not sure if a script should be used
[21:40] <ts2> it should be 90% culture, backed up with 10% policy
[21:40] <jussi01> perhaps having a simple sign up sheet, where people can advise that they will not be around?
[21:41] <jussi01> and encouraging people to take holidays, along with some burnout education?
[21:41] <ts2> sure, we need some notification system
[21:41] <jussi01> Perhaps the burnout education can be included in the ops hours we have been talking about?
[21:41] <Pici> Replace the sign out sheet with a calenar, where people can mark when they're taking time off.
[21:41] <Pici> *calendar
[21:42] <jussi01> we did have something like that planned for the bt2
[21:42] <jussi01> Pici: +1
[21:42] <Pici> We did?
[21:42] <jussi01> Pici: kinda, I suggested it - think its on the gobby doc
[21:43] <jussi01> so for now, perhaps just a shared google calendar?
[21:43] <Pici> I think thats a good first step.  It'll be useful anyway to know when people are taking extended time off.
[21:44] <jussi01> how long are we suggesting people take off=
[21:44] <jussi01> ?
[21:44] <ts2> maybe just giving people the opitunity to msrk their time off will be a catalist
[21:44] <Pici> ts2: I agree
[21:45] <ts2> i think at least 2 weeks in the year, but its individual
[21:45] <jussi01> so, an amendment to the op guidelines and a shared calender then.
[21:46] <topyli> a message on the ML too, to advertise
[21:46] <jussi01> shall we have a vote on it?
[21:46] <Pici> Whats the amendment going to say?  Just encourage time off to fend off burnout?
[21:47] <ts2> people dont realise how critical time off is for our ops
[21:47] <jussi01> Pici: with an encouragement to take at least 2 weeks
[21:47] <Pici> jussi01: okay, as long as we're not forcing it.
[21:47] <topyli> it should also encourage ops to try and recognize burnout signs in others and to talk to them
[21:48] <jussi01> es
[21:48] <jussi01> topyli: +1
[21:48] <Pici> sounds good to me.
[21:48] <topyli> we can work on the wording later
[21:48] <ts2> i think if we talk to eachother more about it, it wll become less of an issue
[21:48] <jussi01> agreed
[21:49] <topyli> ok, let me figure out something votable :)
[21:50] <topyli> [VOTE] amend operator guidelines to encourage sufficient time off, and create a calendar system for ops to mark time off
[21:50] <MootBot> Please vote on:  amend operator guidelines to encourage sufficient time off, and create a calendar system for ops to mark time off.
[21:50] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[21:50] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[21:50] <jussi01> +1
[21:50] <MootBot> +1 received from jussi01. 1 for, 0 against. 0 have abstained. Count is now 1
[21:50] <topyli> +1
[21:50] <MootBot> +1 received from topyli. 2 for, 0 against. 0 have abstained. Count is now 2
[21:51] <Pici> +1
[21:51] <MootBot> +1 received from Pici. 3 for, 0 against. 0 have abstained. Count is now 3
[21:51] <ts2> +1
[21:51] <MootBot> +1 received from ts2. 4 for, 0 against. 0 have abstained. Count is now 4
[21:51] <topyli> [ENDVOTE]
[21:51] <MootBot> Final result is 4 for, 0 against. 0 abstained. Total: 4
[21:51] <topyli> [ACTION] council to work on guidelines amendment
[21:52] <MootBot> ACTION received:  council to work on guidelines amendment
[21:52] <topyli> that's not a real action is it :\
[21:52] <jussi01> not really :P
[21:53] <topyli> let's admit it's not actionable yet :)
[21:53] <topyli> anything else?
[21:53] <jussi01> topyli: you can action someone to get the calendar done.
[21:53] <jussi01> but not me, as I always screw gcal up
[21:54] <jussi01> Ill work on the amendment
[21:54] <Pici> I wouldn't mind putting together the email once we have the other two things done.
[21:54] <topyli> hrm. we can't use the ircc calendar
[21:55] <topyli> i'll create a new one, let's figure out how we get it shared with all the right people
[21:55] <ts2> if only lp had a calendar ;)
[21:55] <topyli> [ACTION] jussi01 to draft ops guidelines amendment
[21:55] <MootBot> ACTION received:  jussi01 to draft ops guidelines amendment
[21:56] <topyli> [ACTION] topyli to create vacation calendar for the ops team
[21:56] <MootBot> ACTION received:  topyli to create vacation calendar for the ops team
[21:56] <Pici> I suppose we could use LP to send out an email to our operator teams... or we should have a separate operator mailing list.
[21:56] <jussi01> I think it has to be limited to ops in the core chans, otherwise it gets too big, no?
[21:57] <Pici> Right
[21:58] <ts2> it's always a good idea for all ops, but core ops are usually under more presur
[21:58] <jussi01> ok, so any new bugs? any stadard items we need to follow up on?
[21:58] <topyli> no new bugs
[21:58] <Pici> I think that was a productive meeting.
[21:58] <topyli> we could encourage other teams to create similar systems
[21:59]  * ts2 closed the guadex(?) bue earlier
[21:59] <topyli> for their ops
[21:59] <topyli> ts2: oh yea, so we have 50% less bugs!
[21:59] <topyli> Pici: indeed
[21:59] <ts2> yeah!
[21:59] <ts2> :)
[21:59] <topyli> hehe
[21:59] <topyli> #endmeeting
[21:59] <MootBot> Meeting finished at 15:59.
[21:59] <jussi01> excellent!
[22:00] <jussi01> good meeting, sorry I missed some
[22:00] <jussi01> laters
[22:00] <topyli> i'll do the standard chores tomorrow, it's late
[22:00] <ts2> Mr. Burns returns
[22:00] <Pici> excellent
[22:01] <topyli> thanks guys :)
[22:01] <ts2>  please don't make me type anymore :)


[02:14] <randall> Hi, Debian ansible maintainer here. I'm looking for the git repo that contains Ubuntu's packaging of ansible. Can someone point me to the right URI?
[02:20] <jbicha> randall: Ubuntu's ansible packaging generally is synced directly from Debian. https://launchpad.net/ubuntu/+source/ansible What are you looking for?
[02:32] <randall> jbicha: There's one version in bionic that I'd like to see: https://changelogs.ubuntu.com/changelogs/pool/universe/a/ansible/ansible_2.5.1+dfsg-1ubuntu0.1/changelog
[02:33] <randall> I guess one way is to just download and unpack the source package but that would loose any comments there might be in git.
[02:38] <jbicha> randall: there is https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/ansible/+git/ansible/+ref/applied/ubuntu/bionic-updates
[02:38] <jbicha> I don't think the original uploader actually used git for that upload but it's a git representation of what was done. No actual comments though
[02:40] <jbicha> here's all the other branches: https://code.launchpad.net/ubuntu/+source/ansible
[02:42] <randall> jbicha: That's something. Interesting, they used gbp pq for patch management. Thanks!
[02:43] <randall> I'm backporting some security fixes for Debian LTS, and noticed some things are already patched in Ubuntu. This will help me save time on a patch or two. Thanks a bunch!
[02:44] <jbicha> I think that's just an automated import
[10:49] <paride> Hi! It seems to me that britney didn't run or finish running in the last days and (as a conseguence?) the autopkgtest triggers are stuck
[10:49] <paride> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says:
[10:49] <paride> Generated: 2021.11.27 18:16:12 +0000
[10:51] <paride> and many "Test in progress" tests are neither running nor enqueued, take for example ganeti (under qemu): it's not running and not in the queue (according to https://autopkgtest.ubuntu.com/running)
[10:51] <paride> and has not recent test runs: https://autopkgtest.ubuntu.com/packages/g/ganeti/jammy/amd64
[10:55] <paride> sil2100 ^^ is this something you can check?
[11:22] <GunnarHj> paride: Maybe the #launchpad channel is better to bring up that issue.
[11:28] <laney> paride: Looking at https://people.canonical.com/~ubuntu-archive/proposed-migration/log/jammy/2021-11-29/ I would say someone might have smacked it back into life this morning and the 09:00:11 run should update the things
[11:29] <laney> If there are still missing runs after that they might be lost and need to be requeued
[11:34] <paride> laney, thanks!
[11:34] <paride> isn't it taking a loong time compared to the previous runs?
[11:34] <paride> maybe it has more work to do due to the previous failures
[11:41] <laney> seems like there are a lot of tests to request
[12:36] <paride> laney, indeed I think some triggers did get lost... Taking again ganeti as an example, it is a "Test in progress" under qemu, but it as no queued run with triggers=qemu, not recent runs with trigger=qemu in https://autopkgtest.ubuntu.com/packages/g/ganeti/jammy/amd64
[12:37] <paride> do those need manual retriggering? or will britney figure it out at some point and retrigger?
[13:12] <laney> paride: it won't, if it believes it is waiting for the results it'll wait forever
[13:12] <laney> someone could fiddle with retry-autopkgtest-regressions to retry all the missing ones
[13:12] <laney> did something bad happen to rabbitmq or the network?
[13:18]  * paride no idea
[14:16] <paride> one strange thing: liburing triggered an autopkgtest run for mariadb-10.5, but there are no relationships between the two packages in d/control
[14:16] <paride> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liburing
[14:16] <paride> my theory is that the test run should be triggered against mariadb-10.6, but binary packages are missing for mariadb-10.6 (it ftbfs everywhere but in risvc)
[14:18] <paride> so the reverse dependency is wrongly resolved to mariadb-10.5 because it builds (some) binary packages with the same name as mariadb-10.6
[14:19] <schopin> Looking for a sponsor for LP: #1946193 (OpenSSL 3 transition)
[16:30] <GunnarHj> schopin: Where is that extra CFLAG you mentioned in the bug report?
[16:31] <schopin> Good question. I must have selected the wrong debdiff version :/
[16:35] <schopin> GunnarHj: fixed, thanks!
[16:39] <GunnarHj> schopin: Sponsored.
[16:39] <schopin> Thanks!
[18:41]  * ginggs runs 'retry-autopkgtest-regressions --state RUNNING --min-age 0.5'
[19:01] <sil2100> !dmb-ping
[19:01] <rafaeldtinoco> o/
[19:46] <sarnold> mwhudson: re the glibc crasher, I'm scared of efforts to try to keep some subset of people on 2.31-0ubuntu9.3 indefinitely -- they *should* get security and bug fixes same as everyone else. the trouble is, we absolutely know that the next update is going to cause regressions for those people, it's basically already happened. it's just a matter of when we rip the bandaid off. :/
[19:49] <sarnold> mwhudson: and living life on packages that can't be found on the archive mirrors isn't great fun -- apt install --reinstall is a useful thing, debug symbols are a useful thing, and maybe they'll need to install another binary package from the glibc source package.. using curl or wget from launchpad to solve those isn't a great look for an LTS
[19:50] <sarnold> mwhudson: I see no alternative besides pushing yet another breaking update and doing our best to message that *some* users are going to need a reboot asap :(
[19:57] <mwhudson> https://code.launchpad.net/~mwhudson/ubuntu-seeds/+git/ubuntu/+merge/411897 <- can i get someone to look at this?
[19:58] <mwhudson> sarnold: yeah, i think it starts by seeing how bad it is
[19:58] <mwhudson> paride: re excuses/autopkgtests rabbitmq had a little lie down i think
[20:12] <bdmurray> bryceh: php8.1 isn't producing i386 packages correct?
[20:18] <sarnold> oh hey, that reminds me ... if we're not building browsers for new releases any more, do we *need* to kill i386? not being able to offer i386 users security updates for packages we shipped was my main reason for thinking we should kill it
[20:20] <sarnold> mwhudson: re "how bad it is", reminds me of https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1674532 when an nss abi break caused similar-feeling problems..
[20:20] <mwhudson> yeah well we're not going to do that :)
[20:22] <mwhudson> sarnold: glibc 2.34+ embeds the commonest nss modules into libc itself which reduces the scope for this sort of hilariousness going forward
[20:23] <mwhudson> sarnold: i wish i understood what was actually going on with the bug you reported
[20:24] <mwhudson> i can see by experiment that using the ld.so from 0ubuntu9.3 with the libc.so from 0ubuntu9.2 breaks really badly
[20:24] <mwhudson> (although trying to debug _why_ mostly involved getting angry with and occasionally crashing gdb)
[20:27] <sarnold> mwhudson: it's a real shame we didn't shove a new 0ubuntu9.4 update out the door immediately and get it over with :( confining all the sadness to one week would have been nice
[20:27] <mwhudson> sarnold: yeah
[20:28] <sarnold> mwhudson: when my own system got into this, it was *really* hard to understand what the heck was going on -- so much just plain didn't work right. I'm not surprised that it's not easy to sort out, because once you've installed it, things don't work right..
[20:28] <mwhudson> sarnold: well the thing is, i made a lxc container (with 9.2), installed 9.3 and things were ... mostly ok?
[20:29] <sarnold> mwhudson: I've become so addicted to tab completion that when that goes sideways, I have immense trouble using the machine at all :)
[20:35] <mwhudson> heh my test container is now _extremely_ wedged
[21:19] <bdmurray> mwhudson: Can we just close out bug 1860942 now?
[21:20] <mwhudson> bdmurray: oh yes, surely
[21:22] <mwhudson> bdmurray: done
[23:15] <mwhudson> sarnold: ah ha i sort of figured out what is going on in https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379
[23:16] <sarnold> mwhudson: yeah? :D woo!
[23:36] <mwhudson> sarnold: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379/comments/8
[23:37] <mwhudson> sarnold: do / did you have any non-default nss config?
[23:40] <sarnold> mwhudson: https://termbin.com/zycj -- and ls -l says it hasn't changed since 2020, so it might even be the same as what I had back then
[23:40] <sarnold> mwhudson: impressive digging
[23:40] <sarnold> mwhudson: what would keep this from happening on any / every upgrade?
[23:41] <sarnold> mwhudson: I mean, new tunables aren't added daily, obviously :) but this is probably not the last
[23:56] <mwhudson> sarnold: hm even installing libnss-mdns and libnss-mymachines doesn't let me reproduce your failure :(