/srv/irclogs.ubuntu.com/2018/06/14/#snappy.txt

niemeyerjdstrand: Replied, sorry for the delay there00:04
diddledanis my system messed up somehow? https://www.irccloud.com/pastebin/zgh6Nf9E/00:18
=== jamesh__ is now known as jamesh
mborzeckimorning04:59
zygaGood morning05:41
zygaI need to take the dog out and I will be back here shortly05:41
* zyga reviews 531606:25
mupPR snapd#5316 closed: store, et al: kill dead code that uses the bulk endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5316>06:51
zygawhaa06:52
zygaI was reading it :06:52
zyga:-)06:52
zygabut that's fine06:52
zygaI guess I should make some coffee and meet with mvo then06:52
mvozyga: yeah, but rush06:53
zygarush or no rush? :D06:54
mvozyga: no rush06:54
mvozyga: sorry06:54
mvozyga: I guess that is a sign that I need more tea06:54
mborzeckii think we're not picking up enough nvidia/cuda libraries06:58
mborzeckiCUDA 9.1 runtime ships libcudart.so* which is not included in our globs06:59
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:01
zygamborzecki: I would love a proof of concept nvidia snap07:01
mborzeckizyga: this and the 'mesa' snap07:02
zygamesa is slightly different07:02
zygaI don't know where it fits07:02
zygais it all a bunch of .so files07:02
zygaor does it need to be in some weird specific spot07:02
mborzeckicuda sdk - merge 1.2GB download :/07:19
mupBug #1639746 changed: Snap launching other snaps <snapd-interface> <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1639746>07:36
Saviqhey all, where do I file bugs about emails from snapcraft.io? Thunderbird flags them as spoofing because of links pointing to a different place than they display. And then when viewing the online version, Firefox warns about it not being a fully safe connection (assets loaded via http)07:54
zygaSaviq: good question, I don't know honestly, perhaps popey or JamieBennett knows?07:55
JamieBennetthttps://github.com/canonical-websites/snapcraft.io07:57
davidcalleSaviq: https://github.com/canonical-websites/snapcraft.io/ is a good place for it, make sure you tag @evandandrea and @lewciie07:57
zygaThank you07:57
* zyga thinks that it would be good to add a small piece of text to the page footer for this07:58
zygamaybe worth a small PR07:58
Saviqthanks!07:58
mborzeckigithub is down or sth?08:01
mupPR snapd#5322 opened: cmd/snap-confine: include CUDA runtime libraries <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5322>08:02
Chipacamoin moin08:10
pstolowskimvo, mborzecki, zyga : do you want to take another look at https://github.com/snapcore/snapd/pull/5288 ? i'd like to land it and see if it improves situation; i've added a little more debug and also added rm -rf cleanup step before the test starts, in case we're reusing the machine and previous cleanup didn't work for whatever reason (i suspect this could explain our issues as I think in such case our caching kicks in and08:10
pstolowskiwe don't see retry on download, only on assertion fetch)08:10
mupPR #5288: tests: econnreset/retry tweaks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5288>08:10
zygalooking08:11
mborzeckiwanted to check cuda with snaps on arch, but the cuda package is installed under /opt/cuda, so our carefully crafter s-c globs basically went out the window08:24
Chipacamvo: you around?08:30
mvoChipaca: yes08:30
Chipacamvo: you have dev access to the hello-world snap, yes?08:31
mvoChipaca: let me check, yes08:31
mvoChipaca: you have as well08:31
ChipacaI do?08:31
mvoChipaca: sure, check your mail08:31
Chipacaah08:31
ChipacaI've been invited to perhaps :-)08:32
mvoChipaca: ;)08:32
mupPR snapd#5323 opened: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5323>08:38
Chipacahrmph, the hello-world data in the store tests has been edited in undocumented ways :-(08:41
Chipacait's testing for content plugs that aren't there for ex08:42
pedronismborzecki: zyga had a suggestion for the InstanceName doc comment, you +1 it, are you applying it in the PR or when you actually implement the logic in a follow up?08:42
mborzeckipedronis: must have missed it, let me push a quick patch08:43
pedronisChipaca: I think we have grown more features that is fair to stick on hello-world :/08:43
mborzeckipedronis: pff yeah, didn't stage it :(08:43
Chipacapedronis: I know, and it's fine, but that's why there's a "download the json, and then <do this to it>" comment in the tests08:44
Chipacagrmbl, grmbl, *AND* grmbl.08:44
pedronisI don't think I ever noticed that08:45
pedronisit's probably/likely partly my fault, sorry08:45
zygapstolowski: yeah, let's merge 5288 .08:46
pstolowskik, thanks08:46
mupPR snapd#5288 closed: tests: econnreset/retry tweaks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5288>08:47
pedronismborzecki: np08:48
zygamborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5315/files08:54
mupPR #5315: cmd/snap-update-ns: introduce MimicRequiredError, make ReadOnlyFsErro… <Created by zyga> <https://github.com/snapcore/snapd/pull/5315>08:54
zygaI applied your suggestion now08:54
popeySaviq: yeah, a github issue about the mails is best, thanks.08:55
Saviqpopey: https://github.com/canonical-websites/snapcraft.io/issues/729 https://github.com/canonical-websites/snapcraft.io/issues/73009:05
popeythanks Saviq09:06
mupPR snapd#5324 opened: snap: run snap-confine from the re-exec location <Created by mvo5> <https://github.com/snapcore/snapd/pull/5324>09:07
pstolowskilife-changing: travis-ci.org##.ansi filter in ublock kills the cpu hungry log window and only leaves 'raw log' button09:33
zygamvo: I saw that, I'm making progress on the system interfaces now09:33
=== boxrick_ is now known as boxrick
mvozyga: nice09:36
zygamvo: there's one more special case to handle09:37
WimpressMorning mvo zyga09:37
zygabut we can do the smart thing as well (not touch it)09:38
zygabase policy09:38
zygawe should translate system back to core there09:38
WimpressI've been asked by an ISV if it is possible to run snapd in Docker.09:38
zygaWimpress: hello, how are you doing sir?09:38
WimpressMy frst thought is no, but I "think" I saw someone show me snapd working in Docker.09:38
zygaWimpress: from what I know it is maybe possible but we don't test that today. It depends on how docker confines the container09:38
pedronisand also what kind of distro is inside I suppose09:39
zygayes, that's also a factor09:39
WimpressSo technically possible but not an "out of box" experience?09:39
jameshzyga: I had a few more thoughts about the "old portals" issue, which I've added to the PR: https://github.com/snapcore/snapd/pull/5271#issuecomment-39723505809:40
mupPR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>09:40
jameshzyga: in short, I agree that it is a problem but think we might have been overestimating how prevalent it is09:41
zygajamesh: thank you for the write up and analysis, I think I tend to agree09:43
zygalet me think about this today and try to catch jdstrand later to discuss, we will reply there09:43
pedronispstolowski: couple small comments on the disconnect hooks one09:52
mupPR snapd#5325 opened: interfaces: add Repository.AllInterfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/5325>09:58
zygapstolowski: https://github.com/snapcore/snapd/pull/532509:59
zygasmall helper for upcoming branch09:59
mupPR #5325: interfaces: add Repository.AllInterfaces <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5325>09:59
Chipacajamesh: question out of the blue: do you know how to tell gnome what 'app' a window is from?10:00
Chipacajamesh: or how it does that for non-gnome apps?10:00
Chipacajamesh: snapped apps don't have an 'app' in looking glass, and they don't have an icon, and I suspect it's the same thing10:00
zygaChipaca: knowing gnome I'd not be surprised if it used google to search each time you open the activities screen10:01
Chipacazyga: :)10:01
jameshChipaca: I'm not sure exactly how gnome-shell links the windows to apps off the top of my head (or if it differs for Wayland vs. X11 apps), sorry.10:01
zygaThe comment said /* Faster than scanning desktop files */10:01
Chipacajamesh: no problem10:02
Chipacajamesh: I'll continue to ask random people in the street then10:02
Chipaca:)10:02
jameshI know the code in unity7 had some nasty hacks10:02
* zyga thinks http://blog.lenovo.com/en/blog/the-new-thinkpad-p52/ is crazy cool10:03
jameshsome of which persists in snapd with  the BAMF_DESKTOP_FILE_HINT stuff10:03
Chipacajamesh: the BAMF_ thing was to tie it into bamfdaemon,  and some older apps also needed to set WMClass10:05
Chipacajamesh: but gnome shell indeed seems to ignore both these things :-)10:05
zygaChipaca: can we run gedit and see what it does10:06
Chipaca(bamfdaemon, i'm not surprised)10:06
zygaChipaca: I suspect the best way to learn is just to observe a real app10:06
ChipacaI'd be completely unsurprised if it were something like "the desktop file needs to be named exactly like the binary"10:06
Chipacaalso saddened10:06
popeythat is in fact the case AIUI10:06
jameshright.  IIRC, bamfdaemon would read the environment of the process via /proc to look for that variable to make the link10:06
zygaChipaca: all bugs are shallow ... eyes... sad... (pours more alcohol)10:07
Chipacapopey: do you know if there's a way to override that?10:08
popeyi do not, I comply10:08
Chipacapopey: how?10:08
popeymaybe the desktop: entry in snapcraft.yaml10:08
zygaChipaca: only 20 separate implementations to check :-(10:08
popeyi always put the .desktop file in snap/gui10:08
popeye.g. https://github.com/snapcrafters/opentoonz/tree/master/snap/gui10:09
mupPR snapd#5324 closed: snap: run snap-confine from the re-exec location <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5324>10:10
Chipacapopey: let me test that then10:10
popeyok, thanks10:10
popeywould be nice not to have to do it10:10
popey(but we always do)10:10
Chipacahuh10:13
Chipacawell i'll be jiggered10:13
Chipacarenaming the desktoop file to kiosceditor_kiosceditor did the trick10:13
mborzeckizyga: can you take another look at #5306?10:14
mupPR #5306: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>10:14
Chipacapopey: https://forum.snapcraft.io/t/ubuntu-18-04-and-snap-issues/5832/8?u=chipaca10:15
popey<310:15
Chipacapedronis: in overlord/snapstate's fakeStore there's a bunch of code that uses a snap's channel to decide what to do10:17
Chipacapedronis: but I'm killing channel (and anychannel) as arguments to snapinfo -- they're not used anywhere in non-test code10:17
Chipacapedronis: do you think it'd be reasonable to give fakeStore an out-of-band way of knowing what's wanted of it?10:18
zygamborzecki: sure10:18
Chipacapedronis: (i think i might add channel back just for these tests, and kill it in a followup, as it'll get gnarly)10:20
mupPR snapd#5326 opened: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>10:21
zygamborzecki: is instance name and instance key the same thing, can they be used interchangeably?10:23
Chipacazyga: AIUI instance name == name + "_" + key10:24
mborzeckizyga: foo_bar, foo_bar === instance name, foo === snap name, bar === instance key10:24
zygathanks10:25
mborzeckipedronis: #5314 was updated, please take another look10:27
mupPR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>10:27
zygamborzecki: done10:33
zygaanother instance of10:35
zygaJun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Mount process finished, but there is no mount.10:36
zygaJun 14 09:24:29 arch snapd[28173]: Jun 14 09:24:27 arch systemd[1]: var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount: Failed with result 'protocol'.10:36
zygain mvo's branch10:36
mupPR snapd#5324 opened: [RFC] snap: run snap-confine from the re-exec location <Created by mvo5> <https://github.com/snapcore/snapd/pull/5324>10:55
mvozyga: the snap-confine on core18 is a bit thorny, I wrote some options down in 5324 maybe we can chat after lunch about the pros/cons, nothing seems perfect but maybe the alternative plan in 5324 is worth persuing11:01
zygaok, I'm reading your PR now11:01
zygathe system interfaces approach is clean so far11:01
zyganot finished yet but very simple what's going on (for now)11:01
ondramvo ping11:02
mvoondra: pong (but almost at lunch)11:03
ondramvo sure, will try to be quick :)11:03
pedronismborzecki: thanks will look in a little bit11:03
ondramvo have I missed something about pi3 kernel and dtb?11:03
mvozyga: yeah, its not hard, just feels a bit "uneven" that we need to use different dirs for the profiles on classic and core and to reuse the snap profile dir11:03
mvoondra: missed in what sense? I haven't looked at this in a while11:04
ondramvo I'm getting a bit confused, so are we free to update kernel as much as we like and dtbs update correctly?11:04
mvoondra: well, we unblocked the kernel updates a while ago because the dtb diff was just a single line in a serial port uart freq11:04
ondramvo I thought we are not updating dtbs from kernel snap to system-boot at all11:04
mvoondra: but of course if this changes and the diff becomes bigger we need to halt things again11:04
mvoondra: we are not doing it in snapd, that is correct11:05
mvoondra: I mean, we don't copy stuff around into /boot at this point11:05
mvoondra: we have no code for this11:05
ondramvo so we are not updating dtbs, but rather relying that kernel does not really change there11:05
mvoondra: correct11:05
mvoondra: yeah, its just so that people get kernel updates but we still have not tackled the dtb update problem11:06
ondramvo can you please comment on that forum post? as Gustavo thinks there is no problem to solve, and I do not think this is correct assumption11:06
niemeyerondra: That's not what was written there11:07
mvoondra: do you have a link for me?11:07
niemeyermvo: https://forum.snapcraft.io/t/proposal-to-enable-pi2-3-major-kernel-updates/5842/811:07
mvoniemeyer: ta11:07
niemeyermvo: np11:08
ondraniemeyer you are claiming that we have updates flowing and there is no problem, but clearly we do not have dtb updates flowing11:08
ondraniemeyer so to me there seems to be mismatch in understanding what is actually updating11:09
niemeyerondra: I specifically said:11:10
niemeyera) The pi2 kernel had a major update just weeks ago, which disagrees with what was presented in the first few sentences11:10
niemeyerb) We have a design for dtb updates in place11:10
niemeyerc) If your needs are different, they need to be put into that design instead of besides it11:10
mupPR snapd#5327 opened: store: switch store.SnapInfo to use the new v2/info endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/5327>11:11
Chipacapedronis: ^11:11
niemeyerd) If you do critical updates like this in hooks it will likely destroy systems in the future11:11
niemeyere) We should have a meeting to discuss this11:11
pedronisChipaca: thx, will look11:11
niemeyerondra: Which of these points is incorrect or unreasonable?11:11
ondraniemeyer I have been talking about this very problem with mvo in Berlin and he told we are still not updating dtbs when we update kernel,11:12
ondraniemeyer so you are telling we are updating dtbs?11:12
zygamvo: is /etc/apparmor.d really read-only on core?11:12
niemeyerondra: I said the pi2 kernel had a major update. Is that true or not?11:12
mvozyga: yes11:12
zygamvo: I see, well, that's okay11:13
niemeyerondra: You're arguing with things I did not say11:13
zygaI mean, it's harder but we can manage11:13
mvozyga: the trouble is that it has a bunch of subdirs11:13
mvozyga: otherwise I would say we just make it writable11:13
ondraniemeyer was that update carefully crafted in a way it does not require dtb changes and can use old dtbs?11:13
zygamvo: if we can move s-c profiles in all the cases to a new place I'm okay with that11:14
mvoondra: we checked carefully that the new kernel would work fine with the old dtbs11:14
ondraniemeyer proposal is targeting issue when dtbs are not updated with kernel updates, you claim there is no such a problem11:14
zygamvo: and we can consider deploying snapd.apparmor.service to core too, to be 100% sure that we have freedom here11:14
ondraniemeyer I do not agree with that11:14
niemeyerondra: Which of the points above says that?11:14
niemeyerondra: In other words, you're saying that yourself.. not me11:15
mvozyga: interessting11:15
zygamvo: this would allow us to use a directory such as /var/lib/snapd/apparmor/internal or whatever we want11:15
zygamvo: and not clash in any wy11:15
zyga*way11:15
ondraniemeyer from forum "@ondra My understanding is that we have updates to pi2 boards flowing, and that the dtb problem in that specific case was a red-herring. "11:15
mvozyga: I like internal/11:15
zygamvo: or ...11:15
niemeyerondra: Exactly.. we had a pi2 kernel update just weeks ago11:15
zygasystem ;)11:15
ondraniemeyer so you are saying there is problem11:15
mvozyga: heh11:15
zygamvo: but anyway, that's besides the point, let me read your branch carefully11:15
niemeyerondra: I said we *DID UPDATE IT*11:15
ondraniemeyer and I can update kernel freely?11:15
mvozyga: I think that is great input, we can probably move it all11:16
niemeyerondra: THis is not theoretical11:16
zygamvo: the service is already in place, we should see if we can just enable it (it's harmless)11:16
ondraniemeyer so you don't see problem that we cannot update dtbs?11:16
zygamvo: that is, ship it and enable via the snapd.run-from-snapd-snap service11:16
niemeyerondra: Why are you still making stuff up?11:16
mvozyga: we need to extend it to cover system/ as well, right?11:16
zygamvo: yes but it is our service11:16
zygait's simple to extend11:16
mvozyga: cool11:17
zygaand we can ship it in snapd snap11:17
ondraniemeyer because you are telling me there is no problem to solve11:17
niemeyerondra: So you hate the blue color?11:17
zygaand it's a blessed shell script instead of one liner for the purpose of being shellchecked11:17
mvozyga: I need to run for lunch, lets catchup afterwards (and/or feel free to write your thoughts into the open PR)11:17
zygamvo: sure, go ahead11:17
ondraniemeyer OK whatever, clearly impossible to talk to you11:17
niemeyerondra: Honestly, this is nuts.. I'm literally saying "let's please have a meeting to discuss your needs" and "if your needs are different let's integrate in the design"11:18
zygaondra, niemeyer: I'm sure we are perfectly capable of solving the problem if we talk together, I really recommend that we have a call later today/tomorrow11:18
niemeyerzyga: That's literally the first thing I said :)11:18
zygaperhaps ondra is not aware of the existing plans or there is a technical detail that we are missing11:19
niemeyerQuoting:11:19
niemeyer"""11:19
niemeyerNevertheless, we already have a design for the proper representation of dtbs that can be updated. Let’s please not cook a different solution without looking at that design first. Even if it’s incomplete for your needs, we should improve on it instead of besides it. Happy to discuss this in our next meeting.11:19
niemeyer"""11:19
* zyga hugs niemeyer and ondra *together* 11:19
pstolowskianyone looking at interfaces-calendar-service test flakiness? if not, i'll coz it's driving me crazy11:20
zygapstolowski: there's a PR from cachio but I don't quite understand how that helps or what the problem is11:20
zygapstolowski: I'd recommend diving into it , yeah11:20
zygaand it seems to happen on all kinds of systems so a small loop with debug would be good11:20
pstolowskioh ok, let me first check what did he do11:20
zygathank you!11:20
pstolowskiright.. it seems that retry didn't help, the PR failed on this test again11:22
pstolowskiinteresting11:22
mborzeckizyga: i think it's related to gvfs which does fuse internally11:23
zygammm11:23
zygamborzecki: yeah, it feels like something is mounted there11:23
zygaotherwise rm would not fail11:23
mborzeckimaybe worth trying is to kill gvfsd* in restore11:23
mborzeckibut that's a long shot anyway :P11:23
zygaI think we need to reproduce and see what's there11:25
cachiopstolowski, the retry didn't work?11:26
pstolowskicachio: it seems to, your PR failed on travis11:26
pstolowski*so11:26
cachiobut failed on a different test11:29
cachiothere are 2 tests failing for the same reason11:29
cachiocalendar and contacts11:29
cachiopstolowski, I was trying to see what it is locking the files inside11:30
cachiobut when I debug it, it is already unlocked11:31
mborzeckicachio: when it fails, can you check if there's anything in that directory (gvfs-metadata) and if there are any gvfs processes alive, if so, kill them11:31
=== chihchun is now known as chihchun_afk
cachiomborzecki, running again to see11:37
mborzeckiok, i'm off to the kindergarten, bbl11:38
mupPR core18#26 closed: hooks: add path <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/26>11:40
pedronisChipaca: did a first pass,  main point is that I think the helpers merit unit tests (also because the current shape of responses doesn't exercize all corners of them)11:41
pedronislooks good though otherwise11:42
* Chipaca ~> lunch11:53
jdstrandzyga: what did you want to talk about? a snapd-apparmor.service for core?11:57
zygajdstrand: I'm not sure, yesterday or today/11:58
zygayesterday I only wanted to ask for a re-review of chopTree PR11:58
zygathere are some interface PRs in flight but I think those are handled well on elsewhere already11:59
zygaI'm sorry, I think the answer is "I'm not sure"11:59
jdstrandzyga: it seems https://github.com/snapcore/snapd/pull/5271#issuecomment-39723505811:59
mupPR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>11:59
zygaah11:59
zygayes, that's that!11:59
zygaso here I tend to agree with James, please think about it and let's discuss in the PR (since James is far away in terms of timezones)12:00
jdstrandzyga: but I would caution you on moving snap-confine to internal/. I mean, the idea of that is not bad in and of itself, but understanding why the profiles aren't being loaded in /etc/apparmor.d is important before suggesting a solution12:00
jdstrandzyga: do we understand the race/problem there?12:00
jdstrandzyga: as in, are we just kicking the can and going to see it happen with internal/ too?12:01
zygajdstrand: this is a more subtle question, it is specific to core systems only12:01
zygawhere we cannot write to /etc/apparmor.d12:02
zygabut need a place to store snap-confine profiles for snapd reexec12:02
zygaand using /var/lib/snapd/apparmor/profiles was undesired as it would need a new prefix not to clash with snap profiles12:02
zyga(but we could do that)12:02
jdstrandwhy are we reexecing on core?12:02
zygathis is the new work on a standalone snapd snap12:02
zygawhere core18 or core16 is used for booting12:02
zygabut snapd is in a separate snap12:03
zyga(snapd.snap)12:03
zygathere's a new protocol for running that12:03
zygabut it involves writing a profile for snap-confine for a given snapd snap revision12:03
zygamvo: I just realised there is a complication12:03
jdstrandit still isn't clear. why are we reexecing on core?12:03
zygajdstrand: because core18 and core16 don't ship a snapd snap12:03
zygaer12:03
zygasnapd itseslf12:03
jdstrandI mean, core16 and core18 won't have snapd, so there is nothing to reexec12:04
zygathis isn't really reexecing, it needs a new name12:04
jdstrandso?12:04
jdstrandok12:04
zygaso we will exec snap-confine from /snap/snapd/123/usr/lib/snapd/snap-confine12:04
zygawe need to generate a profile for that in snapd12:04
zygaand we need to store it persistently12:04
jdstrandbut regardless of what it is called, snapd needs to put a snap-confine profile somewhere12:04
zygaand load it on boot12:04
zygathe question is where do we store it12:04
zygaand /etc/apparmor.d is read only12:04
zygaand has a host of other things inside that makes it harder for us to use as a sync directory12:05
jdstrandthis is getting into the territory of why I thought the snapd snap should not be a normal app snap12:05
zygait is not a normal app snap12:05
jdstrandbut a new 'type: snapd'12:05
jdstrandok, then that has evolved. last I heard it was12:06
zyga(new type is an interesting idea but it's orthogonal, it has special handling already)12:06
zygait is not a normal app snap in the sense that it doesn't expose itself as a service12:06
zygaor snap as an app12:06
zygait's all handled externally with snapd.run-from-snapd-snap.service12:06
Chipacapopey: remember that xps? something was burnt out getting power to the ram; £65 later i've got an xps12:06
jdstrandit is 'type: app' with special-casing. more and more as we go. that is orthogonal, but the more special casing, the more it shouldn't be 'type: app'. it isn't an app. it is a snap from managing and running apps12:07
jdstrands/from/for/12:07
jdstrandanyway12:07
jdstrandsure, put it in apparmor/internal, leave cache the same12:07
zygajdstrand: ack, thank you12:07
zygajdstrand: I agree about making it explicitly special and I think we will over time, this is just a way to hit core18 work on time12:08
jdstrandyou will then need snapd-apparmor.service12:08
zygajdstrand: yes, but as I said, it is just a proposal at this stage12:09
jdstrandnote, I still consider /etc/apparmor.d as read-only a good property on core12:09
zygamvo and I will talk about what the options are and then decide what to pursue12:09
jdstrandbecause it makes it impossible to mess with system policy, tunables and abstractions12:09
zygajdstrand: yeah, I think that's fine too, it's just something we were not aware of a short while ago :)12:09
jdstrandwe actively chose to have /etc/apparmor.d/cache read/write but /etc/apparmor.d read-only12:10
mupPR snapd#5328 opened: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5328>12:10
jdstrandzyga: I was surprised to see that the 'profile not found' issue was not on your list. it seems I see at least once a day an issue where someone is hitting it12:37
zygahmm, indeed, I should look into it12:38
jdstrandzyga: thanks12:39
zygaI need to scan the forum for existing reports12:39
mvojdstrand: has apparmor upstream ever considered /var/lib/apparor.d in addition to /etc/apparmor.d ?12:39
mvojdstrand: having that as an official place would make some things on core18 easier for me, i.e. the snap-confine dynamic profile generation12:40
mvozyga: I was thinking about snapd.apparmor.service, the downside of using it is robustness, having something on core18 itself load profiles (like the current apparmor service) would mean things work even if snapd.run-from-snap does not work for whatever reason12:41
mvozyga: the snapd.* services are all generated only in /run/ at this point12:41
mvozyga: wdyt?12:41
mvozyga: I wonder if I should write a forum post about this, it has more edges than I expected it to have12:42
zygajdstrand: I see what you are saying but once run-from-snapd-snap stops working we are toast anyway12:43
zygano "snap", no "snap revert"12:43
zyganothing works at that time12:43
mvozyga: well, yes. however if in such an even at least the snaps themself keep running that would be preferable it seems12:44
mvozyga: different levels of de-generation :)12:44
jdstrandmvo: apparmor upstream has not dictated how downstreams load policy12:51
jdstrandmvo: apparmor upstream is interested in making a systemd unit that can be used across distros. this will allow adding additional directories, etc12:52
mvojdstrand: ok12:52
jdstrandmvo: today, it is an Ubuntu-ism to load /var/lib/snapd/apparmor/profiles12:53
jdstrandmvo: it would be possible for the apparmor init to add /var/lib/snapd/apparmor/internal12:53
jdstrandmvo: it is also possible to ship /var/lib/snapd/apparmor/snap-confine....12:53
jdstranderr12:54
jdstrand/var/lib/snapd/apparmor/profiles/snap-confine....12:54
zygathat is a directory12:54
zygaah12:54
zygayes12:54
jdstrandthen the init doesn't have to change anything12:54
jdstrandwe already have snap-update-ns. in there, it isn't impossible to think about snap-confine.something too12:55
jdstrandensure dir could ignore stuff that was prefixed with snap-confine.12:55
jdstrandetc12:55
mvojdstrand: you mean to use the "snap-confine." prefix?12:56
mvojdstrand: just like we use the snap-update-ns. prefix?12:56
zygayes, that would work12:56
mvojdstrand: if we go with a unique prefix we could use "system." as this is already not availalbe as a snap12:56
mvozyga: (cc) -^12:56
mvoand then we just write it in both core and classic into the same location - that will be nicer than the current mess^Wapproach12:57
zygamvo: system could even be a snap as snap profiles are snap.*12:57
jdstrandmvo: yes, that is a possibility, then you are working within the current Ubuntu-ism12:57
zyga(so snap.system.foo)12:57
zygavs system.whatever12:57
mvozyga: good point12:57
jdstrandsystem. obviously works too12:57
mvojdstrand: yeah, I think I will go with this, thank you and zyga  for your input!12:58
jdstrandnp12:58
ogra_niemeyer, seriously, i'm not attemprting to discuss anything with you, i was asking for a link to the design you referred to and you shut the topic down ... and you call *me* "passive aggressive" ?!?!12:58
niemeyerogra_: I won't discuss it here either. That's not passive aggressive, that's not having an argument at all. I'll talk to ondra in a place we can understand each other more easily.12:59
ogra_niemeyer, pretty please do you have a link or dont you have a link, i do *not* want to discuss anything but you refer to a design that i'd like to be aware of13:00
ogra_without any intend to discuss anything with you i just want to know about it since i will likely have to use it13:00
* zyga -> standup13:02
=== doko is now known as doko_
=== doko_ is now known as doko__
=== doko__ is now known as doko
ondraniemeyer random question, are we planning to support upgrade from UC16 to UC18?13:04
niemeyerondra: Yeah, definitely.. we need some good work there13:04
jdstrandroadmr: hi! totally not urgent request for pulling r109113:04
jdstrandlool: that has what we talked about ^13:05
roadmrjdstrand: sure thing, I'll put it in the queue and roll the ball from there13:05
jdstrandroadmr: thanks13:06
looljdstrand: cool13:06
ondraniemeyer then I'm gently pointing out, dtbs are not compatible between 4.4 and 4.15 kernels on pi13:12
niemeyerondra: Let's discuss the topic in our next call.13:13
ondraniemeyer sure, more than happy to do so13:14
niemeyerondra: Thanks13:14
snappy_Hi guys..   How can we delete/de-register the snap from the snap store?  Please someone guide me to de-register the snap in the store...13:16
popey^ sparkiegeek13:25
diddledansomething's wonky with the newly rolled-out buildd:13:30
diddledanhttps://www.irccloud.com/pastebin/zDAQYaLN/13:30
diddledanspecifically it's failing to run my wget command in override-build13:31
sergiusensdiddledan: newly rolled out buildd?13:35
diddledansergiusens: https://forum.snapcraft.io/t/released-launchpad-buildd-163/592513:36
sergiusensdiddledan: btw, had you tried corebird (the snap) with the communitheme ?13:36
diddledanno, I haven't13:36
sergiusensget transparent backgrounds13:36
sergiusensmight be a comunitheme issue (ah, that thing is so hard to spell)13:36
sergiusensooh, transparent proxy, that removes a lot of pain from some of the plugins13:37
diddledanit might fix some plugins, but it's preventing wget from working in my build13:40
sergiusensdiddledan: so wget is not found or the network setup is getting in the way?13:41
diddledanit's refusing to download the url - wget says no13:41
diddledansee my paste above13:42
diddledanthe code that drives that is13:43
diddledanhttps://www.irccloud.com/pastebin/vFsm4jzb/13:43
Chipacamvo: La Pampa, https://goo.gl/maps/ugAEKg51sjq, vs the Pampas, https://en.wikipedia.org/wiki/Pampas#/media/File:Pampas_Range.png13:46
Chipacamvo: not to confuse with the Pampa, an indigenous people13:46
* Chipaca really off now13:46
sparkiegeekcjwatson: ^^13:47
pedronismvo: as I said, I think I'm going to pick up this, tomorrow tough likely:  https://github.com/snapcore/snapd/pull/527013:48
mupPR #5270: snap,client: show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270>13:48
mvoChipaca: heh, thank you!13:49
mvopedronis: great, thank you13:49
mvopedronis: I will try to tame snap-confine on core18 now13:49
pedronismvo: we should probably block the --format one tough,  until that one is done, if that's ok13:49
mvopedronis: sure, just add "blocked" there13:49
pedronisok, thx13:50
mupPR snapcraft#2155 closed: build_providers: support for communicating with a qemu VM <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2155>13:50
jdstrandzyga: fyi, I added the small changes you requested in PR 525013:53
mupPR #5250:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Reviewed> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>13:53
zygaAck, I will look shortly. Taking the dog out now13:54
jdstrandmvo: fyi, that ^ is going to really help people like popey who are seeing desktop environment hangs and crashes upon interface connection13:54
jdstrandmvo: I was hoping this would make 2.33, but it didn't. if you are respinning a 2.33, feel free to consider it (and to say 'no' if you want it to bake. if its in trunk, people like popey can use the edge snap)13:55
popeyI'm still using your shonky build of snapd13:55
popeyand not had any desktop explosions yet13:56
jdstrandpopey: I'm so glad it has helped you13:56
* diddledan hides the c413:56
jdstrandpopey: keep an eye on that PR and you can start using the edge one13:56
popeyjdstrand: unrelated. firefox specifies removable media but doesn't autoconnect. Do *they* need to request that?13:57
mvojdstrand: it seems risky for 2.33.113:57
popeyBecause I wanted to upload a photo from a CD (yes, a CD) and had to connect it to get access13:57
mvojdstrand: but if you and $more people assure me it solves more problems than it creates I'm open to this13:58
jdstrandpopey: well, somebody does, yes13:58
popeywould it be okay if I requested it? :D13:58
popeyor do you need the upstream to do it13:58
jdstrandmvo: at its heart, it is a simple change. run udevadm trigger with --subsystem-nomatch=input13:59
jdstrandby default13:59
jdstrandand add in other stuff as needed13:59
jdstrandI will be on holiday tomorrow and next week13:59
mvojdstrand: oh, that evolved since I looked at last then I think. that sounds more innocent now14:00
jdstrandmvo: I think it's safe (which is why I mentioned it at all), but I also won't be around if it gets pushed out. I'm also fine for 2.3414:00
mvojdstrand: I have a look, given that its (mostly aiui) nomatch that makes it much more appealing14:00
cjwatsondiddledan: Could I have the full build link, please?14:01
mvojdstrand: I will ask for it to get squash merged, I assume this is ok with you?14:01
mvojdstrand: to make the cherry-pick to 2.33 easier14:01
jdstrandmvo: yeah, it needs a second review so if you did that it could double as a review for 2.33.114:01
jdstrandmvo: yes14:01
diddledancjwatson: this it? https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/24905014:01
mvojdstrand: great, thank you. once I finished my current task I will look at it14:02
jdstrandmvo: thanks for your review and consideration :)14:02
mupPR snapd#5321 closed: tests: fix interfaces-contacts-service test retrying to remove share dir <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5321>14:02
jdstrandpopey: you can request it14:03
cjwatsondiddledan: mm, somebody's broken BSI's ability to show other users' builds, but I can work it out from that ...14:03
diddledancjwatson: that's the amd64 build, this is the i386 variant - both fail the same way: https://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/24905314:03
cjwatsondiddledan: Is it clear that this is a regression?  That snap has never had any successful builds14:04
diddledanit's a brand new snap. it builds fine locally in cleanbuild14:04
cjwatsonRight, which says nothing about whether it's a regression in launchpad-buildd :)14:05
cjwatsonI can certainly look, it's just less of a panic if it's not obviously a regression.14:06
diddledan@Wimpress can you trigger a build on tmnationsforever to test whether it's a regression as you're using a similar build?14:08
cjwatsonI'm setting it up locally14:09
cjwatsonIt *could* be something wrong with the extra layer of proxying, although you can see the access log there reporting 20014:11
popeydiddledan: actually tmn wasn't hooked up to build yet. I have just done so. (which will trigger a build)14:11
cjwatsonAnd much more complicated things have worked14:11
cjwatsonSo let's see if it reproduces in my local setup14:11
diddledanthanks :-)14:12
popeyhttps://build.snapcraft.io/user/snapcrafters/tmnationsforever14:12
diddledanlooks like the `build-on:` isn't respected by the builders yet (but that's completely orthogonal. I'm just observing.. :-)14:13
cjwatsondiddledan: I know, I've been working on that for the last couple of weeks14:14
diddledanI'm betting it's a pain to get working14:14
cjwatsonIt is very definitely in progress14:14
cjwatsonMost of the pain has been in sorting out APIs for Bazaar-backed things14:14
diddledanyou need to download the project (into a builder?) before you have the required bits to tell you where to build.. glad I'm not working on that :-p14:15
cjwatsonThe actual mechanics of build-on are relatively straightforward, just code that kyrofa supplied for me and plumbing14:15
cjwatsonNah14:15
cjwatsonWe have internal APIs to fetch files from Git repositories14:15
diddledanaha14:15
cjwatsonAnd I've put the same thing together for Bazaar14:15
diddledansneaky backroom dealings!14:15
cjwatsonAlthough now that you mention it I'm going to have to work out how that works for stuff hosted on GH, argh14:16
cjwatsonsudden non-triviality realisation!14:16
diddledanoops, sorry :-(14:16
* diddledan cuddles everyone who needs it14:17
cjwatsonmight need to start doing internal imports or something14:18
zygare14:23
cpaelzerhi, I assume I was lazy not paying attention to some mails - but it seems my small snap was sorted out in the snapstore14:23
cpaelzerI still have it installed14:24
cpaelzervirt-machine-type      0.0.2                   3     edge      paelzer       -14:24
cpaelzerbut can't find it on the store14:24
cpaelzermaybe I violated some new check/rule14:24
cpaelzerhow would I debug that other than digging through the pile that is my mail inbox?14:24
sparkiegeekcpaelzer: define "can't find it on the store" ?14:24
cpaelzerlike search on https://snapcraft.io/store14:25
cpaelzeraren't all snaps there?14:25
sparkiegeekcpaelzer: you haven't released it to stable, the search APIs don't (yet) return snaps that haven't been pushed to stable14:25
cpaelzeroh, that explains why snap find doesn't find it either14:25
cpaelzerthanks sparkiegeek14:26
cpaelzerI thought it was shown on find in the (very) early days14:26
cpaelzerbut that is fine14:26
cpaelzeryeah I can install from edge14:26
cpaelzerthanks sparkiegeek14:27
zygajdstrand: will you have time to review https://github.com/snapcore/snapd/pull/5081 before your holidays?14:28
mupPR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>14:28
popeydiddledan: huh, tmn fails too. https://launchpadlibrarian.net/374512942/buildlog_snap_ubuntu_xenial_amd64_7d2139885b31f8fd1187b9d3482243b9-xenial_BUILDING.txt.gz14:29
sparkiegeekpopey: looks different? is wget in the build-packages stanza?14:30
popeyNo, it's in stage-packages.14:30
popeyworks in cleanbuild though *shrug emoji*14:31
cjwatsonYeah that looks like an obvious bug14:31
diddledanyeah, I had to add wget to build-packages. that's a different issue :-)14:31
cjwatsoncleanbuild uses a slightly fatter base image14:31
sparkiegeekpopey: 🤷14:31
popeyok, thanks will fix that14:31
cjwatsondiddledan: speaking of which you need "build-packages: curl" in the gog-galaxy-version part14:31
popeydoing gods work sparkiegeek thanks14:31
cjwatsonI don't think that's the bug here, but noticed in passing14:31
diddledanI do?14:32
sparkiegeekpopey: I had to leave people hanging :)14:32
diddledanI'm not using curl anywhere14:32
cjwatsonYeah you are14:32
cjwatsonLast line of your snapcraft.yaml14:32
diddledanoh yeah, I see it, thanks14:32
diddledanI should swap that for wget14:32
anarcatgrml... so more firefox problems! :) since 60.0.2 (or 60.0.1? not sure) u2f authentication is failing14:32
cjwatsonEh, curl is more convenient for piping to stuff, so *shrug*14:33
anarcatit works well in firefox-esr from the debian packages and used to work in earlier snap versions, so i'm not sure what's going on14:33
anarcatthe u2f token is a Yubikey NEO and it still works with chromium as well14:33
anarcati'm wondering how/if i can rollback to an earlier snap version14:33
cjwatsondiddledan: reproduced locally; trying under strace to get a better idea of what's failing14:33
popeyChipaca: nice on the xps! The chromebook I got is all up to date (as far as it will go) and will probably live on a dusty shelf now :)14:37
pedronisniemeyer: https://forum.snapcraft.io/t/possible-evolution-path-for-snap-store-endpoints-regarding-epoch/587114:38
jdstrandzyga: yes, see your inbox :)14:39
jdstrandthat's one for today14:39
anarcatshould i send my question on the forum instead?14:39
zygaoh, thanks14:40
sparkiegeekanarcat: snap help revert in general, 'snap revert firefox'  in particular?14:40
zygajdstrand: about readlinkat, I suspect it's an older conffile14:40
zygajdstrand: so one thing about todays discussion, I'd love to get snap-confine profile out of /etc14:41
zygaand out of conf-file hell14:41
anarcatsparkiegeek: thanks, i somewhat missed that14:42
jdstrandI know you would and it makes some sense, especially with the core snap discussion from earlier14:42
jdstrandI've said that elsewhere14:42
anarcatsparkiegeek: what if i confirm the regression? should i file this as a bug somewhere?14:42
mvozyga: I updated 532414:43
zygathanks14:43
anarcatsigh... reverting to 60.0.1 doesn't fix the issue :/14:43
mvozyga: it uses most of the ideas you suggested, I think its nice now, no more special cases, profiles get loaded on boot etc14:43
mupPR snapd#5306 closed: cmd/libsnap-confine-private: introduce a helper for splitting snap name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5306>14:44
popeyjdstrand: we're getting a failure in the store where we're using build, so surprised it's failing... https://dashboard.snapcraft.io/snaps/tmnationsforever/revisions/6/14:44
popeyit says checksums don't match14:44
sparkiegeekanarcat: I'm not familiar with the details of U2F, could it be https://forum.snapcraft.io/t/snapped-firefox-unable-to-use-smart-card/5719 ?14:44
anarcatsparkiegeek: probably related, yes. it's strange because it used to work...14:45
anarcatsparkiegeek: is there a way to revert further back?14:45
jdstrandpopey: it figures that as soon as I see my email that there was nothing reported, something was reported14:46
popeyYou're welcome. :)14:46
jdstrandpopey: I really don't know anything about build. is it using a new enough snapcraft?14:47
zygajdstrand: ack, thank you for the mail14:47
jdstrandpopey: are you doing anything weird like an unsquash/fix something/mksquash?14:48
sparkiegeekanarcat: look at the --revision flag14:48
cjwatsonjdstrand: hey the snapcraft version is right there in the build log14:49
cjwatson(though may not be readily linked to from the store I suppose)14:49
* jdstrand doesn't have the build log url14:49
jdstrandyeah, it isn't yet (that would be great! :)14:49
jdstrandpopey: is this electron-builder?14:49
cjwatsonjdstrand: you can start from https://launchpad.net/~build.snapcraft.io/+snap/7d2139885b31f8fd1187b9d3482243b9-xenial to find this one14:49
popeyjdstrand: no, we dont do anything shonky14:50
cjwatsonjdstrand: but in general, BSI uses whatever's latest in xenial-updates14:50
popeyjdstrand: it's just wine (dumped deb) and another couple of scripts dumped in14:50
anarcatsparkiegeek: how do i find which revisions are available? info does not say much14:51
zygaanarcat: you can only refresh to a revision you already have on your system (snap list --all will tell you)14:51
cjwatsondiddledan: so your problem is simply that the URL you're trying to fetch doesn't exist14:52
anarcatzyga: thanks14:52
cjwatsondiddledan: Downloading https://dl.winehq.org/wine-builds/ubuntu/pool/main/wine-devel_3.9.0~xenial_.deb...14:52
cjwatson(you get a 200 from the CONNECT and then a 404 from the underlying tunnelled protocol; that confused me for a while)14:52
diddledano_O14:52
mvocachio: can you point me to the snapcraft.yaml for the rsync snap please?14:52
mvocachio: nevermind, just found it14:53
diddledanoooh. running locally sets $SNAP_ARCH, but for some reason that's not there in the buildd...14:53
cachiomvo, ok14:53
cachioit is in snapd repo14:53
sparkiegeekcjwatson: nice spot14:53
anarcatuh14:53
cjwatsondiddledan: probably because you're using snapcraft as a snap14:53
mvocachio: yeah, thanks, I will build a core18 version of this :)14:53
anarcatso this never worked apparently14:53
cachiomvo, great, thanks14:54
cjwatsondiddledan: it's the snap execution path that sets SNAP_ARCH, so that's really the wrong variable to use here14:54
cjwatson(I'm not sure exactly what would be correct)14:54
sparkiegeekanarcat: the other possibility is that changes in core could have affected it, so might be worth jumping back to latest firefox and walking back through core versions14:54
cjwatsonmaybe just $(dpkg --print-architecture) ?14:54
anarcator at least it's not a firefox-induced regression: i can't make it work with any snap i have on disk (60.0, 60.0.1, 60.0.2)14:55
anarcati wonder if i had that working with 5914:55
anarcatsparkiegeek: ah yes, i could try the revert trick with core?14:55
sparkiegeekanarcat: yes14:55
anarcatis there a way to see which updates took place when? "logs" and "changes" doesn't show anything useful14:55
diddledanthanks for spotting that :-)14:56
anarcathahaha reverting core to 16-2.32.6 breaks all font display whee!14:57
anarcatwow, blocky hell14:57
anarcatwell shit - i think i had that problem before, but i don't remember how i solved it14:59
anarcathttp://paste.anarc.at/snaps/snap-2018.06.14-10.59.05.png14:59
anarcatboom ^14:59
sparkiegeekanarcat: ... nice14:59
anarcatyeah15:00
anarcatso that was triggered by reverting core from 16-2.32.8 to 16-2.32.615:00
anarcati tried reverting back to 16-2.32.5 as well, no dice, and then reverting *forward* to 16-2.32.8 does not fix the issue15:00
anarcatand also, none of the core versions fix the u2f issue either15:00
cjwatsondiddledan: np15:01
* diddledan goes to sit in the corner with the cone-shaped hat with a big "D" written on it15:02
cjwatsondiddledan: FWIW it might help if you used wget --no-verbose rather than wget --quiet15:02
cjwatson--quiet turns off all output, including errors15:02
diddledanhttp://static.tvtropes.org/pmwiki/pub/images/dunce_hat.jpg15:02
cjwatsonso it's pretty unhelpful in this kind of situation15:02
cjwatson--no-verbose means you get one line of output in the successful case, and something useful in the error case15:03
popeyjdstrand: oddly a later build worked fine!?15:03
anarcatsparkiegeek: any other suggestions?15:04
sparkiegeekanarcat: are you back to sensible fonts on latest core/firefox ?15:05
anarcatsparkiegeek: nope15:06
anarcatsparkiegeek: i'm trying to remove and reinstall FF now15:06
diddledanI just got a checksums don't match, popey , jdstrand15:06
anarcati think it's what fixed it the last time15:06
diddledansame, normal build on BSI15:06
anarcatwell that's one frustrating day15:06
jdstranddiddledan: what is the snap?15:09
diddledanhttps://build.snapcraft.io/user/diddledan/gog-galaxy-wine-snap/15:10
diddledangog-galaxy-wine15:11
cjwatsonjdstrand: https://launchpad.net/~build.snapcraft.io/+snap/be52b943c0d4d977217aac0ad5a8ad1c-xenial/+build/249197 is an affected build15:12
cjwatsonsnapcraft 2.42.1 says the build log15:12
cjwatsonI don't really know the toolchain here but let me know if it looks as though LP is doing something wrong here15:12
anarcataaand remove + install fixed the blocky font problem15:13
jdstrandcjwatson: yes, thank you15:14
jdstrandpopey: that sounds like there is still a lurking timestamp issue15:15
jdstrandas in, the resquash takes too long and the timestamps are different in the resquashed snap15:15
popeySounds plausible.15:16
anarcatsparkiegeek: sigh... and core 16-2.32.5 still exhibits the same u2f problem15:16
jdstrandit is weird that this has been enabled for 4 days and today is the first it is reported15:17
cjwatsonwait, you're relying on the unsquash/resquash all happening within the same second or something?15:17
cjwatsonhave you considered using faketime?15:17
jdstrandcjwatson: obviously we shouldn't be. I'm speculating there is a bug15:17
anarcattesting this is excruciating: i need to revert, uninstall firefox, reinstall firefox, for every iteration15:17
* cjwatson nods15:17
jdstrandcjwatson: squashfs-tools has not been super friendly for us. it would, for example, recreate symlinks during resquash with the current time rather than what was in the inode in the squash.15:18
cjwatsonhelpful15:19
jdstrandcjwatson: I'm suspecting something else in there. faketime is an interesting option I'll look into15:19
jdstrandindeed15:19
jdstrandroadmr: please disable resquashfs15:20
roadmrjdstrand: on it15:20
roadmrjdstrand: done15:20
pedronisa 2nd review of #5328 would be nice, it's small and only test code15:22
mupPR #5328: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5328>15:22
zygapedronis: done15:25
jdstrandroadmr: thanks15:25
jdstrandpopey, diddledan: your next uploads should work15:25
pedroniszyga: thx15:25
diddledanthanks :-)15:25
popeythanks jdstrand15:25
mborzeckipedronis: thanks for the review, i'll try to push an update soon so that we could probably land the branch sometime tomorrow if there are no more issues15:30
jdstranddiddledan: interesting:15:33
jdstrand-drwxrwxrwt root/root                 3 2018-03-07 04:41 squashfs-root/var/spool/samba15:33
jdstrand+drwxrwxrwx root/root                 3 2018-03-07 04:41 squashfs-root/var/spool/samba15:33
jdstranddiddledan: your snap had a sticky dir and the resquash did not15:33
jdstrandI'll look into that15:33
jdstrandcurious, same with tmnationsforever15:38
jdstrand-drwxrwxrwt root/root                 3 2018-03-07 04:42 squashfs-root/var/spool/samba15:38
jdstrand+drwxrwxrwx root/root                 3 2018-03-07 04:42 squashfs-root/var/spool/samba15:38
diddledantmnations is built using a very similar set of packages15:38
pedronismborzecki: ok, added another small comments about a TODO15:39
mborzeckipedronis: thanks15:39
mborzeckipstolowski: current master failed with econnreset :P15:39
pstolowskinoooo15:39
jdstrandit is weird that a subsequent build would produce different results for tmnationsforever15:39
pstolowskidamn15:39
mborzeckipstolowski: https://travis-ci.org/snapcore/snapd/builds/392288895?utm_source=email&utm_medium=notification15:40
jdstrandwell, it could be an overflow or something in squashfs-tools. anyway, I'll look into it15:40
cjwatsonsergiusens: not quite transparent proxy, just transparent handling of authentication15:40
cjwatsonsergiusens: I wouldn't rip out the proxy user/pass handling from snapcraft 'cause it is technically correct, but it should put less pressure on that to be absolutely correct15:41
mborzeckipstolowski:what if we could simulate network issues by using a proxy instead?15:42
pstolowskimborzecki: same story.. download request is happy after 1st attempt and we proceed with fetching assertions.. which fail and are retried as expected. but the test expects download to fail and be retried15:44
pstolowskimborzecki: we could i guess, but there must be an explanation..15:45
mborzeckipstolowski: is it using fakestore?15:45
pstolowskimborzecki: no15:46
mborzeckipstolowski: what if it used, and we add some error injection contraption to it?15:46
mupPR snapd#5328 closed: snapstate: stop using evolving SnapSpec internally, use an internal-only snapSpec instead <Simple> <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5328>15:47
mborzeckipstolowski: https://github.com/tylertreat/comcast https://github.com/shopify/toxiproxy both are written in (surprise, surprise) Go15:48
pstolowskimborzecki: we could, but current approach should work too :/15:48
pstolowskii don't know.. maybe gcloud is actually so crazy fast sometimes that it manages to download entire huge test snap before we apply iptables rule and download simply succeeds? fwtw i saw this download completed in ~10s when i executed download manually on gcloud spread machine15:52
pstolowskiwith ~10s it would be too slow and the test would do the right thing.. but maybe it's faster sometimes15:52
pstolowskidunno15:52
sergiusenscjwatson: no worries, we cannot remove it as we have known instances of people depending on them; but it does put us in a position where we need to solve specific use cases only16:04
mborzeckiis github slow for anyone else too?16:04
mborzeckipedronis: https://github.com/snapcore/snapd/blob/master/asserts/device_asserts.go#L218 is this where we'd check for valid snap names in model assertion?16:08
* zyga takes a break for an hour, no biking this time, just coffee and a new book16:39
zygaI need to vent my mind and rest for a while16:40
=== pstolowski is now known as pstolowski|afk
zygaafter that I'm back to system slots mvo :)16:40
zygajdstrand: thank you for the review on 508116:43
zygaI agree with everything but one remark about having enough data to pick * vs */16:43
zygaperhaps I didn't understand you there16:43
zygaif you don't have time to see my comment there before your holidays then don't worry, I will improve the comments and land and we can polish this more after you return16:44
zygaI will now use this to construct apparmor permissions for mimics and this will fix one of the two remaining layout bugs :)16:44
pedronismborzecki: yes16:46
mborzeckipedronis: ack, looks like a 3rd (or 4th?) copy of snap.ValidateName()16:47
mborzeckipedronis: anyways, added a todo note and pushed everything to github16:47
pedronismborzecki: maybe, anyway, yes for now a todo is ok16:47
pedronismborzecki: also I put some notes in the topic as well, don't know if you saw those16:48
mvozyga: ta16:49
mborzeckipedronis: yup seen those, thanks for posting them16:50
niemeyerpedronis, Chipaca: Here are some notes from today's call:17:13
niemeyerhttps://forum.snapcraft.io/t/possible-evolution-path-for-snap-store-endpoints-regarding-epoch/5871/517:13
cjwatsonkyrofa: https://code.launchpad.net/~cjwatson/launchpad/snap-parse-architectures/+merge/347998 FYI17:15
niemeyer"On Tuesday, June 12, we incorrectly sent you an email stating that your billing account had been terminated for non-payment. No action is required on your part, and there has been no change to your active billing accounts. This email was sent in reference to billing accounts that had already been terminated."17:15
cjwatsonkyrofa: initial work, more to come, but this is what integrates your code most directly17:16
niemeyer<317:16
niemeyerGCE17:16
kyrofaAh, cjwatson, awesome!17:31
kyrofaLooks like I didn't quite get the python2 compatibility I was hoping for judging from the changes-- not too bad I hope?17:34
cachioChipaca, hey, there is a comment on #524217:34
mupPR #5242: tests: new test for joystick interface <Reviewed> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5242>17:34
Chipacacachio: hey17:35
Chipacacachio: me?17:35
cachioit needs your opinion17:35
cachioChipaca, yes17:35
Chipacaah, seen it now17:35
Chipacacachio: replied17:36
Chipacacachio: we've not done that work yet, so it's still the only way to do it17:37
mvozyga: progress on 5324 - with that I managed to run a trivial core18 spread test on a real(ish) core18 image17:37
* mvo calls it a day with that success17:37
cachioChipaca, great, thanks!!17:40
cachiomvo, congrats17:41
niemeyermvo: \o/17:46
cachiomvo, is it possible to run the snapd suite?17:57
mupPR snapcraft#2160 opened: many: refactor snapcraft.yaml loading out of load_config <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2160>18:14
* Chipaca EODs, for great justice18:14
mupPR snapd#5329 opened: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>18:28
cjwatsonkyrofa: very minor unicode_literals handling, but nothing serious18:33
* cachio afk18:48
cjwatsonkyrofa: the only really substantive change I made was to allow snaps to declare that they build on architectures that LP doesn't support, which seems wise to me18:58
kyrofaIndeed, I suppose that makes sense19:01
bdxhaving a bit of an issue with python deps showing up for packages that define #/usr/bin/env python3 as their header20:58
bdxhttps://paste.ubuntu.com/p/XZnpjyzKbz/20:58
bdxI cat the gunicorn exe and I think its just getting the wrong env20:59
bdxhttps://paste.ubuntu.com/p/zBkpvyRXt7/20:59
bdxdue to the fact that python3.6 is actually what is being used ....20:59
bdxI'm not really sure what exactly is going on .... last time I built this snap everything checked out but that was a few months ago, and on xenial21:00
bdxbut now, following a build/install of the snap it seems packages are borked because of the env possibly21:01
bdxoh man ... I was so turned around ... pretty sure I've found my way22:13
binarycreationsOh man, I do not know what I am doing wrong...22:46
binarycreationsThis is my first attempt at creating a snap. I am trying to snap the anki desktop client.22:47
binarycreationsA gist of my snapcraft.yaml is available (https://gist.github.com/binarycreations/3991eba94a9dc78bb9ee1e3d66168e88)22:47
binarycreationsI am building my snap in a 16.04 Ubuntu VM using Vagrant so it is the server version of Ubuntu22:48
binarycreationsI then run the snap on my host which is Arch Linux22:48
binarycreationsThey problem that I seem to have is, whilst the downloaded anki binary works fine on my host within the VM and snap I get a error from anki stating it can't find or load the libfontconfig.so22:49
ondraniemeyer ping22:53
binarycreationsIs that an indication of a missing package? (i.e. I should find the package that includes that linked library in the stage-build)22:54
binarycreationsIs it due to the fact I am trying to build and run a snap on Ubuntu Server, where the app requires Ubuntu Desktop (as in an X server and other related dependencies that would be detected by ldd and added to the snap?)22:54
niemeyerondra: Hey22:57
ondraniemeyer hey22:57
ondraniemeyer  do we have interface, something like light weight content interface, which would allow one snap to change configuration of another snap?22:57
niemeyerbinarycreations: The forum is generally a better place for those discussions as it allows people to respond at the best time for them without you having to wait here and without the conversation scrolling off22:58
binarycreationsOkay, cool. I drop another question on there.22:59
niemeyerondra: Not anything built-in that would allow the equivalent of "snap set" across snaps.. we did discuss something like that a while ago, but only lightly22:59
niemeyerondra: I think it'd make sense to eventually have that as a proper mechanism22:59
ondraniemeyer agree22:59
ondraniemeyer I will kick off forum post about it to start gathering context23:00
niemeyerondra: Sounds good, thank you23:00
niemeyerondra: I think it can literally be some kind of interface that would enalbe "snapctl set" to take an extra argument with a snap name23:01
niemeyerondra: We'd condition that to only work if the interface is connected23:01
niemeyerondra: and we might allow auto-connection if both snaps are from same publisher, similar to how we do the content interface23:01
niemeyerondra: I mean, by default.. we'd also allow auto-connection after manual reviews as usual23:02
ondraniemeyer but wouldn't you want to limit this between snaps A->B? Or you are thinking to have ability to configure all snaps?23:02
ondraniemeyer yeah23:02
ondraniemeyer sorry I misunderstood, so between defined snaps23:02
niemeyerondra: We need to think carefully.. but I think we have some good precedence in the content interface.. the issues are very similar, even if the actual "API" is different23:03
ondraniemeyer yep23:03
ondraniemeyer one can go crazy there and start defining per config keys, but I do not thing we need that fine control23:04
ondraniemeyer I will kick of forum post and let's continue there23:05
niemeyerondra: We still want to have schemas for the configuration, as a general feature.. we might eventually hook the two things together and allow partial access to a configuration via the schema.. but agreed, that's future23:05
niemeyerondra: Thanks23:05
ondracool23:06
mupPR snapcraft#2161 opened: many: automatically detect dependency changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2161>23:51

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