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

mupPR snapcraft#1527 closed: repo: Use os-release(5) to detect supported Linux distributions <Created by Conan-Kudo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1527>00:03
=== JoshStrobl|AFK is now known as JoshStrobl
mupPR snapcraft#1518 closed: project: introduce build-snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1518>02:15
=== JoshStrobl is now known as JoshStrobl|zzz
mupPR snapd#3847 opened: tests: run the tests/unit/go everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3847>06:00
zyga-ubuntumvo: hey06:12
zyga-ubuntumvo: no luck with static go + c06:12
zyga-ubuntumvo: I'll iterate shortly, just need to send kids to school06:12
mvohey zyga-ubuntu06:13
mvozyga-ubuntu: ok, good luck06:13
mvofwiw, I enabled an arful-i386 autopkgtest (outcome of the 2.27 cycle retrospect)06:17
mupPR snapd#3839 closed: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3839>06:18
zyga-ubuntumvo: thanks, I had a question at the last stand-up, what happened to our ppc adt tests?07:07
pstolowskimorning07:08
zyga-ubuntuhey pstolowski07:10
zyga-ubunturainy day, eh?07:10
pstolowskiuhm07:10
mvozyga-ubuntu: we only have a ppc64, not powerpc itself07:20
mvozyga-ubuntu: is that what you mean?07:20
zyga-ubuntuaha, I see07:24
zyga-ubuntumvo: I recall you ran into an issue that only affected a weird arch during the last cycle07:25
zyga-ubuntuand I was wondering if we missed or ignored the adt data07:25
zyga-ubuntuor if we simply didn't have any data07:25
zyga-ubuntupstolowski: hey, I looked at your huge branch07:25
zyga-ubuntupstolowski: that was a painful patch to write, I presume07:26
pstolowskizyga-ubuntu, a little bit, yes ;)07:26
pstolowskizyga-ubuntu, and it breaks every now and then when something new lands ;)07:26
mvozyga-ubuntu: hm, I need to look into the PRs/error logs, I don't remember that one off-ahdn07:27
zyga-ubuntumvo: can you please look at the general design of https://github.com/snapcore/snapd/pull/3810 since you requested those changes07:35
mupPR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>07:35
zyga-ubuntumvo: I will then work with pawel on reviweing that branch and landing it07:36
pstolowskizyga-ubuntu, and it breaks every now and then when something new lands ;)07:36
pstolowskiups, wrong window ;)07:36
pstolowskizyga-ubuntu, thanks for looking at this07:37
mvozyga-ubuntu: yeah, in a short while, just lookiing into 2.28 breakage on artful/i386,s390x07:37
mvozyga-ubuntu: fwiw s/requested/suggested/07:37
zyga-ubuntumvo: sure, no rush and indeed :)07:46
* zyga-ubuntu managed to link statically now07:48
zyga-ubuntuwhee :)07:48
zyga-ubuntumvo: are you looking into "./get-deps.sh: 10: ./get-deps.sh: go: not found" ?07:52
mvozyga-ubuntu: yes, that too07:56
pedronismvo:  will not running the unit tests everywhere increase our test run time too much ?08:12
mvopedronis: that might be a problem yes, i can try to figure out other ways to run them but right now there is a gap in our testing, e.g. unit tests failed on trusty but we don't test for this anywhere08:19
mupPR snapd#3848 opened: snap-seccomp: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3848>08:33
mvomeh, stuff like: "/tmp/go-build037063724/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re13f596af8 for symbol `' out of range08:34
mvoexit status 127" (in the zesty/ppc64el build) make me weep hard08:34
pedronispstolowski: is #3810 so big because of the changes in snap/ ?08:34
mupPR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>08:34
pedroniswere they strictly necessary?08:36
zyga-ubuntumvo: hmmm, symbol "empty string"08:38
pstolowskipedronis, yes, it's because the change in snap/; the change is trivial but affected lots of tests08:38
pedronispstolowski: is it needed though?08:39
pedronisit doesn't make much sense on its own08:39
pstolowskipedronis, not strictly neccessary, but mvo suggested a nice change to avoid code repetition in the new API08:39
pedronisyes, but that's internal08:39
pedronisPlugSlotData vs plugSlotData08:39
pedronisa world of difference08:39
pedronisyes, you noticed by needing to change so much08:39
pedronispstolowski: I don't think mvo suggestion extended to snap, it was about the new stuff08:41
mupPR snapd#3849 opened: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3849>08:47
mvopedronis: when I looked into this iirc I had to exend it to snap/ but I only looked briefly its probalby worth exploring options here08:48
pstolowskipedronis, it did, I merged mvo's branch with these refactoring changes, I fixed all the tests08:49
pstolowskipedronis, perhaps I accepted it too quick, not denying that, if this can be avoided then I'm ok to revert/redo this08:49
pedronispstolowski: well I data *snap.PlugSlotData08:50
pedroniswill probably confuse us08:50
pedronisbecause it recreates the problems we are trying to get away from08:50
pedroniss/I data/I think data/08:50
pedroniswe should really treat the Info stuff as immutable08:51
mupPR snapd#3848 closed: snap-seccomp: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3848>08:51
pedronispstolowski: to be clear I'm not against a shared plugSlotData in the new stuff, I'm not thrilled by snap.PlugSlotData and even less so by sharing it with plugSlotData by reference08:52
mupPR snapd#3849 closed: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3849>08:52
mupPR snapd#3850 opened: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3850>08:52
mupPR snapd#3851 opened: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3851>08:53
pedronispstolowski: using mutated or not copies of *Info is our current confusion/problem08:54
pedronisthis particular changes doesn't seem to address that08:54
pedronispstolowski: I expect some changes coming from addressing that, but the massive rework seems to not help to me08:56
mvopstolowski: sorry for having made your life more complicated08:59
pedronispstolowski: I'm happy to have a HO if this is unclear09:00
pedronismvo: did you suggest to change snap.PlugInfo ?  I saw your suggestion about the new stuff, not those09:00
mvopedronis: when I played with code I did add a snap.PlugSnapData so that it could be embedded into the new stuff09:01
mvopedronis: maybe that was wrong09:01
pedronisyes, it is09:01
pstolowskipedronis, thanks for the feedback, really appreciate it! i'm often missing the big picture when it comes to how the structures we have fit rogether09:01
pedronisI mean, it's not wrong09:01
mvopedronis: I was mostly trying to the duplication09:01
pedronisbut it tempts bad stuff09:01
pstolowskimvo, don't worry :)09:01
pedronisand it's a massive rework09:01
pedronisthat muds things09:01
mvopedronis: ok, do you see another way to avoid the duplication or is that just something we need to accept if we don't want to go down the other route?09:02
* mvo hasn't looked into the branch since a couple of days so will have to refresh his memory09:02
pstolowskipedronis, i need to revisit this branch to refresh my brain, currently finishing some other PR; will let you know later if I need more clarification09:03
pedronismvo: pstolowski: I think the main point is that NewPlug/SlotData need to really copy stuff out of Info09:03
pedronisand then we need to live with the consequences09:03
pedronisof that09:03
pedronisright now because we didn't have dynamic attrs09:03
pedroniswe use *Info either fromt he repo or the snap09:04
pedronisin slightly mixed up ways09:04
pedroniswe cannot afford that once we have dynamic attrs09:04
zyga-ubuntuhmm09:05
pedronisso we do need big changes, but more about how the repository store stuff09:05
pedroniszyga-ubuntu: the PlugInfo and SlotInfo in repo are sanitized, the ones from the snaps aren't, it seems we have no bugs yet, but super unclear if just chance09:07
pedronisanyway the use of the same type makes unclear why using the wrong one would be a problem09:08
zyga-ubuntupedronis: indeed09:09
pedronisgiven that go has types we might as well use them to our advantage, especially now we are adding the complexity of dynamic attrs09:09
pstolowskipedronis, got you. that's a good point09:14
pedronispstolowski: notice that we still need to think a bit about Plug vs PlugInfo vs PlugData09:19
pedronispstolowski: as I said happy to chat a bit about options when you have time09:20
Chipacao/09:21
mupPR snapd#3852 opened: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>09:24
* zyga-ubuntu reboots09:26
pedronisChipaca: hi09:27
pstolowskipedronis, ack, thanks09:29
* zyga-ubuntu walks his son to school, brb09:30
Jasem[m]Hello, I think I found an issue with snap and AppArmor, I tried sending an email to the list09:39
Jasem[m]but it bounced back09:39
mvomwhudson: hey, I ran into /tmp/go-build407282108/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re110ef6af8 for symbol `' out of range in zesty/ppc64el package building. that looks very much like bug 1711935 which you marked fix released but I see it. if it is PIE related I can try to disable PIE on ppc64el maybe?09:40
Jasem[m]anywhere else?09:40
mupBug #1711935: failing to start on ppc64el: R_PPC64_ADDR16_HA 277ef287d88 for symbol `' out of range <containerd (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1711935>09:40
ChipacaJasem[m]: the forum?09:40
Jasem[m]Chipaca: ok will try there09:40
ChipacaJasem[m]: you're in the right place for the chitchat around snapd, for what it's worth09:41
Jasem[m]Chipaca: well, it's an odd problem. I made a snap package for KStars about a year ago, it includes INDI server. So I forgot about the package and today I found that my INDI server (not related to the one in the snap package) was crashing. Turns out it was permission issue, and it only when away to I removed the snap from the system.09:42
Jasem[m]Chipaca: so for some reason, the AppArmor stuff was being applied to things outside of the snap in the reuglar system09:42
ChipacaJasem[m]: that sounds awfully like one of those "that's not how this works" memes09:43
ChipacaJasem[m]: how does the client talk to the server?09:43
Jasem[m]Chipaca: you can image frustration of troubleshooting this.. 2 hours I wasn't going anywhere it was driving me insane. I think a recent update to snap or apprmor changed things. I forgot about the snap package installed last year as I was testing snap packaging.09:44
ChipacaJasem[m]: yes, i can imagine!09:49
ChipacaJasem[m]: did you see my question?09:49
Jasem[m]Chipaca: the server crashes after a few seconds without any client09:49
zyga-ubuntuJasem[m]: hey09:50
zyga-ubuntuJamieBennett: can you please open a bug or a forum thread?09:50
zyga-ubuntuer09:50
zyga-ubuntuJasem[m]: ^09:50
JamieBennettheh, I can ;-)09:50
zyga-ubuntuJasem[m]: sorry, I meant you above :)09:51
zyga-ubuntuJasem[m]: do you see any apparmor denials? dmesg | grep DENIED09:51
Jasem[m]zyga-ubuntu: I didn't check that, but problem went away after the kstars snap was removed.09:51
Jasem[m]Ok I don't see any DENIED related to indiserver.09:53
pedronisChipaca: do you want to give a look  at #3780 again, it was rebased  , also #3727 needs a 2nd review09:54
mupPR #3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>09:54
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>09:54
Chipacapedronis: also a deconflict09:55
zyga-ubuntuJasem[m]: please try to reproduce the issue, collect any data such as journal logs and denials or messages from the service09:55
zyga-ubuntuJasem[m]: and let's chat09:55
Chipacapedronis: was looking at 3870 already09:55
zyga-ubuntuJasem[m]: in the end lets please open a forum topic with all the facts you managed to collect09:55
pedronismvo: #3727 needs a deconflict it seems09:56
mupPR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>09:56
Chipacapedronis: opinions on snapd#3845?10:06
mupPR #3845: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* <Created by chipaca> <https://github.com/snapcore/snapd/pull/3845>10:06
Chipacait's got 1.66… reviews already fwiw10:07
pedronisI'll look in  a sec10:12
mvoChipaca: I can have a look too10:12
Chipacamvo: you already did, twice, and you're doing the release10:13
mvopedronis: I will work on my branches next10:13
mvopedronis: still fighting some annoying issues with our matrix of (arch,release)10:13
mvoChipaca: good point10:13
mvoChipaca: fwiw, looks very nice, thanks for improving the tests btw10:16
zyga-ubuntumvo: btw, does that mean we do 2.27.6 with build fixes?10:19
pedronisChipaca: looked at it, mostly comments on comments and names10:26
* Chipaca looks10:27
=== ShalokShalom_ is now known as ShalokShalom
Chipacapedronis: Commit/Cancel? Commit/Abort?10:31
Chipacamvo: WDYT?10:31
Chipacamvo: (re pedronis' comment that Finalize is bad because Go uses it for something else, and we already use Commit for things that can't be re-committed -- and sql transactions usually can't commit twice)10:32
pedronisChipaca: usually for files the thing you can do many times is "flush"10:34
Chipacamhmm10:34
Chipacawhich isn't this10:34
Chipacathat's called Sync in go, and you can do that on these10:34
pedroniswhat where you thinking about commit and many times?10:34
pedroniss/where/were/10:34
Chipacapedronis: mvo said he'd expect to be able to call Commit piecewise10:34
pedronisI don't know why10:35
pedronisanyway either Cancel or Abort are fine by me10:35
Chipacapedronis: I think it's the bread. Germans do crazy stuff with the bread.10:35
pedronisChipaca: piecewise shouds like flush10:35
pedronisexcept here we commit to the name10:36
pedroniswith the rename10:36
* Chipaca awaits mvo's feedback10:36
mvoChipaca, pedronis: maybe its because of vcs commit that I had a mental "commit, commit" model10:38
mvothe bread is another possiblity10:38
mvoChipaca, pedronis: "submit()"? "finish()"? but I have no super strong objection against commit(), just felt a bit odd to not be able to repeat it10:40
pedroniswe have already two Commit in the codebase10:40
Chipacanobody liked Enfeoff()10:41
pedronismy brain admittedly happily keeps vcs commit and  transactional commit separate10:41
mvook, commit it is then10:42
xnoxdoes core 16, all-snappy systems, use resolved in xenial?10:42
ogra_ogra@nanopi-air:~$ ps ax|grep resolv10:43
ogra_ 1618 pts/0    S+     0:00 grep --color=auto resolv10:43
ogra_xnox, ^^ does that answer it ? :)10:43
xnoxogra_, no, but this would $ systemctl status systemd-resolved10:44
ogra_xnox, we do use networkd10:44
Chipacapedronis: I've flip-flopped over having AtomicWriter being the real thing, and it being an interface. Advantage of the interface is that it's a lot easier to document. Advantage of the real thing is that e.g. you get Sync() for free (because I'd embed *os.File)10:44
Chipacapedronis: do you have an opinion on that?10:44
ogra_ogra@nanopi-air:~$ systemctl status systemd-resolved10:44
ogra_● systemd-resolved.service - Network Name Resolution10:44
ogra_   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)10:44
xnoxack, thanks10:44
mupPR snapd#3850 closed: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>10:47
mupPR snapd#3851 closed: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3851>10:49
pedronisChipaca: the interface is ok11:23
pedronisChipaca: do you have a use case for doing more File stuff ?11:24
Chipacapedronis: no11:24
Chipacapedronis: pushed an iteration11:25
Chipacapedronis: most notably i've rejiggered commit so the only thing that can fail once the file is in place is the final dir sync11:26
Chipacapedronis: and i've chosen to silently ignore that error11:26
Chipaca(if power dies after a failed dir sync, you either have the old or the new thing -- atomicity is there)11:27
Chipacaand, reasons for a failing dir sync after everything else worked, are really hard to come up with without it involving filesystem failure11:27
pedronisChipaca: wondering a bit about the flags, should we have a mutex?   are there patterns where Cancel for example could come from a different goroutine than Commit?11:28
Chipacapedronis: one of the cancels will fail with one of the appropriate errors11:29
Chipacaor one of the cancel / commits11:29
Chipacaer11:29
Chipacalet me look at it just to be sure, but i _think_ all you get is a werider error than is user-friendly11:29
Chipaca(granted that the _expected_ outcome of calling cancel and commit in different goroutines is unknown)11:30
Chipacagah11:30
Chipacai've done that thing again where i think just because something is a boolean, concurrent accesses will only get booleans11:31
Chipacapedronis: would it be fair to say, if you use these things from different goroutines, add a mutex?11:31
pedronisyea, it's fair11:32
pedronismaybe just a matter to write it somewhere11:32
Chipacapedronis: OK. If that's the only issue with the code as it stands, I'll address it in the first PR that actually uses these :-)11:33
ChipacaBTW last night I found a place where we're doing something similar to the old "compile a constant regexp every time a function is called"11:34
Chipaca(that'll be addressed in the first PR that uses this as well)11:35
pedronisChipaca: any particular reasons to stop returning the dir.Sync() error?11:37
Chipacapedronis: there's nothing useful you can do with it11:37
Chipacayou can't cancel the commit11:38
Chipacayou can't re-commit11:38
pedronisyou disk is bad and you go ahead11:38
Chipacathe filesystem is probably consistent, but fucked because otherwise why would it error11:38
Chipacapedronis: stated like that, it sounds like maybe I shouldn't11:39
pedronisit's  a change11:39
pedronisif you are worried about Cancel11:39
pedronisyou can save the error11:39
pedronisand return that instead of11:39
Chipacapedronis: but if I do I feel compelled to make the wording around the interface a lot more convoluted than is probably needed11:39
pedronisjust cannot canccle11:40
ChipacaI'm going to go make lunch and think about it11:40
pedronisok, anyway not giving it a +1 yet11:41
pedronisdo you need an explicit -1 ?11:41
zyga-ubuntujdstrand: hello!11:52
zyga-ubuntujdstrand: if you are around today, can you please have a look at https://github.com/snapcore/snapd/pull/3621 again, I have added a child profile and massaged things into compliance build-wise11:53
mupPR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>11:53
zyga-ubuntujdstrand: as a small note, we now have snap-exec and snap-update-ns as statically linked executables11:53
zyga-ubuntujdstrand: I kept the are-we-reexecing-function in the PR even though I don't need it yet because it may come in handy later11:53
* zyga-ubuntu sighs 12:09
Chipacapedronis: another attempt :-)12:12
jdstrandzyga-ubuntu: hey, I'll try to get to it. I need to figure out the cgroup issue and haven't been through my inbox yet, but it is very high on the list12:19
pedronisChipaca: just reverted that bit of change?12:21
Chipacapedronis: and added docs12:21
jdstrandJasem[m]: I'll just reiterate what zyga-ubuntu said and ask for more information (eg any security denials in journactl at the time the application was crashing)-- the security confinement shouldn't leak out to other processes in the way you described, and if it did, there would be logs12:23
jdstrandJasem[m]: depending on the architecture of how the client interacts with the server, or if you had a deb client and a snap client, or a deb server and a snap server installed at the same time, then there could be conflicts (not necessarily security sandbox related)12:25
zyga-susejdstrand: thank you, I'm trying to sort out last packaging quirk there12:25
pedronisChipaca: matt changed #3780, it looks reasonable/consistent now, don't know if you want to look again12:28
mupPR #3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>12:28
Chipacapedronis: i'll take a look12:36
pedronisjdstrand: hi, this seems something for you:  https://forum.snapcraft.io/t/sandboxing-in-general/198412:42
jdstrandpedronis: yep, just came online, I'll get to it in a bit12:53
jdstrandpedronis: thanks12:53
ogra_sborovkov, https://github.com/snapcore/pi2-gadget/pull/9 ;)13:37
mupPR pi2-gadget#9: add splash support <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/9>13:37
nsgFor fun last weekend, I wrote a little snap store/repo. I downloaded the signed hello-world snap from the official store and was able to install it from my store. The question is, would it be possible to trust my own sign key and selfsign my own snaps and install them from my local store? Or is there something hardcoded in snapd that would prevent that?13:42
=== cachio__ is now known as cachio
zyga-ubuntunsg: there is a chain of trust from the root key, yes13:48
cachiomvo, did you see the error in the base snaps test?13:48
zyga-ubuntunsg: there's a forum thread about that today, I would suggest you catch up first13:48
* zyga-ubuntu needs to pick up his son from school, brb13:48
nsgzyga-ubuntu: will do!13:51
mvocachio: I saw it but have not looked deeper yet, I had some vague idea, let me look again13:51
mvocachio: I spend my morning with seccomp and similar failures in the unittests on s390x and pppc64el :)13:51
cachiomvo, ahh, ok13:51
xnoxmvo, btw, i am ponderring if the new libssecomp should be backported from artful to xenial, to support newer kernels etc.13:52
xnoxand s390x13:52
cachiomvo, np, I am still researching the issues that I see in the results13:52
mvocachio: the error looks a bit like something is wrong with the branch that ubuntu-core-16-arm-32 runs from, the snapbuild version looks outdated13:52
cachiomvo, after I finish beta for 2.28 I'll create a job to run the tests on core i386 and amd6413:53
ogra_jdstrand, regarding the opengl stuff, note that mir works fine with the fixed udev rule (but we perhaps still want to allow access to these platform paths for other apps that rely on them)13:55
jdstrandogra_: yeah, read the thread. those other paths seem reasonable for the interface though13:58
jdstrandogra_: thanks13:58
ogra_:)13:58
cachiomvo, I already reviewed that but it is using the release/2.28 in all the cases13:59
cachiomvo, and the version that is running in the devices is correct too14:01
mvocachio: aha, thanks. strange, I have a look at the snapbuild code, wonder what is going on there14:04
nsghm, I can't find any forum tread from the last day discussing snap selfsigning ... I'm missing something? Any pointers of what to search for? :)14:06
mvocachio: a PR for you: https://github.com/snapcore/spread-cron/pull/41 :)14:09
mupPR spread-cron#41: trigger builds for zesty,artful,trusty as well as xenial <Created by mvo5> <https://github.com/snapcore/spread-cron/pull/41>14:09
nsg(I'm up2date on the "External repositories" thread, if that was the one you was talking about.)14:09
cachiomvo, looking14:13
=== JoshStrobl|zzz is now known as JoshStrobl
mupPR snapd#3853 opened: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3853>14:30
sborovkovogra_: saw the PR, does this one work on the first boot?14:32
niemeyermvo: "add --last to snap abort and snap watch"14:36
niemeyermvo: Slightly surprised to see this one in the notes14:36
niemeyermvo: Is it just --last, or --last=foo?14:36
* niemeyer checks14:36
ogra_sborovkov, on every boot (including the first) ... i added a pre-made snap to your bug for testing14:36
mvoniemeyer: its "snap --last={install,refresh,remove,try,...}14:37
mvoniemeyer: so yes, sorry for that, that should have at least an example14:37
niemeyermvo: Ah, okay, no worries.. I'll put an example in14:37
Son_Gokuzyga-ubuntu: please test the new snapd release for Fedora14:37
Son_GokuI'd like for it to make its way through rather quickly14:38
sborovkovogra_: when you say pre-made snap, you mean gadget snap? Anyway I will pull it and try it out. Thanks a lot! Now there is much better user experience with this. We got a bunch of bugs filed when people ran the image for the first time and it was stuck on login page for a very long time, everone was writing to us that it's broken14:39
mupPR snapd#3853 closed: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3853>14:40
ogra_sborovkov, yes, a gadget snap with the PR included14:40
ogra_sborovkov, fro userspace you can additionally use the psplash snap to run as a service14:40
ogra_the system will switcxh over from one splash to the other14:41
sborovkovok that's great. this PR is for pi2-gadget only though?14:42
mupPR snapd#3854 opened: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3854>14:46
mvocachio: fwiw, I can reproduce the error, looking now14:47
sborovkovogra_: and I see that while pi3-gadget is still getting new commits, it does not have your commit that allow to build uboot from source for instance? Are they kinda diverging now?14:47
ogra_sborovkov, pi2 and pi3 both have the build-from-source commit ... i dont have the splash PR ready for pi3 yet though14:48
mvocachio: I think I know what is going on - we need an update to test-snapd-snapbuild14:49
sborovkovogra_: ah, alright sorry. How different is pi3 gadget snap? If I tried to apply your changes from pi2 PR would it work? We only use pi3 :-(14:50
mvocachio: I'm on it14:50
cachiomvo, nice14:50
ogra_sborovkov, oops, i should have started with pi3 then (i actually thought you do pi2 ... heh) ... i guess it should apply14:50
cachiomvo, I am going to push a fix for lxd tests14:51
cachiomvo, testing it now14:51
mvocachio: sweet, thank you!14:51
cachiomvo, it is quite slow here14:51
mvocachio: yeah, sorry for that :/14:51
mvocachio: you raised concerns in the PR14:51
cachiomvo, np :)14:51
mvocachio: happy to move it to the nightly suite or something, I just think we need it tested :)14:51
mvoniemeyer: good news, CE already did the automated test for 2.28~rc114:52
cachiomvo, yes, the idea is to run the whole test suite inside a vm with ubuntu core14:52
cachioI have to see how to reuse the nested suite14:52
zyga-ubuntuPharaoh_Atem: hello, gladly, I'll test it ASAP15:01
zyga-ubuntunsg: not about self-signing but about federated / external repositories15:01
zyga-ubuntunsg: that topic is related so please look for "external repositories"15:01
mvocachio: the base test should work now on the external backends, I will rerun on my sysem15:03
mvosystem15:03
cachiogreat15:03
mupPR snapd#3845 closed: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3845>15:04
nsgzyga-ubuntu: "the store signs them with an archive key so they can be verified (assertions)" ... I have seen that code from the source but my go skills are not the best so it's a little hard to follow. I guess there must be a public or a key signature somewhere on my computer and/or inside the snapd binary to validate the signature? My question is, where is it and can it be replaced with my own?15:08
niemeyermvo: \o/15:09
nsghm, maybe it's better to ask that instead in the thread... I will do that later :)15:10
niemeyermvo: I'm about half-way though the list, writing a section for each item15:11
niemeyermvo: Will have lunch now and do the rest afterwards15:12
zyga-ubuntunsg: its baked into snapd binary15:13
zyga-ubuntunsg: you can replace it but then none of the existing snaps will validate15:13
=== cachio_ is now known as cachio_lunch
mvoniemeyer: thanks a lot15:16
nsgI see, so I need to build my own snapd then. In this case it's a feature that no other snaps validate :) (need to re-sign the core snap of course). I will see if I take the time to do this (probably not) ... the alternatives are just "wget ... && snap install --dangerous ..." but that sounded so hacky and I liked to avoid it by making a store for my self.15:18
ogra_nsg, it *is* super hacky, dont do it :)15:18
nsgyeah, but the other alternatives are to not use snaps at all :\15:19
nsgneed to have a local repo15:19
zyga-susensg: why do you need this?15:20
zyga-susensg: we understand that some people feel strong about it but most people don't need a local repo today15:20
zyga-susensg: you can create private snaps today15:20
nsgI like to use snaps at work for example, I must host them inside the network15:21
nsgFor my personal things, private snaps are just fine15:21
zyga-suseI see15:22
ogra_mvo, btw, if you are interested ... https://github.com/snapcore/pi2-gadget/pull/9 is the first thing that exercises "split initrd" (see the uboot.env.in bit)15:22
mupPR pi2-gadget#9: add splash support <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/9>15:22
nsgWe did consider just to package debs and deploy them inside lxd containers but snaps was a much better solution for our usecase so I tried to work my self around the problem :)15:22
zyga-susensg: this is not available as a feature yet, it will come out of the commercial side of snapd, where people can just get a local store and point their devices there, that store could live on your land and also act as a mirror/filter for the public snap store15:22
ogra_i have another PR pending (that sits on top of this one) to actually load a modules.img15:22
zyga-susensg: for the moment you can just snap install --dangerous them15:23
mvoogra_: thanks, I check it out later, I haven't managed to find time for it yet (but I did see it)15:23
zyga-susensg: that just skips the assertion check15:23
ogra_mvo, yeah, it is more FYI, i can get reviews from oothers15:23
ogra_works really well though15:23
mvoogra_: nice to hear15:23
ogra_and i can easily do all the gadget bits ahead of time before the snapd changes happen15:24
mvocachio_lunch: just tests tests/main/base-snap on external: and it seems to be happy now15:24
jdstrandtyhicks: hey, do you have a moment to talk about one of the next steps on seccomp deny/log rather than kill?15:24
* zyga-ubuntu would love to listen15:24
nsgzyga-suse: if you can tell, what time frame do you think we talk about here? --dangerous can be a acceptable solution if there is a better solution over the horizon. But if we talk 2019+ it's probably better just to stick to deb:s.15:27
mupPR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>15:29
mupPR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>15:29
mupPR core#55 closed: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>15:29
mupPR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>15:30
mupPR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>15:30
mupPR core#55 opened: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>15:30
zyga-susensg: gustavo recently posted the snapd roadmap: https://forum.snapcraft.io/t/the-snapd-roadmap15:31
diddledantrying to run snapcraft container builds: - Copy snap "core" data (cannot copy "/var/snap/core/2774" to "/var/snap/core/2774": failed to copy all: "cp: cannot stat '/var/snap/core/2774': No such file or directory" (1))15:31
zyga-susensg: having said that this is a store side feature, for that there's no roadmap that I know of15:31
diddledanthat 2774 is a folder which is empty15:32
zyga-susensg: I suspect this is a ~2018 window as I hear about various commercial projects with similar needs15:32
zyga-susensg: so please stick to snaps and let's work together on making this as nice as possible for all the use cases15:32
zyga-susediddledan: that's something Chipaca may know about15:33
diddledanfull log: http://paste.ubuntu.com/25472718/15:33
Chipacadiddledan: known bug, i'm afraid15:33
diddledanergh15:33
Chipacadiddledan: (fixed in the latest)15:33
Chipacadiddledan: not sure where snapcraft comes in to it though15:34
zyga-suseman, it feels good to be on a 100Mbit connection15:34
Chipacadiddledan: that is: the operation that failed fails because of a known, fixed, issue15:34
Chipacadiddledan: but it's an operation that doesn't happen "naturally"; what triggered this?15:34
diddledanthe trigger was : SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft15:35
ogra_zyga-suse, do you hear the "WOOSH" when sending and receiving files ?15:35
diddledanusing snapcraft, version 2.33+git53.69dceb815:35
zyga-suseogra_: I don't have to count the bits anymore15:35
ogra_:)15:35
Chipacadiddledan: what does "snap version" output?15:35
diddledanin the container or locally?15:35
Chipacadiddledan: both!15:36
pstolowskidavidcalle, hey, i've just tested the little problem we discussed with artful. i still cannot get the expected snapcraft build output - see http://pastebin.ubuntu.com/25472726/15:36
pstolowskidavidcalle, any chance you forgot to push simething to your repo?15:36
nsgzyga-suse: yup, I have read that post (a lot if great things in there!), 2018 sounds good. For my simple use case just an easy way to change the key would be fine to... no need of a new store (I can write something simple for that). I will try to convince my team :) Thanks for the info!15:36
davidcallepstolowski: I've tried with a clone of this repo15:36
diddledanlocally: http://paste.ubuntu.com/25472730/ container: https://paste.ubuntu.com/25472734/15:36
zyga-susensg: thanks, please stay around and share your experiences15:37
Chipacadiddledan: what are the containers?15:37
diddledanwhatever snapcraft spins up15:38
diddledanlxd15:38
davidcallepstolowski: looks like you are running snapcraft from the snap dir, should be from the root15:38
mupPR snapcraft#1313 closed: Meta: Version from deb <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1313>15:38
Chipacadiddledan: ok, may i suggest you take all this info and open a forum topic? I suspect snapcraft is doing something screwy and triggering the bug, and while it'll go away in the next snapd release, maybe it shouldn't be doing that thing15:38
pstolowskidavidcalle, oh my, that's it15:39
davidcallepstolowski: aha :)15:39
pstolowskidavidcalle, why doesn't it complain?15:39
zyga-suseok, I think I know how to massage the %gobuild macro on opensuse into compliance15:39
davidcallepstolowski: because snapcraft.yaml can be at the root as well, so it's a valid project dir in itself15:40
* davidcalle note to self: add a readme!15:40
Chipacaerr = osutil.AtomicWriteFile(dst, nil, 0644, 0)15:42
ChipacaWHAT15:42
Chipacawhy15:42
* Chipaca thinks15:43
Chipacaah, ok15:43
Chipaca:-)15:43
pstolowskidavidcalle, interesting15:43
diddledanChipaca: https://forum.snapcraft.io/t/snapcraft-container-builds-triggering-a-bug-in-snapd/199015:44
pstolowskidavidcalle, anyway. just got it built on artful now with hooks as expected. it installed cleanly. it failed when I made it to fail explicitely (I broke its install hook for a test). since i'm uncessful in reproducing, I may need your state.json file15:45
davidcallepstolowski: should I reproduce the issue and send it over to you?15:47
pstolowskidavidcalle, nb, we also have a spread test (i.e. a test with real VM) with a test snap with install hook and it has been passing too. not sure what's going on, but perhaps you got yourself into a state which somehow breaks it15:48
pstolowskidavidcalle, yes, that would be helpful. do you only see it on your box where you already accumulated a bit of history with snapd, or are you able to reproduce with a clean VM?15:49
tyhicksjdstrand, zyga-suse: hey - I just got out of a meeting and can chat about the seccomp changes now15:50
zyga-susegreat15:50
zyga-susetyhicks, jdstrand: I'll adapt to any environment15:51
zyga-susepersonally I think we can do it on IRC here15:51
jdstrandmvo: https://github.com/snapcore/snapd/pull/3850#pullrequestreview-6064718015:51
mupPR #3850: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>15:51
jdstrandmvo: (and hi)15:51
jdstrandtyhicks: ok15:51
mvojdstrand: hi, I have no idea why it regresses, I did not dig into it yet, there was a ton more but I can do so tomorrow15:52
jdstrandtyhicks: basically, my understanding is that the upstream kernel changes will be in 4.14 (the next stable kernel), there will be patches for libseccomp and seccomp-go15:52
mvojdstrand: maybe its just libseccomp ?15:53
jdstrandmvo: maybe it is seccomp-go? I don't know how it interfaces with libseccomp15:53
zyga-susejdstrand: I think the changes will be in seccomp-go and libseccomp (unless they already landed in libseccomp)15:54
tyhicksjdstrand: correct - the libseccomp PR is here: https://github.com/seccomp/libseccomp/pull/9215:54
mupPR seccomp/libseccomp#92: Expose improved kernel logging features through libseccomp <Created by tyhicks> <https://github.com/seccomp/libseccomp/pull/92>15:54
mvojdstrand: I can dig into it tomorrow morning15:54
tyhicksjdstrand: once that gets an ack, I can work on the libseccomp-golang patches15:54
jdstrandmvo: zesty and artful have libseccomp 2.3.1. they also have kernel > 4.3. I didn't look at the glibc bits15:54
jdstrandmvo: thanks15:55
tyhicksthe libseccomp-golang changes should be quick to code up15:55
jdstrandtyhicks: ok, so in terms of using this in snapd, it sounds like we could do some conditional logic in snapd to detect if the feature is available, and if it is, use EPERM, else kill15:56
tyhicksjdstrand: that's correct15:56
jdstrandtyhicks: which is where I think we last landed15:56
tyhicksjdstrand: libseccomp/libseccomp-golang will have ways for applications to test if the kernel supports the new seccomp LOG action and the new seccomp LOG filter flag15:57
zyga-susejdstrand: right, I asked about that aspect but I don't recall an answer; how can we check for this feature at runtime?15:57
tyhickszyga-suse: I responded to your question in the bug report an hour or so ago (I just returned from vacation today)15:57
zyga-suseaha, perfect, I'll catch up with email then15:57
zyga-susethank you15:57
jdstrandtyhicks: seeing that setpriority issue, I wonder if perhaps we should unconditionally use EPERM and conditionally set up logging based on kernel. kernel snaps could have this kernel patch and just start benefiting, but everything acts the same in terms of the snap developer15:57
tyhicksjdstrand: yes, I think that's the way to do it15:58
jdstrandtyhicks: perhaps there is a config option to kill instead of EPERM for systems that prefer that behavior15:58
tyhicksjdstrand: IMO, I'd keep that config option in our back pocket in the case that someone asks for it15:59
=== cachio__ is now known as cachio
jdstrandtyhicks: like, maybe it is part of snap config for the core snap or something15:59
tyhicksseems like added complexity that doesn't have any demand, atm15:59
jdstrandtyhicks: I worry about silent denials16:00
tyhicksjdstrand: good point16:01
jdstrandtyhicks: a way to do this would be the kernel sees if it can log with EPERM. if it cannot, it logs this with a link to the forum. the forum tells what patch is needed for the kernel, and how to set the old behavior (snap set core seccomp=kill) or something16:02
jdstrandtyhicks: this would get info to kernel developers and allow users to configure the system in a way that they could see the denials16:03
tyhicksjdstrand: yeah, that could work16:04
jdstrandtyhicks: so that would be a small change to snapd to read whatever the core 'snap set' would do. it could be that snapd could evaluate an env var SNAPD_SECCOMP=kill (or somthing), and the 'snap set core' simply updates snapd's systemd unit16:06
tyhicksjdstrand: do you know if there's a bug for EPERM-by-default? I could only find a bug for "complain mode" (LP: #1567597)16:06
mupBug #1567597: implement 'complain mode' in seccomp for developer mode with snaps <Snappy:In Progress by tyhicks> <libseccomp (Ubuntu):Confirmed for tyhicks> <linux (Ubuntu):Fix Committed by tyhicks> <https://launchpad.net/bugs/1567597>16:06
tyhicksjdstrand: I think that's a pretty clean design16:07
jdstrandtyhicks: that is the only bug I know of16:07
jdstrandtyhicks: I would suggest creating a forum topic so that others from the snapd team can comment on the design16:07
tyhicksjdstrand: that's a good idea but I'm not sure I'll be able to do that today16:08
jdstrandtyhicks: doesn't have to be today :)16:08
* tyhicks nods16:08
jdstrandtyhicks: anytime before you start implementing things :)16:08
jdstrandtyhicks: the setpriority topic just got me thinking, so wanted to bring it up snce it seems like next steps are coming soonish16:09
om26erHi! whats the practice for not having hard-coded version number in snapcraft.yaml ?16:14
naccom26er: in which sense? for your snap? or for dependencies?16:14
tyhicksjdstrand: glad you brought it up so that at least a few of us are on the same page16:14
om26ernacc: for my snap. In our project we have a central place where we append the version number. For our snap we still have to edit the snapcraft.yaml by hand.16:15
jdstrandtyhicks: I summarized the conversation in trello16:15
jdstrandtyhicks: np16:15
om26ernacc: maybe something similar to what the core snap does ?16:26
naccom26er: i have no idea what it does/how, sorry16:26
ogra_om26er, https://github.com/ogra1/strongswan-snap/blob/master/snap/snapcraft.yaml see "version-script:"16:28
ogra_(you can freely use shell there)16:28
Chipacapedronis: quuestion for you that involves newlines in repairs :-)16:30
pedronisChipaca: yes?16:30
Chipacapedronis: how bad is it if a repair thing ends in a newline?16:31
Chipacapedronis: currently for example runnerSuite.TestNextNotFound checks that the repair ends in }16:31
Chipacaand not }\n16:31
pedroniswhere, what?16:32
pedronisthat's json?16:32
pedronisis not a repair16:32
pedronisChipaca: which line in the test?16:33
Chipaca117916:33
Chipacayes, the json16:34
Chipacapedronis: the problem is https://play.golang.org/p/i5tX-SBcTo16:34
Chipacaswitching runner.go to use AtomicFile instead of AtomicWriteFile results in an extra newline16:34
pedronisand test files?16:35
pedronisfails?16:35
Chipacayep16:35
pedronissomething is weird there, though?16:35
pedronisextra newline, or a newline that is not there before?16:35
Chipacapedronis: http://pastebin.ubuntu.com/25473162/16:35
Chipacapedronis: depends which direction you're thinking in :-)16:36
Chipacapedronis: json.NewEncoder(aw).Encode(thing) adds a newline after encoding the thing, whereas json.Marshal(thing) does not16:36
pedronisI'm not sure whether you are trolling me or what :)16:36
ogra_lool16:37
ogra_err16:37
ogra_lol16:37
ogra_(sorry lool )16:37
Chipacapedronis: I know nothing about repairs, so i thought i'd ask rather than just fix the tests16:37
pedronisChipaca: repair.json is  a repair status file,  as long as we can read it back we are happy16:37
Chipacapedronis: if we hash that json, i'd be breaking stuff16:37
pedronisChipaca: it's not a repair16:38
Chipacaok16:38
pedronisit was actually called repair-state.json16:38
pedronisat some point16:38
* Chipaca edits the tests with glee16:38
Chipacapedronis: sorry for the trolling (even though i think it wasn't intentional)16:38
pedronisChipaca: it's like /var/lib/snapd/state.json bu for repairs16:38
Chipacaok16:38
pedronisfor snap-repair16:38
pedronisChipaca: the repairs are saved as  r#.repair with a different AtomicWriteFile16:39
pedronisand are assertions, those are pickier16:40
pedronisbut for sure don't end in }16:40
=== rharper` is now known as rharper
Chipacapedronis: ok :-D16:42
Chipacapedronis: actually, if you don't mind, I'll change the tests to parse the json and DeepEqual them instead of comparing them with a string? unless there was a reason to do it this way16:42
pedronisit was expedient and seemed ok for the simple cases16:43
Chipacapedronis: agreed it's often simpler; just that now i've broken them with an unrelated change, so ¯\_(ツ)_/¯16:44
pedroniswe do something similar for some tests in overlord/overlord_test.go16:44
pedronisChipaca: notice that there's a helper that also writes states, freshState16:44
pstolowskidavidcalle, hey, can you check journalctl |grep -i "using default"16:45
Chipacapedronis: noted16:45
pstolowskidavidcalle, does it find anything?16:45
=== JoshStrobl is now known as JoshStrobl|Work
* Chipaca gives up after nearly drowning in a sea of map[string]interfaces{}16:56
om26erogra_: that did the trick, thanks.17:00
om26erogra_: how do you include the git commit info on edge channel only ?17:10
om26eris there channel specific version script ?17:10
* Chipaca writes commit messages for zyga-suse to be proud17:20
mupPR snapd#3855 opened: many: switch to use the new osutil.AtomicWriter where reasonable <Created by chipaca> <https://github.com/snapcore/snapd/pull/3855>17:21
* zyga-suse hugs Chipaca :-)17:23
zyga-suseChipaca: is the trim space coming from a new newline?17:25
Chipacazyga-suse: yes17:25
Chipacazyga-suse: because https://play.golang.org/p/i5tX-SBcTo17:25
pedronisChipaca: I'm probably dense today, but none of the cases in that PR seems to involve large data? what's the win?17:26
zyga-suseaha17:26
pedronisexcept snap-repair17:26
zyga-susepedronis: I think I requested that, it involves arbitrary sized data when command-not-found hints are involved17:26
zyga-suseor was it also for section names and snap names?17:26
Chipacazyga-suse: yeah, but for a lot of these we know the size17:26
pedronisyes, but that's not for the cases in that branch17:26
Chipacapedronis: mostly just exercising the new thing, so if you'd rather I didn't do it on most of these I won't mind17:27
pedronisChipaca: another interesting case is state.json itself  but that's mediated through state.Backend.Checkpoint taking []byte atm17:27
pedronisChipaca: given that's it's more code, I'm not super fond,  snap-repair though seems a valid one17:27
Chipacapedronis: ack17:28
pedronisChipaca: I'm a being insuffarable today? I might be17:28
Chipacapedronis: not at all, it's a valid point17:29
Chipacathe new api feels cleaner to me, but by so little, i don't mind17:29
Chipacaas i say this was _mostly_ to exercise the api, see if it was sane17:29
zyga-suseChipaca: the only thing I found surprising is that defer cancel is unconditional, but is "trumped" by commit17:30
Chipacazyga-suse: i love that bit :-)17:30
pedronisChipaca: as I said exploring this vs state.json could be interesting, probably would need to a standalone thing17:30
Chipacapedronis: agreed17:30
Chipacastate.json does its own thing though, i think?17:30
Chipacait uses CopyFile with the sync flag?17:30
pedronisno,17:31
pedronisbut it's mediated through an interface17:31
pedronisChipaca: see overlord/backend.go:3617:31
pedronisand  the code in overlord/state/state.go calling Checkpoint17:32
Chipacaah17:32
* zyga-suse is tired17:32
Chipacapedronis: ok, i'm going to close the PR, and then prune it and reopen it17:33
* Chipaca hugs zyga-suse 17:33
Chipacazyga-suse: why are you still here17:33
pedronisthnak you17:33
zyga-suseI want to solve the build blocker for suse17:33
zyga-suseand dput snapd for sid17:33
mupPR snapd#3855 closed: many: switch to use the new osutil.AtomicWriter where reasonable <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3855>17:34
zyga-suseaww, don't close that17:34
zyga-suseI think it's a good change17:34
Chipacazyga-suse: i'll bring it back, for variable-sized things at least17:35
zyga-suseok17:36
Chipacazyga-suse: i might play with commands first, as that's the other big user (and it doesn't exist in code yet)17:37
diddledanogra_: I got a devmode ring working kinda. it doesn't work straight away, but instead requires you to execute two separate commands because it relies on a session dbus service which is handled by a separate executable, and even tho it's supposed to autostart it doesn't seem able to17:45
mupPR snapcraft#1298 closed: jhbuild plugin: new plugin <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1298>17:51
diddledanaha. strace to the rescue - it's trying to call dbus-launch which doesn't exist (needs a stage-package)17:52
mupPR snapd#3780 closed: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3780>18:18
mupPR snapd#3856 opened: 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>18:29
=== chihchun is now known as chihchun_afk
niemeyerPharaoh_Atem: ping20:37
Pharaoh_Atemniemeyer: pong21:20
Pharaoh_Atemniemeyer: what's up?21:20
Pharaoh_Atemdid you want something?21:23
=== JanC_ is now known as JanC
niemeyerPharaoh_Atem: Heya21:47
niemeyerPharaoh_Atem: If/when you have a moment, I'd like to perform a quick test in the forum to aid in the bug report21:47
King_InuYashaniemeyer: sure22:27
niemeyerOkay, let me create a quick topic.. you'll probably get the notification again22:28
niemeyerKing_InuYasha: Done.. "Testing, please ignore"22:29
King_InuYashait'll take a minute before Discourse decides to send it22:30
King_InuYashaheavens knows why...22:30
King_InuYashaniemeyer: I didn't get any mail so far22:39
King_InuYashaah, here it is22:39
King_InuYashaI just got it22:39
niemeyerKing_InuYasha: Alright, so now I'm sending a reply to it22:39
niemeyerKing_InuYasha: The question is whether you'll get that second one22:40
niemeyerKing_InuYasha: "And this is the reply."22:40
niemeyerKing_InuYasha: It should take about 5 minuts22:40
niemeyerminutes22:40
niemeyerKing_InuYasha: Ah, and please don't visit the topic while the reply is there, otherwise the email is not sent no matter what.22:48
niemeyerKing_InuYasha: If you did see the reply through the web, let me know and I'll send another one.22:49
niemeyerSon_Goku: ^22:49
Son_Gokuniemeyer: yeah, I clicked it22:50
Son_Gokusorry22:50
Son_Goku...22:50
Son_Gokubut I got the reply anyway?22:50
Son_Gokuit just takes ~10 minutes22:51
Son_Gokueach email was sent 11 minutes after posting22:51
niemeyerSon_Goku: Ah, you did get the reply?22:54
Son_Gokuyep22:54
niemeyerSon_Goku: Super, thanks22:54
niemeyerSon_Goku: Will include in the report22:54
Son_Gokunp22:55
niemeyerSon_Goku: The mailing list mode apparently sends anyway, even if you visit the web UI then22:55
Son_Goku:D22:55
niemeyerSon_Goku: The normal notifications won't22:55
Son_GokuI would seriously hope so22:55
Son_Gokuotherwise the ML mode is more broken than I thought22:55
niemeyerYeah, makes sense, at least in that case22:56
mupPR snapcraft#1530 opened: tests: share the cache dir in the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1530>23:18
CodeMouse92__I think I finally figured out my ongoing problem with snapping a kivy app...I need to pip install cython BEFORE pip installing kivy, which means the two need to be installed in separate steps...23:52
CodeMouse92__I assume this means I need to create a second part, but I'm not 100% sure. Insight?23:53

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