=== rvr_ is now known as rvr === chihchun_afk is now known as chihchun === markusfluer1 is now known as markusfluer === chihchun is now known as chihchun_afk === JanC_ is now known as JanC === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:05] PR snapd#2884 closed: snapstate: limit the ubuntu-core transition attempts to 5 in total every 12h [07:07] <_prasen_> hi ogra [07:12] Bug #1631165 changed: no ability to move snap directory out of $HOME [07:56] PR snapd#2900 opened: errtracker: include snapd version in err reports [08:06] PR snapd#2901 opened: tests: update listing test for latest core snap version update [08:09] PR snapd#2902 opened: tests: update listing test for latest core snap version update [08:16] PR snapd#2903 opened: many: rebased uname branch for 2.22 [08:19] PR snapd#2904 opened: overlord/snapstate: tweak messages in {un,}link-snap [08:24] PR snapd#2905 opened: errtracker: include kernel version in error reports [08:30] PR snapcraft#1154 closed: Expose parallel_build_count to scriptlets (LP: #1666271) [08:32] Good evening [08:33] SInce I just got mircade running on QEMU/Ubuntu Core 16, is there already a working Unity8 snap for Mir? [08:42] PR snapcraft#1126 closed: docs: build and push the API docs to github pages [08:43] sorry, disconnected [08:44] laralauer, snap install unity8-session --devmode --edge [08:44] then [08:45] sudo unity8-session [08:45] (you might need to connect some interfaces first though) [08:45] hey _prasen_ [08:46] ogra_: thanks! [09:12] PR snapd#2906 opened: overlord/ifacestate: don't unconditionally retry stuff [09:33] <_prasen_> if i get a random .yaml to build a snap [09:34] <_prasen_> made up of different parts and different apps [09:34] <_prasen_> how do i map the binaries of the apps to the parts? [09:34] <_prasen_> I want to prime different parts one by one [10:04] What are some of the most useful snaps? [10:05] <_prasen_> what does dump plugin exactly do [10:08] PR snapd#2902 closed: tests: update listing test for latest core snap version update [10:26] PR snapd#2907 opened: overlord/ifacestate: improve error messages [10:31] PR snapd#2881 closed: cmd/snap-confine: don't crash if nvidia module is loaded but drivers are not available [10:34] PR snapd#2876 closed: snap: error when `snap list foo` is run and no snap is installed === chihchun is now known as chihchun_afk [10:51] PR snapd#2908 opened: snapstate: fix incorrect cut of the timestamps for the error reports [11:10] _prasen_: dump just copies stuff as-is [11:17] PR snapd#2901 closed: tests: update listing test for latest core snap version update [11:38] fgimenez, you should really put a warning in https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/tests/README.md that adt-buildvm-ubuntu-cloud can take a century :P [11:40] Hi [11:40] PR snapd#2909 opened: overlord/snapstate: improve error reporting around core migration [11:41] Hello? [11:43] Hi [11:46] ogra_, :D PRs welcome! [11:50] sigh, and running it nearly killed my machine ! [11:51] * ogra_ hasn't seen a stuttering cursor on that HW ever ... [11:53] Bug #1666873 opened: Snap icon is not visible when called from terminal but it does when called from dash [11:58] <_prasen_> zyga : i want to understand how organise and filesets options for the dump plugin [11:58] <_prasen_> work* [12:00] _prasen_: I think this is a question for kyrofa and sergiusens - it may be documented already but maybe that is not sufficient [12:00] * zyga would recommend to sergiusens to open a wiki for snapcraft like what was done for snapd [12:02] Is there any plans to fix snappy so that the notification icons actually show up and don't cause headaches like when you're trying to update Telegram and can't because the notifcation icon won't let the app shut down? [12:06] PR snapcraft#1156 closed: python plugin: use stage headers if applicable [12:06] sabret00the: yes but the issue is not simple (legacy protocols are hard to confine or fix) [12:07] sabret00the: can you tell me more about the shutdown issue? [12:07] sabret00the: there are reported issues for other problems but this feels like something new [12:08] <_prasen_> zyga : ty [12:08] zyga: Sure. If you have an update to telegram and press restart, then telegram hangs. However if you disable the notification icon it updates fine. [12:08] <_prasen_> ogra: hi? [12:08] <_prasen_> resolved the proxy issue [12:08] sabret00the: can you pastebin: dmesg | grep "DENIED" [12:08] <_prasen_> : D [12:08] sabret00the: and report this as a separate issue, I'm sure sergiusens will want to know about it [12:09] _prasen_, congrats ! [12:09] <_prasen_> zyga : tis documented but as you said nor nuff for a nub [12:09] <_prasen_> ogra : can you tell me summin about the organise and filesets options for the dump plugin [12:10] _prasen_: you just said this is documented, did you read that documentation? [12:10] <_prasen_> https://snapcraft.io/docs/reference/plugins/dump [12:11] <_prasen_> https://github.com/snapcore/snapcraft/blob/master/docs/your-first-snap.md [12:11] <_prasen_> the git link is snap for a go webcam server [12:11] <_prasen_> it uses the dump plugin [12:11] _prasen_: look at the common keywords: https://snapcraft.io/docs/reference/plugins/common [12:11] _prasen_: organize is documented there [12:11] _prasen_: as are filesets [12:12] <_prasen_> and some comments are there [12:12] <_prasen_> okay..ty! [12:12] <_prasen_> will see this [12:12] * zyga needs to reboot, brb [12:12] <_prasen_> and I guess trying out will get me ahead [12:13] <_prasen_> if i write a single .c file with just a printf and create a makefile for it [12:13] <_prasen_> I made a .yaml for it [12:13] ogra_: I read that you made a Kodi snap for armhf, is there one for x86_64? [12:13] <_prasen_> so what plugin do i need to use for this [12:13] <_prasen_> because "." works fine for the source option [12:14] <_prasen_> if i use the autotools plugin it requires an autoconf file [12:14] ogra_: Sorry, found it, https://code.launchpad.net/~ogra/+snap/kodi-mir-snapshot/+build/17382 [12:15] laralauer, thats far from being usable [12:15] <_prasen_> ogra : hlp hlp hlp [12:15] <_prasen_> ! [12:15] zyga: I've done so https://github.com/sergiusens/telegram-snap/issues/6 [12:28] ogra_: It block for a while, shows the loading screen very briefly and then crashes because of "double free or corruption". It's a start [12:33] laralauer, nope ... its broken and i dont intend to fix it atm ... it is a test package , if it would be intended for use i would have uploaded it to the store [12:34] it is really not intended for anyone to be used [12:34] (you wont make it run) [12:36] ogra_: Okay, thanks [12:37] ogra_: sorry for the poort timing, looks like another usn is out for linux-generic [12:37] poor* [12:37] jdstrand, lol [12:38] jdstrand, i dont see anything newer than -64 [12:38] (and i have that one for the bbb already) [12:39] huh. I thought I remembered this was 63 yesterday [12:40] and you pinged me last night about -64 [12:40] :) [12:40] ogra_: oh, last night was actually meant to be about -63 for pc-kernel [12:40] hehe [12:40] hah [12:40] communication for the win! [12:40] yeah. pc-kernel is a bjf or apw think [12:40] *thing [12:40] they need to release them to stable [12:41] * jdstrand nods [12:41] (same for dragonboard ... just not for pi since that would break the installs out there) [12:41] ogra_: looks like you interprested my question as another ping for bbb and conincidentally (and unknown to me at the time), 64 had snuck in [12:41] man, I can't type [12:41] interpreted* [12:41] weklcome to my worlsd :) [12:42] funny :) [12:42] hehe [12:43] ogra_: our team is going to chase down pc-kernel with the kernel team I think so I'll try not to ping you on that. thanks for the bbb updates! :) [12:43] np [12:54] PR snapd#2908 closed: snapstate: fix incorrect cut of the timestamps for the error reports [13:33] jdstrand: hey, we have some zesty failures on jailmode + classic confinement [13:33] jdstrand: cannot map segment of libc.6 [13:35] jdstrand: maybe the kernel has changed so apparmor semantics has changed again [13:36] jdstrand: I'll tell you more in a sec [13:37] jdstrand: [ 2929.841318] audit: type=1400 audit(1487770576.927:40): apparmor="DENIED" operation="file_mmap" profile="snap.python0.python0" name="/snap/core/1264/lib/x86_64-linux-gnu/libm-2.23.so" pid=5235 comm="python0" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0 [13:37] jdstrand: looks like exactly what we saw before [13:38] jdstrand: I'll report this [13:42] jdstrand: https://bugs.launchpad.net/snapd/+bug/1666897 [13:42] Bug #1666897: snaps with classic + jailmode confinement started to fail on zesty [13:43] Looks like the copr snapcraft repo hasn't been updated to support Fedora 25, is there a technical barrier? [13:44] nelsk: hey [13:45] nelsk: not sure, kyrofa might know [13:45] zyga: Ah, I recognize your handle :) [13:45] nelsk: if you ask about snapd then we have a 2.23 release pending (since Friday) but we're in emergency mode and we won't release it untill this is fixed [13:45] nelsk: and 2.23 will (finally) go into F25 and 26 [13:46] is there some kind of bug blocking release or you guys are just in a code freeze? [13:46] Just curious so I can follow along [13:47] nelsk: for snapd or snapcraft (I don't know about snapcraft) [13:47] nelsk: snapd is in emergency mode, we realized that 2.22.x that went out had a very nasty bug [13:47] nelsk: and we're iterating, since Friday, with point releases that unbreak people in the field [13:47] nelsk: 2.23 is frozen as the whole team is just busy on the fire [13:47] I'm sorry, I meant your snapcore* repo in copr. Looking for snapd, so that makes sense [13:47] Good to know, thank you. [13:47] nelsk: 2.23 and 2.24 will just go out delayed [13:48] nelsk: probably 2.24 will have all the fedora packaging and policy merged [13:48] nelsk: but the code is fine as of last week, we just were waiting for the tag to flow [13:48] just bad luck [13:48] when we release the "candidate" release goes to "stable" [13:48] and master "edge" goes to "candidate" [13:49] and we pushed the candidate to stable and started to see things explode [13:49] so we stopped [13:49] the candidate release also goes for distribution packaging [13:49] like $ubutnu_codename-proposed and what not [13:49] (sid, etc) [13:49] just really bad luck this week [13:49] sounds good, will look forward to the release [13:50] Just popped in to see if there was anything holding up the Fedora 25 repo and if I could help with that [13:50] nelsk: if you want to see what's coming have a look at the snapd repo on fedora git, I think neal has commited everything there already [13:50] nelsk: you can help for sure [13:50] nelsk: we'll need to improve the selinux policy [13:50] nelsk: and just polish bits as I'm sure we'll find out things are not working in some odd edge cases [13:50] ah yes, good old selinux [13:50] nelsk: the test suite doesn't run on fedora yet, but that's easy to fix [13:51] nelsk: fedora builds use /var/lib/snapd/snap as a location for all the mounted packages [13:51] nelsk: and the test suite has hard-coded /snap directory [13:51] are there GH issues floating around against these? [13:51] nelsk: there will be some boring branches to fix that [13:51] nelsk: we switched to laucnhpad for that launchpad.net/snapd [13:51] nelsk: there's no issue filed for the unit tests I think [13:51] cool, will subscribe over there [13:51] nelsk: if you want to help now: fork and clone master of github.com/snapcore/snapd [13:52] nelsk: and I can work with you on enabling the test suite [13:52] nelsk: (the C test suite passes, the Go one will fail on /snap) [13:52] nelsk: I had a look at this a few months ago but I got a gigantic branch that was very ugly [13:52] nelsk: so after talking to some people on the snapd team we decdied to use a different approach [13:52] will fork and ping you later on, thanks for your quick help [13:52] nelsk: and just mock /snap for testing [13:53] nelsk: thanks! great to have you here, stay in touch please [13:53] will do! [13:53] nelsk: for the mocking we'd need to add a function to dirs/dirs.go [13:53] nelsk: and just use it when we test for this in the unit tests [13:53] nelsk: should be not that big of a patch [13:53] I'd be happy to take that one [13:53] nelsk: and cna be done on a per-package basis so some stuff turns green while other is not changed yet [13:54] nelsk: and after the 2.23 release I'd like to enable snapd CI to work with fedora [13:54] I can explan how that works when you want to know [13:54] that would be great. have to run off to some meetings but I will ping you later on [13:56] great, see you :-) [14:03] PR snapcraft#1158 opened: packaging: snapcraft as a snap [14:06] PR snapd#2906 closed: overlord/ifacestate: don't unconditionally retry stuff [14:09] PR snapd#2909 closed: overlord/snapstate: improve error reporting around core migration [14:21] PR snapd#2825 closed: osutil: add package for reading Build-ID [14:23] PR snapd#2910 opened: osutil: add package for reading Build-ID [14:25] PR snapd#2900 closed: errtracker: include snapd version in err reports [14:34] PR snapd#2903 closed: many: rebased uname branch for 2.22 [14:50] PR snapd#2888 closed: many: display kernel version in 'snap version' [14:51] PR snapd#2898 closed: many: merge 2.22.5 back to master [14:52] davidcalle: hi! fyi, I got some feedback on the whitepaper and it is now at rc7. You should have an email in your inbox [14:53] Great, thanks jdstrand [15:00] PR snapcraft#1159 opened: docs: use correct target to generate docs [15:03] I'm sure this gets asked all the time, but I'm having trouble finding info. What's the best way to get snapd on Debian Jessie? If I simply install snap (and not snapd), installing snaps throws errors. [15:03] PR snapd#2911 opened: release: return "unknown" if uname fails [15:03] zyga: I'm not sure 'High' is the right priority for that (I mean, --classic with --jailmode is a bit of a corner case, no?), but I'll respond in the bug [15:07] PR snapd#2905 closed: errtracker: include kernel version in error reports [15:12] PR snapd#2911 closed: release: return "unknown" if uname fails [15:21] zyga: fyi, https://bugs.launchpad.net/snapd/+bug/1666897/comments/1 [15:21] Bug #1666897: snaps with classic + jailmode confinement started to fail on zesty [15:22] zyga: that tells how to fix it [15:23] jjohansen: can you look at https://bugs.launchpad.net/snapd/+bug/1666897/comments/1 ? there is a difference of behavior concerning 'm' mediation on 4.10 and 4.4 [15:23] Bug #1666897: snaps with classic + jailmode confinement started to fail on zesty [15:24] jjohansen: I think that 4.10 may be working correctly... [15:30] PR snapd#2912 opened: errtracker: include the build-id of /usr/bin/sanp [15:42] Hey snappy crew, simple question. Are you using Travis-CI in any of your build toolchain? We're looking into using snaps in travis-ci and have been blocked on some apparmor config we haven't been able to work-around. Curious if anyone else has run into this, and if we haven't, is there a list of apparmor ignore/allow that we can send over to the travis folks and get this unblocked? https://github.com/travis-ci/travis-ci/issues/7318 [15:42] cc cory_fu ^ [15:43] lazyPower: https://github.com/travis-ci/travis-ci/issues/5821 is also somewhat relevant [15:46] lazyPower: elopio had mentioned previously the possibility of using lxd to get a xenial env, but I'm not sure if that would work under Docker that Travis uses? [16:10] Bug #1666978 opened: Security setup may fail with ErrNoState if repository and snapstate get out of sync [16:19] PR snapd#2913 opened: overlord/ifacestate: loudly ignore ErrNoState where we cannot handle it [16:29] PR snapd#2914 opened: snapstate: retry ubuntu-core -> core transition every 6h [16:43] nelsk, zyga_ I don't know about snapcraft on fedora either. It might be community-driven [16:47] O.o [16:47] wait, what? [16:47] snapcraft on Fedora is blocked by two things: [16:47] 1. https://bugs.launchpad.net/snapcraft/+bug/1602258 [16:47] Bug #1602258: Support other distributions as sources (Fedora, Mageia, openSUSE, Debian) instead of Ubuntu [16:48] 2. snapd needs a concept of base snaps [16:48] for different bases [16:48] nelsk, zyga_, kyrofa: ^ [16:49] Pharaoh_Atem, indeed. nelsk asked about a snapcraft copr though, and why it wasn't updated [16:49] we don't have one [16:49] snapcraft *does not run* on anything but Ubuntu [16:49] it can't [16:49] Pharaoh_Atem, kyrofa: I mispoke and actually mean zyga/snapcore [16:50] meant* [16:50] ah [16:50] so you'd like snapd [16:50] Pharaoh_Atem, I'm well aware :) [16:50] Pharaoh_Atem: yep, that's what I was looking for [16:50] nelsk, ah ha! That makes more sense [16:50] indeed [16:50] it's been a while since someone asked about snapcraft on Fedora, so I was confused :P [16:50] Pharaoh_Atem, me too! [16:50] Pharaoh_Atem, I actually assumed it was you messing with stuff [16:51] hah, sorry for the confusion. Relatively new to the project so the significance of that blunder was over my head :P [16:51] no one else knows what the project is called, so that's fine :) [16:51] hahaha [16:51] nelsk, yeah, you're not alone ;) [16:51] I call the whole thing snappy, because there's not something much better [16:51] snapcraft makes snaps, that are consumed by snapd [16:52] nelsk, but, just to clarify: snapd is the daemon behind actually using/running snaps [16:52] nelsk, snapcraft is the tool that actually creates snaps [16:52] does "snapcore" encompass anything more than snapd? [16:52] it's the name of the GitHub organization [16:52] nelsk, on github? Snapcraft as well [16:53] As well as our official gadget snaps, I think [16:53] aha! okay that makes sense [16:53] snapcore was created after it was agreed to move everything out of the Ubuntu organization [16:53] so snapd is actually nearly ready to run OOTB [16:53] two things (again!): [16:54] Two is a terrible number [16:54] 1. snapd selinux policy needs to be merged: https://github.com/snapcore/snapd/pull/2878 [16:54] PR snapd#2878: Merge SELinux policy module [16:54] 2. snapd packaging needs to be merged (no PR yet, since it's blocked on that being merged) [16:54] then snapd can be released and zyga and I can push everything into CentOS and Fedora [16:55] Fedora first, and then we'll work out CentOS [16:55] Pharaoh_Atem, is SELinux integration looking good? [16:55] kyrofa: it's actually not in great shape [16:55] but the module basically throws snapd into permissive domain [16:55] which keeps everything from breaking [16:55] Oh, not ideal [16:55] PR snapd#2915 opened: errtracker: include the number of ubuntu-core -> core retries [16:55] it also allows us to iterate on actually making snapd confined properly [16:56] Rather than one enormous PR, good call [16:56] and by merging the policy into the snapd repo, I'm hoping other people will help me keep up with the churn in snapd [16:56] I'm constantly playing catch-up, which is really, really, really draining [16:56] o/ [16:56] Pharaoh_Atem, I hear you [16:57] it also puts more impetus on hopefully a SELinux developer getting hired to do formal SELinux integration into snapd [16:57] because frankly, my skills are being pushed to their limits with this [16:58] I'm doing the best I can, but keeping up with all of the new things snapd does in every release AND adjusting the policy so that snapd itself is properly confined AND making it so snap-confine would work is impossible fo rme [16:58] *me [16:58] Pharaoh_Atem: once we have CI we can make this better [16:58] Pharaoh_Atem: but we need to release first for CI [16:58] that's what everyone says... === zyga_ is now known as zyga [16:58] CI isn't magic [16:58] well, that's because it is true :) [16:59] Pharaoh_Atem: CI means we don't regress [16:59] well, not necessarily, as you could just ignore them :) [16:59] Pharaoh_Atem: and when we CI on Fedora we know we regress when we break something w [16:59] we don't ignore CI :) [16:59] * kyrofa has to drive back home. Be back in about 5 hours [16:59] that's like CI [16:59] I hope not [16:59] Continuous Ignorance [16:59] :D [16:59] :D [16:59] I see Continuous Ignorance everywhere :) [17:00] it's so easy, after all :P [17:00] bliss ;-) [17:00] Pharaoh_Atem: can you try to package master [17:00] Pharaoh_Atem: that will become 2.23 soon (or .24) [17:02] PR snapd#2916 opened: osutil: trivial tweaks to build ID support [17:13] zyga: I can try [17:24] Pharaoh_Atem: I want to have a good nights sleep and wake up with the fire put out so that we can return to normal work [17:27] zyga: snap-confine fails to build [17:28] zyga: https://paste.fedoraproject.org/paste/EzIdE98z5AUQyKFnbrBH4F5M1UNdIGYhyRLivL9gydE= [17:31] Pharaoh_Atem: that file must be built with -static [17:32] Pharaoh_Atem: and cannot take relocation AFAIK [17:32] Pharaoh_Atem: we had the same issue in ubutu [17:32] Pharaoh_Atem: look at the hack in configure.ac [17:32] Pharaoh_Atem: er in Makefile.am [17:32] Pharaoh_Atem: it's also uselss so if you cannot fix it just rip it out [17:32] Pharaoh_Atem: or do a trivial patch that disables the shutdown helper [17:32] also, the merged-usr switch doesn't work? [17:33] oh? what do you mean? [17:33] look at the log [17:33] it's unrecognized [17:34] Pharaoh_Atem: hmm [17:34] enable-merged-usr? [17:34] maybe simple bug that I didn't see because it doesn't stop [17:34] autotools doesn't die on unrecognized switches [17:34] it's --enable-merged-usr now? [17:35] checking [17:35] Pharaoh_Atem: it was all along [17:35] Pharaoh_Atem: sorry, slipped under my radar [17:36] PR snapd#2916 closed: osutil: trivial tweaks to build ID support [17:42] alright, now the C bits are built [17:46] PR snapd#2808 closed: interfaces: use mount.Entry instead of string snippets [17:48] zyga: you've got godeps to package :) [17:49] zyga: https://paste.fedoraproject.org/paste/cnAi~vkNe-YMvtLyCYRdql5M1UNdIGYhyRLivL9gydE= [17:55] Pharaoh_Atem: gah what an annoying URL with trailing = [17:55] Pharaoh_Atem: can we vendor everything in snapd if we annnotate? [17:59] yes, but it's arguably harder to annotate [17:59] as it has to be versioned Provides [18:00] Pharaoh_Atem: mm? [18:00] Pharaoh_Atem: provides how? [18:00] Pharaoh_Atem: I mean I know provides but I don't know what you mean [18:00] well, it'd have to be something like this... [18:01] Provides: golang(github.com/foo/bar) = (versioned, with githash) [18:02] hmm [18:02] Pharaoh_Atem: that's much better than maintaining ~30 packages [18:02] and every time the dependency is updated, added, removed, these have to be updated [18:02] Pharaoh_Atem: especially we could easily derive this data from vendor.json [18:02] Pharaoh_Atem: it contains exactly that I think [18:03] plus licensing data must be packaged with it too [18:03] Pharaoh_Atem: this is more important [18:03] Pharaoh_Atem: what do we need to package ? each license file? [18:03] Pharaoh_Atem: do we need it with snapd or the source package? [18:04] from each source package [18:04] bundled stuff needs their licensing preserved too [18:04] Pharaoh_Atem: where do we need to put the source files? [18:04] Pharaoh_Atem: that's a curious thing [18:04] Pharaoh_Atem: if we didn't bundle [18:04] Pharaoh_Atem: we'd ship the same binary with one copyright file [18:04] Pharaoh_Atem: if we bundle we ship the same binary with... lots of files [18:04] the reason is because we have the sources somewhere else [18:05] Pharaoh_Atem: it's not like .c wherere the .so files pull in the license [18:05] Pharaoh_Atem: wait, we still do [18:05] Pharaoh_Atem: we can generate a tarball that has the sources [18:05] Pharaoh_Atem: (in fact we do already) [18:06] do you guys have the copyright file with all the dependencies licensing data? [18:06] Pharaoh_Atem: we have a repo that automatically commits the whole dependency into vendor [18:06] Pharaoh_Atem: so all the copyrights and everything [18:07] zyga: I do not see it [18:08] https://github.com/snapcore/snapd-plus-vendor/blob/master/packaging/ubuntu-16.04/copyright [18:08] if you're really shipping vendored tarballs, you're doing it wrong [18:09] zyga: the thing is, an acceptable substitute would have been a debian/copyright file that has all the declarations [18:09] but they don't [18:10] Pharaoh_Atem: no, not that [18:10] Pharaoh_Atem: we don't keep it in one place automatically [18:10] Pharaoh_Atem: I see what you are saying now, that will have to be done [18:11] Pharaoh_Atem: I'll get my hands on this, we should have done this during the vendoring [18:11] yeah [18:11] since it doesn't exist, we cannot vendor yet [18:12] I think I will do both [18:12] zyga: incidentally, a version of the copyright file that doesn't assume that /usr/share/common-licenses/* exists would be extremely helpful [18:12] Pharaoh_Atem: I'll fix debian copyright because that's an omission [18:12] because as you're aware, that's Debian only thing [18:12] Pharaoh_Atem: and I'll package deps separately in case this is a policy issue of any kind [18:13] yeah [18:13] well, fortunately, as a maint/comaint for those deps, it's not problematic to update as needed [18:14] keep in mind it's not like the Debian world where updating deps is difficult politically due to bureaucratic processes just making it difficult [18:14] Pharaoh_Atem: I'll try to get the build deps packaged tonight, maybe at lest two [18:14] Pharaoh_Atem: yes :-) [18:14] Pharaoh_Atem: will you be around in +3 hours if I poke you for a quick review [18:14] yes [18:15] Pharaoh_Atem: looking at the list.. just top-to-bottom I guess [18:16] Pharaoh_Atem: with some luck maybe suse can reuse them [18:16] Pharaoh_Atem: but I don't have high hopes [18:16] * Pharaoh_Atem sighs [18:16] Pharaoh_Atem: btw, I ran into rpkg, is that lie fedpkg for rhel? [18:16] pyrpkg is the base module [18:16] fedpkg, centpkg, and rhpkg are frontends for rpkg [18:17] ah, I see [18:17] cool :) [18:18] Pharaoh_Atem: thanks for letting me know, please commit your changes back [18:19] Pharaoh_Atem: I'm going to be off next week [18:19] Pharaoh_Atem: maybe I can use that time for something fun :) [18:22] * zyga needs some sleep [18:22] at least an hour [18:29] hmm [18:29] I wonder if it might be easier to regenerate the spec using gofed [18:45] PR snapd#2904 closed: overlord/snapstate: tweak messages in {un,}link-snap [18:46] PR snapd#2910 closed: osutil: add package for reading Build-ID [18:48] PR snapd#2907 closed: overlord/ifacestate: improve error messages [19:04] PR snapd#2914 closed: snapstate: retry ubuntu-core -> core transition every 6h [19:09] PR snapd#2915 closed: errtracker: include the number of ubuntu-core -> core retries [19:16] Is there any documentation on this Restart option? [19:16] Feb 22 19:11:25 localhost systemd[1]: snap.apport.enable.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusin [19:31] PR snapd#2912 closed: errtracker: include the build-id of /usr/bin/snap [19:32] jdstrand: okay bug updated [19:41] jjohansen: thanks [20:17] PR snapd#2917 opened: osutil: remove duplicate build_id from other branch [20:20] PR snapd#2918 opened: revert: osutil: add package for reading Build-ID [20:21] PR snapd#2918 closed: revert: osutil: add package for reading Build-ID [20:28] PR snapd#2913 closed: overlord/ifacestate: loudly ignore ErrNoState where we cannot handle it [20:29] PR snapd#2919 opened: overlord/ifacestate: don't fail if affected snap is gone [20:34] PR snapcraft#1159 closed: docs: use correct target to generate docs [20:46] test [20:48] PR snapd#2920 opened: wrappers/services: RemainAfterExit=yes for oneshot daemons w/ stop cmds [22:00] cprov: hey. I'm trying to see the plugs and slots for all the snaps in the store. I'm using curl -s https://search.apps.ubuntu.com/api/v1/snaps/search?fields=name,plugs,slots | jq -M '.', but the output is incomplete (eg, ufw and snappy-debug aren't in there). what am I doing wrong? [22:00] has snapcraft grown support for detecting snapped lxd? [22:01] sorry i asked before i looked and found https://bugs.launchpad.net/snapcraft/+bug/1666735 [22:01] Bug #1666735: snapcraft cleanbuild does not work with lxd installed via snap [22:03] nessita: hey, perhaps you can hel with my question? ^ [22:08] Ah, I found bug 1613971 and commented on it. [22:08] Bug #1613971: using oneshot results in failed service [22:10] jdstrand: the output is paginated, you need a script (but maybe I'm misunderstanding the question) [22:12] jdstrand: yup, there are 6 pages of 100 results each. Let me find a script you can use [22:16] pedronis, cprov: ah, thanks [22:16] I didn't know if there as an extra something to add to the url to give me unpaginated [22:17] nessita: nm, cprov is helping me [22:17] bdmurray: as luck would have it https://github.com/snapcore/snapd/pull/2920 should take care of that :) [22:17] PR snapd#2920: wrappers/services: RemainAfterExit=yes for oneshot daemons w/ stop cmds [22:17] jdstrand: something like this -> https://pastebin.canonical.com/180409/ [22:18] ssweeny: oh, nice! :) [22:18] cprov: let me try [22:20] cprov: yes, that is perfect. thanks! [22:21] jdstrand: anytime [22:22] cprov: and aiui, this is only for stable and there isn't a way to search via search.apps.ubuntu.com for other channels, right? [22:23] ssweeny: hey, do you know of a snap that slots 'upower-observe'? [22:24] jdstrand: yup, stable (strict+classic) [22:24] * jdstrand nods [22:24] thanks again [22:24] np [22:25] jdstrand: can't think of one [22:27] ssweeny: ok, thanks. the slot side was implemented but I can't find a snap that uses it [22:27] slot side of the interface [22:27] I'll ask mor phis tomorrow [22:27] right. I've seen one or two plug side uses of it [22:31] PR snapd#2919 closed: overlord/ifacestate: don't fail if affected snap is gone [22:43] PR snapcraft#1160 opened: history: rename to 'revisions' with alias 'list-revisions' [22:45] PR snapd#2921 opened: releasing package snapd version 2.22.6