/srv/irclogs.ubuntu.com/2017/09/06/#snappy.txt

mupPR snapd#3857 opened: tests: fix lxd test for external backend  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3857>03:46
* Son_Goku grumbles05:13
Son_Gokusomehow, I just woke up at 1am :(05:13
Son_Gokuso... morning, I guess05:13
=== JoshStrobl|Work is now known as JoshStrobl|zzz
mvomwhudson: hey, thanks for helping with the ppc64el link error. do you know if there is any workaround?05:41
mvomwhudson: this is a blocker for 2.28 currently and I wonder what options there are05:41
mvomwhudson: nevermind, I think I found a workaround06:32
mupPR snapd#3858 opened: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/pull/3858>06:39
zyga-ubuntuo/06:49
Son_Gokumeep06:52
Son_Gokuyou know, I *really* don't like how go does compiler flags06:54
Son_Gokuit's a really dumb way to do things06:54
mvogood morning Son_Goku (not actually morning for you I guess ;)06:55
mupPR snapd#3841 closed: Do not emit cloud-init.disabled; cloud-init only runs if datasource is present <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3841>06:55
mvoand good morning to you zyga-ubuntu06:55
Son_Goku[01:12:33 AM] Son_Gokugrumbles06:55
Son_Goku[01:12:40 AM]  <Son_Goku>somehow, I just woke up at 1am :(06:55
Son_Goku[01:12:53 AM]  <Son_Goku>so... morning, I guess06:55
Son_Goku:/06:55
Son_Gokuthis is what I get for going to sleep at 8:30pm06:56
mvoSon_Goku: autsch!06:57
mvoSon_Goku: that is going to be a coffee fueled day then :)06:57
Son_GokuI was feeling pretty bad yesterday, so I took some Advil (headache medicine) and went to sleep06:57
Son_Gokumuch earlier than I usually do06:57
Son_Gokuyeah, I might wind up drinking coffee today06:57
Son_GokuI usually don't...06:57
=== chihchun_afk is now known as chihchun
mvoSon_Goku: aha, yeah. hope you make it well through the day, I get cranky when I did not sleep enough07:00
Son_Gokuwell, my work day begins in 6 hours07:00
Son_Gokuat which point, I'm going to be tired as hell07:00
mvoyeah :)07:00
mvozyga-ubuntu: some easy reviews tagged with 2.28 *hint* ;)07:00
Son_Gokumvo, not having pie across the board for snapd 2.28 kind of sucks, though07:01
mvoSon_Goku: its just for two small helpers07:02
Son_Gokusnapd is made up of "small helpers" :P07:02
mvoSon_Goku: and if you have !go1.7 you can simply reomove it07:02
Son_GokuI wonder if this is even broken on Fedora 25 for ppc64le07:02
Son_Gokuwe have go 1.7 there too07:02
mvoSon_Goku: 2.28 probably is, 2.27 had a slightly different cflags/ldflags iirc for snap-seccomp07:03
zyga-susegood morning :)07:04
Son_Gokuhmm07:04
zyga-susemvo: I'll have a look07:04
Son_Goku1.7.4 ~ 1.7.607:04
Son_GokuI guess there's only one way to find out...07:04
* Son_Goku logs into Fedora ppc64le test machines07:06
zyga-ubuntumvo: please check out https://github.com/snapcore/snapd/pull/3854#pullrequestreview-6081859407:07
mupPR #3854: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3854>07:07
zyga-ubuntumvo: I need a re-review from jamie on https://github.com/snapcore/snapd/pull/3621 and I need to fix one opensuse packaing quirk (still fighting natively) and with merged master it should go green07:07
mupPR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>07:07
zyga-ubuntumvo: but since it is tagged for 2.28, could you please have a look?07:08
zyga-ubuntumvo: note that we must wait for jdstrand's review for the child profile07:08
zyga-ubuntumvo: so if you want to release earlier, please drop it from the release07:08
mvozyga-ubuntu: I dropped it, I am happy to review but unfortunately it missed the 2.28 cycle07:10
mvozyga-ubuntu: I replied to 362107:10
Son_Gokumvo, I'm running through a test build of current master on Fedora 25 ppc64le07:12
Son_Gokuwhich has golang 1.7.607:12
mvoSon_Goku: nice07:12
Son_Gokuman... ppc64le is slow07:20
zyga-suseok07:21
zyga-suseSon_Goku: it has to be, there is only one machine on the whole planet, everything else is virtualzed and over-committed ;-)07:21
Son_Gokuhaha07:21
Son_Gokuyou're probably not far off from the truth07:22
Son_Gokuat least I'm not debugging arm crap07:22
Son_GokuI hate doing that07:22
Son_Gokuarm SoCs are even slower07:22
* zyga-suse just had a brilliant business idea07:23
* Son_Goku shoots the light bulb over zyga-suse's head07:24
zyga-susein some future where everything is running on one big machine, to sustain old business models we will still pay for traffic from A to B even though A is B,07:24
Son_Gokuoh god07:24
Son_GokuI didn't shoot it fast enough07:24
zyga-susemaybe we need a payasyougo.ko to track this07:25
Son_Gokuoh god damnit07:25
Son_Gokusomeone switched the import path for cheggaaa/pb07:25
zyga-suseyeah, it got switched to the canonical path07:26
* Son_Goku groans07:26
Son_Gokuzyga-suse, file a bug against the fedora cheggaaa/pb package07:27
Son_Gokuit needs the gopkg.in import path supported07:27
zyga-suseok, what should the bug report say?07:28
zyga-susejust "please support the canonical import path via gopkg.in"?07:28
Son_Gokuyeah07:29
zyga-susehmm, I seem to have plenty of stale kernels07:29
zyga-suseSon_Goku: ok, let me try to report that07:30
Son_Gokudescribe what the new import path is, and why we need it added (snapd 2.28 requires it)07:30
zyga-suseok07:30
zyga-suseSon_Goku: for rawhide?07:35
Son_Gokumark the fedora release as rawhide, but ask for it to be added for all releases the package is provided for in the bug report07:36
zyga-suseok07:37
Son_Gokupoor Jan07:37
Son_Gokuhe just updated cheggaaa/pb, too07:37
pedronismvo: hi, thanks for the review of the overlord.Mock PR07:37
Son_Gokumvo: snapd git master compiles just fine today with Fedora 25 golang 1.7.607:39
zyga-suseSon_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=148874707:40
Son_GokuI'm surprised Fedora tests haven't started failing07:41
Son_Gokuor maybe they have and no one said anything07:41
Son_Gokuif that's the case, why bother having the tests... :(07:42
pedronismvo: #3727 seems to have a real unit tests issue now, probably related to some recent merge to master07:43
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>07:43
Son_Gokuoh geez07:45
Son_Gokuit worked somehow07:45
Son_Gokuoh, no07:46
Son_Gokulet me guess07:46
Son_Gokuzyga-suse: are we giving a vendorized tarball to the snapd build in Fedora?07:46
zyga-suseI don't think we do07:46
zyga-suse(especially because that progress bar package was older in fedora and had UI corrputions)07:46
zyga-suse*corruptions07:46
zyga-suseand this was fixed in subsequent commits upstream07:47
Son_GokuI mean in spread07:47
zyga-susein spread yes, we do07:47
Son_GokuFUCK07:47
Son_Gokudamn it07:47
Son_Gokuthe damned build tests are useless then07:48
pedronisthat is bound to be always helpful07:48
pedronis*to not be07:48
Son_Gokuokay, then I need to break this07:48
Son_Gokucrap, this means I need to make it so patches apply cleanly with the vendor tarball07:49
Son_Gokuno one notices when builddeps are missing because of the stupid usage of vendor stuff07:49
zyga-suseSon_Goku: indeed, that's a real problem07:50
zyga-suseSon_Goku: our debian build suffers from the same thing07:50
Son_Gokuactually, I can just rm -rf vendor/* in %prep, I suppose07:51
Son_Gokuminus the vendor.json07:51
zyga-suseSon_Goku: I think even with the vendor json, nothing needs that (just don't run get-deps)07:51
mvopedronis: thanks, checking07:51
Son_Gokuzyga-suse: remember that I need to be able to apply patches07:51
Son_Gokuand I'd like to not have to edit patches more than I already have to when backported07:52
Son_Goku*backporting07:52
Son_Gokuit was somewhat annoying to backport userd to 2.27.5, but I did07:52
zyga-susewhat's the experience, does it work?07:52
Son_Gokuyou tell me07:52
Son_Gokuthe updates are sitting in bodhi right now07:53
Son_Gokuwell, koji07:53
Son_Gokufor some reason they haven't made it to updates-testing yet07:53
mvoSon_Goku: hm, zesty has go 1.7.4 wonder if thats related but aiui only 1.8 fixes the issue, I will dig07:53
Son_Gokumvo: https://src.fedoraproject.org/rpms/golang/tree/f2507:54
Son_Gokuthat should help07:54
zyga-suseSon_Goku: how should I remove stale kernels from my fedora box?07:55
Son_Gokudid you change /etc/dnf/dnf.conf for installonlypkgs limit?07:55
Son_Gokuit should be set to 3 by default07:55
zyga-suserebooting07:56
zyga-susesomething broke so I booted into the recovery kernel and updated07:56
zyga-suseand ...07:56
zyga-susethe logo ...07:56
zyga-suseand...07:57
zyga-susethe same07:57
zyga-suseI'll leave it for 5 minutes in case it's some timeut07:57
zyga-susebut it looks broken :/07:57
Son_Goku~_~07:58
Son_Gokuif it's Fedora 26 or newer, then `dnf install dnf-utils; package-cleanup --oldkernels --count=3`07:58
Son_GokuFedora 25 and older will require you to actually do the work yourself :P07:59
zyga-susefedora 2608:00
zyga-susebut broken at boot, let me try recovery again08:00
mupPR snapd#3859 opened: packaging/fedora: Ensure vendor/ is empty for builds <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3859>08:12
Son_Gokuzyga-suse: there ^08:12
Son_Gokuif spread isn't failing after we do this, then there's a problem08:13
davidcallepstolowski: did you remotely access my machine last night? Because it's working now o_o08:14
mvodavidcalle: maybe he did (automatic snap refresh maybe?)08:14
davidcallemvo:  doesn't look like it, I had install hooks failing 100% of the time. On stable core, artful snapd, so no recent changes on this front afaik... Unless another snap was messing with everything08:17
davidcallemvo: anyway, bug seems to be fixed, so...08:17
davidcallepstolowski: just confirmed that the install hook was being called as expected, thanks for the help08:21
* zyga-suse walks daughter to school08:22
pedronisis Chipaca off today?08:28
pstolowskidavidcalle, waaat08:33
pstolowski:)08:33
pstolowskidavidcalle, fyi, I investigated it further yestaerday's evening / this morning.. your state.json didn't show any apparent problem, only confirmed the issue (the error you saw was there). the only *theoretical* explanation I had was that for whatever reason an old version of snap-exec was used (as judging from the error message, snap-exec didn't know about install hooks). but since you didn't disable reexec, I'm clueless...08:36
pstolowskipedronis, hey, are you familiar with CommandManager / cmdstate?08:38
pedronispstolowski: I think I might have reviewed it, what's the question?08:39
pstolowskipedronis, for some reason in a spread test I'm hitting timeout (which is very generous), as if change wasn't set to ready after finished - https://github.com/snapcore/snapd/pull/3852/files#diff-8c0b309b451b46cd7f7dac1f80654270R113  ; this is working fine in unit test where I'm not actually executing command, but mocking it and set change to ready explicitely08:41
mupPR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>08:41
pstolowskipedronis, perhaps there is something about taskrunner / changes that I do not know or misunderstand08:47
zyga-susere08:47
pstolowskibut afaiu it should be set ready automatically when tasks are finished08:47
ogra_zyga-suse, hmm, what changed in snap-confine ? seems a lot of users get "cannot locate the base snap: ubuntu-core: No such file or directory" ... grepping the source i only see this message in snap-confine/mount-support.c08:48
ogra_(there are at least three threads on the forum wherre this seems to be an issue)08:49
zyga-suseogra_: hmmmm08:50
zyga-suseogra_: it's a small patch that landed that lets people use an alternate base snap as an opt-in08:50
ogra_i assume it isnt snap-confine itself but smething hands it "ubuntu-core"08:50
zyga-susemvo: ^08:50
pedronispstolowski: you are keeping the lock in  runServiceCommand, how can anything else run?08:50
zyga-suseogra_: ooh08:50
zyga-suseogra_: ubuntu-core you say08:50
ogra_well, read the error above :)08:50
zyga-suseright, I see now08:51
zyga-susethat is ... curious08:51
ogra_whats even more curious is that some users in these threads show snap list with core 16-2.26.1408:51
pedronispstolowski: I don't what's happenign in your tests but for sure that code doesn't look right08:52
ogra_(though that might just be a rre-exec thing ... running a newer deb version)08:52
pedronispstolowski: I mean all lock mgmt in runServiceCommand seems off08:52
pstolowskipedronis, ahh, thanks08:53
pedronispstolowski: seems you are mocking too much08:53
pedronisbtw08:53
pedronisthat's probably related to why the tests fowkrs08:54
zyga-suseogra_: core 2.26.14 with snapd 2.27.408:55
ogra_yeah08:55
zyga-suseogra_: but that's not possible on debian stable, it must be sid08:55
ogra_because the stable core wasnt updated yet08:55
* zyga-suse booted debian 908:55
zyga-suseogra_: it was, last night AFAIR08:55
ogra_yup08:56
ogra_ogra@anubis:~/datengrab/devel/branches/snapd$ snap info core|grep stable08:56
ogra_  stable:    16-2.27.5                (2774) 85MB -08:56
ogra_i stand corrected08:56
zyga-suseyes08:56
ogra_but that user didnt have it :)08:56
ogra_(refresh can take up to 24h iirc)08:56
ogra_(depending on the timers)08:56
zyga-suseI'm reading https://forum.snapcraft.io/t/castersoundboard-snap-requires-deprecated-ubuntu-core/199908:57
zyga-susehere the user did have 2.27.408:57
ogra_theer is also https://forum.snapcraft.io/t/call-for-testing-warzone-2100/2001/408:57
zyga-suseso that's definitely a debian unstable08:57
ogra_and cjwatson's LXD build announcement08:57
ogra_(and i think i saw it once more but i cant find it)08:57
pedronispstolowski: maybe you want to give a look at #3856 , it might be useful for your tests there08:59
mupPR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>08:59
=== chihchun is now known as chihchun_afk
ogra_zyga-suse, oh ... same thing but different https://forum.snapcraft.io/t/cannot-locate-core-snap-error/88409:00
pedronisChipaca: hi09:03
Chipacapedronis: o/09:03
pstolowskipedronis, ack, thanks.09:03
pedronisChipaca: #3727 and #3856 could use 2nd reviews09:04
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>09:04
mupPR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>09:04
zyga-susemvo: I forsee 2.27.609:05
ogra_yeah :/09:05
Chipacapedronis: ack09:05
Chipacazyga-suse: :'(09:05
Chipacadoes the travis log loading bog down your whole browser, or is my laptopt showing its age?09:07
Chipacaif I wait for it to load it's multiple minutes; even getting to click the static log button takes a few seconds (the static logs load almost instantly)09:08
pedronisit takes kind of forever09:08
=== chihchun_afk is now known as chihchun
zyga-suseChipaca: it's travis + javascript suxxines09:12
Chipacaor maybe our logs are too verbose :-D09:12
pedroniszyga-suse: spread on opensuse seems broken because of an actual issue in the scripts09:12
pedronis+ go install -s -v -p 4 -x macro doesnt allow us to pass any additional parameters '#' so we we have to invoke '`go' 'install`' here manually. export GOPATH=/usr/src/packages/BUILD/go:/usr/lib64/go/contrib export GOBIN=/usr/src/packages/BUILD/go/bin '#' Options used are the same as the /usr/lib/rpm/golang.sh build macro does but as it '#' doesnt allow us to amend new flags we have to repeat them github.com/snapcore/snapd/09:12
pedronishere:09:12
ogra_Chipaca, use lynx :P09:12
pedroniscan't load package: package macro: cannot find package "macro" in any of:09:12
zyga-susepedronis: where? can you give me a link to the failure please?09:13
pedroniszyga-suse: here for example: https://travis-ci.org/snapcore/snapd/builds/272361316?utm_source=github_status&utm_medium=notification09:13
* zyga-suse looks09:13
pedronisseems like a comment ends up as data09:13
zyga-susepedronis: I'm debugging something similar right now, it's the %gobuild macro that is really both go build and go install09:14
zyga-susepedronis: I'm looking for a solution09:14
zyga-susepedronis: (note that this only affects opensuse)09:14
pedronishow did it make to master?09:14
zyga-susepedronis: how was this merged09:15
zyga-susepedronis: good question, my branch that is affected has not landed yet09:15
zyga-susepedronis: I'll check this out soon, looking at debian sid and possible regression09:15
pedroniszyga-suse: mvo: master is broken like this :(09:15
pedronishow was it merged?09:16
pedronisor something has changed in suse itself?09:16
zyga-susepedronis: nothing like that would change inside leap09:17
pedroniswell master is red and broken09:18
zyga-susesure09:18
zyga-suseI think it may be a commented-out macro09:18
zyga-susemacros cannot be commented out09:18
zyga-susebecause of how rpm works09:18
* zyga-suse looks quickly09:18
pedronissomething doesn't compute here09:18
pedronisI how did it land either way?09:19
zyga-suseogra_: interestingly, snapd in sid is not reexecing09:19
zyga-susepedronis: no idea09:19
ogra_oh09:19
pedroniszyga-suse:  there's a comment like  this   in the spec:     # The %gobuild macro09:21
pedronisI suppose it gets interpreted anyway?09:21
zyga-suseI see09:21
zyga-susethough this didn't fail before09:21
zyga-suseI just removed them, let's make a quick PR09:21
Son_Gokuzyga-suse, I feel like I should leave this broken: https://github.com/snapcore/snapd/pull/385909:22
mupPR #3859: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3859>09:22
zyga-susepedronis: I just made a PR, let's see what happens09:24
mupPR snapd#3860 opened: packaging: don't include any marcos in comments <Created by zyga> <https://github.com/snapcore/snapd/pull/3860>09:24
pedroniszyga-suse: seems definitely something that changed under our feet because those comments are still from Simon09:26
zyga-susepedronis: I'll check changelogs09:27
ogra_huh ?09:32
zyga-suseogra_: I cannot reproduce the issue, I'll report back but I suspect it's something funky on the reporter's machine09:32
ogra_how did 2.28 into beta ?09:32
ogra_*get into09:32
zyga-suseogra_: mvo uploaded it09:32
zyga-suseogra_: after 2.27.5 was stable09:32
mvoogra_: its 2.28~rc1 fwiw09:33
ogra_why ?09:33
ogra_ah,09:33
ogra_it doesnt say -rc109:33
mvothe thing that builds the versions cuts a but too aggressively it seems09:33
ogra_ah09:33
mvozyga-suse: meh, do you have a handle on this issue already?09:35
zyga-ubuntumvo: which of the recent ones?09:36
mvoogra_: probably worth fixing, its slightly annoyying09:36
ogra_yeah, will confuse people09:36
mvozyga-ubuntu: the name where snap-confine stops working for some people, that is rather criticial09:36
zyga-ubuntumvo: not yet, I cannot reproduce it on debian 9 and sid09:36
zyga-ubuntumvo: I asked for more information09:36
mvozyga-ubuntu, pedronis: I would say we disable suse for the moment and deal with the other crisis first, ok?09:37
zyga-ubuntumvo: and I'll check the code, what would trigger this09:37
mvozyga-ubuntu: thanks a bunch - so all reports from debian so far?09:37
zyga-ubuntumvo: technically it looks like snapd passes ubuntu-core as the name of the base snap09:37
zyga-ubuntumvo: I sent a PR that might cure suse, if it fails I'll disable it09:37
zyga-ubuntumvo: there are three reports, one is from debian "9" (but really sid apparently), the rest is unknown for now09:38
mvozyga-ubuntu: ta09:38
mupPR core#55 closed: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core/pull/55>09:39
mvozyga-ubuntu: thanks for the suse fix, interessting bug09:40
zyga-ubuntumvo: not sure if that's really it09:40
pedronismvo: it's rather mysterious09:40
zyga-ubuntumvo: I was building suse package very often and I dind't hit this09:40
mvozyga-ubuntu: it sounds likely09:41
zyga-ubuntumvo: but my packaging is different and I'm on tumbleweed, not leap09:41
mvozyga-ubuntu: yeah, like pedronis said, mysterious why it is happeing just now09:41
zyga-ubuntumvo: I'll check in detail later, the core regression is more serious09:41
mvozyga-ubuntu: +10009:41
pedronisfrom the logs is seems like it's running macros from inside the comments09:41
zyga-ubuntumvo: golang packaging is being changed but I don't think those changes would be backported to leap09:41
zyga-ubuntumvo: maybe I'm just wron09:41
zyga-ubuntu*wrong09:41
zyga-ubuntuI'll sync suse packaging later to see what's not in trunk09:42
mvopedronis: yeah, this is what zyga-ubuntu fixed in his branch09:42
mvozyga-ubuntu: are all reports from the same user?09:53
zyga-susemvo: so far yes09:59
zyga-susemvo: my suspicion is that something odd is going on on his machine09:59
ogra_zyga-suse, well, seems to be sid ...10:00
zyga-suseyes, it must be sid10:01
ogra_(surprise: unstable is unstable :) )10:01
zyga-susebecause it has 2.27.4-110:01
zyga-susemvo: it looks like we append "info.Base"10:01
zyga-susemvo: as base snap name10:02
mvozyga-suse: yes, iirc if info.Base != ""10:04
mvozyga-suse: which seems reasonable, no?10:04
zyga-suseyes10:06
Son_Gokuunless you're re-execing?10:07
Son_Gokuthen it should break due to mismatch10:07
mvozyga-suse: fwiw, I tried with my debian9 install and had no luck reproducing the issue10:12
zyga-susesame10:12
brunch875sep 06 12:11:36 magpie kernel: audit: type=1400 audit(1504692696.878:207): apparmor="DENIED" operation="open" profile="snap.hexchat.hexchat" name="/run/systemd/resolve/stub-resolv.conf" pid=6685 comm="hexchat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=10210:23
brunch875uh oh...10:23
zyga-suseheh, prune failed on ppc again10:59
zyga-suseI bet PPC has even weirder tick/scheduling10:59
mupPR snapd#3861 opened: interfaces: add NETLINK_KOBJECT_UEVENT to kernel-module-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/3861>11:00
zyga-ubuntumvo: hmm, that feels ill-placed for that interface11:01
zyga-ubuntumvo: I wonder if we are just missing an interface for something more specific11:02
zyga-ubuntumvo: or if we should add a quirk system that lets us inject snippets for a specific snap11:02
zyga-ubuntumvo: (ideally via store assertions)11:02
zyga-ubuntumvo: so we could fix people in the wild11:02
mvozyga-ubuntu: yeah, I agree. i asked jdstrand for suggestions11:02
zyga-ubuntu(though I don't think we refresh assertions, do we?)11:02
pedroniscomplexity, schmoplixity11:03
pedroniswe can do a lot of stuff11:03
pedronisdont' know if more moving parts will save us in the end though11:03
mvozyga-ubuntu: we could udisks2 or modem-manager or any of the kobject_uevent interfaes to livepatch11:03
zyga-ubuntumvo: "add" I presume11:03
zyga-ubuntupedronis: I think that for things like this11:04
zyga-ubuntuoh, why did my laptop quit?11:04
zyga-ubuntufor things like this, post-releaes issues wrt security11:04
mvozyga-ubuntu: correct11:04
zyga-ubuntuit would be good to 1) fix existing specific snaps11:04
zyga-ubuntuand 2) create new interfaces and let people upgrade11:04
zyga-ubuntu(people=snap devs)11:04
zyga-ubuntuI think we broke many things when netlink mediation landed11:04
zyga-ubuntubecause we started to reject things previously allowed11:05
zyga-ubuntuand then proceeded to samp the extra permissions in various places11:05
pedronisas I said we can do many things, but complexity is a proiblem in itself11:05
zyga-ubuntupedronis: I don't disagree in any way :)11:05
zyga-ubuntuI think suse download servers are broken now11:05
zyga-ubuntuI see it both at home and on linode11:06
pedroniswe don't even apply any of those kind of changes immediately, atm11:06
pedronisyou need a new revno either way11:06
zyga-ubuntuI see11:06
pedronisI think we need interface hooks done before we add anything more in that area11:10
zyga-susemvo: hey, noob question here: what can I monitor after dputting something to sid?11:21
pedroniszyga-suse: yes, suse servers seems down11:23
pedronis:/11:23
pedronistime to put it to manual until other fires are out I think11:23
pedronisgiven master is broken atm11:23
zyga-suseyes11:25
* zyga-suse pushes branch11:25
zyga-suseFYI: https://status.opensuse.org/11:25
zyga-susepedronis: ah, it seems we both did it11:28
zyga-susebtw, mup seems off/slow11:28
pedronisthat kind of day11:28
mupPR snapd#3862 opened: spread.yaml: turn suse to manual given that it's breaking master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3862>11:28
mupPR snapd#3863 opened: spread: disable openSUSE on linode backend <Created by zyga> <https://github.com/snapcore/snapd/pull/3863>11:28
zyga-susemvo: can you please merge one of the two instantly11:28
Son_Gokuapparently fedoraproject.org DNS in Europe is having problems, too11:29
Son_Goku:)11:29
zyga-susewell11:29
zyga-suseit must be that kind of day then11:29
zyga-susemvo: so are we doing 2.27.6?11:30
pedronislikely11:30
zyga-susemvo: with fixes for canonical-livepatch11:30
pedronisI think we are waiting to discuss what's best with jdstran-d11:30
zyga-susemvo: and whatever may be causing that ubuntu-core back-from-hell11:30
zyga-susemvo: we could do a hack where we never pass ubuntu-core to snap-confine, and just change that to "core"11:30
zyga-susemvo: I'm looking at theories why this could ever happen11:31
zyga-susemvo: hmm, I think I know what may be going on11:34
zyga-susemvo: my bet is that the reporter lost the current symlink11:36
zyga-susepedronis: whatever the outcome it feels like we will have a new release11:36
=== ShalokShalom_ is now known as ShalokShalom
zyga-susemvo: I won though whatever took out /snap/core/current also blew everything else out of the water11:51
zyga-susemvo: I'm worried that it might be some crazy upgrade script that does rm -rf /snap11:52
pedronisyou mean in a classic snap?11:54
pedronisor somebody using such  a script on their system?11:54
zyga-suseI meant the upgrade script in debian (.postinst and such)11:54
pedronisor part of packaging?11:54
zyga-susemaybe there's some bug that causes it to run the prune code11:55
* zyga-suse looks11:55
pedronison ubuntu we just have postrm that rm things only on prune11:58
pedronissorry, on purge11:58
zyga-suseright, but I think there's a delta with debian, looking at that now11:59
pedroniszyga-suse: I merged mine turn off suse given it got green12:07
zyga-suseok12:07
zyga-suseplease close the other12:07
mupPR snapd#3862 closed: spread.yaml: turn suse to manual given that it's breaking master <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3862>12:08
mupPR snapd#3863 closed: spread: disable openSUSE on linode backend <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3863>12:09
zyga-susethank you12:13
zyga-susethe postrm script look sane12:14
zyga-susepedronis, mvo: I wonder if the snap manager should ensure that all snap mount points exist and the units are mounted in its ensure loop12:16
zyga-susehaving something like that would give us a healing system that would fix whatever has affected that particular user12:16
zyga-susesimilarly to how snapd ensures security profiles are correct12:17
pedronismaybe, doesn't sound 2.27+ material12:21
* zyga-suse break 12:22
pedronismvo: #3727 needs a master merge12:29
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>12:29
mvopedronis: sure, doing that now12:30
mvozyga-suse: you should get an accept mail after dputing (sorry for the delay)12:31
zyga-susemvo: no worries12:34
zyga-susemvo: I got the mail (REJECTED, but that's another topic)12:34
zyga-susemvo, pedronis: I think that after we fix what affects canonical-livepatch we *must* teach snapd to start any services that are stopped/broken12:34
zyga-suseas I bet the background service is broken on various running machines now12:34
zyga-suseand while the .6 update will fix it it would only auto-start on the next reboot, defeating the purpose12:35
zyga-suseChipaca: ^12:37
mvozyga-suse: we will update livepatch too (the snap)12:38
ogra_woah12:39
ogra_http://paste.ubuntu.com/25478060/12:39
ogra_do we never clean up when core gets updated ?12:39
zyga-susemvo: that's another solution12:41
* ogra_ wonders when users will start running out of inodes 12:41
zyga-suseogra_: known bug, I think12:42
ogra_ah, k, then i wont file it ... looks shocking nontheless12:42
zyga-susethere's a bug open for hit12:43
zyga-susefor it*12:43
mupPR snapd#3861 closed: interfaces: add NETLINK_KOBJECT_UEVENT to kernel-module-control <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3861>12:44
zyga-susemvo: is there any interface that allows just kobject uevent?12:44
zyga-susemvo: if no let's add it to some netlink-kobject-uevent maybe and then patch the livepatch snap to use it12:45
pedronisI don't think that's the spirit, we don't have interfaces with so low granularity afaict12:46
pedronisanyway seems jdstrand is thinking/looking into this12:47
jdstrandlet's not do that12:47
jdstrandmvo and I have a plan and a workaround for livepatch12:47
mupPR snapd#3864 opened: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>12:49
zyga-susejdstrand: hey12:55
zyga-susejdstrand: what is the plan?12:55
jdstrandthat pr ^12:55
jdstrandzyga-suse: that achieves what you suggested in an existing interface. and that interface is the correct place for the policy12:55
zyga-susejdstrand: thanks12:55
zyga-susemvo: I commented on the PR, would love it if you could revise the commit message12:56
mvozyga-suse: sure12:58
* jdstrand thought the comment was clear (and commented on it)12:58
jdstrandbut whatever you come up with is fine12:58
mvoogra_: are those "just" empty mount points?12:59
ogra_mvo, i think so, let me check12:59
ogra_mvo, confirmed13:00
zyga-ubuntuChipaca, pedronis: standup13:02
Chipacaomw13:02
mupPR snapcraft#1519 closed: lxd: use a unique temporary folder <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1519>13:12
mvoSon_Goku: fwiw, 2.27 has working base snaps, I would love to try this with your fedora work13:20
mvoSon_Goku: aiui you have a fedora base already :)?13:20
Son_Gokuwhat do you mean, working base snaps?13:20
Son_GokuI have a script for making core/base snaps, yes: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap13:20
Son_GokuI stopped working it a while back because I can't test the output13:20
ogra_now you can13:21
ogra_:)13:21
zyga-ubunture13:38
zyga-ubuntuSon_Goku: I can explain13:39
zyga-ubuntuSon_Goku: but yes, we can now try13:39
Son_GokuI'm going to guess that my YAML needs to be different for the base snap13:39
ogra_needs to be base'ic ... (muhahaha)13:41
pstolowskidavidcalle, hey, one more question re your issue and how it disappeared this morning - have you rebooted your box?13:44
davidcallepstolowski: yes, I tend to reboot frequently, yesterday, the day before...13:46
pstolowskizyga-ubuntu, ^13:46
zyga-ubuntupstolowski: so I know what the problem is IMO13:47
zyga-ubuntupstolowski: I can revive a branch that fixes it and we can sit on the bug in apparmor that this exposes13:48
mupPR snapd#3642 closed: cmd/snap: get keys or root document <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3642>13:48
pedronispstolowski: let me know if you want to have a step back chat about Plug/SlotData today or tomorrow ?13:53
cachio_mvo, I see this error https://paste.ubuntu.com/25478387/13:53
cachio_in most of the ubuntu cores13:53
pstolowskipedronis, sure, will let you know, probably tomorrow. thanks13:53
pstolowskizyga-suse, oh, so it goes deepeer13:54
pstolowskizyga-ubuntu, ^13:54
zyga-ubuntupstolowski: it's pretty simple but the fix ran into a bug in the kernel13:54
cachio_I reproduced it13:54
pstolowskizyga-ubuntu, is this about namespaces?13:54
zyga-ubuntupstolowski: the bug is from 201613:54
zyga-ubuntupstolowski: its open on LP13:54
cachio_mvo, but not sure it is a bug or not13:54
Chipacazyga-ubuntu: 2016? psh, amateur :-p13:54
cachio_mvo, it is in the border line13:54
=== jkridner|pd is now known as jkridner
pstolowskizyga-ubuntu, why couldn't I reproduce it? and it was happening to davidcalle every day (till this morning)?13:55
* zyga-ubuntu just had a very interesting question from tech-illiterate friend13:55
zyga-ubuntupstolowski: I'll explain in a sec13:55
zyga-ubuntuquestion was: should I download amd64 or i386 build of ubuntu if I have a celeron procesor, he was going for i386 because his box is not amd13:56
pstolowskii'm glad though it's not a fundamental issue with install hook though13:56
zyga-ubuntuI wonder how many people use 32bit systems because of that13:56
zyga-ubuntupstolowski: so the hook is in the core snap13:56
zyga-ubuntupstolowski: which is the root fs13:56
pstolowskizyga-ubuntu, no, the hook is in a reguar snap13:57
zyga-ubuntupstolowski: to reproduce have two revisions of a snap and two revisions of the core13:57
zyga-ubuntupstolowski: (sorry, I meant snap-exec)13:57
pstolowskiright13:57
zyga-ubuntupstolowski: start on old-core and old-snap and run the snap (or any hook) so that we have a mount namespace13:57
zyga-ubuntupstolowski: now refresh core to new-core (with new hook support in snap-exec) and refresh to new-snap13:57
zyga-ubuntupstolowski: when core changes we don't have a mechanism for refreshing existing mount namespaces13:58
zyga-ubuntupstolowski: the fix, even once my branch lands, won't always refresh it either13:58
zyga-ubuntupstolowski: because we don't do it for valid reasons13:58
zyga-ubuntupstolowski: a simple fix is to run snap-exec via ... and bare with me... /var/lib/snapd/hostfs/snap/core/current/usr/lib/snap-exec13:58
zyga-ubuntupstolowski: because *that* will be always fresh13:58
zyga-ubuntupstolowski: it should be a one liner in snap run and one liner in snap-confine.apparmor.in13:59
zyga-ubuntupstolowski: try writing a case that reproduces this first13:59
zyga-ubuntupstolowski: it's a very interesting bug13:59
zyga-ubuntupstolowski: NOTE: it's sufficient to test a subset13:59
zyga-ubuntupstolowski: stat snap-exec before and after core refresh13:59
zyga-ubuntupstolowski: and if the inode is not changed, we are running the wrong one13:59
zyga-ubuntupstolowski: if you can come up with a full test that would be nice but I think it's not really needed given how hard it is to set this up14:00
zyga-ubuntupstolowski: as long as we run snap-exec via hostfs we're fine14:00
zyga-ubuntupstolowski: one more thing is that new base snap support makes this more complex14:00
zyga-ubuntupstolowski: but I think bases need to have hostfs so the fix is universal14:00
zyga-ubuntupstolowski: that's all14:00
zyga-ubuntumvo: ^14:00
* zyga-ubuntu returns to 14.04 debugging14:01
mvozyga-ubuntu: uh, interessting14:01
pstolowskizyga-ubuntu, wow, that's interesting bug indeed. thanks for explanation! I need to copy it somewhere..14:03
mvoa second review for 3854 would be great (should be trivial)14:09
* zyga-ubuntu looks14:11
Chipacamvo: question: why use mockCommand, instead of mocking SystemctlCmd?14:12
zyga-ubuntuah, I already did14:12
Chipacamvo: another question: why aren't i asking this in the PR?14:12
zyga-ubuntumvo: thank you for the explanation14:12
mupPR snapcraft#1531 opened: Release changelog for 2.34 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1531>14:12
Chipacaah, corecfg14:12
Chipacaah14:12
mvoChipaca: I guess corecfg actually would need some work to do it this way, might not be a bad idea to convert it14:12
* zyga-ubuntu had an idea to have a way for a given module to offer to mock itself out14:13
zyga-ubuntuso that we don't have to know how to mock internal details in tests of something else that just happen to use the public API of that first thing14:13
Chipacamvo: corecfg is already using systemd.SystemctlCmd14:14
Chipacazyga-ubuntu: ^14:14
Chipacait's not doing its own exec14:14
zyga-ubuntuChipaca: sure but there's no way to say <module>.MockEverythingExternal()14:14
zyga-ubuntuChipaca: so if <other> uses <module> it needs to know too much in its tests14:14
zyga-ubuntuideally this would be exposed for tests in the public api but not clutter the real public api14:15
zyga-ubuntuI think that's hard in go14:15
Chipacazyga-ubuntu: so you're saying that knowing the details of the implementation of something, and mocking one of the details, is better than knowing the API that thing exposes and using that in your tests?14:15
pedronisChipaca: mvo: seems to be doing both14:15
Chipacapedronis: where's it calling systemctl itself?14:16
pedronisit's also using  s.coreCfgSuite.SetUpSuite(c)14:16
pedronissorry14:16
zyga-ubuntuChipaca: I no, I'm saying that if I work on A that uses public api of B I should not need to know internal details of B that so that I can mock it out (again: external interactions of B)14:16
zyga-ubuntuChipaca: maybe I'm wrong but I feel it would be nice14:16
pedronisChipaca: I mean the tests are using mocking SystemctlCmd as well14:16
mvoChipaca: aha, interessting, so I mocked the wrong thing14:16
mvoChipaca: thanks, I will  tweak that14:16
Chipacazyga-ubuntu: it sounds like we agree on the premise14:17
pedronisChipaca: I don't if the code is using both, I asked that in the review though14:17
zyga-ubuntuChipaca: +1 :)14:17
* zyga-ubuntu is starving14:17
zyga-ubuntuI'll skip 14.04 debugging and get a meal14:17
Chipacazyga-ubuntu: so based on that, setting SystemctlCmd is the right thing to do, and using MockCommand to replace systemctl, the wrong thing14:17
Chipacazyga-ubuntu: gah! go get food :-)14:17
zyga-ubuntuChipaca: yes14:17
zyga-ubuntuChipaca: though it'd be nice if we could standardize that more14:17
zyga-ubuntuChipaca: <module>.MockIt() or whatever14:18
Chipacazyga-ubuntu: just as soon as we standardize all modules to be <module>.DoIt()14:18
pedronisChipaca: I think zyga-ubuntu as a point here14:19
pedronisChipaca: modern style is   MockFoo(foo) (restore func())14:19
pedronisor at least I hope that was his point14:19
Chipacapedronis: in export_test yes; would we want to make that part of the public api also?14:20
pedroniswe do sometimes14:20
Chipacaah14:20
pedronishaving a global that you can clobber isn't much better14:20
Chipacaoh, agreed, it's not pretty14:21
pedronisChipaca: release.MockOnClassic for example14:21
pedronisetc14:21
Chipacaman, this battery lasts ~10 minutes :-(14:21
pedronisif we need this across packages we do it14:21
pedronisI mean put it in the pkg public api14:21
Chipacapedronis: sounds like an easy PR14:21
pedronisthey all are, they say  (at the beginning) :)14:22
pedronisnot looking to add another cleanup to my current pile14:22
Chipacai'll do it at some point maybe14:23
om26eris there an interface that allows to take a screenshot of the desktop ? (I am not aware of technicalities on what needs read permission under X11 for that)14:24
Chipacaom26er: x11 is probably good enough for that14:25
Chipacaom26er: but it won't work on wayland; i don't think we've got anything that'll work there yet14:25
om26erChipaca: yeah, I am only concerned about X11 for now. Will check if just connecting x11 works.14:26
=== chihchun is now known as chihchun_afk
zyga-ubuntupedronis: that was the point14:27
zyga-ubuntuChipaca: ~10min on your laptop?14:28
Chipacazyga-ubuntu: it's an 8yr old battery14:28
Chipacayes14:28
mvoChipaca: this is about adding "systemd.MockSystemctlCmd()"?14:28
zyga-ubuntuah14:28
pedronisit's good it hasn't exploded or deformed14:28
Chipacamvo: not in that PR14:28
mvoChipaca: I missed most of the earlier discussion14:28
mvoChipaca: it might make sense, should be easy(ish)14:29
Chipacamvo: bottom line for your PR: replace SystemctlCmd everywhere, don't use MockCommand14:29
zyga-ubuntumvo: how about systemd.MockExternalInteractions14:29
zyga-ubuntuMEI14:29
Chipacazyga-ubuntu: not in that PR!14:29
zyga-ubuntuMEIBI14:29
zyga-ubuntuChipaca: fair enough14:29
pedronisExternalInteractions14:29
pedroniswhat are those?14:29
mvoChipaca: yes, that part I got out of it14:29
Chipacamvo: that's all, for your pr14:29
Chipacathe rest is a bigger change that needs more work14:29
zyga-ubuntupedronis: vague stuff including things like running processes14:29
pedronisMockBoundaryCrossingPokings14:29
zyga-ubuntu+114:29
Chipacazyga-ubuntu: pedronis: that would mean providing two functions at least14:30
pedronis?14:30
ChipacaSystemctlCMd and  JournalctlCmd14:30
pedronisChipaca: we mock both with SystemctlCmd now ?14:30
pedronisor are you saying there are two globals?14:31
pedronisI don't care honestly, as long as what one has to do is understanble14:31
pedronisExternalInteraction seems a bit too vague for my taste14:31
Chipacathere are two globals14:31
Chipacapedronis: yes, that was a bit my point14:31
Chipacawe're trying to pretend everything is homogeneousible (?) and it clearly isn't14:32
zyga-ubuntujdstrand: hey, can you please review the changes made to https://github.com/snapcore/snapd/pull/3621 -- I'd like to land it when you give it a +114:33
mupPR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>14:33
zyga-ubuntujdstrand: I wrote the child profile, should be uncontroversial apart from broad/open umount14:35
zyga-ubuntujdstrand: I can tighten that further with more PRs or inside this one, as you prefer14:36
zyga-ubuntujdstrand: but landing this would allow me to propose useful enchancements14:36
mvoChipaca: an alternative would be to simpliy use "testutil.MockCommand("systemctl")" maybe? less elegant I guess14:36
zyga-ubuntumvo: what do you think about my idea to let a module offer to mock its internals out as a public API?14:37
Chipacamvo: i see MockCommand as a last resource; the path fiddling it does is rather racy14:38
mvozyga-ubuntu: yeah, I think that is consistent with other uses we have14:38
mvoChipaca: ok14:39
zyga-ubuntuofftopic, I read how getenv/setenv work and OMG :/14:39
zyga-ubuntuthat's not a nice API14:39
Chipacazyga-ubuntu: hehe14:39
zyga-ubuntunot nice because designed with stupid assumptions eons ago14:39
Chipacazyga-ubuntu: wait, did you look at it in go, or in glibc?14:39
zyga-ubuntubut less setenv we do, the better14:39
zyga-ubuntuin glibc14:39
Chipacazyga-ubuntu: look at it in go sometimes14:39
Chipacasometime*14:39
zyga-ubuntuah, will do14:39
Chipacazyga-ubuntu: that's the source of the raciness i mentioned14:40
zyga-ubuntuChipaca: the glibc one has other issues and I suspect gets called eventually14:40
ChipacaOTOH even setenv is MT-Unsafe14:40
zyga-ubuntuyes14:40
* zyga-ubuntu just checked14:40
zyga-ubuntuwhich probably explains why tests fail when started with -count=100014:41
zyga-ubuntugetenv just borks14:41
zyga-ubuntuand mocked commands don't get used14:41
Chipacayep14:41
Chipacazyga-ubuntu: so, we could work around that14:41
zyga-ubuntuespecially coreconfig tests14:41
zyga-ubuntuyes, I think we ought to14:42
Chipacaby tweaking the path super early14:42
zyga-ubuntudesign it not to fail so easily14:42
Chipacaand having a single test path env14:42
zyga-ubuntuI wish golang had a warning for setenv14:42
zyga-ubuntulike gcc linker scripts have for gets14:43
Chipacazyga-ubuntu: just don't wish too hard14:47
Chipacazyga-ubuntu: look what happened to setuid14:47
zyga-ubuntu /o\14:48
mvocachio_: if you have a moment could you please have a look at spread-cron and in particular the snapd-vendor-sync branch? it seems like its not doing things automatically anymore. it should sync the lp:snapd-vendor branch on each merge to master but we had several merges today and nothing got merged since 21h. I think the last merge happend when I clicked a manual rebuild. maybe the actual cron thing is no longer running?14:59
cachio_mvo, I saw the same and restarted the snap like 30 mins ago15:00
cachio_it should be running again15:00
cachio_snapd-vendor-sync is on the queue to be executed15:01
cachio_mvo, not sure what happened, I'll take a look15:01
cachio_mvo, I am gonna disconnect now15:03
cachio_backing from the vpn15:03
mvocachio_: thank you15:04
mvoChipaca: is http://paste.ubuntu.com/25478666/ what you had in mind for better mocking of the systemctl thing?15:07
Chipacamvo: that looks an awful lot like what pedronis and zyga were suggesting, which I recommended happen in a different PR15:09
Chipacamvo: or is this a different PR15:09
mvopedronis: 3858 should be ready for another look15:09
mvoChipaca: it is a different pr, its nothing at all right now, I was waiting for tests and that seemed to be about the level of mental capacity I had left :/ so if it looks sane(ish) I can turn it into a PR15:10
Chipacamvo: ah ok :)15:10
Chipacamvo: now the same but for journalctl ;-D15:11
mvoChipaca: yeah, much less exposure that one15:12
=== cachio is now known as cachio_lunch
mupPR snapd#3865 opened: many: provide systemd.MockSystemctl() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3865>15:31
=== chihchun_afk is now known as chihchun
pedronismvo: was having a walk,  seems it gets dark earlier and if I wait after dinner for my walk I end up not walking at all15:41
mvopedronis: no worries, thank you15:42
mvopedronis: enjoy the walk!15:42
pedronismvo: I'm back15:42
pedronismvo: #3727 seems mergeable to me15:42
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>15:42
pedronisbut I let you do the honors if you want/need to tweak the commit message15:42
mvopedronis: I think I take a short break now myself, feel free to merge otherwise I will when I'm back15:45
mvopedronis: your 3856 also looks ready for merging (not sure if you want to tweak further but definitely enough +1 :)15:46
jdstrandzyga-ubuntu: this continues to be on my todo list. it is not forgotten. yesterday had a lot of things I had to respond to over the weekend. note I need to review more than the child profile-- I need to do a careful review of the arg parsing (and env, but I expect that part to go fast)15:47
pedronismvo: I wanted to merge #3727 because I expect conflicts/needing some tweaks15:47
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>15:47
jdstrandzyga-ubuntu: it is also extremely high on said list15:47
pedroniswith #385615:47
mupPR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>15:47
jdstrandmvo: fyi, https://github.com/snapcore/snapd/pull/3864/files#r13730943315:50
mupPR #3864: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>15:50
jdstrandmvo: I'd like you to add 'bind' to the seccomp policy. this isn't for livepatch since it gets it elsewhere, but it is so hardware-observe can standalone15:51
mupPR snapd#3727 closed: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3727>15:51
jdstrandmvo: I would've done it in another PR but it looks like you didn't update that one yet, so thought I'd mention it. if you prefer to just merge it as is, that is fine, I'll do a followup PR15:52
mupPR snapd#3847 closed: tests: run the tests/unit/go everywhere <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3847>15:59
niemeyerChipaca: Hey, which release did we get tab-completion fully working again?  Isn't that 2.27?  I probably missed it in the notes16:02
Chipacaniemeyer: what do you mean by "fully working"16:02
niemeyerChipaca: Usable by snaps without any local changes16:02
Chipacaniemeyer: 2.27.2 had snippets, meaning it works without local changes on classic16:03
Chipacaand falls over flat on core16:03
Chipacaniemeyer: 2.27.4 skips creating snippets on core16:03
Chipacaor maybe that's 2.27.516:03
Chipacayeah, .516:03
niemeyerChipaca: Aha, yeah, so it's 2.27 indeed.. I will fix the notes16:03
Chipacabut 2.27 doesn't have it16:04
Chipacathere are features in the .s of 2.2716:04
niemeyerChipaca: Yeah, sorry.. there's a bit of confusion around that.. I've made a mroe general 2.27 announcement since this was really when we've sorted all small blockers and updated the core snap16:05
Chipacaok16:05
=== cachio_lunch is now known as cachio
cachiomvo, about hte base snaps test, do you know why it did not fail on linode but it failed on the external:ubuntu-core?16:10
mupPR snapd#3866 opened: many: implement fetching sections and package names periodically <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>16:36
Chipacait lives!16:36
ogra_hmm16:40
ogra_so in my update-manager snapd is showing up as "Tool to interact with Ubuntu Core Snappy" in the UI16:41
ogra_i wonder if we should change that to something less specific :)16:41
Sir_GallantmonFeel free to steal my summary and description from my package16:53
mvocachio: yes, it failed because on external it uses a snap that was build ~6month ago and on linode it uses our self-build snapbuild16:58
mvojdstrand: if you mention it in the PR I will address it next (adding bind)16:59
jdstrandmvo: I did16:59
cachiomvo, ok16:59
cachiomvo, ok, thanks17:00
mvojdstrand: excellent, thank you17:01
dokohi, please could somebody address https://forum.snapcraft.io/t/snapcraft-autopkgtest-failure/200717:04
* zyga-ubuntu breaks for dinner17:07
zyga-ubuntudoko: hey, good to see you17:08
ogra_finally doko found his way into the proper channels :)17:09
jdstrandmvo: ok, I've looked at this quite a bit. I looked to see what had network netlink rules and udev and all interfacecs that had both are fine (these are all slot implementations)17:25
jdstrandmvo: I then looked at avahi and found that what it is missing is NETLINK_ROUTE, but it gets that with 'network' so no regression in that snap (I'll still fix that interface for comleteness)17:26
jdstrandmvo: I then checked all the interfaces with just a 'network netlink' rule. these were all slots that were heavily checked before and have been verified by CE to work without regressions, so that should be fine17:27
mupPR snapcraft#1532 opened: tests: update the meson test to latest meson requirements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1532>17:27
jdstrandmvo: there were three plugging interfaces with 'network netlink'-- account-control, network-control and network-observe17:28
jdstrandmvo: account-control is correct and doesn't need to be changed17:28
jdstrandmvo: I then looked in the store to see what plugged account-control, network-control or network-observe and found that about half plug neither hardware-observe, x11 or unity7 (ie, things that give NETLINK_KOBJECT_UEVENT)17:30
jdstrandmvo: so I investigated if we should just add NETLINK_KOBJECT_UEVENT to network-control and network-observe, and looking at kernel sources in net/core, I think we should17:30
jdstrandmvo: therefore, I will proactively send up a PR for network-control and network-observe for NETLINK_KOBJECT_UEVENT, even though we have no regression reports on these. this will make it so nothing in the stable channel in the public store will regress on NETLINK_KOBJECT_UEVENT, because everything that could've gotten it for free with bare 'socket' before will get the new rule via an interface that they already plugs17:32
=== JoshStrobl|zzz is now known as JoshStrobl
mvojdstrand: sounds good, I guess we want to also pull this into 2.27.6 then, right?17:38
jdstrandmvo: if you are rolling a 2.27.6, yes17:39
mvojdstrand: I think it makes sense17:39
mvojdstrand: if only for canonical-livepatch - even though we workaround it it feels better to do a proper fix17:39
jdstrandmvo: I'll be sending up the PR for network-control and network-observe in just a bit17:39
mvojdstrand: thank you, I will look at it in my morning17:40
jdstrandmvo: it'll be separate from any other policy work so it is easy to pull in17:40
jdstrandmvo: should I target master, 2.28 and 2.27?17:40
mvojdstrand: we will need it in 2.27 and 2.28 and master :/  but if I can cherry pick it then one PR is enough and I just cherry-pick it17:42
cachiomvo, is it gonna come a new 2.27 today?17:46
cachioa beta one?17:46
cachiomvo, I have physiotherapy now, I can start as soon you have something17:48
=== cachio is now known as cachio_afk
mupPR snapd#3867 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3867>18:23
mupPR snapd#3869 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3869>18:39
mupPR snapd#3870 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.27 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3870>18:42
jdstrandmvo: ok, fyi ^ (3867, 3869 and 3870)18:43
=== chihchun is now known as chihchun_afk
=== cachio_afk is now known as cachio
mupPR snapcraft#1532 closed: tests: update the meson test to latest meson requirements <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1532>19:28
mupPR snapd#3871 opened: tests: fix regex to check core version on snap list <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3871>21:58
mupPR snapcraft#1533 opened: demos: update the name of the remote mqtt part <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1533>23:26
mupPR snapcraft#1534 opened: Fix UnboundLocalError for chmod_path in jhbuild plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1534>23:38

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