[00:01] is there a status page for snap services in case of outtages or such? (I have automated testing of download and installation of my snap and it's been slow or timed out the last few hours; is this a problem on my end or in store services?) [00:02] mdye, check http://status.snapcraft.io/ [00:02] thx [00:03] mdye, ah, some firewall maintenance is happening today, I wonder if that is affecting things [00:04] But I'll admit, that status page is quite a bit more optimistic about things than my experience has been. I have snaps uploading to CI daily and it's about 50/50 whether I'll get an email about a failed upload [00:10] PR snapcraft#1100 opened: repo: remove symlinks to libc [01:05] when installing the app, it seems like the daemon in my snap is being started before the configure hook gets a chance to run. I use the configure hook to setup the config and a few other things. As a result, the daemon fails to start and the whole snap then seems to fail to install because of that. Is this an error or the expected behavior? [01:05] *when installing the snap [01:07] olympionex, that's expected behavior. When you consider running a hook upon install, there are two possible scenarios: [01:08] 1. Run the hook after services start. This gives the hook a chance to query the running services, make sure everything is running correctly, and modify configuration if necessary. If something is wrong, it can error and rollback installation [01:09] 2. Run the hook before services start. Which allows the hook to do some setup required by included daemons, but makes it useless for querying them and checking their health [01:09] olympionex, honesty I think this is a good case for an install hook instead of making the configure hook do everything [01:10] olympionex, but that's the reason the configure hook runs when it does-- it's closer to its purpose [01:10] olympionex, would you mind logging a bug? [01:11] kyrofa: agreed, just making sure I don't have an option. I'm trying to snapify a troublesome daemon that I can't modify unfortunately and need to do some setup upon install [01:12] olympionex, currently your only option is to write a shell wrapper that makes sure it's setup correctly when run. That wrapper should be your daemon, and after it ensures things are setup, it should run the real binary [01:12] olympionex, if we had an install hook that ran before the services did, you could use that instead [01:13] kyrofa: yeah, makes sense -- snap seems to have a lot of development going on, so maybe I can look forward to it soon [01:14] olympionex, the configure hook stands alone in this regard because no one has asked for anything else. Please log a bug if you feel you need this [01:15] kyrofa, for snapcore/snapd? [01:15] olympionex, right here: https://bugs.launchpad.net/ubuntu/+source/snapd/+filebug [01:18] olympionex, if you want some examples of other snaps that go the wrapper route, check out the nextcloud snap. A good example is the `mysql` daemon: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml [01:18] olympionex, notice that it doesn't run mysqd directly, it runs start_mysql: https://github.com/nextcloud/nextcloud-snap/blob/master/src/mysql/start_mysql [01:18] kyrofa: thanks - I actually already have a wrapper to handle some of the required pid file requirements of my daemon [01:18] Which makes sure a database is generated, etc. [01:18] Good dea [01:19] l [02:04] i snap installed docker, how do I docker pull? [02:04] like I know I can cd into the /snap/docker/bin but is that how I'm supposed to do it, or is there a different way? [04:15] never mind i fiugred it out [04:15] figured* [04:22] I'm having a catch-22 with classic confinement and snapcraft. It won't let me run snapcraft unless I install the core snap, and there is no way to do that b/c it conflicts with the immovable ubuntu-core snap [04:23] this is on 16.04, weird that it works fine on my other pc [04:23] same versions of everything, including the ubuntu-core snap [04:25] i had to end up purging snapd and reinstalling [07:01] oSoMoN: can you retest bug #1642900 vs. https://github.com/ubuntu/snapcraft-desktop-helpers/pull/40 ? [07:01] PR ubuntu/snapcraft-desktop-helpers#40: Use also ubuntu-app-platform's lib/$ARCH dir for LD_LIBRARY_PATH (LP:… [07:01] Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap [07:02] oSoMoN: note that you'd need edge version of platform snap to have the libgcc_s.so.1 [07:04] Mirv, will do [07:36] o/ === JanC is now known as Guest98802 === JanC_ is now known as JanC [08:03] PR snapd#2692 closed: spread: add unit suite [08:08] PR snapd#2741 closed: store: enable download deltas on classic by default [08:09] PR snapd#2751 closed: 14.04/integrationtests: rely on upstart to restart ssh [08:11] PR snapd#2743 closed: debian: move the snap-confine packaging into snapd [08:26] jjohansen: hey [08:26] jjohansen: which timezone do you live in? [08:27] zyga: uhm UCT-8 (portland, OR area) [08:28] but well, I can't say I uhmm follow the tz all that well [08:29] zyga: I haven't gotten to testing the test kernels against your bug yet. I have been chasing it as a regression for 1661030 and jdstrand's bug 1648903 [08:29] Bug #1648903: Permission denied and inconsistent behavior in complain mode with 'ip netns list' command [08:29] I was about to get around trying your reproducer [08:29] jjohansen: haha, that explains a lot :) [08:29] jjohansen: I'm already running the test with the kernel you indicated [08:30] ah nice [08:30] jjohansen: btw, where is your tree, I could follow your patches and learn a few things [08:31] zyga: ha which tree? I have a whole bunch of trees, sadly most are more stale than I like [08:31] there are the set on kernel.ubuntu.com/jj/ [08:31] jjohansen: s/tree/repo/ [08:31] let's see [08:31] 1 for each release + the backport kernels (which is work I need to get back too) [08:31] hmm, that's a 404 [08:32] jjohansen: do you use multiple repositories for that/ [08:32] I'm not familiar with kernel development process [08:32] http://kernel.ubuntu.com/git/jj/ [08:32] its git://kernel.ubuntu.com/jj/ from git [08:33] zyga: I was trying to get a base set of backport kernels setup in a single repo, sadly its in poor shape as I just haven't had enough to do it properly [08:33] I also have an upstream tree [08:34] thanks, I'm looking a the xenial tree now [08:34] but I don''t push to that one often because a lot of bots watch it, and if I push dev code there I get slammed with emails from bots complaining about any and every little thing [08:34] great some times, but not when you are in the middle of dev [08:35] zyga: the proposed patch hasn't been pushed yet [08:35] jjohansen: where is it? [08:35] give me a minute [08:35] ah [08:35] sure :) [08:35] jjohansen: curious, what do bots do when you push there? [08:37] (so far fetching from git://kernel.ubuntu.com/jj/ubuntu-xenial.git fails on corrupted repository) [08:42] jjohansen: the test passed!!! [08:42] jjohansen: it's fixed :) [08:44] jjohansen: when can you land that in the ubuntu kernels and upstream? [08:52] zyga: okay its pushed, I will send the patch out in a few minutes. It will land into -proposed with the other fixes (it fixes a regression) [08:53] so it should land in the next kernel release in 2.5 weeks [08:56] jjohansen: understood, thank you! [08:57] jjohansen: did you push it to git://kernel.ubuntu.com/jj/ubuntu-xenial.git? [08:58] I still get: remote: error: Could not read 162e766089a4fdbbb6626f39cc23da92fdb2204e [08:58] zyga: yes, on the master branch [08:59] gah, I need to reset my master-next as its been rebased and the ref no longer exists [08:59] this happens all the time [09:01] gah, no something else is broken [09:07] PR snapd#2759 opened: asserts: support for correctly suggesting format 2 for snap-declaration [09:14] jjohansen: btw, I'll break my userspace code and see if I can trigger an oops that I ran into earlier [09:14] jjohansen: I was trying to use a O_PATH fd to do something that wasn't meant for it (setns) [09:14] jjohansen: and that oopsed [09:15] zyga: sounds good, I am still trying to figure out what is wrong with the tree, something broke [09:17] jjohansen: what are your typical work hours? [09:17] O_o the tree has lost all its heads [09:17] jjohansen: this one? http://kernel.ubuntu.com/git/jj/ubuntu-xenial.git/log/ ? [09:18] zyga: yes [09:19] zyga: my work hours drift but for the last few weeks they have been roughly 07:00-11:00 UCT and 20:00-02:00 UCT [09:20] PR snapd#2760 opened: merge release 2.22.1 into master [09:20] if I got the conversion right [09:20] thats 23:00-4:00 and 12:00-18:00 local time [09:21] are you doing this to stay in touch with devs in europe? [09:23] zyga: some times, but not atm, I'm a night owl and tend to work at nights when things quiet down here [09:24] I do try reseting my hours every once and a while but then something comes up, I push and they drift ... [09:25] jjohansen: I know how this feels :) [09:25] :) [09:26] jjohansen: thank you for fixing this and a host of other issues [09:26] jjohansen: I'll check if the oops happens and let you know if it does (with a test case if I can) [09:27] sounds good [09:33] PR snapd#2761 opened: vendor: move gettext.go back to github.com/ojii/gettext.go [09:41] PR snapd#2762 opened: debian: update breaks/replaces for snap-config->snapd [09:46] jjohansen: no more oops [09:46] jjohansen: so whatever it was, one of your patches fixed it [10:10] zyga: \o/ [10:36] PR snapd#2763 opened: store: retry on 502 http response as well [11:32] ogra_: where did the livecdrootfs stuff live? [11:41] PR snapd#2762 closed: debian: update breaks/replaces for snap-confine->snapd === tinwood is now known as tinwood_afk [12:02] sergiusens, image PPA [12:02] https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial [12:18] ogra_: so download source deb and the push? Might I just ask you to do something? xdg-open is in /usr/local/bin, would be nice to get that in the default PATH [12:18] sergiusens, well, see my comment on the bug :) [12:20] sergiusens, we have /usr/local/bin in the default path on images ... and the calling user on a classic system should also have it in his default PATH ... the only way to *not* have it in the default PATH is if a desktop wrapper redefines PATH [12:20] sergiusens, so IMHO the desktop wrppers need a fix here [12:20] *wrappers [12:21] ogra@localhost:~$ echo $PATH [12:21] bah [12:21] ogra@localhost:~$ echo $PATH [12:21] /home/ogra/bin:/home/ogra/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin [12:21] thats on my Pi [12:21] (and i get the same thing on my desktop classic install) [12:22] ogra_: http://paste.ubuntu.com/23910571/ [12:22] ogra_: I wonder if snap-confine is wiping it then [12:22] oops [12:22] that would be a question to zyga i guess [12:22] oh, no oops, I pasted the paste bin and confused by your output :-) [12:23] ogra_: hey [12:23] how can I help? [12:23] zyga, does snap-confine reset PATH ? [12:23] yes it does [12:23] aha [12:23] for snaps other than classic confinement that is [12:23] otherwise you don't know what PATH you may see [12:23] zyga, can we add /usr/local/bin then ? [12:23] zyga: then it needs /usr/local/bin and didrocks was right, you do need to fix it ;-) [12:23] zyga, we need to find xdg-open there [12:23] ogra_: does that path exist on core? [12:23] yes [12:24] ogra_: oh, curious [12:24] ogra_: sure I can fix this quickly [12:24] for apt, dpkg palceholders and for xdg-open [12:24] ogra_: is there a bug for reference? [12:24] yeah [12:24] zyga: do you use gui snaps at all??? [12:24] sergiusens: not that much, my local setup is in a weird state for content testing [12:24] sergiusens: and I don't want to rely on snaps on a dev machine [12:24] sergiusens: I use them on other machines though [12:25] sergiusens: why? [12:25] Bug 1661023 [12:25] Bug #1661023: PATH does not include /usr/local/bin and /usr/local/sbin [12:25] ogra_: thank you [12:25] zyga, nad it needs to be first ... before /usr/bin [12:25] /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin [12:26] like that [12:26] ogra_: noted [12:26] else it wont override [12:27] ogra_: actually without /snap/bin [12:28] heh, yeah, i guess [12:28] (that was just tghe PATH from ym Pi) [12:36] didrocks, when I build a webbrowser-app snap locally and install it, the app won’t start, I’m getting this error: [12:36] This application failed to start because it could not find or load the Qt platform plugin "xcb" [12:36] in "". [12:36] zyga: I would strongly recommend you do dev in a VM and leave your main system as a dog fooding one to enjoy the pain and fix stuff as they show (some sort of stress testing) [12:37] oSoMoN: did you snapcraft update since tuesday? [12:37] oSoMoN: pat confirmed that updating to latest works [12:37] didrocks, no I hadn’t, let me try that [12:37] sergiusens: I'm already working in a VM but I don't use the host as much, that's my "main" vm that moves from host to host as I change devices [12:39] sergiusens: I also use snaps but I don't use gui snaps that much [12:39] sergiusens: (I'm mostly a terminal + browser person [12:40] use a snapped browser and a snapped terminal !! [12:40] :) [12:40] didrocks, confirmed, that fixed the issue [12:40] oSoMoN: phew, same fixed issue then :) [12:42] (the issue being part definition is cached, but the parameters used in the git repo has changed/been added) [12:42] can snapcraft be improved to handle this better? [12:42] unsure, I guess we have to think that the definition can be async compared to code [12:43] so handling backward compatibility and not treating as one unit, but 2 [12:43] (I didn't think about the caching at the time) [12:43] * didrocks really needs to take a lunch break, ttyl [12:43] but if you already cache you know the local version [12:43] so its just a matter of comparing to the remote and notifying the user [12:44] oSoMoN: handle what better? [12:44] remote parts updates [12:45] oSoMoN: so you want the latest and greatest always no matter if what is locally works and what is remote doesn't? [12:45] i guess jst a notification that there is a new remote version would help [12:46] ogra_: we could do that on `pull` as it is an online operation; don't think it would be wise to anywhere else [12:47] and notify, not auto update [12:47] right [12:47] just let the user know "hey, there is a newer version of this remote part" [12:47] prevents support questions because of outdated local revisions [12:47] oSoMoN: if you log a bug, we can do it ;-) [12:48] didrocks, mind filing the bug? you have a better understanding of the problem, and you would explain it better than I could [13:48] jdstrand, mhall119 after all that help day before yesterday you two gave me I have found out that my system is to blame. Every snap installed on my system exhibits some sort of issue. [13:48] But if I add process-control to the program and connect them they work fine. [13:49] I'm currently trying to sort out the issue. [13:49] HumbleBeaver: its still just the one program? [13:49] PR snapd#2764 opened: tests: disable ubuntu-core->core transition on ppc64el (its just too slow) [13:53] jdstrand no, another program I wrote is now exhibiting the same issue. (main screen never displays) , but hexchat locks up, blender-tpaw doesn't launch, Krita doesn't load, and both Telegram snaps won't allow me to attach files via the attach clip. [13:53] tvoss, you around? [13:54] HumbleBeaver: and for all of them, if you connect 'process-control' it fixes the issue? [13:56] jdstrand I've only added it to numnom so far, and yes it fixed the problem. [13:57] HumbleBeaver: can you give the output of 'grep type=1326 /var/log/syslog' after you see all these denials? [13:57] s/denials/failures/ [13:58] jdstrand sure can, stand by [14:02] stokachu: yup, I am [14:08] jdstrand paste.ubuntu.com/23911024 [14:08] ogra_: https://github.com/snapcore/snapd/pull/2765 [14:08] PR snapd#2765: cmd: add /usr/local/* to PATH [14:08] ogra_: review appreciated :) [14:09] PR snapd#2765 opened: cmd: add /usr/local/* to PATH [14:11] jdstrand: if you are around I'd like to quickly discuss where to take the sc_must_stpcpy branch, [14:11] jdstrand: we talked but I'm not sure what the bottom line was [14:12] jdstrand: I'm +1 on the rename to sc_append_string (or similar) and +1 to drop the size limit if you want to as well; [14:12] jdstrand: and +0.5 on the simplification (from stpcpy-like to strcat-like) [14:14] zyga, looks fine, though not sure we need games actually :) [14:14] ogra_: I felt the same, added it for completeness [14:14] yeah [14:14] ogra_: but I can remove it if you feel we don't want to have it === ara_ is now known as ara [14:15] well, we have it everywhere else, seems more consistent in the end === ara is now known as Guest84900 [14:16] zyga: I am here, I'll need to circle back though [14:19] zyga: it sounds like you are in favor of basically everything then. I think going to strcat-like is going to be more useful long term. already you have to reset the pointer at the end of all the stpcpy calls to send the string off to be used, so this will remove that requirement [14:20] jdstrand: yes, it makes it simpler and more reliable at a irrelevant cost in performance [14:20] jdstrand: if you agree I'll folow up and do just that [14:20] jdstrand: and apply this across the tree to kill the static char buffers [14:21] HumbleBeaver: telegram, numnom, krita and codebreakers are all sched_setscheduler and that is a regression in 2.22 [14:22] HumbleBeaver: hexchat is fchown which was never allowed [14:22] ogra_: if you reviewed that branch can you please add a comment; that helps [14:22] zyga: sounds fine [14:22] jdstrand: thanks! :) [14:22] zyga, yeah, sorry distracted [14:24] ogra_: no worries, thank you :) [14:26] jdstrand, well that explains why they still work on other people's computers. Thanks for your help [14:32] HumbleBeaver: right, you have 2.22, other people only have 2.21 [14:33] HumbleBeaver: for each of telegram, numnom, krita and codebreakers, can you add 'sched_setscheduler' (without the quotes) to the botton of /var/lib/snapd/seccomp/profiles/snap., then relaunch the app and let me know if it works? [14:33] bottom* [14:33] HumbleBeaver: fyi, bug 1661265 [14:33] Bug #1661265: [regression] sched_setscheduler denied with Qt/QML applications [14:35] mvo: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1659522/comments/10 [14:35] Bug #1659522: [SRU] 2.22 [14:36] jdstrand: oh, so we need a 2.22.2? [14:36] mvo: \o/ [14:36] mvo: I've assigned that to me, but I would like to do a little digging first [14:36] mvo: l.oo.l release [14:36] mvo: yes, sorry [14:36] jdstrand: no worries [14:36] jdstrand: I caused 2.22.1 myself :/ [14:36] jdstrand: do you have a rough estimate about times? [14:37] mvo: let me PR a fix right this second that way you aren't blocked on my investigation. I will want to augment the comment for this syscall pending my investigation [14:38] sounds good [14:39] PR snapd#2766 opened: tests: improve snap-env test [14:45] PR snapd#2767 opened: interfaces: allow sched_setscheduler again by default (LP: #1661265) [14:45] mvo: ^ [14:47] mvo: I did it to master. will you get it to 2.22.2 or should I do something extra? [14:47] jdstrand: I can cherry-pick it into the 2.22 branch [14:48] HumbleBeaver: in addition to trying all that, can you point me to your hexchat snap? I'd like to see how it is using fchown [14:51] jdstrand, tingping is the developer of hexchat. It's the one in the store. [14:51] HumbleBeaver: great, thanks! === tinwood_afk is now known as tinwood [15:13] PR snapd#2768 opened: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default [15:20] jdstrand: FYI, I found this insteresting: https://github.com/snapcore/snapd/pull/2768/files#r99141379 [15:20] PR snapd#2768: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default [15:22] zyga: yes, that occurred to me to. we'll have to design it to support snapd policy versions if we are going to allow different series core snaps on the same device. note, this isn't the only issue with this-- I suspect there will be a lot of things that will need to be done differently based on the core series [15:23] jdstrand: after writing this I realized that we can see the slot so we can identify 16 and 18 series but I totally agree with what you just said [15:24] zyga: I'd rather not try to predict all that right now though. when series 18 core snaps are a thing and we want to pull the trigger on something different, we should see how we want to do that [15:24] it's kinda scary if you really think about it-- series 22 with series 16-- how will snap-confine/snapd have changed? [15:24] jdstrand: I bet we will be asked for continuity so that 16-based snaps can be installed aon 18 [15:24] jdstrand: yes [15:25] jdstrand: I think it is worth to think about what we will do with multi-base snaps when we start to split that sometime soon [15:25] zyga: that request will need to also consider positive change moving forward [15:25] jdstrand: (I suspect we'll make ubuntu-base-16 before EOY) [15:26] jdstrand: backwards compatibility will win ous many hearts and I think it's not impossible to do [15:26] jdstrand: we'll just recommend devs to update to 18-base [15:26] eg, it is perfectly correct to evolve and deprecate. series 16 should always work, but does that mean series 18+ need to not evolve? interesting questions [15:26] jdstrand: I suspect that we may phase out series over time (e.g. a given snapd will only support 16 and 18 and maybe 20 but not 22 and 16 at the same time) [15:26] jdstrand: no, I didn't mean that [15:27] jdstrand: in 18 we should change what that interface does [15:27] jdstrand: (or to be precise) when that interface is connected to a 16-base snap it should behave as it does [15:27] jdstrand: but not in 18-base snap [15:27] jdstrand: from the same snapd process [15:27] jdstrand: (curious issues with >1 base snap and snap interfaces and auto-connection) [15:27] jdstrand: lots of fun things ahead :) [15:27] well, I think this needs to be all thought through at the appropriate time. there is a lot to consider [15:27] yes [15:36] Hmmm 'snapcraft push' just gabe me '502 Bad Gateway' [15:36] Basically a bunch of raw HTML [15:39] Tried again, now it seems to have worked [16:02] kalikiana, I get that every other day when LP tries to push as well [16:03] jdstrand, did you see my comment on the remote syslog bug ? would be nice to have /etc/rsyslog.d writable by the core-support interface [16:03] i can then add the needed script bits to the config script [16:04] ogra_: I thought I saw the comment, and I thought I saw you say you were going to do that, and I meant to say 'thank you' to you :)( [16:04] :) [16:04] oh [16:04] i only made the dir writable on an image level yet [16:05] PR snapd#2769 opened: snap-exec: support nested environment variables in environment: [16:05] ogra_: oh, I see what you mean [16:06] ogra_: let me take that onto an existing PR [16:06] awesome ! [16:06] thanks ... i'll care for the rest then [16:10] ogra_: is there a particular path or naming convention you are going to use? ie, we have a choice to allow modifying anything in there (eg, 50-default.conf) or to only modify [0-9][0-9]-snap*.conf (or something) [16:11] well, i made the whole dir writable on the image level ... if you want to restrict the interface to a particular filename, feel free to do so, just tell me the name then [16:12] PR snapd#2767 closed: interfaces: allow sched_setscheduler again by default (LP: #1661265) [16:13] jdstrand, the latter sounds sane though ... also in the light that we might want to be able to add more options later [16:14] and i'd like to keep one file per option to not have to do sed stunts in the scripts [16:15] (rm $filepath is so much easier than in-place editing of a big config file) [16:15] ogra_: I was going to do this: http://paste.ubuntu.com/23911801/ [16:15] perfect [16:16] that at least namespaces it a bit [16:16] yep [16:16] I figure you might want some flexibility on 00-snap-foo.conf vs 99-snap-bar.conf vs snap-baz.conf [16:17] yeah [16:17] cool [16:17] I'll send it up. I think I will do a separate PR since I already have approval on the other one [16:17] ogra_: this is exciting! :) [16:18] :D [16:18] for some reason I'm a bit of a logging nerd :) [16:18] and i love to save wear levelling of my SDs [16:19] directing all my boards to a central place surely helps that [16:20] Bug #1661265 opened: [regression] sched_setscheduler denied with Qt/QML applications [16:24] PR snapd#2758 closed: overlord/devicestate: implement policy about gadget and kernel matching the model [16:25] PR snapd#2770 opened: interfaces/core-support: allow modifying snap rsyslog configuration