[08:26] <LocutusOfBorg> thanks bdmurray, updated!
=== caribou_ is now known as caribou
[09:21] <FourDollars> How to use git-build-recipe locally? Does it have some step by step guide?
[09:27] <cjwatson> FourDollars: https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted at least mentions it a little bit
[09:28] <FourDollars> cjwatson: In the "Testing the recipe" section, there is "bzr dailydeb --allow-fallback-to-native wikkid.recipe working-dir" for bzr, but none for git.
[09:28] <cjwatson> FourDollars: "Things are similar for git, but use git-build-recipe instead of bzr dailydeb"
[09:29] <cjwatson> right there in the text
[09:29] <cjwatson> git-build-recipe was derived from bzr-builder and has more or less the same interface
[09:29] <FourDollars> cjwatson: So "git-build-recipe --allow-fallback-to-native wikkid.recipe working-dir" should work, right?
[09:29] <cjwatson> Yes, if the recipe is written for git
[09:29] <FourDollars> OK. Thx a lot.
[09:29] <cjwatson> np
[09:33] <FourDollars> cjwatson: Could you help me to check https://code.launchpad.net/~fourdollars/+recipe/edid-decode-daily? I don't know what is wrong.
[09:35] <cjwatson> FourDollars: lp:~fourdollars/edid-decode/+git/debian doesn't have a "master" branch.  Try changing "master" to "debian/master" on the second line of the recipe?
[09:36] <cjwatson> FourDollars: Ah, but you will also run into https://bugs.launchpad.net/git-build-recipe/+bug/1683913.  Go to https://code.launchpad.net/~fourdollars/edid-decode/+git/debian/+edit and set a default branch for that repository (probably "debian/master")
[09:36] <ubottu> Launchpad bug 1683913 in git-build-recipe "git-build-recipe assumes that HEAD exists in the source repositories" [Undecided,New]
[09:39] <FourDollars> cjwatson: Yes, you are right. This issue is the root cause.
[09:39] <FourDollars> cjwatson: It works now. Thank you very much.
[09:42] <cjwatson> Good.  Let me see if I can do something about that bug since it's annoying
[11:21] <acheronuk> jbicha: would you want to fix LP: #1830860 in debian soon, or is it ok for me to just do it for now in Ubuntu?
[11:21] <ubottu> Launchpad bug 1830860 in pipewire (Ubuntu) "Building against pipewire fails with: invalid conversion from ‘void*’ to ‘spa_pod*’" [Undecided,New] https://launchpad.net/bugs/1830860
[11:26] <Laney> acheronuk: can you file a merge request on salsa?
[11:36] <acheronuk> Laney: I think so. not right now, as I have to go to dentist, but sure I can in the next few days
[11:37] <Laney> thanks, if you ping me I'll review it
[11:38] <Laney> bonus points if you can point to a build failure that happens in Debian
[11:38] <acheronuk> ok. thanks
=== ricab is now known as ricab|lunch
=== ricab|lunch is now known as ricab
[13:24] <ddstreet> rbalint what's the plan for systemd in eoan-proposed?  i have an upload of systemd for eoan
[13:25] <ddstreet> ah, it's late there :-/
[13:31] <Odd_Bloke> ddstreet: I think rbalint is also on vacation this week (though I'm not on his team, so I may have got the wrong end of the stick).
[13:32] <ddstreet> ah, well that's unfortunate...
[13:44] <ddstreet> rbasak not actually sru related, but you're the sru vanguard on the schedule so i'll ping you first; as rbalint is out this week (it appears) and his systemd upload to eoan has been in -proposed for 11 days and caused a regression, can i have someone sponsor my eoan systemd upload without rbalint's patch?  i'd prefer not to wait until next week when he gets back, and the regession appears serious enough (kbd stops working)
[13:45] <ddstreet> for reference, lp #1803993 and github regression bug is https://github.com/systemd/systemd/issues/12616
[13:45] <ubottu> Launchpad bug 1803993 in systemd (Ubuntu) "Password appears on the VT1 screen" [High,In progress] https://launchpad.net/bugs/1803993
[13:49] <ddstreet> xnox sil2100 do either of you have an opinion ^
[13:52]  * rbasak looks
[13:54] <rbasak> ddstreet: are you confident that it is his upload that caused the regression?
[13:55] <ddstreet> rbasak upstream systemd appears to think so, and rbalint asked for his c/d uploads to be rejected because of it
[13:55] <rbasak> ddstreet: based on http://autopkgtest.ubuntu.com/packages/s/systemd/eoan/amd64 it looks like 240-6ubuntu5 is generally failing too?
[13:56] <ddstreet> rbasak systemd on amd64/i386 has been failing like that intermittently for a couple weeks now
[13:56] <ddstreet> someone with access to the scalingstack instances needs to see why autopkgtest-virt-ssh can't ssh into the instance after a reboot
[13:56] <rbasak> Ah OK, so that's separate?
[13:56] <ddstreet> yes
[13:59] <ddstreet> rbasak re: failing systemd autopkgtest.u.c on amd64/i386, upstream has been a bit upset about it also, lp #1829829
[13:59] <ubottu> Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [Undecided,New] https://launchpad.net/bugs/1829829
[14:00] <rbasak> ddstreet: do you think rbalint would agree it's a regression in Eoan caused by that upload?
[14:00] <ddstreet> rbasak lemme find the freenode logs where he asked for his other uploads to be rejected, one minute
[14:02] <ddstreet> rbasak https://irclogs.ubuntu.com/2019/05/21/%23ubuntu-devel.txt
[14:02] <ddstreet> [12:01] <rbalint> xnox, seb128: the regression still seems to be better than leaking passwords and breaking keyboard on gdm after a few logouts, but i'm also open to reverting it until everything is sorted out
[14:02] <ddstreet> [12:03] <rbalint> xnox, with or without the revert i think it would be be beneficial to have ddstreet's autopkgtest fixes in eoan and in old releases even going in ahead of the VT fix
[14:03] <ddstreet> i'm ok either way, really, in eoan - i'd just like for it to get out of -proposed so i can ask someone to upload my systemd to eoan
[14:04] <rbasak> ddstreet: it sounds OK to me then. What I suggest you do is prepare an upload for sponsorship which explicitly reversts (with a changelog message) and then adds your changes.
[14:05] <ddstreet> rbasak will do, thnx
[15:16] <Odd_Bloke> xnox: Can you remind me where that reboot time script of yours is?
[15:19] <xnox> Odd_Bloke:  git clone lp:finalrd ?
[15:22] <Odd_Bloke> Aha, yep, that's it; thanks!
[16:30] <ddstreet> rbasak can you sponsor systemd to eoan for me for lp #1825378
[16:30] <ubottu> Launchpad bug 1825378 in systemd (Ubuntu Eoan) "systemd-networkd doesn't set wireguard peer endpoint" [Medium,In progress] https://launchpad.net/bugs/1825378
[16:34] <ddstreet> bdmurray are you able to access the autopkgtest.u.c systems?  i would love to know why systemd tests for amd64/i386 keep failing because the testbed isn't reachable by ssh after a reboot... been going on for a couple weeks now, including for upstream system tests.  lp #1829829
[16:34] <ubottu> Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [Undecided,New] https://launchpad.net/bugs/1829829
[16:34] <ddstreet> i don't know which people actually have access to the scalingstack infrastructure to see what's wrong with it
[16:37] <vorlon> ddstreet: that's primarily Laney, juliank, myself running it
[16:38] <ddstreet> vorlon do you know what release the host systems are?  trusty or xenial maybe?
[16:38] <ddstreet> compute nodes, i mean
[16:38] <juliank> Woohoo somebody mentioned my name
[16:38] <vorlon> ddstreet: I don't, we just consume compute as users of the cloud
[16:39] <ddstreet> ah ok
[16:39] <Laney> xnox has been pinged about 100 times about that
[16:39] <vorlon> but these are the lcy01 and lgw01 scalingstack regions
[16:39] <Laney> waiting for some kind of initial analysis from that end
[16:40] <ddstreet> Laney from xnox's end you mean?
[16:40] <Laney> yes
[16:40] <vorlon> ddstreet: why are you asking rbasak for systemd sponsorship, instead of going through xnox (Foundations maintains the package)?
[16:40] <ddstreet> i discussed it with rbasak earlier, and included xnox in the irc pings
[16:40] <ddstreet> xnox if you want to sponsor plz feel free to
[16:40] <ddstreet> i assume he's gone
[16:41] <ddstreet> vorlon do you mean that nobody except xnox should upload systemd to eoan?
[16:41] <vorlon> xnox and rbasak are in the same tz
[16:41] <ddstreet> ok, xnox, ping, you around?
[16:42] <vorlon> ddstreet: it's a heavy and complicated package and no one should be uploading it without /coordinating/ with foundations since there is often work in flight
[16:43] <ddstreet> vorlon sorry, so do you mean for systemd srus, i should not upload those myself, i should get xnox to upload systemd srus?
[16:43] <ddstreet> or do you just mean for the devel release
[16:43] <vorlon> ddstreet: I more mean for devel release
[16:43] <vorlon> and again, this is not about who uploads
[16:43] <vorlon> it's about coordinating to make sure no one's stepping on toes wrt other in-progress work
[16:44] <ddstreet> im pretty sure xnox is aware of my work here, it involves a few bugs he's opened, and i've pinged him in irc now enough times even today to be annoying ;-)
[16:44] <ddstreet> anywho
[16:46] <rbasak> ddstreet: ah, just seen this. I'm not confident enough to upload systemd without a +1 from a core dev on the foundations team, sorry!
[16:46] <xnox> ddstreet:  yes.
[16:46] <xnox> i am around
[16:47] <ddstreet> xnox hi, can you sponsor lp #1825378 for me, bugfix as well as quite a few test fixes
[16:47] <ubottu> Launchpad bug 1825378 in systemd (Ubuntu Eoan) "systemd-networkd doesn't set wireguard peer endpoint" [Medium,In progress] https://launchpad.net/bugs/1825378
[16:47] <ddstreet> once that's in i have even more to sru back
[16:47] <ddstreet> let me know if there's anything that annoys you.  thanks.
[16:49] <Laney> ddstreet: tkamppeter had a patch to SRU for systemd, if you're planning to upload soon could you maybe coordinate and grab that one too pleeeease?
[16:49] <xnox> reviewing
[16:50] <ddstreet> Laney that was for x/b only right?  the network-manager dns bug?
[16:51] <Laney> I think so but you best check with Till
[16:52] <ddstreet> IIRC that bug had reports of still not being fixed on the n-m side...i'll go find it and look at the systemd part tho
[16:53] <Laney> yeah, but the systemd bits will be needed when NM is re-fixed
[17:04] <seb128> rbasak, hey, unsure if you are over your SRU team shift hours but it would be nice if you could look at software-properties in bionic-proposed and migrate it to updates? It doesn't have a full week staging but the changes are safe error handling ones to fix regressions from the SRU that recently migrates to -updates
=== ricab is now known as ricab|bbl
[17:59] <rbasak> seb128: looing
[17:59] <rbasak> *looking
[18:03] <rbasak> seb128: does that mean that some of these bugs should be tagged regression-update? Which ones?
[18:15] <vorlon> seb128: network-manager 1.18.0-1ubuntu2 dropping gir1.2-networkmanager-1.0 now breaks debian/tests/nm.py which depends on it (the autopkgtests only passed because the NBS binary package in the eoan release pocket was still installable; now it's been removed)
[18:17] <vorlon> seb128: how should this be fixed? the test does use exports from gi.repository.NetworkManager, I don't know what those should be replaced with
[18:19] <cyphermox> gir1.2-nm-1.0
[18:19] <cyphermox> (I'll be pushing the button in a second...)
[18:20] <vorlon> cyphermox: ok
=== ricab|bbl is now known as ricab
[18:25] <cyphermox> hrm, actually, scratch that
[18:26] <cyphermox> it's more complicated than I thought, I'm starting to think gir1.2-networkmanager-1.0 shouldn't have been dropped
=== smoser1 is now known as smoser
[20:05] <seb128> vorlon, cyphermox, ups..., the NBS report was not enough to flag that :/
[20:05] <vorlon> indeed
[20:05] <vorlon> nor should this have been a blocker for deleting the NBS package
[20:06] <seb128> rbasak, yes, bug #1830348 and bug #1830353
[20:06] <ubottu> bug 1830348 in software-properties (Ubuntu Bionic) "/usr/bin/software-properties-gtk:TypeError:msg_reply_handler:_enabled_reply_handler:__call__:call_async" [Undecided,Fix committed] https://launchpad.net/bugs/1830348
[20:06] <ubottu> bug 1830353 in software-properties (Ubuntu Bionic) "/usr/bin/software-properties-gtk:AttributeError:_update_availability:<lambda>:get_status:_get_raw_snap" [Undecided,Fix committed] https://launchpad.net/bugs/1830353
[20:07] <seb128> rbasak, I tagged them now, if that helps
[20:08] <seb128> vorlon, cyphermox, tomorrow is an holidays here but I've a look on friday if no-one beats me to it
[20:08] <cyphermox> seb128: vorlon: the autopkgtests needed porting, really
[20:08] <cyphermox> it's not even new changes, it's been years :/
[20:09] <seb128> n-m has been basically unmaintained in Ubutu for ages, which we keep raising as an issue but hasn't really be resolved yet
[20:11] <seb128> cyphermox, vorlon, I expect porting those tests is going to take a while since we don't have anyone knowing about those bindings atm, unsure what to do meanwhile
[20:13] <vorlon> seb128: restore the deprecated binary packages?
[20:13] <vorlon> so we don't have to drop test coverage in the near term
[20:13] <seb128> I guess :/
[20:13] <cyphermox> give me a day?
[20:13] <seb128> cyphermox, if you want/could have a look that would be great