[10:34] <rbasak> mwhudson, waveform: https://github.com/snapcore/core/pull/96 might be relevant to your current problem
[10:34] <mwhudson> rbasak: ah very likely
[10:35] <rbasak> I thought it was fixed a long time ago though
[10:35] <rbasak> Fundamentally though when bundling an environment (like snaps do, but same with any other bundling) and the app needs to also see the host system, things get confused as to where they are running things from
[10:36] <rbasak> git-ubuntu shouldn't run anything in the host system, but it happens by accident sometimes. It is a bug if it happens but I don't know of a good way to test for it.
[10:36] <rbasak> Perhaps an AppArmor profile should be used to prevent it actually.
[10:36] <rbasak> That might be a feature request for classic snaps!
[10:53] <rafaeldtinoco> morning o/
[11:55] <juliank> RikMills: heya, are you looking into the kdeconnect autopkgtest failures on bionic?
[11:56] <juliank> does it maybe need a rebuild against openssl 1.1.1?
[11:56] <RikMills> juliank: no, as upstream KDE don't care
[11:56] <RikMills> no, just a racy test AFAIK
[11:58] <juliank> given that it is constantly failing, and worked fine before openssl 1.1.1...
[11:58] <juliank> We gotta get this thing fixed
[11:59] <juliank> or remove the test
[12:00] <juliank> I don't care if KDE cares or not, this is super annoying
[12:00] <juliank> It causes autopkgtest regressions for even dpkg
[12:01] <RikMills> juliank: oh, 1.1.1 is recent?
[12:01] <RikMills> could be it then
[12:03] <juliank> RikMills: Jun 10
[12:03] <juliank> RikMills: Last working test was Jun 3
[12:03] <juliank> RikMills: Next test after that one was Jul 4
[12:04] <RikMills> sounds likely cause then
[12:07] <juliank> RikMills: I'm running a test and a rebuild+test now
[12:09] <RikMills> juliank: thank you!
[12:10] <LocutusOfBorg> smb, hello, permission to steal iproute2 merge?
[12:10] <LocutusOfBorg> I'm trying to debug firewalld testsuite failures...
[12:11] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10393698/+listing-archive-extra
[12:11] <LocutusOfBorg> if you want to take it
[12:13] <juliank> RikMills: Ah, so cosmic fails as well, but disco passes
[12:13] <juliank> RikMills: and the rebuild also fails
[12:14] <juliank> RikMills: But I see 1.3.5 has patches for that, probably they are in disco too, and just need backporting to bionic
[12:14] <smb> LocutusOfBorg, for Eoan? Will you do it using the git ubuntu trees?
[12:15] <juliank> So I guess the question is whether you'd just want 1.3.4 in bionic and get some actual bugfixes in
[12:16] <juliank> ah, that's the disable the patch thing
[12:16] <juliank> Although debian does have a fix the tests patch in there too
[12:16] <juliank> how odd
[12:16] <smb> LocutusOfBorg, usually I have to get things sponsored too (cpaelzer / ahasenack, would there be a problem taking a merge that ^ way)
[12:16] <RikMills> juliank: yeah, that test has always been 'racy'
[12:16] <juliank> ah I see
[12:17] <RikMills> juliank: that debian patch fixed it on their CI, but not our infra for some reason
[12:17] <RikMills> so I lost patience when even upstream went "so what"
[12:17] <juliank> In any case, I'd kind of like to see this skipped rather than just ignoring autopkgtest regressions for that altogether or having to re-check that it's not a regression on every SRU that riggers it
[12:18] <RikMills> skipping on bionic sounds reasonable
[12:19] <juliank> It just seems a bit pointless to upload an SRU without user-visible changes :/
[12:20] <RikMills> juliank: not sure I will have time this week to prepare a more 'meaningful' SRU
[12:21] <RikMills> probably a job for after Eoan feature freeze for me
[12:23] <juliank> RikMills: I guess that's OK, but we should get it done eventually for future SRUs :)
[12:24] <RikMills> juliank: agreed. please remind me if I seem to forget!
[12:24] <juliank> ack
[12:54] <cpaelzer> smb: both ways (debdiff from ppa) or MP can be sponsored (obviously) but you (SMB) will loose the split commits for the next merge
[13:31] <smb> LocutusOfBorg, in that case, if you preserve the individual commits and do a merge proposal, I would be ok with you doing it, otherwise I rather would do it myself
[13:32] <LocutusOfBorg> smb, if you commit on git I'm happy to sponsor :)
[13:33] <LocutusOfBorg> I dind't realize you don't have permissions to upload...
[13:34] <smb> LocutusOfBorg, Something I'd like to fix at some point, and I'll try to somehow squeeze this in. But cannot promise it to be quick.
[13:35] <LocutusOfBorg> I mean, if you like the work I did, can you please just commit? otherwise I'll be happy to be pinged back if you want to take care
[13:36] <LocutusOfBorg> or even, I can try to commit myself if I don't screw things
[13:36] <LocutusOfBorg> not sure where the git repo is located
[13:38] <smb> LocutusOfBorg, just commit from debdiff, no, because the point is to have per-delta item commits. The tree is launchpad and the simplest setup would be via git ubuntu, that is a (classic) snap only, though
[13:40] <smb> LocutusOfBorg,  https://git.launchpad.net/~usd-import-team/ubuntu/+source/iproute2
[13:40] <smb> LocutusOfBorg, the workflow I try to follow is to push that to a personal git repo on lp and create a merge proposal from that
[13:40] <LocutusOfBorg> ok so I leave it...
[13:40] <LocutusOfBorg> the risk of messing up is huge :)
[13:41] <rbasak> ?
[13:41] <rbasak> git diff whats_in_ubuntu your_merge_proposal
[13:41] <rbasak> If you can review a debdiff, you can review that.
[13:42] <rbasak> The cost of messing up therefore cannot be any higher.
[13:43] <rbasak> (separately, almost everyone using the git ubuntu package merge workflow has found mistakes that other uploaders have been carrying forward for years using merge-o-matic)
[13:45] <tomreyn> thanks for your post on the file-roller bug, seb128!
[13:46] <seb128> tomreyn, yw!
[13:48] <smb> rbasak, I guess the hurdle might be git in general if one only did deb based merges before. Most people are really scared of git. Maybe it helps to point out that this way one fetches but has no ability to mess anything up directly beyond ones own copy. And the personal tree also is completely seperate. And until the merge proposal gets accepted no harm is done
[13:49] <rbasak> Yes, it certainly seems very complicated to start with.
[13:50] <rbasak> My argument is that Ubuntu package merges are inherently complicated. git-ubuntu's merge workflow makes this clear up front. Or you can blunder through using merge-o-matic without realising.
[13:50] <rbasak> (which is fine for trivial package merges)
[13:56] <smb> rbasak, Yep, just mentioned it as I suspected that scared LocutusOfBorg. But might be good for me if I am forced to get that next merge done in the end. So maybe one day I can upload it, too. :)
[13:59] <LocutusOfBorg> rbasak, smb my merges are done this way: grab-merge (DoM), look at *ubuntu*patch, see what is missing, see if it applies again and needed, update, dpkg-buildpackage -S -d, debdiff of the result, compare with the previous diff from Debian, upload
[13:59] <LocutusOfBorg> with git, should I import the debian version in some way?
[14:00] <smb> LocutusOfBorg, that importer git tree already has the debian remotes, so one can rebase the ubuntu branch onto the next debian
[14:01] <rbasak> LocutusOfBorg: you need to be checking that the entire Ubuntu delta is still applicable against the new Debian.
[14:01] <LocutusOfBorg> rbasak, I do check that, yes
[14:01] <rbasak> LocutusOfBorg: and, if any of the delta has disappeared (eg. if Debian adopted it), you need to be aware of it so you can adjust the documentation in debian/changelog accordingly.
[14:01] <rbasak> OK :)
[14:02] <LocutusOfBorg> rbasak, in case it disappears, doing meld between the new diff and the *ubuntu*patch will make them visible
[14:02] <rbasak> Like smb says, the relevant bits you need are already all imported into the git-ubuntu trees.
[14:02] <rbasak> Essentially all you need to do is git rebase the old ubuntu tip onto the new Debian tip.
[14:02] <LocutusOfBorg> I do that for gstreamer packages, but I always have the feeling that I'm not doing stuff right
[14:02] <rbasak> If you can do this with git directly yourself, you don't need the git-ubuntu tooling yourself.
[14:03] <rbasak> The tooling just makes some common repetitive edge cases around that work easier, such as the handling debian/changelog correctly.
[14:08] <smb> LocutusOfBorg, but again, if you do not dare to start doing things that way with iproute2, I can handle it. Just maybe not that quickly
[14:10] <tkamppeter> LocutusOfBorg, hi
[14:12] <tkamppeter> LocutusOfBorg, you know that the firewalld 0.7.x (on arm64 only) is blocking network-manager 1.18.0-1ubuntu6 to get out of -proposed in Eoan?
[14:15] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1839154
[14:15] <LocutusOfBorg> tkamppeter,
[14:16]  * smb feels the matrix is resetting itself into a loop
[14:17] <smb> sforshee, cascardo ^
[14:18] <tkamppeter> LocutusOfBorg, thank you very much.
[14:24] <LocutusOfBorg> tkamppeter, I can probably hack upload the firewalld workaround
[14:24] <LocutusOfBorg> but this is a kernel bug.
[14:34] <seb128> LocutusOfBorg, tkamppeter, you could probably ask for the test result to be skipped one time to have things migrating also as an option?
[14:35] <LocutusOfBorg> seb128, I'm adding a modprobe in the test suite, to see if the test is good
[14:38] <seb128> k
[16:48] <seb128> bah, I never can figure out how to make git mps on launchpad work :/
[16:48] <seb128> I'm trying to mp https://code.launchpad.net/~seb128/wslu/+git/wslu/+ref/ubuntu/master
[16:48] <seb128> the default target is lp:wslu is that right for https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/wslu/+git/wslu ?
[16:48] <seb128> and if so why is target branch ubuntu/master of ref/heads/ubuntu/master not working?
[16:49] <seb128> I'm sure I screwed something again, either pushed to the wrong location or the target is wrong but I can't figure out what I should do differently :-/
[16:52] <cjwatson> You need to push to lp:~seb128/ubuntu/+source/wslu, not to lp:~seb128/wslu/+git/wslu
[16:53] <cjwatson> Your source repository is in a different namespace from the target so MPs are forbidden
[16:53] <cjwatson> The "ubuntu/+source/wslu" bit is the namespace
[16:59] <rbasak> seb128: I think you could use this bug fixed https://bugs.launchpad.net/launchpad/+bug/1813778 :)
[17:02] <cjwatson> If you know anyone good to point at the open job advert for a Launchpad developer (https://boards.greenhouse.io/canonical/jobs/1709248), that would be a great way to improve the likelihood of this being fixed :-)
[17:25] <seb128> cjwatson, thx, I get confused by that every time :/
[17:25] <seb128> rbasak, right
[17:27] <niedbalski> bdmurray: hey :-), any chance for you to check the verified SRU on LP: #1835581? which is also holding LP: #1668771
[17:33] <niedbalski> or RAOF ^^ if you are able to, please :-)
[17:34] <bdmurray> niedbalski: By "check the verified SRU" do you mean you want me to look at releasing it from -proposed to -updates?
[17:34] <niedbalski> bdmurray: that's right.
[20:22] <niedbalski> bdmurray: thank you, i think you might have missed disco (which is also in -proposed and verified)