/srv/irclogs.ubuntu.com/2019/09/27/#snappy.txt

mupPR snapcraft#2733 closed: cmake plugin: support disable-parallel option <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2733>04:32
=== vicamo_ is now known as vicamo
mborzeckimorning06:30
=== pedronis_ is now known as pedronis
zygahey07:03
zygaI'm sick but I will try to get some work done today07:03
zygano promises, it's a day off07:04
=== pstolowski|afk is now known as pstolowski
pstolowskimornings07:05
mborzeckizyga: pstolowski: hey07:06
zygahey :)07:07
mborzeckizyga: why don't you type in /quit in your irc client ;)07:07
zygaI hate being sick07:07
zygamborzecki, that's a good question07:07
mborzecki:P07:07
mborzeckiheh :P07:07
zygawell, that was interesting07:08
pedronispstolowski: 2.41+ has the unset option support ? or was it 2.40+ ?07:25
pedronisdegville: pstolowski: I'm adding some mention of how unsetting work to https://forum.snapcraft.io/t/system-options/87 as well07:27
pstolowskipedronis: 2.4107:32
pedronispstolowski: thx, it's what I used, were there bugs with it and system that we fixed only in 2.42 ?07:32
pstolowskipedronis: and thanks for updating the forum; nb i announced it before here https://forum.snapcraft.io/t/configuration-of-snaps-new-commands-for-unsetting/13118 and updated the docs (links in the annoncement)07:35
pedronispstolowski: yes, I saw the new docs, but somebody at some asked in the system options how to unset them07:35
pedronisand we had some example at the top of how to set/get, so just added unset and ! there too07:35
pedronisanyway degville is free to tweak/remove if he deems it annoying07:36
pstolowskipedronis: yes, there was a bugfix for system i made on 11th Sep (so not in 2.41), but it was minor - you could unset unknown (unsupported) options and it wouldn't complain, whereas snap set errors out in such cases07:38
pedronisok, thx07:38
ograpedronis, moaning ... :) ... i assume there are no plans to turn Ubuntu Core into multi-user systems ? .... https://forum.snapcraft.io/t/passwd-command-error-in-app-snap/13408/707:39
degvillepedronis: thanks for letting me know about the updates! I'll take a look.07:41
pedronisdegville: unrelated, did you see this: https://forum.snapcraft.io/t/is-snapd-forward-compatible-with-new-app-interfaces/10498/407:51
degvillepedronis: ah, thanks. I'll update the snap.yaml reference.07:57
Chipacamoin moin08:04
zygadegville: do you know who maintains https://ubuntu.com/download/iot/kvm ?08:22
ograzyga, at the very bottom there is a "report a bug on this site" (most right option)08:24
zygathanks!08:25
pedronisChipaca: hi,  could you pin this from jdstrand for some reasonable time: https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/1341808:30
Chipacapedronis: how much is reasonable time?08:30
Chipacaa month?08:30
Chipacasix?08:30
Chipaca3 years, like the first crusade?08:31
mupBug #1626986 changed: snapd should allow snaps to define systemd unit alias names <snapd:Triaged> <https://launchpad.net/bugs/1626986>08:31
mupBug #1627218 changed: snap refresh does not pull the latest betas <snapd:Incomplete> <https://launchpad.net/bugs/1627218>08:31
* ogra hugs Chipaca .... i was really a bit lost with that passwd thread08:31
pedronisChipaca: 3 weeks08:31
Chipacapedronis: pinning until oct 21, ie the first monday after 3 weeks08:32
pedronisthx08:32
mupBug #1627643 changed: oops on pi3 (seemingly wlan related) <Snappy:Invalid> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>08:34
Chipacapedronis: there's also "banner" topics which are even more prominent, fwiw08:35
Chipacathere can only be one banner topic, there can be multiple pinned ones08:36
Chipacacurrently there are two globally-pinned topics; the other is the "welcome!" one08:36
pedronisChipaca: ok, pinning seems fine though08:36
Chipacapedronis: the policy PR always uses current for boot.InUse, which is wrong :-| need to change the api, probably08:43
Chipacaexplicit revision needed or sth08:43
degvillezyga: probably the web design team (sorry for the delay, I'm actually on a swap day and I've biked over to the cinema).08:45
Chipacapedronis: ok, advice needed: currently (in the PR) CanRemove takes a boolean 'all'. What's actually needed is *either* that boolean, *or* the index into Sequence (or the revision meant to be removed, but the index makes it unnecessary to return a lookup error). I could: 1. add a parameter, 2. change the boolean to an index, -1 meaning all; 3. change the boolean to a *Revision, nil meaning all; 4. ad-hoc opts struct that would need validating and thus08:53
Chipacaadd an error return. Leaning to (2) myself.08:53
Chipaca5. somehting else i didn't think of :)08:53
pedronisChipaca: variation on 2? pass a revision with unset meaning all?08:54
pedroniswell really 2+308:55
Chipacapedronis: and add an error return / change it from returning bool to error, nil==ok (gives us error message) (feels like big api change, maybe squash the error and do the error return later)08:55
Chipacayes this is stream-of-conciousness irc08:55
pedronisChipaca: remember it's used in exactly one place08:56
Chipacaunset meaning all sgtm fwiw08:56
pedronisso I would add the error now08:56
Chipacapedronis: we have a TODO to report *why* you can't remove, so I'd change it to return an error with the why while I'm at it08:57
Chipacainstead of the bool i mean08:57
pedronisok08:57
Chipacaok! on it08:57
Chipacapedronis: is CanRemove still the right name for something that returns error?08:57
mborzeckihmm yum command line argument parsing seems broken09:03
pedronisChipaca: we tend to use Check for those situations but I'm not sure we are super consistent, maybe grep ?09:03
pedronisI mean Check*09:03
Chipacayah, will do09:03
mborzeckicentos guys have pushed a systemd build that potentially fixes the issue we've been seeing, but passing --enablerepo=fasttrack in our pkgdb.sh seems to behave rather funny09:04
Chipacasigh, need to tweak the api of boot.InUse :-)09:08
Chipacamore coffee first09:08
=== vicamo_ is now known as vicamo
mupBug #1632508 changed: Get a way to differentiate uninstall/shutdown from snap update in stop script <libvirt> <lxd> <openstack> <snapd:Triaged> <https://launchpad.net/bugs/1632508>09:28
mupBug #1633111 changed: Missing API documentation for /v2/snaps/[name] POST <snapd:New> <https://launchpad.net/bugs/1633111>09:28
zygaChipaca: is the REST api documented on the forum?09:29
Chipacazyga: no, the wiki09:29
zygaChipaca: the github wiki?09:31
zygaah, I see it at https://github.com/snapcore/snapd/wiki/REST-API09:31
Chipacazyga: and, it's always out of date :-|09:32
Chipacabut, it's a good place to start09:32
Chipacazyga: why?09:32
zygaChipaca: when spread churns I'm looking at bugs https://bugs.launchpad.net/snapd/+bug/163311109:33
mupBug #1633111: Missing API documentation for /v2/snaps/[name] POST <snapd:Fix Released> <https://launchpad.net/bugs/1633111>09:33
mupBug #1635011 changed: /v2/changes/ is not documented in rest.md <snapd:Fix Released> <https://launchpad.net/bugs/1635011>09:44
mupPR snapd#7523 opened: sandbox/selinux: move SELinux related bits from 'release' to 'sandbox/selinux' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7523>09:44
mborzeckizyga: ^^^09:45
zygamborzecki: ack09:45
mupBug #1647139 changed: CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-12520/chroot-autobuild', 'linux64', '/bin/sh', '-c', 'cd /build/qucs-spice && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:312809:47
muphttp_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 <build> <lp> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1647139>09:47
zygamborzecki: +109:47
mborzeckizyga: seccomp is the last bit that's still under release09:47
mborzeckinot for long though :)09:47
mupBug #1697770 changed: can't run juju from snap: "Too many levels of symbolic links" <snapd:Won't Fix> <https://launchpad.net/bugs/1697770>09:50
mupBug #1740130 changed: Use XDG set profile folders <Snappy:Invalid> <https://launchpad.net/bugs/1740130>09:53
pedronisChipaca: can help with those questions you sent in the PR? notice that gadget doesn't apper in any boot env stuff, so not sure how in use would help10:02
Chipacapedronis: d'oh. ok, for gadget. What about kernel?10:02
Chipacapedronis: we're checking both10:02
mupPR snapd#7524 opened: tests: add unit test for gadget defaults with a multiline string <Created by stolowski> <https://github.com/snapcore/snapd/pull/7524>10:03
pedronisChipaca: both, what both?10:03
pedronisor which both?10:03
Chipacapedronis: boot.InUse and model.Kernel10:03
pedronisthat sounds ok10:04
Chipacapedronis: isn't it redundant?10:04
pedronisdoesn't InUse need a revision?10:04
Chipacapedronis: yes10:04
pedronisso what if it's all10:05
Chipacapedronis: (although i've modded it locally to take unset to mean 'any'10:05
Chipacahmmm10:05
Chipacamaybe i've overcomplicated things then :-)10:05
pedronisyes10:05
pedronislikely10:05
Chipaca:-)10:05
pedronisif all,  check model,  if revision check in use10:06
pedronissomething like that?10:06
Chipacayeah, i'll make that explicit10:06
Chipacajust so i don't forget again10:06
pedroniscore, boot base and kernel should have similar rules10:07
pedronis(except core has rules for classic too)10:07
=== arnatious_ is now known as arnatious
pedronispstolowski: I updated #7468 and answered sthe comments10:26
mupPR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>10:26
pstolowskity10:26
zygaah10:27
zygaI learned something about mount namespaces just now10:27
zygaman that stuff is tricky10:27
zygait's just super tricky10:27
zygaon the upside this is invaluable to fixing bugs10:28
zygadetails shortly, let me write them down10:28
mupPR snapd#7522 closed: httputil: set user agent for CONNECT <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7522>10:34
mborzeckianyone with power to cherry-pick and push to 2.42?10:36
zyga2.42 the branc?10:38
zygaanyone10:38
zygathe release? it's an SRU10:38
zygaI must misunderstand your question10:38
mborzeckizyga: hm afaik direct git push to the repo only works for mvo10:38
zygaoh, that's new then10:39
zygaI guess you can propose a PR instead10:39
zygajust target 2.4210:39
mborzeckimhm, opening right now10:39
pstolowskiyeah, why not PR?10:39
mborzeckipstolowski: bc we don't need to run spread then10:39
pstolowskimborzecki: bad bad ;)10:40
zyganaughty :)10:40
mupPR snapd#7525 opened: tests: disable {contacts,calendar}-service tests on Arch Linux (2.42) <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7525>10:40
Chipacapedronis: so... https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate_test.go#L1113211:10
Chipacapedronis: i just broke that test :-|11:10
Chipacagranted it passed by accident before, but it feels like an actual case we want to work11:14
Chipacathat is: current boot kernel is not (no longer) the model kernel, you shouldn't be able to 'snap remove' it yet11:14
Chipacaactually could be no longer or not yet, either way11:14
pedronisChipaca: sorry, how did it work before and how doesn't anymore?11:22
Chipacapedronis: as per above, i no longer call boot.InUse if the revision is unset11:22
Chipacapedronis: it worked up to this point because i'd use snapst.Current as the revision for InUse11:23
Chipacapedronis: sounds like i do need to tweak boot.InUse to check any when unset (could be in a separate pr)11:24
pedronisChipaca: I'm not sure that test make sense11:24
Chipacathat would make life easier :-)11:25
mupBug #1845636 opened: connect-plug-i2c hook failing <Snappy:New> <https://launchpad.net/bugs/1845636>11:26
pedronisif there is a kernel-to-be in a remodel conflicts should prevent to remove it, toward the end of the remodel it becomes in use (at which point checking for any on the other side doesn't) and at the very end we atomically switch the model11:26
pedronisthe current kernel  is still the one from the model except inside the remodel itself11:27
pedronisuntil the remodel is done11:27
pedronisat some earlier point as I said it stops to be in use11:27
mupPR snapd#7526 opened: cmd/snap-confine: allow digits in hook names <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7526>11:28
pedronisChipaca: we let you remove by revision only non-current revisions no?11:28
mupBug #1845636 changed: connect-plug-i2c hook failing <snapd:In Progress by zyga> <https://launchpad.net/bugs/1845636>11:29
Chipacapedronis: correct11:29
pedronisChipaca: it might be that we need to turn that description I just made into a set of CanRemove tests11:30
pedronisor really Remove tests11:30
pedronisthat show you can remove what you expect at various points of the switching11:30
Chipacawith a remodel going on you mean?11:30
pedroniswell doesn't mean to be a real one11:30
pedronisbut to simulate something close enough11:30
pedronisafaict the test you pointed at doesn't correspond to a possible state11:31
pedronis(unless bugs)11:31
mupBug #1638988 changed: Cannot run spread hello world on all-snaps image <snapd:Triaged> <https://launchpad.net/bugs/1638988>11:35
Chipacazyga: don't we have an interface for lxc?11:37
zygaChipaca: not one that would allow you to run lxc-the-command-line-tool11:38
zygaChipaca: that's a general property btw11:38
Chipacazyga: even if you shipped it?11:38
Chipacazyga: just lxc, not lxd11:38
mupBug #1638796 changed: mir clients that use cpu renderable surfaces don't work under confinement <snapd:New> <https://launchpad.net/bugs/1638796>11:38
zygaChipaca: if you shipped it it might work but that's not what the bug is about11:39
Chipacazyga: i've got my spread-snap-contributor hat on11:39
zygaChipaca: casual combination of tools shipped as snaps is not supported11:39
zygaChipaca: when that combination is packaged as a snap11:39
zygaChipaca: if we expand spread to talk to lxc/d directly it's something to consider but I think that's not high priority11:40
mupPR snapd#7527 opened: interfaces/input: support confined snaps accessing keyboard and mouse directly <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7527>11:40
Chipacazyga: i don't understand what you mean there11:40
Chipacazyga: spread has an lxd backend11:40
Chipacawe already expect it to talk to it11:40
zygaChipaca: yes but that backend just invokes lxc as a new process11:41
zygaChipaca: if we agree on that, that's exactly what is not supported in snapd11:41
Chipacazyga: right, so if we ship lxc in the spread snap, that should work if we get the interface11:41
zygaChipaca: yes, that's correct11:41
Chipacazyga: sounds like an easy win, i'll see if i find time to do it11:41
zygaChipaca: if you want to, sure. I was just triaging old bugs as I wait for spread runs11:42
zygaChipaca: IMO we should explore how not changing the spread snap to ship lxc could be supported11:42
zygaChipaca: it's a more complex problem though11:42
zygaChipaca: involving lots of variables like API stability of the cli, passing resources, observing children termination, etc11:42
zygaChipaca: it would, however, allow us to handle this generally11:43
* zyga looks at the next PR11:43
zygaChipaca: IMO osutil.StreamsEqual is buggy11:54
Chipacazyga: oh? do tell11:54
zygaChipaca: it uses ReadAtLeast with a buffer size of 16K11:54
zygaah, sorry11:55
zygajust scrolled down to see the error handling :E11:55
Chipacazyga: you mean the one that comes right after the six-line comment explaining the situation?11:56
zygayeah, I was scrolling down and reached the pair of ReadAtLeast11:56
zygaand got curious about the buffer size11:56
zygaanyway, go have lunch, sorry for the noise11:56
Chipaca👋11:57
mupPR snapd#7528 opened: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <https://github.com/snapcore/snapd/pull/7528>12:16
pedronisnot quite simple but not too big ^12:20
pedronissomething sergiusens pointed out12:20
mupPR snapd#7521 closed: [RFC] many: use --root as first arg to systemctl everywhere <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7521>12:46
zygapedronis: I will skip the standup, conflict12:56
pedroniszyga: I will also be in the conflict12:57
zygaok :)12:57
pedronisChipaca will drive the standup today12:57
sergiusensChipaca: wrt spread lxd, if you ship the lxc binary and your lxd backend is a non local remote, you don't need any interface13:06
sergiusensChipaca: heh, using local would only require being able to talk to the socket13:07
=== ricab is now known as ricab|lunch
mupPR snapcraft#2732 closed: project: use os.sched_getaffinity instead of multiprocessing.cpu_count <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2732>13:18
zygajdstrand: can you please enqueue https://github.com/snapcore/snapd/pull/742113:37
mupPR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>13:37
zygajdstrand: you reviewed that before, v2 is simpler and should be good-to-go13:37
pedroniszyga: I think he is swapping today13:38
zygapedronis: yeah, I was just checking since he's away on IRC13:38
zygathat's fine13:38
zygaI'll ask next week13:39
cwaynekenvandine: ok so the fix did indeed seem to work, let us know if you run into any more issues (or whenever you want us to add new snaps :D)13:58
mupPR snapd#7526 closed: cmd/snap-confine: allow digits in hook names <Bug> <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7526>14:09
=== ricab|lunch is now known as ricab
zygaChipaca: hey14:48
zygaChipaca: I have a question about osutil/cmp_test.go14:48
zygaChipaca: can you please look at TestCmp there14:48
zygaChipaca: the buffer size is fixed but the payload (file size) varies14:49
zygaChipaca: am I reading that right?14:49
pstolowskipedronis: i think failures on #7528 are real, tests/main/base-invalid-type needs updating15:08
mupPR #7528: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <https://github.com/snapcore/snapd/pull/7528>15:08
pedronispstolowski: quite possible15:08
pedronisbut somebody just restarted it15:09
pedronis(not me)15:09
pedronisso I cannot look15:09
pedronisor I'm very confused15:10
Chipacazyga: yes15:10
zygaChipaca: thanks15:10
zygaI'm almost done with that PR15:10
zygaI removed my implemenetation15:10
zygaadded one extra check into yours15:10
zygaand kept the set of tests15:10
pstolowskipedronis: hmm not me15:10
pedroniszyga: I moved the 'snap run --explain' notes to the forum: https://forum.snapcraft.io/t/snap-run-explain/1342715:13
zygapedronis: nice, thank you15:13
pstolowskipedronis: the status is still visible: https://api.travis-ci.org/v3/job/590391360/log.txt15:14
ijohnsonpedronis, pstolowski: not me either15:14
pedronisI was just confused by travis15:14
pedronisI see the problem now15:14
pedronisChipaca: can CanRemove PR be reviewed again? or still WIP? (would not happen today)15:15
zygapedronis: can I give it a stab at implementing a super-simple version of that over weekend? I'm going to stay at home sick anyway15:16
zygapedronis: or would you rather give it to someone else15:16
mupPR snapd#7520 closed: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7520>15:16
pedroniszyga: how far are we from wrapping up robustness?15:17
zygapedronis: I need some jamie time for the reviews, probably a day or so15:18
zygapedronis: it is that and app awareness next week15:18
zygapedronis: I think I can do new stuff now15:18
pedroniszyga: you could start to sketch --explain but might likely have to give it to somebody else to finish depending15:19
zygaok15:19
pedronisit's lower priority than the other things on your plate15:19
pedronisbasically15:19
zygapedronis: ack15:19
pstolowskizyga: what's the plan re https://github.com/snapcore/snapd/pull/6174 ?15:21
mupPR #6174: many: add snap debug refresh-catalogs <Created by zyga> <https://github.com/snapcore/snapd/pull/6174>15:21
zygapstolowski: I'll fix it up next week15:22
zygaor perhaps today if I finish the pass over other PRs15:22
zygapstolowski: needs some deconflicting/rebasing15:22
pstolowskiok, thanks15:23
pstolowskipedronis: btw my #7355 is redy for reviews again15:27
Chipacapedronis: I recentl pushed to the canRemove pr, i think it's good to go but i thought so yesterday and then spread failed :-)15:27
mupPR #7355: interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>15:27
* zyga -> lunch15:29
pedronisChipaca: ok15:29
pedronispstolowski: thanks, probably will look at it on Monday at this point15:30
* ijohnson will miss TGIF, still in middle of reviewing 735515:30
pstolowskiijohnson: take a break ;)15:30
pstolowskiijohnson: btw appreciate it!15:30
Chipacapedronis: i just spotted a bug i think15:31
Chipacapedronis: :-( i'll comment on it in case you get to review it before i fix it15:31
Chipacaat the very list it points to a missing test15:32
Chipacaleast*15:32
Chipacaoh dear me15:32
* Chipaca takes a break15:35
Chipacaahem. For real now.15:39
pedronispstolowski: I did this: https://github.com/snapcore/snapd/pull/7469/commits/700ce5a5d816c37901e686fd689f586b40dbc2e5 in the next PR16:18
mupPR #7469: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7469>16:18
zygaondra: offtopic16:22
zygaondra: I have a thing I wanted to show you16:22
zygaondra: I wrote it earlier this week, perhaps it could be something useful to your team16:23
zygaondra: check this out please https://gist.github.com/zyga/2210f334115645a0014e1ecce22a944c16:23
zygaondra: it's a tool for extracting SD card image off a running system16:23
zygaondra: and streaming it to a nearby computer16:23
zygaondra: there's some "pre-preparation" step that's missing in the script itself (dd if=/dev/zero of=zero bs=4M; rm zero;) but we can consider polishing the script some more16:24
pstolowskipedronis: ty!16:25
zygaondra: it works on core18, can easily work on core16 (I didn't try) and most importantly, on windows / linux / mac on the receiving end16:25
zygaondra: so anyone can easily capture an image and send it for analysis16:25
zygaondra: on windows just double-click on the script and continue (install python first)16:25
zygaondra: on other systems it's more generic16:26
=== pstolowski is now known as pstolowski|afk
ondrazyga that looks interesting!16:32
ondranice one16:33
zygaondra: I have some more ideas to make it robust but I wanted to share a quick prototype with an user that needed it16:34
zygaChipaca: I changed some code you wrote in https://github.com/snapcore/snapd/pull/7484 -- perhaps you could do a review over cmp.go there16:35
mupPR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>16:35
zygaondra: if you end up using it and give it a life please tell me :)16:36
ondrazyga we might use that as we go closer to production and need to debug special cases16:38
Chipacazyga: I might take a peek over the weekend17:15
Chipacaright now, it's beer o'clock17:15
Chipacameaning it's go-get-the-supermarket-stuff o'clock, first17:16
Chipacaput-the-pizza-in-the-oven o'clock17:16
Chipacathat kinda stuff17:16
Chipacahave a great weekend y'awl17:16
Chipacaijohnson: you too, when your time comes17:16
Chipaca:)17:16
Chipaca👋17:16
mupPR snapd#7528 closed: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7528>17:18
mupPR snapd#7529 opened: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/7529>17:41
zygapedronis: I was about to look at 7529 but I think I am too tired today17:47
mupBug #1639984 changed: Granting incorrect access in the shutdown interface in snapd <snapd:Triaged> <https://launchpad.net/bugs/1639984>18:02
mupBug #1640281 changed: Conflict - Telemetry project, Snap, uses snapd and snapctl <snapd:Triaged> <https://launchpad.net/bugs/1640281>18:02
mupBug #1641752 changed: request for snap interface that expose userspace device APIs <snapd:Confirmed> <https://launchpad.net/bugs/1641752>18:05
* zyga stops triaging bugs and EODs18:07
zygait's 8PM anyway ...18:07
zygattyl, enjoy your weekends everyone18:07
mupBug #1640114 changed: configure hook output not accessible <snapd:Confirmed> <https://launchpad.net/bugs/1640114>18:08
ijohnsonbye zyga, hope you feel better18:08
zygaijohnson: thank you :)18:08
pedroniszyga: that one is simple in itself but is at the end of a long chain19:48
joedborgafternoon all, i'm still having trouble debugging my configure hook - is there anyway I can see the output of the hook (snapd seems to swallow -x and echos etc)20:57
joedborgand  it's not shown in the snapd journal20:57
ijohnsonjoedborg: unfortunately no, not unless your configure hook exits with exit code 120:58
ijohnsonbut if it always does that, then you can't install the snap20:58
joedborgijohnson: can i run it within a snap shell? `sudo snap run --shell`20:59
joedborgijohnson: ah yes, looks like i can :)21:00
ijohnsonyes you should be able to21:01
joedborgijohnson: is there any plan to be able to float errors / feedback from hooks?  if not, I might raise an LP21:05
ijohnsonno not really, hooks aren't really meant for that kind of thing, but feel free to file an LP bug21:10
ijohnsonjoedborg: actually what you're looking for are snap warnings, see https://forum.snapcraft.io/t/warnings/759921:15
joedborgijohnson: that looks promising, but i need more immediate feedback for validating of `snap set`21:17
joedborgijohnson: i guess the set-health is the best way21:21
ijohnsonjoedborg: well if you are validating snap set, couldn't you just exit1 if it's wrong?21:34
ijohnsonthen the user sees the output21:34
joedborgijohnson: yeah, i've got with `set-health` as it's more about getting 2 required configs set (as well as validating).  i have noticed that there's no record of `blocked` message in `snap warnings`21:36

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