[05:41] -queuebot:#ubuntu-release- New: accepted libobject-result-perl [amd64] (mantic-proposed) [0.000003-1]
[05:41] -queuebot:#ubuntu-release- New: accepted php-algo26-idna-convert [amd64] (mantic-proposed) [3.1.0-1]
[11:29] -queuebot:#ubuntu-release- New sync: rust-gstreamer (mantic-proposed/primary) [0.19.3-1]
[11:34] -queuebot:#ubuntu-release- New sync: rust-gstreamer-base (mantic-proposed/primary) [0.19.3-1]
[11:35] -queuebot:#ubuntu-release- New sync: rust-gstreamer-audio (mantic-proposed/primary) [0.19.3-1]
[11:35] -queuebot:#ubuntu-release- New sync: rust-gstreamer-video (mantic-proposed/primary) [0.19.3-1]
[18:01] -queuebot:#ubuntu-release- Unapproved: gallery-dl (jammy-backports/universe) [1.25.4-1~bpo22.04.1 => 1.25.5-1~bpo22.04.1] (no packageset)
[20:08] -queuebot:#ubuntu-release- New sync: rust-wayland-backend (mantic-proposed/primary) [0.1.1-1]


[06:39] <mborzecki> morning
[07:02] <zyga> mborzecki: hey :)
[07:03] <mborzecki> zyga: hey hey
[07:03] <zyga> how was your weekend?
[07:03] <zyga> mborzecki: easy landing https://github.com/snapcore/snapd/pull/7867
[07:04] <mup> PR #7867: tests: fix fwupd version regular expression <Simple 😃> <⚠ Critical> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7867>
[07:05] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7864 needs love
[07:05] <mup> PR #7864: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
[07:06] <mup> PR snapd#7867 closed: tests: fix fwupd version regular expression <Simple 😃> <⚠ Critical> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7867>
[07:07] <mborzecki> zyga: do you know the backstory of https://github.com/snapcore/snapd/pull/7865 ?
[07:07] <mup> PR #7865: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865>
[07:08] <zyga> mborzecki: no idea but probably allows one to travis a fork
[07:09] <mborzecki> zyga: https://golang.org/cmd/go/#hdr-Remote_import_paths
[07:12] <mborzecki> hm, why didn't that fail on < 19.04
[07:25] <mup> PR snapd#7854 closed: snap-confine: raise egid before calling setup_private_mount() <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7854>
[07:25] <sdhd-sascha> hello :-)
[07:37] <zyga> hey sdhd-sascha
[07:37] <mup> PR snapd#7840 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7840>
[07:42] <sdhd-sascha> zyga: I'm not sure if it made sense to split the travis jobs. Maybe they were summarized because of the total build-time. And it is difficult to get a free build slot on the online travis-platform...
[07:43] <zyga> sdhd-sascha: yeah, it's a weird limitation; I don't know if your PR should be merged or not yet. I think sergio should review it
[07:44] <zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/7129
[07:44] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[07:44] <sdhd-sascha> zyga: but the gopath import would be nice. Because with it, it's possible to build on own github/travis account, before PR
[07:44] <zyga> it's pretty old and I think nobody looks at it
[07:52] <zyga> mborzecki: thinking about https://github.com/snapcore/snapd/pull/7205
[07:52] <mup> PR #7205: rfc: introduce confinement options failsafe flag <Created by zyga> <https://github.com/snapcore/snapd/pull/7205>
[07:52] <zyga> what can we do to make it landable?
[07:54] <mborzecki> zyga: hmm so the snap-mgm test fails bc there's lxd socket unit, turns out the socket units are there base image
[07:55] <zyga> ok, let's filter those out then
[08:00] <pstolowski> morning
[08:00] <zyga> hey :)
[08:18] <mup> PR snapd#7866 closed: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7866>
[08:19] <mup> PR snapd#7868 opened: Revert "travis-ci: split integration tests into parts (>4MB log limit)" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7868>
[08:21] <mborzecki> pstolowski: mvo: hey
[08:25] <mvo> hey mborzecki
[08:26] <mup> PR snapd#7868 closed: Revert "travis-ci: split integration tests into parts (>4MB log limit)" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7868>
[08:27] <mup> PR snapd#7862 closed: release: 2.42.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7862>
[08:33] <mborzecki> zyga: heh, updated #7864
[08:33] <zyga> mmm, looking
[08:33] <mup> PR #7864: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
[08:33] <zyga> aha
[08:33] <zyga> smart
[08:33] <zyga> nice
[08:35] <pstolowski> mborzecki: going to review your seccomp branch this morning
[08:35] <mborzecki> pstolowski: cool, thank you!
[08:35] <zyga> pstolowski: can you do a pass over https://github.com/snapcore/snapd/pull/7863
[08:35] <mup> PR #7863: interfaces/builtin: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863>
[08:36] <pstolowski> zyga: yes, sure
[08:36] <mvo> sdhd-sascha: hey, re 7866 - I accidently merged it but it was not reviewed yet so I reverted it again. please just reopen (or I can reopen). sorry for this! fwiw, we only hit the 4mb limit under certain circumstances of failing tests. not sure we want to split generally - the downside of a general split is that we only have a fixed amount of travis slots aiui so it may slow things down
[08:36] <mborzecki> ha, wireguard has landed in mainline
[08:38] <zyga> coffee and 1-2-1 prep
[08:38] <zyga> ttyl
[08:39] <sdhd-sascha> mvo: no problem.
[08:39] <mvo> sdhd-sascha: thank you!
[08:40] <sdhd-sascha> mvo: could you test the PR with the go import path? with them it was possible to build snapd on my own repo and travis
[08:41] <mvo> sdhd-sascha: could you please merge it on master or rebase it on master - there was a bug in master that caused the integration tests to fail which got fixed this morning. this should make the test green.
[08:42] <sdhd-sascha> mvo: so anybody can test building before any PR.
[08:42] <mvo> sdhd-sascha: also could you please elaborate a little bit on this works? it sounds very cool!
[08:42] <sdhd-sascha> mvo: what should i merge?
[08:42] <mvo> sdhd-sascha: just fetch the lastest upstream from snapd and merge master into your PR. I'm happy to do this for you if you prefer
[08:43] <sdhd-sascha> mvo: sure, but i'm also new on travis ;-) i'm just googling for a solution ...
[08:43] <mvo> sdhd-sascha: I see :)
[08:43] <sdhd-sascha> mvo: ok
[08:44] <mvo> sdhd-sascha: so with 7865, what would I have to do to run my forked branch? what steps to follow etc :) ? (does my question make sense?)
[08:50] <mborzecki> mvo: as i understand, you'll be able to run the travis job on your private fork
[08:50] <sdhd-sascha> mvo: with 7865. just add the go_import_path, and add your repo under "MyRepositories" on travis. Then manually build on travis or wait on the next git push
[08:50] <sdhd-sascha> mborzecki: right
[08:53] <zyga> re
[08:55] <sdhd-sascha> I will now merge master on my pull-request. Can somebody please cancel my travis-jobs ? I wait until it works my private repo first.
[08:55] <zyga> sdhd-sascha: jobs auto-cancel on push
[08:55] <sdhd-sascha> ...on my private repo
[08:55] <sdhd-sascha> zyga: ?
[08:55] <zyga> no, on your private repo you can cancel them
[08:55] <zyga> I was talking about the snapd repo
[08:56] <sdhd-sascha> zyga: I'm too. I won't waste your build time
[08:56] <sdhd-sascha> don't want
[08:59] <Eighth_Doctor> mborzecki, zyga : do either of you know what's going on here? https://bugzilla.redhat.com/show_bug.cgi?id=1780712
[08:59] <Eighth_Doctor> it seems like snapd doesn't know how to read the path properly...
[09:00] <mborzecki> Eighth_Doctor:  it's sudo dropping env
[09:00] <zyga> Eighth_Doctor: the keyword is sudo
[09:00] <Eighth_Doctor> blech
[09:00] <Eighth_Doctor> I was afraid of that
[09:00] <zyga> try sudo env
[09:00] <zyga> I need to jump to a meeting
[09:00] <mborzecki> Eighth_Doctor: https://forum.snapcraft.io/t/centos-7-error-system-does-not-fully-support-snapd-cannot-read-the-value-of-fs-may-detach-mounts-kernel-parameter/14392/5
[09:02] <sdhd-sascha> would "sudo -E" help ?
[09:02] <sdhd-sascha> """-E, --preserve-env            preserve user environment when running command"""
[09:03] <mborzecki> sdhd-sascha: iirc the security policy will still drop your current $PATH
[09:03] <mborzecki> sudo -i should work though
[09:32] <sdhd-sascha> mvo: is there a reopen button on github for 7866, or should i opened a new pr
[09:36] <zyga> re
[09:36] <mvo> sdhd-sascha: I think you need to open a new PR
[09:37] <mvo> sdhd-sascha, mborzecki thanks for explaining how 7865 works
[09:48] <zyga> Eighth_Doctor: do you think the proposed solution in https://bugzilla.redhat.com/show_bug.cgi?id=1691996 is workable?
[09:48] <zyga> Eighth_Doctor: btw, I need to thank you for excellent maintenance of snapd in Fedora. I've been using Fedora for a few weeks on my daily driver and it's nothing short of excellent
[09:49] <zyga> Eighth_Doctor: it really helps me to develop cgroupv2 features
[09:50] <mup> PR snapd#7869 opened: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7869>
[09:51] <sdhd-sascha> mvo: i had to reapply the commit, because of the revert
[09:52] <mvo> sdhd-sascha: yeah, again, sorry for the trouble :( won't happen again
[09:54] <mup> PR snapd#7853 closed: [RFC] boot,bootloader: setup the snapd_recovery_kernel grubenv <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7853>
[09:56] <mborzecki> zyga: will you be pushing fixes to 7129?
[09:56] <zyga> checking
[09:57] <zyga> what kind of fixes?
[09:57] <mborzecki> zyga: just added a bunch of comments, but i can push the fixes too if you're busy with somehting else
[09:57] <zyga> mborzecki: you forgot to click send
[09:57] <zyga> there are no new comments
[09:57] <mborzecki> zyga: try refreshing
[09:57] <zyga> mborzecki: did
[09:58] <zyga> again
[09:58] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/7129#pullrequestreview-328794160
[09:58] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[09:58] <zyga> wow, now I see them
[09:58] <mborzecki> haha ;)
[09:58] <zyga> man, eventually consistent my ass
[09:58] <zyga> yeah, go for it
[09:58] <zyga> thank you for looking
[09:58] <mborzecki> ok
[09:58] <mborzecki> trivials anyway ;)
[09:58] <zyga> feels like something close
[09:58] <zyga> I'll jump back into https://github.com/snapcore/snapd/pull/7625
[09:59] <zyga> to get it unblocked
[09:59] <mup> PR #7625: cmd/snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7625>
[09:59] <mborzecki> but really, the desktop stuff is like duct tape and glue all the way
[09:59] <pedronis> mborzecki: notice that 7129 is blocked on jdstrand review
[09:59] <zyga> mborzecki: yeah
[10:00] <mborzecki> pedronis: right, i can ping jdstrand_ in case he missed it (though i'm sure it's in his queue)
[10:00] <pedronis> it's in his queue
[10:13] <mup> PR snapd#7768 closed: interfaces: add raw-volume interface for access to partitions <⛔ Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7768>
[10:14] <mup> PR snapd#7768 opened: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[10:37] <ijohnson> morning folks
[10:38] <zyga> hey ijohnson
[10:38] <ijohnson> hey zyga
[10:39] <mvo> hey ijohnson
[10:39] <ijohnson> mvo: did you see my comment on the SU doc? I didn't make it very far in updating the grub.cfg.normal for the UC20 pc gadget, also I had it in my notes that grub.cfg.recovery was the ubuntu-seed partition but reading through it, I think grub.cfg.recovery is for ubuntu-boot no?
[10:40] <ijohnson> reading the grub.cfg specifically
[10:42] <pedronis> ijohnson: recovery goes to ubuntu-seed and *not* recovery goes to ubuntu-boot
[10:43] <ijohnson> pedronis: Hmm that's not how it's written now though, the grub.cfg.recovery is currently doing the chainloading to the recovery system grub IIUC
[10:43] <pedronis> ijohnson: sorry, we are talking different things
[10:44] <ijohnson> sure, it is like 4 am here so not surprised I have something confused :-)
[10:44] <pedronis> ijohnson: that should happen only for mode != run
[10:45] <pedronis> not saying that is what happens right now, neither are definitive
[10:45] <pedronis> or close to that
[10:45] <mvo> ijohnson: I have not yet, will look at it next, sorry!
[10:45] <pedronis> which is part of the problem
[10:45] <pedronis> ijohnson: I mean in run mode we should chain from ubuntu-seed recovery grub into ubuntu-boot grub
[10:46] <ijohnson> mvo: no problem just wanted to make sure you were aware if you needed someone else to work on this before Wednesday
[10:46] <mvo> ijohnson: yeah, that's fine, I figured :)
[10:46] <pedronis> the recovery systems should really play a role only if mode != run
[10:46] <mvo> ijohnson: hope the trip was fine?
[10:46] <ijohnson> pedronis: yes I understand that part, I'm just a bit confused which grub file in the repo corresponds to which partition
[10:47] <pedronis> ijohnson: recovery should correspond to seed, and the other to boot
[10:47] <pedronis> if it's the other way around right, things are more messed up than I thought
[10:48] <ijohnson> mvo: actually I found a flight this morning so I'm at the airport waiting for my flight (hence being up at 4 am)... Hopefully the trip is fine it's currently snowing and we're supposed to get like 10 cm+ of snow this morning
[10:49] <mvo> ijohnson: uh! good luck!
[10:49] <ijohnson> pedronis: it's possible I am wrong about what it's currently doing but the recovery grub seems to be doing the logic to look for a recovery system to boot into
[10:49] <mvo> ijohnson: also - 4am sounds brual
[10:49] <mvo> ijohnson: brutal :)
[10:49] <mvo> ijohnson: was wonder about the early time :)
[10:49] <pedronis> ijohnson: that's exactly what I would expect for seed
[10:50] <pedronis> seed == recovery
[10:50] <ijohnson> pedronis: right that's why I was confused as well
[10:50] <ijohnson> Err wait sorry I misread
[10:51] <pedronis> it looks correct, maybe there is no run mode logic there yet
[10:51] <pedronis> I don't know
[10:51] <pedronis> it's all part of the problem
[10:52] <mvo> I think there is no run mode logic in the recovery grub yet
[10:52] <ijohnson> pedronis: why would the seed recovery system grub need to look for all the other recovery systems? Is that by design that you can switch between recovery systems using grub? I guess that kinda makes sense now thinking about it
[10:52] <ijohnson> mvo: yeah it's a _bit_ early :-)
[10:54] <pedronis> mvo: ah
[10:55] <mvo> pedronis: it's something to discuss with xnox today
[11:26] <zyga> brb, cold, going to make tea
[11:34] <mborzecki> pstolowski: thanks for the comments, updated #7821
[11:34] <mup> PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
[11:34] <mup> PR snapd#7864 closed: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
[11:36] <pstolowski> yw, thanks for the PR!
[11:37] <zyga> re
[11:39] <mup> PR snapd#7870 opened: boot,bootlaoder: setup the snap recovery system bootenv <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7870>
[11:47] <zyga> pstolowski: good catch, mborzecki https://github.com/snapcore/snapd/pull/7821#discussion_r355405488
[11:47] <mup> PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
[12:00] <zyga> sdhd-sascha: https://github.com/snapcore/snapd/pull/7865#pullrequestreview-328870384
[12:00] <mup> PR #7865: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865>
[12:09] <mborzecki> zyga: already been addressed
[12:09] <zyga> mborzecki: thanks
[12:09] <pstolowski> zyga, pedronis did you want jdstrand_ 's review on https://github.com/snapcore/snapd/pull/7830 or can it land?
[12:09] <mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
[12:10] <zyga> not really but I think it's short and would be good to keep him in the loop
[12:11] <pstolowski> zyga: sure
[12:19] <sdhd-sascha> zyga: just started a new build on my repo
[12:19] <zyga> sdhd-sascha: you don't need to use repo builds you know
[12:19] <sdhd-sascha> zyga: could you see, this build from me ? : https://travis-ci.org/sd-hd/snapd/builds/621989511
[12:19] <zyga> there are faster ways to iterate
[12:19] <zyga> you can just use spread on a local system
[12:19] <sdhd-sascha> zyga: kitchen was on my plan
[12:19] <sdhd-sascha> zyga: kitchen is local travis
[12:20] <sdhd-sascha> zyga: the build above, from weekend. has this patch and only debian sid is failed. all others are green
[12:21] <mup> PR snapd#7850 closed: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Simple 😃> <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7850>
[12:23] <pedronis> zyga: any blockers to merge #7228 ?
[12:23] <mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
[12:23] <zyga> pedronis: checking
[12:25] <sdhd-sascha> zyga: i do more tests, i will report
[12:26] <zyga> pedronis: I think it's good
[12:27] <mup> PR snapd#7871 opened: tests: add spread test for hook permissions <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871>
[12:28] <mup> PR snapd#7228 closed: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7228>
[12:33] <vidal72[m]> zyga: this possibly will be in linux 5.6 https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=work.openat2&id=b767b87044c4b15c4f222daf6948a7a43f802f7e
[12:33] <zyga> yeah, I noticed on twitter yesterday
[12:33] <zyga> along with the new mount APIs it's great to see those
[12:34] <zyga> I don't have a clear vision of how to adopt such new APIs in snapd
[12:34] <zyga> as we will likely support the old APIs for foreseeable future
[12:41] <pedronis> zyga: I pushed something to #7768, let me know whether it is what you expected
[12:41] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[12:41] <zyga> looking
[12:43] <zyga> pedronis: looks great, thanks
[12:45] <pedronis> zyga: I am a bit confused by https://github.com/snapcore/snapd/pull/7768/files#r355413333, that's a go regexp, not something we feed apparmor
[12:45] <mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
[12:45] <zyga> oh, did I misunderstand that
[12:45] <zyga> uff
[12:45] <zyga> sorry
[12:46] <zyga> I didn't notice that
[12:46] <zyga> I just noticed composition and was worried
[12:46] <zyga> commented
[12:47] <pedronis> given that hotplug is for follow up (and we don't have an immediate use case), I think it can land if it gets green
[12:47] <zyga> I agree
[12:47] <zyga> hotplug is should be more careful, it's not as easy as uio as it is fairly dynamic in nature
[12:48] <zyga> and covers a wide variety of cases
[12:48] <zyga> but I think it's a natural case to attempt
[13:04]  * zyga small break
[13:08]  * Chipaca lunch
[13:10] <mup> PR snapd#7872 opened: doc: HACKING.md change autopkgtest-trusty-amd64.img name <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7872>
[13:11] <sdhd-sascha> Can anybody stop my Travis-Build for modifying "HACKING.md" ?
[13:19] <pedronis> pstolowski: what's the status of this: https://bugs.launchpad.net/snapd/+bug/1849564
[13:20] <mup> Bug #1849564: snap connections doesn't work as expected when interface attributes change <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1849564>
[13:30] <pedronis> mvo: zyga: I think we have finally fixed this: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 ?
[13:31] <mup> Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141>
[13:32] <pedronis> mvo: I suppose this should be closed somehow at this point: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1739494
[13:32] <mup> Bug #1739494: snapd <IP_ADDRESS> is not installable on powerpc <regression-update> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1739494>
[13:34] <mvo> pedronis: totally
[13:41] <pstolowski> pedronis: it's probably another case of  https://bugs.launchpad.net/bugs/1848516 (as suggested in the report) but i'd need to double check if it's fixed too. note that in the bug report the plug name was changed, that's why it's the same problem (i think). if it was just attributes change, then i think we would hit the (known) problem of stale attributes on refresh that we only fixed for content interface
[13:41] <mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:Fix Committed by stolowski> <https://launchpad.net/bugs/1848516>
[13:51] <mup> PR snapd#7873 opened: image: set recovery system label when creating the image <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7873>
[14:12] <pedronis> mvo: is it won't fix or fix released?
[14:30] <stgraber> mvo: how are things going with getting 2.42.5 rolled out?
[14:37] <mvo> stgraber: looking good, we are waiting for the cert team right now to give us a +1 for moving to candidate, cachio  has the details on where we stand here
[14:38] <jdstrand_> pedronis: please don't land 7768 yet. some of the changes that went in I want to change
[14:39] <pedronis> jdstrand: you'll have to tell me more
[14:39] <pedronis> jdstrand: which of the changes?
[14:39] <pedronis> jdstrand: the test changes or the path changes
[14:40] <jdstrand> pedronis: in ijohnson's comment, there needed to be a change, but not to rip out the mmc and vda1
[14:40] <pedronis> jdstrand: they aren't used
[14:40] <jdstrand> pedronis: I know. that is what needed to change, to use them, not to remove them
[14:40] <pedronis> jdstrand: the code doesn't care where the slot come from
[14:40] <pedronis> so not sure what difference it would make
[14:41] <pedronis> jdstrand: I mean, I follow up sounds ok, I don't think anything fondumental is untested at this point
[14:41] <jdstrand> I picked those 3 paths specifically so make sure it worked in the normal case, the requested mmc case and the i2o case
[14:42] <jdstrand> the tests aren't done yet so I'd like to add it back
[14:42] <jdstrand> plus, I don't understand the s#vda1#vda1/# change
[14:43] <jdstrand> I only am just looking at it, but I want to understand why that was changed before committing
[14:43] <pedronis> jdstrand: that tests the Clean
[14:43] <pedronis> it wasn't tested
[14:43] <pedronis> and zyga asked about it
[14:44] <pedronis> we are actually likely missing tests about that for other interfaces that also have a Clean fwiw
[14:47] <pedronis> jdstrand: anyway I don't see any fundamental blockers, but of course more testing is alway appreciated
[14:48] <jdstrand> pedronis: now I'm rethinking that clean is there at all. the regex is very precise
[14:48] <jdstrand> that clean should be there*
[14:48] <pedronis> jdstrand: as I said to zyga all the other interfaces like this one do that
[14:48] <pedronis> the Clean
[14:48] <pedronis> so it would be incosistent not to have it at this point
[14:49] <pedronis> jdstrand: see serial-port or spi
[14:49] <pedronis> etc
[14:49] <pedronis> I don't know what it was decided to do it that way
[14:49] <pedronis> s/what/why/
[14:50] <jdstrand> pedronis: yeah, but maybe that is wrong. why would we allow /dev/././././vda1////////
[14:50] <pedronis> jdstrand: we cannot simply change it, you would need to start with warning in review-tools
[14:50] <pedronis> for the old ones
[14:50] <jdstrand> pedronis: well, I'm talking about this one
[14:51] <pedronis> it's a well defined process, clean and then check
[14:51] <pedronis> and consistency is important
[14:51] <jdstrand> but consitently wrong?
[14:51] <pedronis> I didn't make the initial decision
[14:52] <jdstrand> it is not a bad pattern in general
[14:52] <jdstrand> just conceptually
[14:52] <jdstrand> but seeing /dev/vda1/ - that is not what we want to allow
[14:52] <pedronis> jdstrand: but we do allow it
[14:52] <jdstrand> there are things, like i2o, that are a subdir
[14:52] <jdstrand> /dev/i2o/
[14:53] <pedronis> that's the code you wrote
[14:53] <pedronis> I just refactored it
[14:53] <jdstrand> pedronis: yes, and I am rethinking that after seeing the test for /dev/vda1/
[14:54] <pedronis> jdstrand: ok, but then you need to give a list of other interfaces you think we ideally should remove the Clean
[14:54] <jdstrand> of course, /dev/i2o/ going to /dev/i2o doesn't match the regex, but still
[14:54] <pedronis> because is everywhere atm
[14:54] <pedronis> which is probably why you also put it in the first place
[14:55] <jdstrand> it is, I copied an existing over as a template
[14:55] <Chipaca> nice 500s from the forum
[14:55] <pedronis> jdstrand: what I'm saying, you either convince me it's exactly a problem only for the new one, or which it is, and  a path forward
[14:55] <jdstrand> pedronis: we should've been doing if path != filepath.Clean(path) err
[14:56] <pedronis> just changing it for this one feels arbitrary
[14:56] <jdstrand> well, bugs happen. sometimes you only notice after a while
[14:56] <jdstrand> I just noticed this
[14:57] <jdstrand> I'm not sure consistency is a reason to add another one
[14:57] <pedronis> that's ok, but we still need a path forward for everything
[14:57] <pedronis> also because otherwise we'll get there again
[14:58] <pedronis> jdstrand: 1 thing doing it one way, and 5 another is not a pattern
[14:59] <jdstrand> pedronis: I'm not saying that none of them can or can't change, but my point of 5 historical and everything else going forward as correct is a pattern. the 5 historical can be documented in the code
[14:59] <Chipaca> what's the problem with 'path != filepath.Clean(path)'?
[15:00] <pedronis> Chipaca: that all the previous interfaces don't do that
[15:00] <jdstrand> Chipaca: the potential issue is that we might break existing snaps
[15:00] <Chipaca> ah
[15:00] <Chipaca> k
[15:00] <jdstrand> (if we change the existing ones)
[15:00] <pedronis> Chipaca: we cannot just change it for old interfaces
[15:00] <pedronis> without going to some review-tools long warning phase
[15:00] <pedronis> or something
[15:01] <jdstrand> fyi, common files uses if p != np {
[15:02] <jdstrand> so does content
[15:03] <jdstrand> bool does not
[15:03] <zyga> re
[15:04] <jdstrand> neither does hidraw, i2c, iio, serial-port or spi
[15:04] <pedronis> to be clear this has path, so the closest are the ones useing a path attribute
[15:04] <zyga> jdstrand: did snapd solve p != np?
[15:04] <zyga> ;D
[15:05] <zyga> I'll grab lunch and be back
[15:05] <zyga> do I need to read the backlog?
[15:05] <jdstrand> so, content, personal-files and system-files use !=, and bool, hidraw, i2c, iip, serial-port and spi just feed the cleaned path through the regex
[15:07] <pedronis> jdstrand: as I said from attribute used (path), this belong to the latter set
[15:08] <jdstrand> the first three don't have an attribute named 'path'
[15:10] <pedronis> jdstrand: which 3 ?
[15:11] <jdstrand> pedronis: now that I've seen it. I'm uncomfortable adding this to raw-volume. I disagree we should for consistency. I see your point about content, personal-files and system-files (ie, the first three) not having a "path" attribute, but they are effectively the same an imo should be considered
[15:12] <jdstrand> pedronis: I don't see how to move existing over in a very acceptable manner. it is your prerogative to say no to me
[15:13] <jdstrand> pedronis: what I could do is fix raw-volume and then add to all the others a code comment explaining that the pattern is historical
[15:13] <jdstrand> pedronis: that is probably the best I can do barring a long drawn out migration
[15:14] <pedronis> jdstrand: ok, we probably want to think how to change those but is not trivial
[15:14] <pedronis> they have been like that since a long time
[15:15] <jdstrand> yeah
[15:18] <jdstrand> pedronis: I'm not sure where we stand. I think you said fix raw-volume to use != (and while you didn't say it, I'll do a followup pr to add a code comment to the others and a test verifying the current behavior). if that isn't what you meant, please let me know what you want
[15:19] <pedronis> jdstrand: what I would prefer is also that we make the path function a helper in utils, so there's a chance that we can use it again for similar new cases
[15:20] <pedronis> jdstrand: also probably all the comments in the old code needs to point to raw-volume and or this helper
[15:20] <jdstrand> pedronis: something like where the api is pathHelper(path, regex) (name tbd)?
[15:21] <pedronis> well it can take the slot etc
[15:21] <pedronis> but whatever works
[15:21] <pedronis> jdstrand: look at the helper as it exist now
[15:21] <jdstrand> pedronis: gotcha. ok, I'll do that in a followup PR
[15:30]  * zyga -> afk
[15:31] <ijohnson> pedronis: jdstrand: could you do the store check thing to see a full listing of all the paths that folks are using for these slots? If nobody's using a non-clean path then you could make the change more safely
[15:36] <jdstrand> ijohnson: that is true
[15:37] <jdstrand> ijohnson: btw, did you solve the rofs issue?
[15:37] <ijohnson> Well haven't tested solving it yet, but the first thing I did was patch containerd to always put containers under a specified label if an env var is set
[15:38] <jdstrand> pedronis: btw, when 2.43 goes to candidate, we need to do the final round of pulseaudio grandfathering. we could do a round now(ish) to get a jump start on it
[15:38] <ijohnson> jdstrand: But I also got strace of the mounts that containerd does and the mount ns of the containerd and I can't see why the rootfs would be ro
[15:38] <jdstrand> pedronis: what you gave me last time is sufficient for my needs
[15:39] <pedronis> jdstrand: ok
[15:40] <jdstrand> ijohnson: weird. it occurred to me that perhaps temporarily an overlayfs could be used to workaround it. that wouldn't be a long term fix of course
[15:40] <sborovkov> Hey guys, I am trying to build snap with QtWebEngine for rpi eglfs. So it builds fine. Qt apps work. But when trying to run apps that actually use webengine I am getting a crash in webengine process (failed to execvp...). When running with LD_DEBUG I get this - /snap/screenly-client/x40/bin/screenly-client: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal)
[15:40] <sborovkov> any idea what that can be realted with? I am building latest Qt, using system libs as dependencies
[15:40] <jdstrand> pedronis: just whenever you have a chance. if you don't have a chance until candidate, that is ok too
[15:41] <pedronis> jdstrand: yea, we'll see, I'm also not sure when we'll branch 2.43
[15:43] <ijohnson> jdstrand: If you have a little bit of time maybe you could look at https://pastebin.canonical.com/p/yh8M7G6qpk/ and https://www.irccloud.com/pastebin/IhtxTEjG/
[15:44] <ijohnson> I can't see anything obvious there about why the rootfs in the container would be read-only
[15:44] <ijohnson> Note that in the strace log, there are multiple containers being created and we really only care about the last one
[15:46]  * cachio lunch
[15:59] <jdstrand> ijohnson: sorry, someone asked me something. line 369 of https://pastebin.canonical.com/p/yh8M7G6qpk/
[16:01]  * zyga back from lunch, hacking more
[16:01] <jdstrand> ijohnson: that is doing what I thought it might be. it isn't necessarily an issue, but a pivot_root did happen before
[16:02] <ijohnson> jdstrand: no worries, so that mount call is making "/" which at this point is an overlayfs mount, a slave mount, but that shouldn't make it read-only right?
[16:02] <ijohnson> jdstrand: yeah I don't think pivot_root is as big of a deal as I thought it was
[16:03] <ijohnson> Because apparently our dockerd patches don't even prevent docker from doing pivot_root anymore and it still works because it runs inside a different apparmor label
[16:03] <mborzecki> sdhd-sascha: left a comment https://github.com/snapcore/snapd/pull/7845#issuecomment-563306248 imo there's an opportunity to fix in in systemd upstream too
[16:03] <mup> PR #7845: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Simple 😃> <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845>
[16:03] <ijohnson> s/it runs/the container runs/
[16:04] <jdstrand> ijohnson: no, but doesn't line 285 look weird? what is going on with lowerdir?
[16:05] <ijohnson> jdstrand: what's weird about that overlayfs lowerdir? It just has multiple lower dirs which last I checked is perfectly valid and well supported
[16:06] <zyga> ijohnson, jdstrand: what are you chasing?
[16:06] <ijohnson> zyga: the dream
[16:06] <zyga> don't we all? :)
[16:06] <ijohnson> (of kubernetes as a snap working nicely)
[16:06] <ijohnson> :-)
[16:07] <ijohnson> Maybe zyga you could take a look at the links I posted a bit above in the backlog, essentially the issue is that a container is started and it has "/" as read-only which is weird because it should have its own "/" built from overlayfs mounts
[16:08] <zyga> looking
[16:09] <sdhd-sascha> mborzecki: is there a bug in systemd too ?
[16:09] <ijohnson> zyga: note to only look at the last set of mounts, etc. Because the first few are unrelated containers
[16:09] <mborzecki> sdhd-sascha: hm not a bug really, they don't have that path in sytemd.pc
[16:09] <cmatsuoka> cachio: is this something you're aware of? https://api.travis-ci.org/v3/job/622591349/log.txt
[16:10] <sdhd-sascha> mborzecki: ah, ok. i could do that ?
[16:11] <jdstrand> ijohnson: ok, I haven't seen that before but see in https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt that it is supported.
[16:11] <zyga> ijohnson: stat -f /var/snap/kubernetes-worker/common/containerd/var/lib/io.containerd.snapshotter.v1.overlayfs/snapshots/91/fs
[16:12] <zyga> jdstrand: yeah, that's the thing I mentioned in Vancouver :/
[16:12] <zyga> just many lowerdirs
[16:12] <ijohnson> zyga: issue is that this is an ephemeral container that is launched immediately and dies before we can really do anything
[16:12] <zyga> ok
[16:13] <zyga> ijohnson: so what's the symptom, that / is read-only?
[16:13] <ijohnson> zyga: yes / is read-only is the symptom
[16:13] <zyga> ijohnson: how is this determined?
[16:13] <zyga> ijohnson: can I reproduce this?
[16:14] <cachio> cmatsuoka, thanks for the report, I'll ake a look
[16:14] <ijohnson> well not easily reproducible locally due to many levels of $CONTAINER_TECHNOLOGIES and $CLOUD_TECHNOLOGIES
[16:14] <cachio> cmatsuoka, this test has been updated recently
[16:15] <zyga> ijohnson: I don't see why it would be read only otherwise
[16:15] <ijohnson> zyga: the container in it's entry point tries to create `/host/dir`
[16:15] <zyga> aha
[16:15] <zyga> and you get EROFS?
[16:15] <ijohnson> Yes
[16:15] <zyga> do you get a write error or a specific errno?
[16:15] <ijohnson> Uhh I don't have the specific error in front of me
[16:15] <zyga> ijohnson: I can help but I would love to get my hands on this
[16:15] <ijohnson> joedborg: are you around? Do you have the specific error when you get that read only issue?
[16:16] <zyga> ijohnson: otherwise it looks like it's not true, something is read only for real
[16:16] <zyga> the mountinfo dump, where is that from
[16:16] <zyga> from the container?
[16:16] <joedborg> ijohnson: i'm here
[16:16] <zyga> can we get a shell at the moment that mountinfo was collected?
[16:16] <joedborg> ijohnson: which did you want?
[16:17] <ijohnson> joedborg: can you pastebin the error you see when launching the container with the AWS script?
[16:17] <joedborg> ijohnson: sure
[16:17] <ijohnson> zyga: kinda it's tough because the container pops up for very short amount of time then exits
[16:17] <jdstrand> what is going on with line 173: [pid  3012] mount("/", "/", 0xc0001c60a0, MS_RDONLY|MS_REMOUNT|MS_BIND|MS_REC, NULL) = 0
[16:18] <zyga> ijohnson: how do you get that shell trace then?
[16:18] <ijohnson> zyga: so to get that mountinfo we had an `nsenter -all -t $(until pgrep install-aws.sh)`
[16:18] <zyga> ijohnson: looks like it makes the bind mount read only without remounting the filesystem
[16:18] <zyga> er
[16:18] <zyga> jdstrand: ^
[16:18] <ijohnson> (sorry can only type so fast on a plane from my phone :-) )
[16:18] <zyga> and recursively so, though I'm not quite sure that is really respected in the kernel
[16:18] <zyga> ijohnson: oh
[16:18] <zyga> ijohnson: man, you're good :D
[16:19] <jdstrand> zyga: I more meant, hey, ijohnson, does this look like it is doing the right thing?
[16:19] <zyga> I see
[16:19]  * ijohnson thinks
[16:19] <zyga> jdstrand: but note that the 1st line of mountinfo shows it is writable, both the filesystem and the mount point - you can see "rw" there twice
[16:19] <ijohnson> jdstrand: I saw that too I think it's a red herring
[16:20] <ijohnson> There are multiple containers run and the first one is just a bug checking container for the kernel I think
[16:20] <jdstrand> ijohnson: so, I bet you could get some of the info zyga wants by using a container that works (ie, one that doesn't try to create /host/..., run a shell, and then try to touch /host/foo or something to see if you get the same error
[16:20] <ijohnson> I think containerd creates a dummy container on startup to see if it has to work around kernel bugs or not
[16:20] <zyga> jdstrand: that's a good idea
[16:21] <ijohnson> well yes that would be good but is complicated due to $CLOUD_TECHNOLOGIES and $CONTAINER_TECHNOLOGIES
[16:21] <ijohnson> Essentially we don't know the full config of the container being created so we could reproduce
[16:22] <joedborg> https://www.irccloud.com/pastebin/dna5cAMu/
[16:22] <joedborg> ijohnson: zyga: ^
[16:22] <ijohnson> If we did yes it would be easy to reproduce but for example a simple container created with the cli tool ctr for containerd doesn't use anywhere near the same config as this cloud provider does
[16:23] <jdstrand> ijohnson: well, I know that joedborg was able to get some containers to run with what is available today. I'm just saying, maybe shell into one of those pods and see if the /host issue exists there too. if it does, perhaps it is the same issue was are seeing with eks
[16:23] <zyga> joedborg: that's EROFS allright
[16:23] <zyga> joedborg: how hard would it be to run some custom shell script instead?
[16:23] <jdstrand> ijohnson: that would at least rule in if it is eks only or if it is a generic issue
[16:24] <joedborg> zyga: it’s pretty easy to open a shell, just not within that container as that comes straight from Amazon.  Can it be a new container and be useful?
[16:24] <zyga> yeah
[16:24] <zyga> anything that is similar enough to reproduce the problem
[16:24] <zyga> I'm mainly interested in:
[16:25] <jdstrand> joedborg: that is the question. it is probably useful if we can reproduce the same rofs error in that container
[16:25] <zyga> joedborg: /proc/self/mountinfo from the point of view of the failure
[16:25] <jdstrand> s/same/same type of/
[16:25] <zyga> joedborg: stat -f /
[16:25] <zyga> joedborg: along with any logs from the host that may contain relevant stuff
[16:26] <zyga> jdstrand: it would be quite evil to craft a seccomp profile that returns EROFS instead of EPERM ;)
[16:26] <ijohnson> I'm about to land so I'll be AFK for a bit but yeah if we can get a similarly configured container shell that would be helpful
[16:26] <zyga> ijohnson: safe travel
[16:26] <jdstrand> hah, it would
[16:26] <zyga> I'll be around for a while
[16:26] <zyga> if I'm gone just leave me a message please
[16:31] <joedborg> now working on getting a shell
[16:32] <zyga> thank you
[16:36] <joedborg> the issue is, because it's the networking pod that's failing, interacting with the cluster is a pain
[16:37] <zyga> joedborg: are you racing with the container failure?
[16:37] <zyga> joedborg: is this .... (winks) pod racing? :D
[16:38] <joedborg> zyga: hahahaha, there are as many crashes
[16:57] <ijohnson> Hahaha yes this is exactly pod racing, this demo is just like Anakin's racer :-)
[16:58] <ogra> two thin strings holding it all together ?
[16:58] <mup> PR snapcraft#2825 closed: remote-build: remove need to specify user <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2825>
[17:18] <joedborg> zyga: ijohnson: jdstrand: just wondering if any of you could take a look over this https://pastebin.canonical.com/p/yxh2bnq6ms/, can anyone see if the URI specified at the end is inside a pivot root?  I don't think it is, but I think the Permission Denied is related to what we're seeing
[17:18] <zyga> looking
[17:19] <zyga> joedborg: is this from snap run --strace?
[17:19] <zyga> joedborg: if so _all_ of is it after snap-induced pivot
[17:20] <joedborg> zyga: thanks!  yep, i'm running ctr within the snap
[17:20] <joedborg> zyga: when i say within, i mean via
[17:20] <zyga> how do you mean?
[17:20]  * ijohnson looks
[17:20] <zyga> pivot affects everything in the mount namespace
[17:20] <zyga> all paths are affected
[17:21] <zyga> I see some permission failures on epoll
[17:22] <joedborg> zyga: from what i understand, this socket is meant to be opened to transport the tty, but it's failing to so I can't get a shell
[17:22] <ijohnson> zyga, epoll EPERM is expected I think IIRC
[17:22] <zyga> joedborg: on the host do you see any denials?
[17:22] <zyga> joedborg: to answer your question, yes this is "inside" a pivot root
[17:23] <ijohnson> joedborg: do you have all interfaces connected
[17:23] <zyga> the permission denial needs to be overcome first
[17:23] <zyga> there are ways to do that
[17:23] <zyga> connect existing interfaces
[17:23] <zyga> or switch the entire profile to complain mode
[17:23] <joedborg> ijohnson: yeah i do this time :)
[17:23] <joedborg> zyga: there aren't any denails
[17:23] <joedborg> *denials
[17:23] <zyga> are you running this as root? perhaps those are DAC failures
[17:24] <joedborg> zyga: i am yeah
[17:27] <jdstrand> 'abstract unix socket'
[17:27] <zyga> dog
[17:27] <zyga> doh
[17:27] <jdstrand> that won't be affected by pivot_root, assuming the error is accurate
[17:27] <zyga> I didn't notice that
[17:27] <zyga> yeah
[17:27] <joedborg> jdstrand: yeah it is /not/ documented well
[17:27] <zyga> jdstrand: sharp eyes!
[17:27] <joedborg> so i have no idea where it's meant to be written
[17:27] <mup> PR snapd#7874 opened: seed: support ModeSnaps(mode) for mode != "run" <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7874>
[17:28] <joedborg> jdstrand: zyga: ijohnson: I've got to run to an appointment, i'll have patchy comms, but will try to answer anything
[17:29] <jdstrand> joedborg: the policy doesn't allow that path
[17:29] <jdstrand> we have:
[17:29] <jdstrand> unix (bind,listen) type=stream<EMAIL_ADDRESS>[17:29] <jdstrand> unix (bind,listen) type=stream<EMAIL_ADDRESS>[17:29] <jdstrand> we need unix (bind,listen) type=stream<EMAIL_ADDRESS>[17:29] <zyga> jdstrand: it's interesting that joedborg said there are no denials on the host
[17:29] <joedborg> jdstrand: i think it used to be the case, but now has changed
[17:29] <jdstrand> joedborg: did you disable kernel rate limiting?
[17:29] <joedborg> zyga: that might be because i have a custom snapd
[17:30] <joedborg> jdstrand: yeah
[17:30] <jdstrand> joedborg: I suggest while trying to get this up and running to stay on a particular tag/commit/something for containerd
[17:31] <joedborg> jdstrand: ah i meant between when that policy was written for docker and now, i have always stayed on 1 commiut
[17:31] <jdstrand> joedborg: can you add to /var/lib/snapd/apparmor/profiles/snap.kubernetes-worker.containerd the above rule?
[17:31] <jdstrand> joedborg: and reload the policy with apparmor_parser -r /var/lib/... and then restart containerd and see if you get farther?
[17:32] <joedborg> jdstrand: ah that works for getting a containerd shell
[17:32] <joedborg> thanks
[17:32] <jdstrand> cool
[17:33] <jdstrand> joedborg: i've made a note of that
[17:34] <joedborg> jdstrand: thanks!
[17:36]  * zyga EODs
[17:36] <joedborg> okay, so this shell allows me to mkdir /host and write to it, so it's either an issue specifically via k8s or the aws container image
[17:37] <joedborg> thanks for your help zyga
[17:37] <zyga> good luck
[17:38] <ijohnson> joedborg: so with that rule you still have issues with the eks container image?
[17:39] <jdstrand> joedborg: that is useful. you said "it's either an issue specifically via k8s or the aws container image". is the shell you just used not via k8s (ie, the MVP from last cycle)?
[17:40] <joedborg> jdstrand: no so i can't get a shell via k8s atm because this aws container that won't start controlls the netwroking in and out of the node
[17:40] <joedborg> jdstrand: with out own control plane, it works fine
[17:41] <jdstrand> joedborg: is this a regression from the mvp, this never worked or this wasn't tested before?
[17:41] <joedborg> jdstrand: it's an aws specific thing
[17:42] <jdstrand> joedborg: ok, so we've seen it work with OTHER_CONTROL_PLANE_TECHNOLOGY
[17:42] <jdstrand> ijohnson: ;)
[17:42] <zyga> haha
[17:42] <joedborg> jdstrand: we have, but this issue will surface with any workload that doesn't conform with standard unix root directories
[17:43] <joedborg> jdstrand: i agree they shouldn't do this, but people like to use /myapp when in containers
[17:43] <ijohnson> jdstrand: :-) if only we weren't going to try and demo this with $SPECIFIC_CONTROL_PLANE vendor
[17:43] <zyga> we can whitelist any number of /myapp variants ;)
[17:43] <jdstrand> joedborg: sure, I'm just trying to understand if this is a regression or not
[17:43] <zyga> maybe they get bored eventualyl
[17:44]  * zyga really EODs
[17:44] <zyga> good luck
[17:44] <joedborg> guys, really sorry, i have to run for this appointment (normally i wouldn't, but it's not rescheduable)
[17:44] <jdstrand> ijohnson: you are interested in understanding if the added unix rule allows for a shell with aws?
[17:44] <ijohnson> joedborg: no problem
[17:45] <jdstrand> joedborg: np. I'll give you a deb with the unix rule
[17:45] <ijohnson> jdstrand: sorry don't quite follow the question, yes I am interested in getting AWS eks to work with the snap
[17:46] <jdstrand> ijohnson: you asked "joedborg: so with that rule you still have issues with the eks container image?" - I was just making sure that question wasn't lost
[17:46] <joedborg> jdstrand: thanks, maybe where it says “default”, “k8s.io” should probably be generic
[17:46] <ijohnson> Oh right yes I did
[17:46] <joedborg> Because that’s just the namespace sep by the container
[17:47] <jdstrand> joedborg: I already did that
[17:47] <jdstrand> joedborg: thinkikng the same thing
[17:47] <joedborg> Awesome thanks
[17:52] <jdstrand> joedborg: ok, uploaded a new deb
[18:04] <cmatsuoka> cachio: got this one too:
[18:04] <cmatsuoka> rsync: write failed on "/mnt/user-data/gopath/src/github.com/snapcore/snapd/share/locale/mnw/LC_MESSAGES/snappy.mo": No space left on device (28)
[18:05] <cachio> cmatsuoka, about the previous one I could reproduce the issue, the problem is in another test which is leaving the environment corrupted
[18:06] <cmatsuoka> cachio: ah interesting
[18:06] <cmatsuoka> cachio: do you know how to fix it?
[18:06] <cachio> so you know in which system is happening hte "no space error"?
[18:07] <cmatsuoka> cachio: ubuntu-core-18-64
[18:08] <cmatsuoka> on snap-set-core-config
[18:08] <cachio> cmatsuoka, not yet because for some reason the snap test-snapd-service-watchdog is leaving garbage after it is deleted
[18:08] <cachio> cmatsuoka, I left some links in the stanup doc
[18:08] <cachio> cmatsuoka, https://paste.ubuntu.com/p/FgV9nr9rDg/
[18:09] <cachio> so then when we run the test snap-set-core-config it fails
[18:09] <cachio> but is it because systemd is degraded
[18:09] <cachio> cmatsuoka, and if I run the snap-set-core-config in a loop it works perfect
[18:10] <cachio> so I presume there is some test which is executed before and it is causing this
[18:10] <cachio> cmatsuoka, I am now trying to see which is that test
[18:16] <mup> PR snapd#7875 opened: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
[18:39] <mup> PR snapd#7876 opened: seed: fix seed location of local but asserted snaps <:birthday:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7876>
[19:06]  * cachio afk
[20:15] <mup> PR snapd#7848 closed: cmd/snap-bootstrap: mount ubuntu-data tmpfs, in one go with kernel & base <UC20> <Created by xnox> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7848>
[20:19] <cmatsuoka> cachio: that test is passing now, did you do anything?
[20:24] <cachio> cmatsuoka, no, it dependes on the tests order
[20:25] <cachio> the problem is on the test ubuntu-core-gadget-config-defaults
[20:25] <cachio> it is leaving a wrong systemd state
[20:25] <cachio> I am testing a fix for this
[20:25] <cmatsuoka> cachio: ah nice, thank you
[20:26] <cachio> cmatsuoka, thanks for showing me the issue


