/srv/irclogs.ubuntu.com/2019/08/06/#ubuntu-devel.txt

=== M_hc[m] is now known as _hc
rbasakmwhudson, waveform: https://github.com/snapcore/core/pull/96 might be relevant to your current problem10:34
mwhudsonrbasak: ah very likely10:34
rbasakI thought it was fixed a long time ago though10:35
rbasakFundamentally 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 from10:35
rbasakgit-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
rbasakPerhaps an AppArmor profile should be used to prevent it actually.10:36
rbasakThat might be a feature request for classic snaps!10:36
rafaeldtinocomorning o/10:53
juliankRikMills: heya, are you looking into the kdeconnect autopkgtest failures on bionic?11:55
juliankdoes it maybe need a rebuild against openssl 1.1.1?11:56
RikMillsjuliank: no, as upstream KDE don't care11:56
RikMillsno, just a racy test AFAIK11:56
juliankgiven that it is constantly failing, and worked fine before openssl 1.1.1...11:58
juliankWe gotta get this thing fixed11:58
juliankor remove the test11:59
juliankI don't care if KDE cares or not, this is super annoying12:00
juliankIt causes autopkgtest regressions for even dpkg12:00
RikMillsjuliank: oh, 1.1.1 is recent?12:01
RikMillscould be it then12:01
juliankRikMills: Jun 1012:03
juliankRikMills: Last working test was Jun 312:03
juliankRikMills: Next test after that one was Jul 412:03
RikMillssounds likely cause then12:04
juliankRikMills: I'm running a test and a rebuild+test now12:07
=== ricab is now known as ricab|lunch
RikMillsjuliank: thank you!12:09
LocutusOfBorgsmb, hello, permission to steal iproute2 merge?12:10
LocutusOfBorgI'm trying to debug firewalld testsuite failures...12:10
LocutusOfBorghttps://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/10393698/+listing-archive-extra12:11
LocutusOfBorgif you want to take it12:11
juliankRikMills: Ah, so cosmic fails as well, but disco passes12:13
juliankRikMills: and the rebuild also fails12:13
juliankRikMills: But I see 1.3.5 has patches for that, probably they are in disco too, and just need backporting to bionic12:14
smbLocutusOfBorg, for Eoan? Will you do it using the git ubuntu trees?12:14
juliankSo I guess the question is whether you'd just want 1.3.4 in bionic and get some actual bugfixes in12:15
juliankah, that's the disable the patch thing12:16
juliankAlthough debian does have a fix the tests patch in there too12:16
juliankhow odd12:16
smbLocutusOfBorg, usually I have to get things sponsored too (cpaelzer / ahasenack, would there be a problem taking a merge that ^ way)12:16
RikMillsjuliank: yeah, that test has always been 'racy'12:16
juliankah I see12:16
RikMillsjuliank: that debian patch fixed it on their CI, but not our infra for some reason12:17
RikMillsso I lost patience when even upstream went "so what"12:17
juliankIn 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 it12:17
RikMillsskipping on bionic sounds reasonable12:18
juliankIt just seems a bit pointless to upload an SRU without user-visible changes :/12:19
RikMillsjuliank: not sure I will have time this week to prepare a more 'meaningful' SRU12:20
RikMillsprobably a job for after Eoan feature freeze for me12:21
juliankRikMills: I guess that's OK, but we should get it done eventually for future SRUs :)12:23
RikMillsjuliank: agreed. please remind me if I seem to forget!12:24
juliankack12:24
cpaelzersmb: both ways (debdiff from ppa) or MP can be sponsored (obviously) but you (SMB) will loose the split commits for the next merge12:54
=== Eleventh_Doctor is now known as Pharaoh_Atem
=== ricab|lunch is now known as ricab
smbLocutusOfBorg, 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 myself13:31
LocutusOfBorgsmb, if you commit on git I'm happy to sponsor :)13:32
LocutusOfBorgI dind't realize you don't have permissions to upload...13:33
smbLocutusOfBorg, 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:34
LocutusOfBorgI 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 care13:35
LocutusOfBorgor even, I can try to commit myself if I don't screw things13:36
LocutusOfBorgnot sure where the git repo is located13:36
smbLocutusOfBorg, 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, though13:38
smbLocutusOfBorg,  https://git.launchpad.net/~usd-import-team/ubuntu/+source/iproute213:40
smbLocutusOfBorg, the workflow I try to follow is to push that to a personal git repo on lp and create a merge proposal from that13:40
LocutusOfBorgok so I leave it...13:40
LocutusOfBorgthe risk of messing up is huge :)13:40
rbasak?13:41
rbasakgit diff whats_in_ubuntu your_merge_proposal13:41
rbasakIf you can review a debdiff, you can review that.13:41
rbasakThe cost of messing up therefore cannot be any higher.13:42
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:43
tomreynthanks for your post on the file-roller bug, seb128!13:45
seb128tomreyn, yw!13:46
smbrbasak, 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 done13:48
rbasakYes, it certainly seems very complicated to start with.13:49
rbasakMy 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:50
smbrbasak, 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:56
LocutusOfBorgrbasak, 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, upload13:59
LocutusOfBorgwith git, should I import the debian version in some way?13:59
smbLocutusOfBorg, that importer git tree already has the debian remotes, so one can rebase the ubuntu branch onto the next debian14:00
rbasakLocutusOfBorg: you need to be checking that the entire Ubuntu delta is still applicable against the new Debian.14:01
LocutusOfBorgrbasak, I do check that, yes14:01
rbasakLocutusOfBorg: 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
rbasakOK :)14:01
LocutusOfBorgrbasak, in case it disappears, doing meld between the new diff and the *ubuntu*patch will make them visible14:02
rbasakLike smb says, the relevant bits you need are already all imported into the git-ubuntu trees.14:02
rbasakEssentially all you need to do is git rebase the old ubuntu tip onto the new Debian tip.14:02
LocutusOfBorgI do that for gstreamer packages, but I always have the feeling that I'm not doing stuff right14:02
rbasakIf you can do this with git directly yourself, you don't need the git-ubuntu tooling yourself.14:02
rbasakThe tooling just makes some common repetitive edge cases around that work easier, such as the handling debian/changelog correctly.14:03
smbLocutusOfBorg, but again, if you do not dare to start doing things that way with iproute2, I can handle it. Just maybe not that quickly14:08
tkamppeterLocutusOfBorg, hi14:10
tkamppeterLocutusOfBorg, 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:12
LocutusOfBorghttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/183915414:15
ubottuLaunchpad bug 1839154 in linux (Ubuntu) "please backport upstream patch to kernel 5.2" [Critical,Confirmed]14:15
LocutusOfBorgtkamppeter,14:15
* smb feels the matrix is resetting itself into a loop14:16
smbsforshee, cascardo ^14:17
tkamppeterLocutusOfBorg, thank you very much.14:18
LocutusOfBorgtkamppeter, I can probably hack upload the firewalld workaround14:24
LocutusOfBorgbut this is a kernel bug.14:24
seb128LocutusOfBorg, tkamppeter, you could probably ask for the test result to be skipped one time to have things migrating also as an option?14:34
LocutusOfBorgseb128, I'm adding a modprobe in the test suite, to see if the test is good14:35
seb128k14:38
=== Wryhder is now known as Lucas_Gray
seb128bah, I never can figure out how to make git mps on launchpad work :/16:48
seb128I'm trying to mp https://code.launchpad.net/~seb128/wslu/+git/wslu/+ref/ubuntu/master16:48
seb128the default target is lp:wslu is that right for https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/wslu/+git/wslu ?16:48
seb128and if so why is target branch ubuntu/master of ref/heads/ubuntu/master not working?16:48
seb128I'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:49
cjwatsonYou need to push to lp:~seb128/ubuntu/+source/wslu, not to lp:~seb128/wslu/+git/wslu16:52
cjwatsonYour source repository is in a different namespace from the target so MPs are forbidden16:53
cjwatsonThe "ubuntu/+source/wslu" bit is the namespace16:53
rbasakseb128: I think you could use this bug fixed https://bugs.launchpad.net/launchpad/+bug/1813778 :)16:59
ubottuLaunchpad bug 1813778 in Launchpad itself ""Personal" push URLs not displayed on code pages" [Low,Triaged]16:59
cjwatsonIf 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:02
seb128cjwatson, thx, I get confused by that every time :/17:25
seb128rbasak, right17:25
niedbalskibdmurray: hey :-), any chance for you to check the verified SRU on LP: #1835581? which is also holding LP: #166877117:27
ubottuLaunchpad bug 1835581 in systemd (Ubuntu Eoan) "networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes" [Medium,Fix committed] https://launchpad.net/bugs/183558117:27
ubottuLaunchpad bug 1668771 in systemd "[SRU] systemd-resolved negative caching for extended period of time" [Unknown,New] https://launchpad.net/bugs/166877117:27
niedbalskior RAOF ^^ if you are able to, please :-)17:33
bdmurrayniedbalski: By "check the verified SRU" do you mean you want me to look at releasing it from -proposed to -updates?17:34
niedbalskibdmurray: that's right.17:34
=== BriggsE is now known as BriggsE2
=== BriggsE2 is now known as BriggsE3
niedbalskibdmurray: thank you, i think you might have missed disco (which is also in -proposed and verified)20:22

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!