=== cpaelzer_ is now known as cpaelzer [05:10] PR snapd#5851 closed: tests: don't fail interfaces-bluez test if bluez is already installed [05:10] morning [05:12] mborzecki: hey, good morning [05:14] mvo: hey hey, how was your trip back? [05:15] mborzecki: hey, it was mostly good, one train was super delayed but fortunately I found an alternative so no harm done [05:16] mvo: nice [05:16] mborzecki: and you? had a good trip as well? [05:16] mvo: yup, no hiccups, though i got home around midnight [05:17] mborzecki: nice [05:24] PR snapd#5847 closed: overlord/snapstate: improve cleaup in mount-snap handler [05:35] PR snapd#5809 closed: tests: using single sh snap in interface tests [05:36] 40 PRs, not bad [05:36] PR snapd#5855 opened: tests: cleanup copy/paste dup in interfaces-network-setup-control [06:33] PR snapd#5855 closed: tests: cleanup copy/paste dup in interfaces-network-setup-control === pstolowski|afk is now known as pstolowski [07:01] mornings [07:07] pstolowski: hey [07:16] hey pstolowski [07:20] PR snapd#5672 closed: tests: make nfs test available for more systems [07:27] mvo: have you seen this? https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/30 [07:33] mborzecki: no, let me see [07:34] mborzecki: hm, that is a complication indeed [07:34] mborzecki: do we considered it metered if GUESSS is set? or only if we know for sure? [07:37] mvo: yes, it's both NM_METERED_YES and NM_METERED_GUESS_YES [07:38] mvo: YES is only set if it was explicitly marked by the user, otherwise it's GUESS_YES [07:38] mborzecki: aha, I see [07:42] mvo: the idea of defaulting to refresh.metered=hold only on classic devices is actually quite appealing [07:43] mborzecki: yeah, it looks like thats the best way out of this mess [07:43] mvo: in the notes from friday niemeyer mentioned more strings for refresh.metered, do you recall any examples? [07:44] mborzecki: I think there was a slight misunderstanding in that there was this notation that the old config option was a yes/no boolean [07:44] mborzecki: but it was not iirc, it is already "" or hold [07:44] mborzecki: iirc that were the bits we talked about [07:45] mvo: ah, ok, well it's kind of 2 state now to be fair :) [07:46] mborzecki: yeah, its boolean :) but also using mostly sensible names (not just yes/no) [07:48] * pstolowski does the expensify. yuck [07:49] zyga: quick question - when you did the flock to mount you mentioned that systemd did timeout on boot when the mounts are serialized. how many snaps did you had installed when trying this? [08:05] mvo: left a note under #5792 [08:05] PR #5792: [RFC] {config,snap}state: add new refresh.metered=force option and flip default [08:07] mborzecki: ta [08:08] moin moin [08:10] mborzecki: wrt metered, how's it looking? [08:11] reading the feedback from field, it sounds like we might want an 'auto' setting that only looks at _yes (and not _guess_yes) [08:11] Chipaca: hey, some updates in the forum topic, https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/30 [08:11] yeap, was just reading that [08:12] Chipaca: well, _yes is half solution for desktop users [08:13] mborzecki: yes, otoh they're much more able to tweak it than devices out there [08:13] Chipaca: we could tweak the nm wrapper to return whether the result is a guess or not and use that to pick proper default for desktop/device scenario [08:14] Hey hey. I just want to say I’m off today. [08:14] zyga: are you sure? because you don't _look_ off [08:15] mborzecki: it's looking like we'll need something like that t make erryone happy [08:18] Chipaca: that and 'refresh.metered=force', you could mark the connection as metered for some other application but would stiill want snap updates [08:19] mborzecki: 'force' was the 'ignore metered', right? and what was 'assume metered'? [08:21] zyga: thanks! enjoy your time off [08:22] Chipaca: yeah, servicing my laptop now [08:22] See you later :-) [08:22] zyga: boot your mac sometime [08:22] Chipaca: there wasn't, there's 'hold' which covers yes && guess_yes, and default '' which was like ignore-metered [08:23] zyga: ah you already have, thanks :-D [08:23] … wait no it's dead [08:23] drat [08:23] mborzecki: we need to map out scenarios [08:23] mborzecki: i think [08:27] Chipaca, buy your own mac! popey might be able to help as well [08:27] wat wat [08:28] kyrofa: I possess one of AFAIK 2 canonical-owned macs! [08:28] kyrofa: alas it's too old to be useful at this point [08:28] I have a macbook air if needed [08:29] Chipaca, yeah I have one of the first intel ones, I know what you mean [08:29] popey: good to know in case something urgent comes up; zyga has a lab I can ssh into for a bunch of different things and his mac is just one of 'em, and I thought I'd test https://github.com/sergiusens/homebrew-snapcraft on it ahead of Sergio, but it's not urgent at all [08:29] kk. [08:30] I tested it using linuxbrew, which is probably good enough for now :-) [08:39] Chipaca: i know you love terminals. Did you know on a bare tty, the tickmark next to a verified snap is a green diamond? [08:39] popey: yes [08:39] ok [08:39] popey: I thought that wasn't too bad [08:39] popey: I'm open to being wrong though [08:40] I haven't investigated the alternatives. I expect you're right. [08:40] popey: add --unicode=never to see if it'd be better with "linux terminals don't do unicode" [08:40] a green asterisk [08:41] I am honestly not sure which I prefer. [08:42] Chipaca: I’ll boot it in 30 min [08:43] wonder what it would look like on this bad boy... https://www.ebay.co.uk/itm/WANG-Computer-WANG-Terminal-Model-2246-Computer-IBM-XT-AT-DEC-SPERRY/113221449456 [08:43] so tempted [08:43] Returning home from apple support shop [08:48] popey: eww, AZERTY [08:49] diamonds are forever, stay with it ! [08:55] PR snapd#5823 closed: snapcraft.yaml: add workaround for LP:#1791871 [09:00] popey: also: it'd be cheaper, easier and more reliable to take a too-old-to-be-useful laptop and use it to boot linux as a dumb serial terminal [09:00] popey: OTOH, not as cool [09:00] and this wasn't ever about cheap, easy, nor reliable :-) [09:00] May I point you at my ThinkPad X61S running Ubuntu Core :D [09:01] That's me! :D [09:05] popeycore: you can point all you want, but my virtual reality irc headset isn't working to see where you're pointing at [09:06] mvo: can we refresh go-flags, or was ppc bocking that? [09:07] Chipaca: lets try it [09:07] Chipaca: if it needs an updated sys/unix we are in trouble [09:07] mvo: some nice fixes landed over the weekend [09:08] mvo: if you look at 'man snap', and search for '^ *info', you'll see a bug [09:08] that's fixed :-) [09:09] mvo: it does not depend on sys/unix [09:09] its unit tests no longer work with 1.6, alas, but that's another issue [09:09] (easy to distro-patch a fix if needed) [09:09] (and what we currently use has the same issue afaik) [09:09] Chipaca: "easy" ;) [09:09] Chipaca: but yeah [09:09] souper easy [09:09] :-) [09:10] Chipaca: it will be a small pain for the debian downstream [09:10] mvo: are they still on 1.6? [09:10] 1.7 works [09:10] Chipaca: oh, right, sorry [09:10] Chipaca: of course not [09:10] phew [09:10] Chipaca: so hopefully no problem for anyone except us [09:11] Chipaca: and we don't run the unit tests of it so … [09:11] hehe [09:11] mvo: if we vendor it, we're fine [09:11] Chipaca: yeah, we do [09:23] Chipaca: mvo: how does this sound? https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/32 [09:25] mborzecki: terrible, awful, it's the worst thing to ever be put up on the internet, and it's all the wrong colour [09:25] hahaha [09:25] mborzecki: maybe I should click the link [09:35] anyone using discord under KDE? [09:37] Chipaca: re [09:37] Chipaca: do you need access now? [09:37] mborzecki: i am [09:37] zyga: I could use it, i dont need it [09:37] Chipaca: try now [09:37] it should be up [09:38] * zyga just rented the house for TV production on Wednesday [09:39] zyga: computer says yes [09:39] whee [09:39] Chipaca: FYI today is the day when a new macOS is available, you can try now and then later when I upgrade [09:39] zyga: didn't you have homebrew installed? [09:39] Chipaca: I think the next OS doesn't leave any old apps behind so you can reasonably expect everyone to be using this version soon [09:40] Chipaca: no, I didn't [09:40] Chipaca: want me to install it? [09:40] Chipaca: I have go installed [09:40] zyga: I should be able to do it myself without sudo even [09:40] but not homebrew [09:41] Chipaca: cool, let me know if you need anything [09:41] zyga: hmm, it's asking me for sudo to do thinks in /usr/local. It seems doing it in my home needs more options. Which would you rather I do? [09:41] Chipaca: just use sudo [09:41] I gave you access [09:42] * zyga hugs and trusts Chipaca with his main computer :) [09:42] * Chipaca accepts the hug, and trusts the brew people for this [09:46] damn, desktop files are a mess [09:50] Chipaca: there's an update to command line tools for Xcode (aka the toolchain) [09:50] Chipaca: shall I ignore that for the duration of your experiments? [09:51] zyga: yes please [09:51] ok [09:55] zyga: now you have more go than before! [10:01] Hellos o/ [10:02] hey niemeyer! [10:05] zyga: done [10:06] zyga: what's the difference between today's update and before? so I can write "tested with _____" [10:06] niemeyer: hey! how are you? good trip back? [10:06] Chipaca: today is macOS high sierra [10:06] Chipaca: tomorrow is macOS Mojave [10:06] hey mvo, niemeyer [10:06] * zyga is off b [10:07] mvo: Yeah, that was surprisingly easy :) [10:07] but apparently terrible at it :) [10:07] Was lucky enough to get out of the plane and straight into the bus [10:07] though I really want to take a nap, sleeping with two kids and a dog in one bed is ... not perfect [10:07] I was home in no time [10:07] niemeyer: nice change, right? :) [10:07] zyga: 8) [10:10] niemeyer: nice! [10:22] currently "snap interface"'s help says "List snap interfaces" and "snap interfaces"' help says "List interfaces in the system" [10:23] would "Show details of snap interfaces" and "List interface slots and plugs in the system" be better and more accurate? [10:23] niemeyer: zyga: ^ [10:23] Chipaca: +1 [10:23] Chipaca: First one should probably be singular [10:24] ... of snap interface [10:24] niemeyer: if you just do "snap interface" it lists them all though [10:24] yeah, that's a nice change [10:24] Chipaca: while the second should be plural [10:24] List interfaces ... [10:24] Chipaca: all instantiated and connected [10:24] Ah, no.. slots and plugs [10:24] aaah [10:24] * zyga runs and tries to be off [10:24] zyga: which were you adding to there [10:24] Chipaca: Ah, interesting [10:25] niemeyer: ¯\_(ツ)_/¯ [10:25] trying to make it less interesting :-) [10:25] Chipaca: +1 either way :) [10:25] "List interfaces' slots and plugs" works too [10:26] but then we get the dreaded "plural possessive" discussion [10:26] :-) [10:26] I blame degville [10:49] PR snapcraft#2289 opened: local source: only filter out snapcraft artifacts [11:02] PR snapd#5856 opened: cmd/snap: tame the help zoo [11:02] niemeyer: can you make it so I can request a review from degville? (currently I can't) [11:03] Hmm, I guess he's not in the org yet [11:03] I am looking through though - how about `List slots and plugs for all interfaces' as an alternative? [11:04] degville: if you could say so on the PR, then we can keep tabs on it all [11:04] Chipaca: will do. [11:04] degville: thanks [11:05] I expect "Admin" to be contentious, just didn't find anything better and thought it best to just push it and see [11:06] Chipaca: Done [11:06] degville: You should have received an invite [11:06] niemeyer: got it, thanks. [11:15] Chipaca: I reworked 5717 a bit with gustavos input in mind, would be great if you could have another look to see if looks sane. it will unblock two more PRs [11:16] * Chipaca is afk, punching trees [11:16] j/k. Looking. [11:20] ta [11:26] mvo: q: why can't one do GET things in degraded mode? === pstolowski is now known as pstolowski|lunch [11:36] Chipaca: I was simply conservative, happy to allow that [11:37] mvo: I'd just make it degraded -> nothing but GET [11:38] mvo: but I don't know if there are exceptions that would warrant the flag [11:38] I don't _think_ so :-) [11:38] by definition, GET should not be writing state [11:38] Chipaca: lets say YAGNI and I will just allow get and we add the flag again when we need it? [11:38] and we never have bugs [11:38] so, \o/ [11:38] mvo: sgtm! [11:38] mvo: less flags -> less code -> less bugs [11:39] huzzah [11:40] !!! [11:40] * mvo goes and makes it so [12:01] PR snapd#5857 opened: userd: extend the list of supported XDG Desktop properties when autostarting user applications [12:01] * Chipaca ~> lunch break [12:07] off to pick up the kids === pstolowski|lunch is now known as pstolowski [12:37] Chipaca: can you check what's the value of XDG_CURRENT_DESKTOP in your env? [12:38] mborzecki: my EAAS costs are 2¢ per request, and .5¢ per byte response [12:39] Chipaca: EAAS - env as a service? :) [12:39] mborzecki: your request was: $XDG_CURRENT_DESKTOP [12:39] mborzecki: your response is: "Unity" [12:39] Chipaca: ooh, that's 16.04? [12:40] mborzecki: you account is now overdrawn by 2.3¢ [12:40] I think there's a bug in my accounting software [12:40] mborzecki: yes :-) [12:40] Chipaca: i'm sure i can expense it to canonical :D [12:41] mborzecki: why? [12:41] how did you get from "Unity" to "16.04"? [12:41] Chipaca: i figured it would be GNOME on 18.04 [12:41] mvo: are you on 18.04 by any chance? [12:42] mborzecki: I have that on my tablet downstairs, I think (haven't turned it on in a couple of months now) [12:42] grmbl grmbl kernel broke the touchscreen grmbl [12:44] Chipaca: pieces of autostart handling look at XDG_CURRENT_DESKTOP when deciding if the app should be started, I wonder if GNOME specific settings should be applied under unity too [12:45] mborzecki: making that desktop-dependent will probably confuse app devs more than not [12:45] unless they're _wanting_ it to not autostart on non-gnome (or bicerveza) [12:51] Chipaca: discord sets X-GNOME-Autostart-enabled atm, don't know what they set for unity though [12:51] installing discord... [12:54] mborzecki: in what file do they set that? [12:56] mborzecki: the option to autostart defaults to enabled, and grep finds no X-GNOME-Autostart [12:56] mborzecki: but I also find no desktop file under ~/snap/discord [12:56] so … dunno what I'm looking for [12:56] mborzecki: I'm on 18.04 - yes [12:57] mborzecki: haha, I disabled it, and it created the file [12:57] mvo, zyga, so I'm currently working on compilation failures with snapd on el7 [12:57] mborzecki: so it looks like they have a bug :-) [12:58] seems like there's a bad interaction with partial static linking now :( [12:58] mborzecki: and they do create the file, with X-GNOME-Autostart-enabled=false in it [12:58] Son_Goku: nobody uses e17 anyway [12:58] Chipaca: hah definitely no one uses e17 [12:58] at least, I hope not [12:59] (I seriously read that the first time and did a double-take) [12:59] :D [12:59] mvo, as you're aware, parts of snapd's go code is statically linked to support bases properly [13:00] so I'm trying to figure out how things are blowing up [13:00] PR snapd#5854 closed: interfaces/docker-support: add rules to read apparmor macros [13:01] popey: discord snap has a bug, fwiw, want a irc rantoid, or a github issue? [13:02] pull request pls :D [13:02] https://github.com/snapcrafters/discord [13:02] issue is fine [13:04] Chipaca: yeah, the file is dropped only when you tigger the radio button :/ [13:07] popey: https://github.com/snapcrafters/discord/issues/46 fwiw [13:08] <3 [13:09] popey: would you like a PR with autostart desktop file support too? :) [13:14] PR's are always welcome :) [13:14] Also, I have a bug for you guys :) [13:14] snap install something --edge, then replace it with snap install ./something --dangerous [13:14] snap list says x1 edge, as if I am tracking edge, even though I am now on a local install [13:17] PR snapcraft#2290 opened: pluginhandler: update build should overwrite organize [13:30] popey: not sure that's a bug, exactly [13:30] popey: snap install ./something --dangerous and tehn snap switch --edge something works [13:31] surely if i install something locally, I should stop tracking the store? [13:31] popey: you can then do 'snap amend' [13:32] niemeyer: I could hear _something_ in the background, but thought it was just aggressive audio compression [13:32] Chipaca: Cool, so not enough to be a nuisance [13:32] popey: er, i meant 'snap refresh --amend' [13:33] niemeyer: unless you're degville [13:33] :-D [13:34] niemeyer: what do you think? should "snap install ./something" when you already have 'something' installed break the 'tracking' relationship? [13:34] actually [13:34] Chipaca: Isn't that the case already? [13:34] maybe 'snap install --dangerous' should refuse to work if you have an installed something [13:34] yeah, that sounds like what should happen [13:34] niemeyer: nope, you can have a local snap tracking the store [13:35] niemeyer: ("snap switch" works on local snaps) [13:35] Chipaca: That's a bit awkward.. [13:35] niemeyer: you then can use "snap refresh --amend" [13:35] Chipaca: I don't think it should work, and my memories are that it didn't [13:35] Chipaca: Ah, okay, so it won't refresh until that takes place? [13:35] refreshes are blocked, yes [13:35] Cool, ok [13:36] it's a bit weird [13:36] but in any case, we probably want to block the asserted -> unasserted install [13:36] unasserted -> unasserted is fine, used for dev all the time [13:37] unasserted -> asserted also fine i think [13:37] asserted -> unasserted, you're trying to do something you shouldn't [13:39] (otoh you did say --dangerous) [13:39] ¯\_(ツ)_/¯ dunno, send help [13:39] * Chipaca goes to the gym [13:42] Chipaca: Yeah, not sure.. we need to think about the actual issues on these cases [13:42] thinking is hard [13:49] * Chipaca aborted the gym trip, gets back to work [14:29] Chipaca: gym is harder? :P [14:30] niemeyer: it's going to be rough :-) but nah, i just missed my window [15:03] i had ot make adjustments in how we built conjure-up, now juju/jujud aren't being included in the snap [15:03] https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml [15:03] so not sure what im missing here now [15:04] this is came about b/c we're now forced to move our snap specific wrapper scripts outside of snap dir [15:15] sergiusens, ^ [15:28] stokachu: did I not propose a PR? [15:28] sergiusens, nah [15:28] I just landed now, so I think I will ask kyrofa to look at your repo [15:29] ok thanks [15:29] cory_fu, with charmtools had to do something similar wrt the snap/wrappers die [15:29] dir* [15:30] kyrofa, the workaround i have in there for the wrapper scripts work now, but juju/jujud isn't being included in the snap anymore [15:30] would like to not have to use the workaround with snapcraftctl prime though [15:31] stokachu: I think the reason juju's not being included is that you don't call `snapcraftctl build` at the top of the override-build section [15:31] ah [15:32] cory_fu, good catch [15:32] rebuilding now to see [15:32] stokachu, kyrofa, sergiusens: I would really like to know of a better way to manage the wrappers, because having to use override sections is messy [15:33] Originally tried to use dump plugin parts but could never get the paths to work out correctly [15:33] It was particularly frustrating because the pwd seemed to change depending on whether an override section was present or not === pstolowski is now known as pstolowski|afk [16:41] snapstore seems down too, Store upload failed: ('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution')) [16:42] that's from launchpad [16:45] no, that's a SUPER WEIRD problem on one of the Launchpad script servers, not a store problem [16:56] cory_fu, stokachu, why not create a new part for the wrappers instead of trying to do it from an unrelated part? [16:56] Hard-coding paths like that isn't stable [16:58] kyrofa: Tried that originally and couldn't get it to work. [17:00] that's what we had originally [17:02] kyrofa: First issue we hit was the change from things not being allowed in the snap directory anymore. Even once we moved it out of there, though, for charm-tools at least, I couldn't get it to include the file in the built snap properly. [17:03] cjwatson, ah ok [17:03] cjwatson, it looks like it was uploaded? [17:03] im getting a different error now [17:03] binary_sha3_384: A file with this exact same content has already been uploaded [17:15] stokachu: Yeah, unfortunately some errors aren't currently retryable sensibly (we have a plan but it's not implemented yet), so in this situation you have to rebuild [17:16] cjwatson, ok cool, np [17:17] And the worker in question hasn't been restarted, so there's a 1/3 failure chance [17:17] It is really very mysterious [17:17] :D [17:20] cory_fu, which file exactly seems to not make it? [17:22] kyrofa: For charm-tools, there's one wrapper in https://github.com/juju/charm-tools/tree/master/helpers/snap-wrappers and I was trying to get it into bin/wrappers/ [17:23] Seems like it should be pretty straightforward, but I tried for a long time to get it to work [18:07] cory_fu, hoo boy is this a hefty snap. I'll make a PR shortly [18:13] kyrofa: Thanks! [18:14] cory_fu, https://github.com/juju/charm-tools/pull/449 [18:14] PR juju/charm-tools#449: snapcraft.yaml: add new part for wrappers [18:17] you call that a hefty snap ? you havent seen the gimp snap yet, have you ? :) [18:17] ogra, not in size, in build time [18:17] ogra, but yes I'll admit: I haven't messed with the gimp snap [18:18] oh, seems popey or diddledan have cleaned it up ... last time i looked the snapcraft.yal had 1800 lines ! [18:18] *yaml [18:18] yeah, moving to core18 allowed a LOT of dependency trimming [18:19] kyrofa: So that's going to hit the the issue that originally started all of this, which was the dump plugin failing with a "part modified" error. We worked around this at first by adding "source-type: git" but then that had path issues or something. I know there was a snapcraft fix for that, but I don't know if it's available on the LP builders now? [18:19] yeah, it was a bit like a novel before [18:19] missing chapters though [18:19] cory_fu, you got "part modified" because you were using the snap dir [18:19] kyrofa: Oooh [18:20] I believe reading it in it's entirety would have opened up a portal to hell [18:21] lol [18:21] necronomicon.yaml [18:21] cory_fu, snapcraft makes the assumption that it owns the snap/ dir (we'll ignore the fact that this assumption wasn't at all well-communicated). It writes caches into it, and so on. Then if you say `source: snap/` it picks up the changes it wrote itself as source changes [18:22] kyrofa: Hrm. But we originally got the "part modified" error on the versions part, which is why we have the source-type in it still [18:22] halloween just around the corner, too ;-p [18:22]