[00:51] diddledan every Tuesday, the snap; every 3 weeks the deb [00:51] :-p [00:58] Ugh, man it gets dark early [01:09] Canonical needs to buy me a few soft boxes [01:38] hey, whats up all [01:38] beating this nginx logging horse to death here [01:40] I had great success with getting my logs to syslog via the snap logging proxy [01:40] not sure the technical name for that mechanism [01:41] a req came down the line that this application log to a separate file(s) and the logs end up in s3 [01:41] so I had to log to $SNAP_COMMON [01:41] which works great until I try to setup logrotate [01:42] I hit my head on a few things, but ended up getting logrotate in this working/broken state [01:43] in short, the issue I seem to be having is that when logrotate goes to swap out the logfile, nginx needs a kick (reload) to start writing to the new logfile [01:44] which brings me to the (logrotate) postrotate sripts [01:44] which can be used to send signal or run a bin when your gets rotated and swapped out [01:45] so my idea here was to create a wrapper command in my snap to facilitate running the `nginx -s reload` command [01:49] here's whats in my wrapper http://paste.ubuntu.com/26115750/ [01:50] the output I'm getting ^ [01:50] seems like the snap is preventing the process from being restarted [01:50] nginx: [alert] kill(17878, 1) failed (1: Operation not permitted) [01:50] I should probably write another forum post pertaining to this [01:51] possibly my last one on logging wasn't specific enough [01:51] is this making sense? [01:51] do I need to add more context somehow in a more proper write up? [01:51] let me know [01:51] thx thx [02:21] elopio would be great if you could run through snapcraft#1789 and also maybe try and apply your changes, I don't see how they look good when running [02:21] PR snapcraft#1789: cli: improve the help command [05:49] PR snapcraft#1791 opened: tests: move the python plugin integration tests to a separate suite [06:03] morning [06:25] PR snapcraft#1792 opened: tests: do not hit the network in python unit tests [06:46] https://github.com/m4sk1n/snapcraft/tree/i18n-wip I don't know how should I config ./bin/snapcraft to apply translations… [07:01] mvo: hey [07:01] hey mborzecki - good monring [07:01] morning even [07:02] :) [07:02] mvo: got a quick question, https://travis-ci.org/snapcore/snapd/builds/311243551?utm_source=github_status&utm_medium=notification any idea why this has failed? [07:04] mborzecki: yes, I looked at it earlier and restarted because iirc it could not allocate machines, it looked very transient, I don't have the log in front of me unfortunately anymore [07:05] i'll restart the build then [07:07] traving is also having hiccups today, couldn't restart the build [07:07] mborzecki: it is restarted already, at least when I looked at it ~1min ago :) [07:08] i clicked 3-4 times, got 'Oh no! .. blah blah' [07:11] mvo: that arch test that fails, got this from sysctl: kernel.random.entropy_avail = 32, not a good sign [07:12] mborzecki: heh, yeah [07:12] i kind of lik the idead that was circled yesterday, just mknod /dev/random c 1 9 and we're done for the tests at least [07:13] mborzecki: yeah, I think we should just do it, for clarity I would use a symlink (if gpg is happy with that) [07:13] mborzecki: will you do a PR with that? or shall I do one :) ? [07:13] oh and `dd=/dev/random of=/dev/null` chokes obvioulsy on that machine [07:13] i can do it [07:14] if anyone has a fedora system at hand, what is the package that contains aa-enforce in fedora? [07:14] and apparmor_parser ? [07:30] mvo: there's no aa in fedora [07:39] PR snapd#4354 opened: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare [07:40] mvo: ^^ [08:01] hey hey [08:02] zyga-ubu1tu: hey [08:02] sorry for being absent-ish yesterday, I'll try to make up for that [08:03] zyga-ubu1tu: need a 2nd review on #4338 if you would be so kind :) [08:03] PR #4338: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule [08:05] mborzecki: yep, looking [08:06] zyga-ubu1tu: thanks [08:08] PR snapd#4338 closed: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule [08:09] mvo: this build timed out https://travis-ci.org/snapcore/snapd/builds/311243551?utm_source=github_status&utm_medium=notification [08:13] zyga-ubu1tu: while you're doing reviews, would you mind taking a look at #4340 as well? [08:13] PR #4340: snap: YAML and app validation parts of after/before app startup ordering [08:15] zyga-ubu1tu, hey! can you take another look at #4303 (addressed your previous feedback, and got +1 from Gustavo) [08:15] PR #4303: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) [08:15] pstolowski: sure, looking now [08:15] zyga-ubu1tu, thanks! [08:17] pstolowski: that's a biggie :) [08:17] zyga-ubu1tu, look at the followup... it's fairly mechanical though [08:22] brb, reboot === __chip__ is now known as Chipaca [08:41] i have two differnt python based snaps which are not working if they are rebuilt in a bionic userspace; both exploding when installed and run with: [08:41] /snap/so-trello/x1/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /snap/so-trello/x1/usr/bin/python3) [08:42] apw: hey [08:42] apw: yo uneed to build them on xenial userspace [08:42] apw: I believe kalikiana is aware of the issue [08:42] mvo: crazy idea: include newer libc in core/ [08:42] ^ [08:42] huh, since when did that change [08:42] i thought the point was that core contained everything you might need [08:42] apw: bionic uses newer libc, core ships older libc [08:43] and if it didn't your snap got all fat [08:43] apw: yes, but it doesn't contain your latest libc [08:43] right, so it should be using the one in the core snap [08:43] apw: if by "it" you mean snapcraft then yes [08:43] apw: but this is hard to do, use cleanbuild to build in a container [08:45] zyga-ubuntu, i'll try that then, though it should do that by defualt probabally ... [08:45] hey zyga-ubuntu wanna see somethin' cool? :) [08:45] ("cool" being at your own interpretation obv.) [08:49] ikey: sure :) [08:49] https://ibin.co/3jcgpSR7n4Tu.png [08:49] * zyga-ubuntu was making kitchen tidy enough to make tea [08:49] :D [08:50] oooh [08:50] snap store [08:50] thank you :) [08:50] is that released? can I play? [08:51] its not yet :P [08:51] this is as far as i got yesterday [08:51] today i shall add more stuff [08:51] ikey: how is the integration, any pain points? anything missing [08:51] zyga-ubuntu: why a newer libc? [08:51] zyga-ubuntu, same as before [08:51] no caching of offline usable metadata, meaning many, many roundtrips [08:51] mvo: because it would be compatible with existing software and it would let people use bionic and artful libs with greater ease [08:51] no cached indexes or proper categories [08:52] no integration with appstream so having to support two visual standards [08:52] ikey: the api is that you talk to snapd and then snapd talks to the store, right? [08:52] right [08:52] and the list installed stuff is wonky [08:52] ikey: I thought we started to do appstream now [08:52] as it only has like half the meta [08:52] so even for an installed snap you need to go to the store to get the real data on it [08:52] (which seems an odd choice) [08:53] yes, that's true [08:53] Chipaca: ^ [08:53] for now im just gonna have to supplement the hand-picked snaps with some extra meta-data [08:53] due to aforementioned lack of organisation/appstream [08:53] ikey: hmmm [08:54] ikey: you should talk about this with chipaca, robert ancell and store people [08:54] this is nothing new btw, same issues as back in september [08:54] aha, I see [08:54] zyga-ubuntu: i'm aware [08:54] great [08:54] as long as we all know it will get fixed over time [08:54] the other issue is snapd startup time [08:55] its.. painful [08:55] my plate is full of things -- and in particular spread misbehaving in weird ways [08:55] on Solus snapd is socket activated to prevent massive boot time regressions [08:55] unfortunately it also means slowing down the startup of the SC the first time it runs [08:55] until snapd is "ready" [08:55] the same thing can be emulated just issuing "snap list" after boot [08:55] ikey: right [08:56] takes around 5+ seconds [08:56] ikey: thank you for the honest feedback! [08:56] no worries :] [08:56] ikey: ouch. We moved away from socket activating it -- why not start it automatically now? [08:56] ikey: does systemd have an "idle" schedule to run stuff when everything has settled? [08:56] i mean, don't make things block on it [08:56] * apw now finds snapcraft cleanbuild fails with no root device found from lxc [08:56] yes, systemd does have that [08:56] because we actually care about stuff like this Chipaca [08:56] https://www.phoronix.com/scan.php?page=article&item=11-linux-boot&num=1 [08:56] spoiler: we came in just after clear linux (where I used to work) [08:57] snapd presents a huge boot time regression [08:57] ikey: what happpens if you set snapd's type to 'idle'? [08:57] honestly, not tried [08:57] but it has no need to be switched on during boot anyway [08:57] it should only be turned on when spoken to [08:58] ikey: if it's socket activated, refreshes might never happen, and retries might never happen [08:58] ikey: unless you've set things up for that [08:58] well. tbh i dont think automatic refreshes should be mandatory anyway [08:58] so theres another design decision im not in agreement with [08:58] for our users they risk excessive bandwidth consumption as they have no direct control over updates [08:59] ikey: have you been paying no attention to the quagmire of awfulness that is security in the face of no automatic updates? [08:59] i think you forget who you're talking to, Chipaca. [08:59] if you don't give users a way to at least delay an update until an appropriate time, you're pulling a Windows [09:00] ikey: 5+ seconds :/ I wonder why, that is really slow. I think we (snapd team) need to dig into this [09:00] many people are still reliant on HSDPA+/3G [09:00] and have bandwidth limitations [09:00] being able to defer the update until it is *affordable* is a must for the most basic UX requirements [09:00] ikey: i'm on a short fuse for personal reasons this week, please read things as if i were being 2 points more polite [09:00] throwing "security" as a blanket for piss-poor engineering in IoT isn't going to cut it [09:00] fair do. [09:01] as an argument here [09:01] I think the core should update automatically [09:01] services should update if started [09:01] and apps should be blocked from running (by default) when out-of-date [09:01] PR snapd#4353 closed: hookstate: add compat "configure-snapd" task [09:01] zyga-ubuntu, so you're gonna pull a PS4? :) [09:01] (especially desktop apps can have nicer notification) [09:01] * mvo hugs Chipaca [09:01] ikey: you can already set updates to happen at whatever time bandwidth is cheap [09:01] "Time" ? [09:01] ikey: well, it's a gradient; I don't care if my apps are as up-to-date as my system [09:01] ikey: if I know and can act on it [09:02] Launch-blocking is one approach [09:02] ikey: there are ways this can change over time [09:02] And allows having deferred updates [09:02] Mandatory core updates, again I would disagree with, depending on context [09:02] If a user has LSI installed they don't need core [09:02] ikey: for snapd [09:02] Unless they're on Ubuntu with snapd reexec [09:02] Anywhere else, core is unnecessary [09:02] mvo: the police asked for a summary of all the bullying since it started, and writing all that out has been rough [09:03] zyga-ubuntu, is there any other instance core is used by snapd outside of the reexec case? [09:03] Chipaca: *meh* I can imagine :( sorry to hear that [09:03] reminds me i need to take thursday off to go look at a new school [09:03] ikey: I think core will shrink to "just snapd" over tiem [09:03] gotcha [09:03] ikey: as bases mature and there is a distinct 16 and 18 ubuntu base [09:04] basically, current ux: [09:04] sudo snap install --edge solus-runtime-gaming [09:04] installs core [09:04] then installs the runtime [09:04] Chipaca: man, that sucks. I hope it can get resolved quickly [09:04] zyga-ubuntu: do you happen to known in what fedora package "apparmor_parser" and "aa-enforce" are? same question for opensuse [09:04] runtime gets updates, linux-steam-integration does not [09:04] mvo: none [09:04] neither can be found in searches [09:04] mvo: it's not packaged [09:04] mvo: for suse it is just "apparmor" (in tumblweed, I believe) [09:05] in solus we give users choice over which updates are applied and when [09:05] zyga-ubuntu: ta [09:05] because, believe it or not, not ALL updates are security. [09:05] mvo: am i wrong in thinking 2.29 should be getting default-provider snaps automatically? [09:05] in Solus we differentiate updates at 3 levels: Mandatory, Security, Other [09:05] ikey: I think most users don't care; I would focus on making it less annoying and getting bandwidth under control [09:06] With all due respect, they do. [09:06] Solus users care about it a lot [09:06] Having things update beyond their control is frustrating and a kickback to the Windows world they left [09:06] And if you decide to block the launch of an app because of an update, you will have outrage unless there is a good *reason* to block it [09:07] Blocking the launch because someone decided to reshade the theme? Gonna get people vexed [09:07] Stop their laptop shutting down before a meeting because of updates? or kill their bandwidth before heading out to NZ on tethered phone for a week? Gonna piss em off :P [09:07] ikey: yeah, there are things to polish in the experience [09:07] ikey: ok, so how do you programatically tell a good reason from a bad one? [09:08] ikey: perhaps blocking on startup is excessive (for vast majority of updates) [09:08] Chipaca: they have the evil bit set [09:08] oh man [09:08] of _course_ users want their shit to just work [09:08] Chipaca, by describing an update [09:08] not set :) [09:08] :-( [09:08] so in solus we auto-describe security updates through reference to some CVE or other [09:08] and its flagged as zyga-ubuntu says [09:08] so thats security, sorta more important than "user is finicky about updates" [09:08] mandatory in snapd terms is core [09:09] i.e. required for architecture to work [09:09] (in solus thats actually libc, bash, etc) [09:09] * Chipaca goes back to hating spread because he's unfit for human interaction right now [09:09] so you have this core set of things that will always update regardless of any other update/install/refresh, because "mandatory" ^^ [09:09] zyga-ubuntu, ok this cleanbuild option is using an lxc command line which doens't work ... i needs a --storage option [09:09] compromises++ [09:10] apw: ask kalikiana about that please [09:10] kalikiana, ^ [09:11] apw: you want to talk with kalikiana [09:11] heh [09:11] talk isn't the word i want to use right now :/ [09:12] Chipaca: hi, sorry, laptop went crazy [09:12] Chipaca: so default providers, the PR is not merged yet, some complications in it [09:12] aw [09:12] apw: i don't quite know what you are doing but [09:13] mwhudson, trying to make snap work again, as apparently that is impossible, i will just stop trying i think [09:13] apw: if you create a lxd container called "snapcraft-$project", you can use SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft build and it will use the container you created [09:13] mwhudson, project as in the snap name ? [09:13] Chipaca: https://github.com/snapcore/snapd/pull/4103 [09:13] PR #4103: snapstate: auto install default-providers for content snaps [09:13] apw: yes [09:14] apw: it's a slimy hack, but it does work [09:14] mwhudson, i'd try random hack three then,. thanks [09:15] mvo: yikes [09:15] apw: nice attitude there [09:16] Chipaca, heh its never a good start to your day when your snaps won't work and you can't rebuild them anymore [09:16] sorry about the distraction, my son hasn't arrived for classes, trying to sort this out [09:17] apw: I'm surprised you've not had to switch to cleanbuild ages ago; the libc change is a couple of months old already [09:17] Chipaca, well apparently i can't switch to cleanbuild cause that don't work either :/ [09:18] apw: it does for other people, so why doesn't it for you? [09:18] hm, zyga-ubuntu, thought, what if we went in completely the opposite direction..? [09:18] apw: it's not a random hack; if it's not working it's a bug [09:18] instead of trying to jimmy snaps to fit distro "ways", instead use the software center to *educate* users about snaps.. [09:18] Chipaca, it isn't supplying a required option to lxc on my system to start the container [09:18] Chipaca, and i was refering to mwhudson's description of the next thing to try as a slimy hack [09:18] ikey: hmm? sorry can you please re-state your question [09:18] Chipaca, not my choice of epithet for the thing i was trying [09:19] zyga-ubuntu, ok so instead of trying to force snaps to fit the old fashioned method of distro updates, instead educate users about snaps being self-updating [09:19] and why they differ [09:19] before they ever go to install one [09:19] i.e. promote the difference instead of trying to stifle it [09:19] mvo: hi. In https://github.com/snapcore/snapd/pull/4140#issuecomment-347159305 you said you uploaded the test snap to the store. I was looking at writing a spread test using it, but can't seem to see it there. Is there anything more needed? [09:20] PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service [09:20] apw: ah i missed him saying that -- sorry for calling you on it then [09:20] Chipaca, heh i don't mind, i _am_ feeling grumpy about it all today :) [09:20] apw: my main concern is that calling them hacks doesn't put the focus on getting things fixed, whereas calling them bugs does [09:21] Chipaca: fwiw my use case for my hack is fixed by https://github.com/snapcore/snapcraft/pull/1769 [09:21] PR snapcraft#1769: lxd: add an --image argument to cleanbuild [09:22] although having control over the container that gets created when you use SNAPCRAFT_CONTAINER_BUILDS would also be good [09:22] mwhudson, and only installing it once with build-deps etc sounds good [09:24] * mwhudson grumbles at pylint [09:25] apw: yeah [09:27] eh [09:27] mystery resolved [09:27] my son turned off his phone in school [09:27] went inside the class and waited for the teacher [09:27] the teacher waited outside of the class and tried to call him and then me [09:27] ^_^ [09:27] stress-- [09:28] back to work [09:28] pstolowski: branch looks good so far, I'll try to finish it quickly [09:28] pstolowski: sorry for the lag [09:28] * ikey passes metaphorical handkerchief to zyga-ubuntu [09:28] zyga-ubuntu, np, thanks for looking at this monster [09:28] pstolowski: hey [09:29] pstolowski: what's the status of snapctl restart et al? [09:29] mwhudson, that fails with: PermissionError: [Errno 13] Permission denied: 'snap/.snapcraft' [09:30] apw: congrats [09:30] ? [09:30] sorry that's probably not very helpful but i've not seen anything like that before [09:30] i think i have to accept that snapcraft and bionic is just not a thing [09:30] and create a VM to do this in [09:34] ? [09:34] ups, ignore me [09:35] pstolowski: did you see my question about snapctl service control? [09:35] Chipaca, yes, will reply [09:35] k [09:35] pstolowski: i ask because of the forum thing, you can reply there if you'd rather [09:37] Chipaca, yes, will reply there, I didn't respond right away cause I'm not sure if it made it in 2.30 or not at the end, need to check [09:44] Chipaca, replied [09:45] Chipaca, nb, nothing stops anyone from using systemctl + a long hard to remember name directly, right? [09:46] pstolowski: confinement sure does [09:53] not inside a snap [09:55] right [10:02] PR snapcraft#1779 closed: catkin-tools plugin: use stage-packages [10:02] pstolowski: Chipaca: anyway afaik and skimming the code snapctl start/stop etc made it to 2.30 [10:02] yes === matteo` is now known as matteo [10:20] error: cannot refresh "core": snap "core" has changes in progress [10:20] what does this mean [10:20] ShibaInu: that "snap changes" will show that some other operation on core snap is already in progress [10:20] zyga-ubuntu: not sure what is going on though, I seemingly dont have any snap running? [10:21] ShibaInu: run "snap changes" [10:21] 27 Do 2017-11-30T10:13:40Z - Auto-refresh snap "core" [10:21] ShibaInu: so the message should be probably beter [10:21] better* [10:22] "refreshing of snap core is already in progress" [10:22] or something alike [10:23] zyga-ubuntu: do you know by the way whether vulkan now works on snappy? [10:23] ShibaInu: I don't know, sorry [10:24] ok, no problem [10:24] thanks by the way [10:24] ShibaInu: are you using core from edge? [10:24] pedronis: yes [10:24] ShibaInu: we should have some vulkan test snap but I'm not aware of any [10:25] ShibaInu: there was an issue that will get an update in that state, you need to abort the change , snap abort 27, the next edge build from today then should work [10:26] or so we think [10:26] pedronis: so if i do snap abort 27 i will have to wait for the next edge? or will vulkan work [10:26] this is not about vulkan [10:27] just the update getting stuck [10:27] oh [10:27] i see [10:28] i guess you'd have to include mesa-vulkan-drivers and libvulkan1 inside your snap [10:29] and allow/connect the opengl interface to give it HW access [10:29] (just a guess though) [10:38] mvo, test on candidate completed, we are ready to go to stable [10:39] cachio: brilliant news [10:39] cachio: lets target after the meeting, then we can briefly discuss and we need to warn the store people as well [10:39] mvo, agree [10:40] thanks cachio [10:43] pstolowski: almost done [10:45] \o/ [10:47] pstolowski: oh damn, those "load diff" parts of the PR [10:47] pstolowski: it's even longer :") [10:47] :} [10:48] * Chipaca -> physio while spread runs [10:49] * zyga-ubuntu misread that as "past" [10:49] "pasta" [10:50] uuuuhhh [10:50] HOW MANY ARE THERE [10:51] pstolowski: I wanted to say I'm near the end [10:51] but the end is full of "load more" buttons [10:51] pstolowski: I'm at lxd_support_test.go [10:55] zyga-ubuntu, sorry... [10:56] * zyga-ubuntu hugs pstolowski who had to _write_ all that [10:56] zyga-ubuntu, https://www.youtube.com/watch?v=jHPOzQzk9Qo [10:57] pstolowski: when the camera pans and shows more people on crosses this is how scrolling down feel [10:58] *feels [10:58] there's more interfaces :D [10:58] yes, that video seems very appropriate ;) [11:10] hi [11:11] o/ [11:11] I'm looking for some documentation on seed.yaml [11:11] can anyone point me in the right direction? [11:13] mmm maybe pedronis ca [11:15] PR snapd#4355 opened: release: 2.30~rc2 [11:18] mvo, 30 rc2 ready for beta validation? [11:18] cachio: yes [11:18] cachio: should be a piece of cake almost no change [11:18] mvo, ok, I'll start with it [11:18] cachio: except arm/arm64, LP is busted right now and can't build those [11:19]