[07:44] <vila> hi all !
[07:58] <jelmer> yo vila
[07:58] <vila> jelmer: hey !
[08:03] <poolie> hi all
[08:07] <jelmer> hi poolie
[08:09] <mgz> morning all
[08:09] <vila> mgz: hey
[08:10] <poolie> hi mgz, jelmer
[08:10] <poolie> :)
[09:28] <vila> mgz, jelmer: 'bzr st' says 'bzrlib/locale' is unknown, any idea where it's coming from ?
[09:28] <mgz> the build
[09:28] <mgz> it should probably be added to ignores
[09:29] <mgz> mo files get put in there
[09:29] <mgz> (otherwise it's a pain to test locale stuff in place)
[09:29] <vila> ooooh, and a full test suite run triggers a build...
[09:30] <vila> bad isolation :-/
[09:30] <vila> ok, thks
[09:30] <vila> yeah, probably worth adding it to .bzrignore
[09:30] <mgz> hm, yeah, selftest really shouldn't build mo files in place
[09:30] <jelmer> mo files mo problems
[09:31] <vila> LOL
[09:51] <vila> jelmer: in other words: config options are good to test command-line parameters before making them official, I'm far from convinced that --overwrite-tags should be an official cmdline parameter (which is totally different from being convinced that *right* now (including 2.5) we *need* a way to overwrite tags)
[09:52] <mgz> vila: do you have any idea why doing -Olaunchpd_username= isn't enough to revert from bzr+ssh to http?
[09:52] <mgz> also, is there a way of unsetting a value, rather than using an empty string?
[09:52] <fullermd> launchpd?
[09:53] <mgz> ...irc tyop only
[09:53] <fullermd> Oh, right, I missed that you were talking to vila.  Yeah, gotta keep it in his dialect  ;p
[09:54] <vila> mgz: the missing 'a' is a typo right ?
[09:54] <vila> mgz: ha ! authentication.conf ! lp-login creates a section there :-/
[09:55] <vila> crap, read the log before replying vila...
[09:56] <mgz> aha, and authentication.conf is still a special case.
[09:58] <jelmer> vila: I disagree, if we add a configuration option for something before making it official then that means that we have to update all format implementations twice, plus all of the skew that comes with API changes
[10:02] <vila> jelmer: meh, your're assuming it will become official...
[10:02] <jelmer> vila: you did :)
[10:02] <jelmer> 10:51 < vila> jelmer: in other words: config options are good to test command-line parameters before making them official,
[10:03] <vila> test doesn't imply success
[10:03] <jelmer> what do you want to test in that case?
[10:04] <vila> that pull and push are the right place to add the parameter for example which is not obvious 'bzr tags' or something along the way to versioned tags may well be better suited
[10:05] <vila> ghaa, miss punctuation
[10:05] <vila> that pull and push are the right place to add the parameter for example ; which is not obvious. 'bzr tags', or something along the way to versioned tags, may well be better suited
[10:06] <vila> if push and pull is not appropriate your arguments about API skew will then apply to the removal
[10:06]  * fullermd finds the whole discussion a little bizarre...
[10:07] <vila> fullermd: see https://code.launchpad.net/~jelmer/bzr/overwrite-tags/+merge/91277 and https://code.launchpad.net/~jelmer/bzr/overwrite-tags/+merge/94551
[10:07] <jelmer> vila: I really don't see why this would need be tested in that way
[10:07] <jelmer> vila: if you think pull and push are inappropriate for this option, then I think it's fair to bring that up during review
[10:08] <jelmer> vila: I don't see why this is something we would want to test and then perhaps later revert, or why 'bzr tags' might be more appropriate
[10:08] <vila> without a better definition of versioned tags, I can't
[10:08] <fullermd> Oh, I've seen the discussion.  It just seems wacky.
[10:08] <jelmer> fullermd: what's wacky about it?
[10:09] <vila> since there is a way to bring in the feature *without* adding a parameter that may be removed later, I prefer the less intrusive path which address the issue now and leave us room to decide later
[10:09] <fullermd> The whole idea of using the "config option" tool for the "vary how the command works this one time I invoke it" job leaves me wanting a drink.
[10:09] <jelmer> vila: I don't see why the configuration option leaves us more room to remove it later.
[10:10] <vila> removing the cmdline param
[10:10] <jelmer> vila: what about removing the cmdline param?
[10:10] <jelmer> removing the cmdline parameter and configuration option both break backwards compatibility.
[10:11] <vila> not adding the cmdline param means we won't have to remove it
[10:12] <jelmer> vila: but then we'll have to remove the configuration option
[10:12] <jelmer> Using a configuration option is just a slightly implicit way of passing the information along from the command-line to the underlying code
[10:13] <vila> which is less intrusive, opt-in and less work overall than a cmdline param in term of support down the road
[10:13] <jelmer> vila: how is it any less intrusive *or* opt-in?
[10:14] <jelmer> in both cases the backends will need to be updated to support the new functionality
[10:14] <vila> but not the front-ends
[10:14] <jelmer> the frontend change is trivial, and without it it is really hard to discover this functionality
[10:16] <vila> you may consider it trivial but its fallouts are not
[10:16] <jelmer> which fallouts?
[10:17] <vila> If we have --overwrite-tags, I can argue that during pull in a dirty wt, I also want an option that will overwrite my local changes if they conflict with the versions I'm pulling
[10:17] <vila> there is no end to that
[10:18] <vila> --overwrite-tags is a work-around for lack of versioned tags, can we agree on that ?
[10:18] <jelmer> vila: partially, overwrite tags makes perfect sense with versioned tags too
[10:19] <jelmer> vila: I don't see how a working tree is relevant here, tags are associated with branches
[10:19] <vila> if you go that route, --take-other on bzr pull also makes perfect sense, where do you draw the line ?
[10:20] <vila> the working tree analogy is relevant in the context of versioned tags where bzr provides a way to resolve tag conflicts
[10:20] <vila> --overwrite-tags is a simplification, I may well cherry pick which tags I want to override
[10:20] <jelmer> vila: so is --overwrite, which currently *already* overwrites tags
[10:22] <fullermd> That whole really sounds like a perfect-enemy-of-the-good sort of argument.
[10:22] <fullermd> Pull is already a bit of a mess of confused branch-vs-wt actions.  This sorta continues in that vein and doesn't really make it better.  But I'm not sure that it really makes it _worse_.
[10:22] <vila> jelmer: no, --overwrite will works the same with versioned tags, it resets the branch tip
[10:23] <jelmer> vila: it would also reset the tags, I hope
[10:24] <vila> jelmer: me too
[10:24] <jelmer> vila: so I don't see why it's so odd to also allow people to *just* overwrite the tags, not the branch tip
[10:25] <vila> because it's only one out of several choices which only make it more obvious that the UI is broken until we have versioned tags
[10:26]  * quicksilver wonders if jelmer recommends any *particular* drink for working with bzr config options.
[10:26] <vila> so rather than adding one option now and another (or several later), I'd rather say: look, we know we have an issue there, this option will address the most obvious shortcoming *until* we have a more complete solution
[10:27] <jelmer> vila: by that reasoning, we should have never added the current unversioned tags in the first place
[10:27] <vila> no
[10:27] <vila> :)
[10:28] <vila> tags are they exist today address valid uses cases
[10:28] <jelmer> vila: This still brings us down to the same basic question: how is a configuration option less permanent than a command-line option?
[10:28] <vila> because we can say so :)
[10:29] <jelmer> vila: We can do so with a command-line option too.
[10:29] <jelmer> quicksilver: :)
[10:29] <vila> it doesn't carry the same weight
[10:30] <jelmer> vila: Why not?
[10:30] <vila> and doesn't have to be tighted to a particular command
[10:31] <vila> if you call it tags.overwrite for example it can be used by both pull and push today and by tags tomorrow and will better reflect the feature itself rather than the command behavior
[10:32] <jelmer> vila: I don't see how you would want to use this with 'bzr tags' tomorrow, even with versioned tags. Why does that matter if people are going to specify this on the command-line to push and pull?
[10:33] <vila> jelmer: bzr tags or whatever command we add to deal with versioned tags
[10:34] <jelmer> vila: why does that even matter? It will still require code changes to the backends *and* it will require users to change their use of bzr, both with a command-line option and with a configuration option.
[10:35] <jelmer> I'm sorry, this whole point just seems surreal to me.
[10:36] <vila> we're running into circles if you keep ignoring my objection about adding a parameter to commands which shouldn't have to handle tags in the first place :-/
[10:37] <vila> the distinction seems pretty clear to me: an option makes it clearer that we working around an issue, it feels dirty to add official parameters for each and every workaround
[10:37] <vila> whatever is needed for the front-ends, the backends should be updated to address the issue, split that part and the issue is addressed
[10:37] <mgz> vila: tags are clearly a special case, and pull isn't drowning in switches
[10:38] <vila> mgz: good, let's not start then
[10:38] <mgz> in many ways I think a config option is worse
[10:38] <mgz> this is likely to be something most people will only want to do on occasion
[10:38] <mgz> whereas encouraging them to turn it on all the time without thinking is likely to lead to mistakes
[10:39] <vila> hold on, where did I encourage anyone to turn it on all the time ?
[10:39] <fullermd> In the term 'config option'.
[10:40] <mgz> by suggesting a config option rather than a switch, that's the direction we're poking people in
[10:40] <vila> .. which doesn't say anything about the default value :)
[10:40] <fullermd> It may functionally be a distinction without a difference, but it's still conceptually a distinction.
[10:40] <mgz> it's an encounter problem once, set config option, forget you did it, kind of scenario
[10:40] <mgz> whereas with a switch you need to pass it every time you want the different effect
[10:41] <vila> -O is not persistent and should be the recommended use
[10:41] <vila> mgz: this perfectly applies to -O
[10:42] <mgz> we have this even with https cert optionss where we suggest -O in errors but people are unsuprisingly setting the option globally
[10:42] <vila> the distinction I make between the cmdline param and the option is that the cmdline param says: we will support it for this cmd, whereas the option is more blurry about being tighted to the cmd or not
[10:43] <vila> mgz: that's yet another bug (already filed) that we don't provide a way to set it on a per-host basis, different use case
[10:43] <jelmer> vila: a configuration option should apply to all things where it is relevant
[10:44] <vila> jelmer: exactly, that doesn't mean the set of things can't evolve
[10:45] <jelmer> vila: the point is, 'bzr pull' and 'bzr push' already deal with tags. my branch isn't changing anything about that, it just gives users a bit more control over how tags are handled.
[10:45] <mgz> I think --overwrite-tags is the right thing for now, and it's not that hard to deprecate switches if we completely change how tags work in the future, especially one that basically becomes a noop
[10:46] <vila> and that's my objection: we don't know yet whether it will always apply to push/pull and we already know it doesn't really fit well there, it's the only reasonable place today
[10:46] <jelmer> vila: sure, but how is a configuration option better in that regard?
[10:47] <vila> read above
[10:47] <mgz> my objection is the reverse, the mp is too worried about how things may change, rather than just fixing the tags problem :)
[10:48] <jelmer> vila: if we remove tag dealing from bzr pull then whether users use 'bzr pull -Otags.overwrite=true' or 'bzr pull --overwrite-tags', we'll have to break backwards compatibility.
[10:50] <vila> jelmer: and it will be less work for an option than for a cmdline param, that's the point
[10:50] <vila> well, one point
[10:50] <vila> the other being that we won't have added an option fully knowing it wasn't the right place for it
[10:50] <jelmer> vila: we probably don't want to silently ignore that option but print some sort of warning; I'm not sure if a configuration option is easier in that regard
[10:51] <vila> grr a cmdline param not an option
[10:51] <jelmer> vila: either way, it shouldn't really be a big difference either way
[10:51] <jelmer> s/either way//
[10:51] <mgz> vila: but you also would want a -Ooverwrite=true config option? That's asking people to make mistakes.
[10:51] <mgz> this isn't a configy thing.
[10:52] <vila> mgz: no, --overwrite makes perfect sense for a branch
[10:52] <vila> there were discussions when tags were introduced with concerns about leaks, this is one more leak
[10:54] <vila> people are already sometimes confused because you can pull (or even push locally) into a dirty tree, this will add to the confusion
[10:54] <jelmer> vila: pull and push *already* deal with tags, this doesn't make it any worse, it just gives users more control.
[10:55] <vila> using an option recognizes that we know this is a workaround
[10:55] <mgz> I'm with fullermd, I don't really thing it makes the current status worse
[10:58] <vila> well, obviously we're not making progress and we can't reach a consensus, to me, this means there is something wrong. I don't see what I can add to clarify further :-/
[11:00] <fullermd> That generally means we're all pointing at somewhat different things as being The Problem.
[11:02] <fullermd> There _are_ various differences in the implications of removing command line options vs. config options.  I don't think they're particularly relevant though (partly because I just don't see how removal gets on the forseeable horizon anyway).
[11:06] <fullermd> But I'm outside the circle that really gets a say in it, and I've got a meeting in ~9 hours I really should get some sleep before, so...
[11:07] <vila> fullermd: enjoy your sleep !
[11:07] <jelmer> fullermd: Thanks for trying to help resolve it
[11:07] <jelmer> We indeed don't seem to be making much headway
[11:08] <vila> fullermd: you have a say in it
[12:01] <jml> if I want to fetch a get a local tree for a particular revision of a remote branch, what's the fastest way to do that? checkout? export?
[12:03] <jelmer> jml: it should be export
[19:18] <mgrandi> hi, wondering if anyone could answer a question about bzr-git for me :
[19:30] <jelmer> mgrandi: sure
[19:31] <mgrandi> so, you probably remember i was pushing a bzr branch to github
[19:31] <mgrandi> when i branched it originally, it had some git commits, then i made some in bzr
[19:31] <mgrandi> and those commits had bzr revision ids
[19:31] <mgrandi> and then when i pushed to github, those were replaced with the git-v1:<sha> revision ids
[19:32] <mgrandi> i was just wondering if the bzr ones were saved somewhere or they revision ids just changed when you start pushing to a git repo?
[19:34] <jelmer> mgrandi: the original revisions are still in the repository, just no longer in the branch
[19:34] <mgrandi> so the branch essentially just has two sets of revisions, the bzr ones and the git ones?
[19:34] <mgrandi> err repo*
[19:34] <jelmer> mgrandi: the new revisions are created by fetching the changes that were pushed into git back into bzr
[19:35] <jelmer> mgrandi: the bzr ones are no longer used after 'bzr dpush'
[19:35] <jelmer> mgrandi: you can keepusing the bzr revisions in your local branch by using 'bzr dpush --no-rebase'
[19:35] <jelmer> but if you do that, your local branch and the remote git branch will have diverged
[19:35] <mgrandi> ah ok
[19:36] <mgrandi> so this way you are theoretically the same as the git branch, albiet being in bzr
[19:36] <jelmer> mgrandi: yes - and using 'bzr dpush' will discard all information that can not be represented in git
[19:36] <mgrandi> it will discard it in the local branch as well?
[19:37] <jelmer> mgrandi: unless you specify --no-rebase
[19:38] <mgrandi> ok. is it necessarily a bad thing if you use --no-rebase ? will it still show up as one branch on the git side or will it show as merges from another branch sorta
[19:38] <jelmer> mgrandi: if you use --no-rebase then your local branch will diverge from the remote git branch
[19:38] <jelmer> because the revisions have different contents and different revision ids
[19:38] <mgrandi> yeah, but all i'm doing is really just mirroring my changes on github
[19:39] <mgrandi> and pushing to github occasionally
[19:39] <mgrandi> so in that case it wouldn't really matter if my local branch diverged since i'm working in bzr mostly
[19:39] <jelmer> in that case 'bzr dpush --no-rebase' should probably work sufficiently well
[19:39] <mgrandi> ok. cool =)
[19:39] <jelmer> mgrandi: but you'd have trouble pulling in changes from people who base their work on your git branch
[19:39] <mgrandi> keyword "probably" =P
[19:40] <mgrandi> ah.
[19:40] <jelmer> mgrandi: at some point bzr-git will support 'bzr push' itself and just store bzr metadata in git revisions for things that can't be natively represented in git
[19:40] <mgrandi> in that case i'll just leave it be. what sort of things cannot be represented in git, just curiously?
[19:40] <mgrandi> ah thats cool!
[19:41] <mgrandi> would it be stored as a file or something or does git have a metadata thing
[19:41] <jelmer> mgrandi: revision ids, file ids, revision properties, ghost revisions
[19:41] <jelmer> it would be stored as a magic file and in git notes
[19:41] <mgrandi> magic file as in just a file that only bzr uses?
[19:42] <jelmer> yeah
[19:42] <mgrandi> thats cool =) thanks, i was just curious
[19:42] <mgrandi> and something to keep in mind if i ever care about the revision ids
[19:44] <jelmer> mgrandi: well, you care about the revision ids if you e.g. want to use 'bzr dpush --no-rebase' and merge in contributions from people using git :)
[19:44] <mgrandi> yeah
[19:44] <mgrandi> cause then it gets all confused im assuming
[19:45] <jelmer> mgrandi: well, not really confused; they are in fact different revisions :)
[19:45] <mgrandi> yeah, which would make merging harder then it should be
[19:46] <mgrandi> so i'll just leave it without the --no-rebase thing for now in case i ever need to merge something back in it
[20:00] <mgrandi> also, i'm intereted in perhaps participating in the GSoC thing, even if i don't actually 'offically' participate in it, but it would be cool to work on something
[20:00] <mgrandi> i dunno if anyone decided on what stuff to do for it, although i saw people on the list were talking about netbeans support, which i assume is a java ide, and i know java fairly well
[20:10] <jelmer> mgrandi: there is a page with GSoC ideas
[20:10] <jelmer> let me find the link
[20:11] <mgrandi> (although i feel an eclipse plugin might be better, since many things use eclipse, android, flashbuiler, eclipse itself, etc)
[20:11] <jelmer> mgrandi: http://wiki.bazaar.canonical.com/SummerOfCode2012
[20:11] <jelmer> mgrandi: I think we would be happy to mentor you, whether as part of SoC or outside of it
[20:12] <mgrandi> yeah.
[20:12] <mgrandi> quick question, what in bzr uses CPython?
[20:12] <mgrandi> re the 'porting bzr to python 3'
[20:13] <jelmer> mgrandi: apparently bzr works reasonably well in pypy, LarstiQ should know the details
[20:13] <mgrandi> well i mean
[20:14] <mgrandi> bzr is written in python, so i dont see why it was saying good knowledge of cpython is needed unless there are C excentions or something
[20:15] <mgrandi> unless its referring to porting bzr to pypy or something, not just making it work with python3
[20:16] <jelmer> mgrandi: well, there are a bunch of implementation details in Python3 you have to know about to do the porting
[20:16] <jelmer> especially regarding character encoding handling
[20:16] <mgrandi> true
[20:16] <mgrandi> thats always fun
[20:31] <LarstiQ> note that while pypy has 3.x support in the works it currently implements python 2.7 api
[20:31] <LarstiQ> so working in pypy doesn't help with working in python 3
[20:32] <LarstiQ> imo the two paragraphs under "Alternative Python implementations" are unrelated
[20:32] <mgrandi> yeah
[20:32] <mgrandi> thats what confused me xD
[20:34] <LarstiQ> mgrandi: there are, afaik, two eclipse plugins
[20:34] <mgrandi> last i heard they didn't work too well
[20:35]  * LarstiQ nods
[20:36] <LarstiQ> not that I'm an eclipse user, but that is indeed my impression
[20:38] <mgrandi> might be good to start with. although eclipse is a beast within itself haha
[22:48] <thomi> Hi. I have a bzrlib Branch object, a relative path within that branch, and some line numbers, and I'd like to work out who wrote those lines (essentially like annotate, but only for certain lines in a file).
[22:49] <thomi> it looks like I need a VersionedFile object from a branch, but I can't see any easy way to get one. Any hints?
[22:51] <spiv> thomi: you should be able to resolve the path to a versionedfile via branch.repository
[22:51] <spiv> Although I forget the exact method
[22:52] <thomi> spiv: ok, thanks. I'll poke around :)
[22:52] <spiv> But basically it's the branch's repository that actually holds all the records about the history
[22:53] <spiv> (You may need the current revision ID, branch.last_revision(), to pass to whatever repo API you need)
[22:53] <spiv> I'd start by looking at how annotate works :)
[22:55] <thomi> cheers
[23:30] <thomi> spiv: I'm so close to having this working - the problem I have now is that bzrlib.annotate.annotate_file_tree calls _print_annotations, but I just want to get the annotation information...
[23:31] <thomi> I could reimplement annotate_file_tree in my code I guess..
[23:44] <spiv> thomi: yeah, the core of it is just a call to branch.repository.texts.annotate((file_id, file_rev_id))
[23:45] <spiv> thomi: (as you might have already found, file_rev_id might not be branch.last_revision(), you need to consult the branch.repository.inventory to map your file path to the file_id,rev_id pair to use)
[23:46] <thomi> yeah.
[23:46] <spiv> Er, not quite literally branch.repository.inventory, but you know what I mean I think :)
[23:46] <thomi> I hadn't seen the repo.texts thing, i was trying to do it some other way
[23:47] <spiv> (I'm getting rusty at bzrlib clearly!)
[23:47] <thomi> yep


[09:11] <fossfreedom> freakyy: what is different between 16.10 and 17.04?
[09:19] <fossfreedom> jbicha: just looking at network-manager captive portals (this issue that was raised on the budgie-desktop tracker)
[09:19] <fossfreedom> I don
[09:20] <fossfreedom> I don't see /usr/lib/NetworkManager/conf.d/20-connectivity.conf or a similar file in Ubuntu GNOME - does UG handle captive portals in another way?
[12:57] <jbicha> fossfreedom: it's a proposed feature, see https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039696.html
[13:42] <fossfreedom> jbicha: ah - its an excellent idea! Subscribed to the bug report - yes would like also to add this as a recommended package - I presume to a flavours meta package.
[13:55] <jbicha> I'm guessing all that would do for Budgie now is change the icon to a question mark, which is still useful
[13:55] <jbicha> (I only tested on GNOME)


[01:29] <ApOgEE> Hi
[01:32] <ApOgEE> I got spam email today, but it seems like the sender is from (seviper.canonical.com. [<IP_ADDRESS>]). to whom should i speak regarding this issue?
[01:33] <sarnold> ApOgEE: forward the thing, with full headers, to<EMAIL_ADDRESS>with a quick explanation
[01:50] <ApOgEE> okay sarnold , thanks
[02:44] <Eickmeyer> ApOgEE: Do you have a reason for staying in this channel, or is your business done for now?
[02:44] <Eickmeyer> (lurking is not allowed here)
[06:55] <ApOgEE> Eickmeyer: thank you