[00:00] nessita darn, I went into fixing our python3 plugin and was trying with ill results until I noticed this was python2 :-P [03:14] PR snapcraft#771 opened: Python plugin improvements === PatrizioQON is now known as pbek [05:06] is there an interface that rants an application permissions to read files in /etc (hosts, resolv.conf)? [05:06] s/rants/grants [05:12] kyrofa: strange, when I call `qownnotes` directly in the desktop file I get a: `404 Client Error: Not Found` === chihchun_afk is now known as chihchun === cpaelzer_ is now known as cpaelzer [05:45] kyrofa: using `desktop-launch $SNAP/usr/bin/QOwnNotes --snap` didn't work neither, but it now seems `qownnotes` worked 3 out of 4 times. I only got the error `404 Client Error: Not Found` once, so I will stick with that. Thanks a lot! [05:58] PR snapd#1798 closed: firstboot: change location of netplan config [05:59] PR snapd#1796 closed: interfaces: add screen-inhibit-control interface (LP: #1604880) [06:00] PR snapd#1795 closed: camera interface improvements [06:03] PR snapd#1792 closed: asserts: introduce device-session-request [06:08] PR snapd#1800 opened: tests: fix firstboot-assertions to actually work on clasic again === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:35] hey hey [06:38] o/ [07:04] PR snapd#1800 closed: tests: fix firstboot-assertions to actually be runnable on classic again [07:21] PR snapd#1801 opened: snap: make snap download also download the assertions for the snap === jamespag` is now known as jamespage [07:44] mvo: thanks for merging that [07:54] o/ [07:56] is there a way to let a snappy application access system files (e.g. /etc/hosts)? === ant_ is now known as Guest45561 [08:14] mwhudson: yw [08:14] mwhudson: thanks for working on it in the first place :) [08:25] tsimonq2: yes, using interfaces [08:26] tsimonq2: that file should be in the default permission set [08:26] * zyga checks [08:33] morning! [08:33] any idea how to tell the new u-d-f to use my own gadget snap? [08:34] hey, anyone has an idea what's wrong if I hit this from ubuntu-device-flash? [08:34] cannot bind mount /dev to /tmp/snap.rootfs_k6mTS3/dev. errmsg: No such file or directory [08:34] tsimonq2: that file is not allowed currently [08:34] I've the u-d-f version from the snappy store [08:34] tsimonq2: please open a bug and tag it with 'snapd-interfaces' on launchpad.net/snappy [08:35] mzanetti: this is a message from snap-confine, does your system have /dev? [08:35] I have no idea [08:35] ysionneau: no idea, sorry [08:35] mzanetti: ls -ld /dev ? [08:35] zyga, ah, you mean the folder, yes it does :D [08:35] I thought "dev mode enabled" or something :D [08:35] mzanetti: how about: ls -ld /snap/ubuntu-core/current/dev [08:36] nope that's missing [08:36] mzanetti: can you try: export SNAP_CONFINE_DEBUG=1 [08:36] mzanetti: oh? how about snap list [08:36] mzanetti: snap list [08:36] mzanetti: tell me if you have the core snap installed (ubuntu-core) [08:36] mzanetti: and if so, which revision that is [08:36] I do, but it says "broken" in the Notes [08:36] rev 48 [08:37] mzanetti: interesting, any idea how you managed to do that? [08:37] mvo: ^^ [08:37] no [08:37] mzanetti: (this is why you cannot run snaps) [08:37] right, makes sense [08:37] mzanetti: if you look in /var/lib/snapd/snap can you see the corresponding .snap file? [08:37] (for ubuntu core) [08:38] I'm on xenial (+stable-phone-overlay) and I installed the ubuntu-calculator-app via snap some months ago, didn't really touch it since... now it's broken [08:38] yes, the ubuntu-core.snap is there [08:39] mzanetti: curious, can you report a bug, attach your /var/lib/snapd/state.json file (please make the bug private) [08:39] mzanetti: which version of snapd are you on now>? [08:39] 2.13 [08:58] mzanetti: fwiw i had that happen to me and rebooting fixed it [08:58] i think [08:59] random flailing around, including rebooting, fixed it [09:01] mwhudson, will the new console-conf skip network device config if it finds an existing one (did you guys test with a configured wlan device yet) ? [09:02] ogra_: it won't skip, but just pressing ok should work fine [09:02] what got me in the loop was the inability to cancel or skip that bit iirc [09:02] ok [09:02] ogra_: i haven't tested it myself (not sure where i put my dragonboard!) [09:03] a pi3 would even be better ... since it has eth and wlan ;) (and i fear a typical usecase is to not use the eth) [09:04] my linaro days left me with a profound dislike of all developer boards :) [09:04] lol [09:05] see, that is why i never went there ;) [09:05] probably sane [09:05] it leaves its marks to work for a company that sounds like a sanitary pad ;) [09:06] hmm do rpis actually have proper MAC addresses? [09:06] sounds like an improvement over some things... [09:06] yep ... on our images they do ;) [09:07] like e.g. the dragonboard iirc [09:07] the dragonboard images have fixed MACs as well === dpm_ is now known as dpm [09:47] hi folks - I'm trying to snap codetree (lp.net/codetree) and I'm most of the way there, but I'd expect it'll need to be able to use bazaar and git credentials for a user. Are there some docs that would explain how to do that? [10:04] mthaddon: I don't believe you can do that today, there are existing interfaces that aim to allow a snap to use certain "dot" directories [10:04] mthaddon: sorry, I meant, bugs and pull requests [10:04] zyga: ack, thx [10:05] mthaddon: the $HOME directory is not the real home, that's a separate issue [10:05] it's non-hidden home, right? [10:05] mthaddon: so I'd say that you need to look at solving two separate problems [10:05] mthaddon: 1) knowing where real home is (e.g. through a new SNAP_REAL_HOME variable) [10:06] mthaddon: teaching your snap to construct symlinks to $SNAP_REAL_HOME/.ssh .bzr and .git and what not in $HOME [10:06] mthaddon: and using an interface to gain read/write access there (you can start with devmode) [10:06] mthaddon: given that $LOGNAME exists you can work around the first problem by just faking it with /home/$LOGNAME [10:06] mwhudson: give that a try! [10:06] Son_Goku: hey! [10:06] Son_Goku: just the person I was looking for [10:07] Son_Goku: what are the common names for locale packages? [10:07] thx [10:07] Son_Goku: I was working on an update to golang gettext bindings when I noticed tests don't work anymore, the test code was tweaked to use setlocale(LC_ALL, "") and I suspect I need to add appropriate locale packages to the mock environment as build-deps [10:10] zyga, dnf repoquery --whatprovides "glibc-langpack" will give you a list of them [10:10] the C and C.utf-8 locales are provided by glibc-minimal-langpack [10:11] you probably want glibc-all-langpacks for gettext [10:11] Upstream of what I'm trying to snap up don't provide source, and ship only a zip file. Scripts in this zip file aren't executable, but they do expect one another to be. Is there a good way for me to run "chmod +x .../*" as part of my snapcraft build? [10:12] (I'm currently just using the dump plugin.) [10:16] Son_Goku: thanks! [10:16] Odd_Bloke: I'm old so I love make, just use make :) [10:16] zyga, prior to fedora 24, all langpacks were installed by default since they weren't split out in glibc [10:16] so none of this existing pre-f24 [10:17] all the base locale stuff was installed by default in f23 and older [10:17] zyga: How do I use upstream zip as a source but get my own Makefile integrated in? [10:17] it might be that or something else, I'm investigating [10:17] could be that the test fails because of the current working directory [10:17] Odd_Bloke: just unpack it as a part of the make target [10:17] Odd_Bloke: keep the makefile in your tree [10:18] zyga: And also fetch it as part of the make target? [10:18] Odd_Bloke: get the zip using snapcraft [10:18] Oh, just don't tell it it's a zip file? [10:18] Odd_Bloke: yep, just switch to the make plugin and point to the separate makefile [10:31] how are people handling log rotation inside their snaps? [10:37] Son_Goku: anything I can pass to fedpkg mockbuild to get an interactive shell at a particular point? [10:38] PR snapd#1802 opened: image,overlord/boot,snap: metadata from asserts for image snaps [10:40] zyga: would I expect to see a PR for allowing access to specific dot directories on https://github.com/snapcore/snapcraft/pulls ? Would like to track the issue if there is one [10:42] also don't see a bug matching "dot" or "hidden" on https://bugs.launchpad.net/snapcraft [10:47] mthaddon: there's a bug about this, not sure if there's a PR for it too [10:47] try launchpad.net/snappy [10:48] * zyga would like a snapcore project group [10:48] and snapd, snapcraft, ... projects insid [10:48] e [10:48] cool, https://bugs.launchpad.net/snappy/+bug/1607067 - thx [10:48] Bug #1607067: Add a dotfiles / hidden files interface [10:48] zyga, that group is called snappy-dev on LP ;) [10:49] ogra_: not group, project group [10:49] ogra_: that's nice to use to search bugs amongs snappy related projects [10:49] ogra_: coordinate milestones and find the relevant projects in one spot [10:50] https://bugs.launchpad.net/~snappy-dev ... we just need tio sunscribe the team to the right packages and branches [10:50] *sub [10:51] ogra_: that doesn't help people when bugs are spread amongs projects and they are not a member of the -dev group to know about it in the first place [10:51] (no idea why nobody did that yet ... we definitely use the team for everything else... like automation, branch and PPA ownerships) [10:51] huh ? why wouldnt it [10:51] everyone can see the buglist [10:52] ogra_: do you know what a launchpad project group is? [10:52] ogra_: e.g. https://launchpad.net/checkbox-project [10:53] https://bugs.launchpad.net/snappy ? [10:53] ogra_: that doesn't show bugs in snapcraft or in snap-confine [10:53] that is exactly my point [10:53] so we can add these [10:54] ogra_: ? [10:54] ogra_: add them where? [10:55] PR snapd#1803 opened: spread: enable halt-timeout, tweak image selection [10:55] cant you add additional bug monitoring to the project by subscribing it to other projects ? [10:55] iirc thats possible [10:56] ogra_: I don't know anything about that, sorry [10:56] https://launchpad.net/snappy/+sharing [10:56] the snapcraft team would have to share them with usa [10:56] *us+ [10:56] bah [10:56] then they will show up in the snappy buglist [10:57] ogra_: in the end, will I see all the bugs in bugs.launchpad.net/snappy? [10:57] right [10:57] lets talk about it in the meeting [10:57] ogra_: interesting, I wonder what's the desire with the project group feature overlap [10:57] ogra_: I think the issue is social, people recall snapcraft as the "brand" because that is what the mailing lists and the website is called [10:58] right [10:58] ogra_: we talked about setting up a project group a while ago but it never materialized [11:02] Pharaoh_Atem: hey, I have a question, is it ok to commit non-working packaging to master [11:02] Pharaoh_Atem: I'd like to have a second pair of eyes on the problem I was facing === hikiko is now known as hikiko|ln [11:26] ogra_: 9 M snap size and 0.9% memory usage on my pi3, does that sound better for you for the network-manager snap? :-) [11:28] morphis, definitely an improvement, but indeed still more then 0MB :) [11:28] *than [11:30] i think NM preseeded is absolutely fine on PC class installs like the dell gateways, but i still think we shouldnt pre-seed it on embedded (rpi, dragonboard) and use the existing alternative there [11:31] why? [11:31] latest NM is quite small and lightweight [11:31] and it's super easy to configure [11:32] Son_Goku, because it is still bigger than zero ;) [11:32] it just doesnt make sense ot have something like NM on the embedded board of your lawnmower [11:32] it really doesn't make sense for your lawn mower to be internet connected [11:32] where you most likely have pretty hard requirements regarding disk and ram size [11:32] huh ? [11:33] I'd say in that case it should have nothing [11:33] how else would i install additional autopilot snaps ;) [11:33] not even the legacy networking [11:33] or steer it via that mobile app [11:33] .... [11:33] you have problems [11:34] well, snappy was initially designed for IoT ... and we'll go there again after that little detour to make it a generic package format [11:36] ogra_: yeah I agree [11:36] by default we give netplan/ifupdown which is enough and then someone can pick [11:37] well, we should have a default image with NM as well ... just not for the low level devices [11:37] sure, but that is then for the implementor to pick [11:38] as long as the snap is in the store, tested and ready to use you can put it in images, install on demand, whatever you want [11:38] yeah [11:39] * ogra_ trickles launchpad [11:39] come on publisher ... you knwo you can do it [11:39] btw. I lied, amd64 is 7.9 M and armhf is 5.9 now [11:39] how about arm64 ? [11:39] i suspect thats the biggest [11:39] need to check [11:41] morphis, why not use networkd [11:41] we do [11:41] when NM isnt installed [11:41] good [11:41] Son_Goku: networkd does give you some advance features in certain situation [11:41] it's quite nice [11:42] and it isn't ifupdown :) [11:42] which means no sysv scripts [11:42] * ogra_ doesnt get all the hate for ifupdown ... [11:42] ogra_: https://launchpad.net/~morphis/+snap/network-manager-reduced-footprint [11:43] my server stalls for more than 5 minutes at work while trying to bring up networking [11:43] swapping that out for NetworkManager completely eliminated the bottleneck [11:43] wow, that sounds like a buggy setup then [11:45] * tvoss hugs the poor little publisher [11:48] hmm [11:48] my current upgrade wants to uninstall unity8-desktop-session [11:48] that doesnt sound right [11:51] * ogra_ triggers an ubuntu-core edge build with console-conf included ... lets see how it behaves now [11:57] pitti: quick (silly) question, what kind of network restrictions do we have inside adt? I would love to run our spread tests inside adt but need some access, notable github and the snappy store. I guess the later is no problem, what about the former? [12:08] ogra_ uhh no [12:08] my setup is damn simple [12:08] it's just bringing up the interface with dhcp [12:09] ifupdown is just brittle as hell [12:09] well, except that it isnt normal to take 5min :) [12:10] not even with ifupdown [12:10] * Son_Goku shrugs [12:10] moving to networkd or NetworkManager fixes it [12:10] * ogra_ doesnt have such probs with any of his machines ... so i never felt the need to move [12:10] PR snapd#1804 opened: tests: use the spread tests with the adhoc interface inside autopkgtest [12:12] hmm, it would be really nice if the store wouldnt spam me with a 504 error mail for each ubuntu-core snap build [12:13] (especially since its a lie) [12:16] mvo: you can use that, as long as you respect the proxy vars [12:18] mvo: we routinely run tests which clone stuff from github, works fine [12:19] pitti: cool, thank you [12:19] ogra_: hm, we have a "test" user in our image? [12:20] ogra_: do you know anything about this? uid 1001 === hikiko|ln is now known as hikiko [12:22] mvo, nope [12:22] PR snapd#1803 closed: spread: enable halt-timeout, tweak image selection [12:23] mvo, which ubuntu-core revision is that ? i just did a test build with console-conf re-added [12:23] ogra_: this is the one I got I think [12:23] then it might come from there [12:24] pitti: and one more silly question, what is the best way to test if autopkgtest works in the real environment we use? I guess a yakkety upload? or is there some better way? [12:24] ogra_: so console-conf might add a test user? [12:24] i dont know what else would [12:24] definitely not livecd-rootfs [12:25] and i havent seen any cloud-init changes either [12:25] mvo: if it works locally with qemu it should mostly likely work on teh infra too [12:25] mvo: you can try it on canonistack too if you want [12:29] pitti: ok, that is good enough for me (qemu), I will double check in there then and hope for the best :) [12:29] mvo, looking at the subiquity diff i dont see anything that would add a test user [12:31] mvo: note that github has a great CI functionality too -- we can run the autopkgtests on PRs on xenial and yakkety [12:32] which is a much better way to do it than waiting for an upload and then trying to find out what broke stuff === JanC is now known as Guest73215 [12:36] morning [12:38] pitti: you mean via travis? [12:38] pitti: this is close to what we are doing, except that we use spread instead of autopkgtest. I'm trying to brige these worlds right now [12:38] mvo: no, you can configure a web hook to request an autopkgtest on our infra, and ask it to build and test a PR branch [12:39] we've done this for systemd for a long time now, and didrocks once set it up for ubuntu-make [12:39] mvo: this just needs an hour of sitting down, exchanging some shared secrets and configuring the snappy gh project [12:41] pitti: indeed, we had the webhook setup too, we had some trouble with the infrastructure though, federico knows the details and eventually moved to spread [12:43] mvo, oh, FYI .. http://people.canonical.com/~ogra/ubuntu-core-builds/ ... ( that is only pparsing the log from the auto-builder though, so manual builds are ignored) [12:43] PR snapd#1788 closed: snapstate: use umount --lazy when removing the mount units [12:43] (but helpful if you need the mapping between LP and the store revisions) [12:44] neat [12:45] changelogs (manifest diffs) and manifests will show up there too... once we have them [12:46] PR snapd#1805 opened: use beta u-d-f in test by default [12:53] pitti mvo if it helps snapcraft runs adt on every PR; but mvo just recall that is what you sort of moved away from (I think) [12:54] jdstrand, hello! [12:54] the canonistack/prodstack side of it [12:57] sergiusens: yeah, the canonistack was the part we had trouble with hence spread. but I hope I can cross the worlds again [12:57] sergiusens: how do i unstuck this? [12:57] sergiusens: https://github.com/snapcore/snapcraft/pull/748#issuecomment-241420986 [12:57] PR snapcraft#748: kernel plugin: vmlinuz -> kernel.img hard link [12:58] PR snapd#1806 opened: overlord/devicestate: set device registration URLs [13:00] ppisati can you address the comment in here https://github.com/snapcore/snapcraft/pull/748/files ? [13:00] PR snapcraft#748: kernel plugin: vmlinuz -> kernel.img hard link [13:00] ppisati in some sense I am asking to just remove that os.link call and the comment above if they aren't needed anymore [13:02] sergiusens: oh ok [13:06] ppisati if we sort that out today I will wait for it for the 2.16 release being tagged today [13:06] sergiusens: would a symlink be good for you? [13:06] ppisati os.link is fine, I am just wondering if we need the vmlinuz one [13:06] sergiusens: the bootloader should only look for kernel.img [13:06] sergiusens: re 'grade'> no [13:06] so we can remopve that vmlinuz completely [13:06] pstolowski: hi [13:06] k [13:07] ppisati great, so yeah, `dd` (in vi) on the line `os.link(src, os.path.join(self.installdir, 'vmlinuz'))` and the one above is my specific quetion :-) [13:07] jdstrand I've affected the project on the bug. [13:07] jdstrand, hi! i've hit https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1618737 today, and took the liberty of assigning it to you [13:07] Bug #1618737: firewall-control doesn't grant all the required permissions for ufw to work [13:09] sergiusens: you forgot the unit tests :) [13:10] pstolowski: that is bug #1583514 [13:10] Bug #1583514: firewall-control and ip[6]table_filter module loading [13:10] jdstrand, ah! ok, thanks! [13:10] pstolowski: what is needed is a kernel module backend. that is also needed by docker, ppp and other interfaces [13:12] jamiebennett, lool: can someone get bug #1583514 assigned? ^ [13:12] Bug #1583514: firewall-control and ip[6]table_filter module loading [13:14] PR snapd#1807 opened: interfaces/builtin/bluetooth_control.go: Add access to /dev/vhci [13:22] pstolowski is doing some bug triage atm [13:22] pstolowski: can you take a look to see what is required? [13:25] jamiebennett, sure, will do [13:25] pstolowski: fyi, comment #1 in the bug lays out the high-level idea which was approved by niemeyer and zyga. I can point you at other converstaions for lower level details. give me a minute [13:31] PR snapd#1736 closed: tests: port integration tests to spread [13:31] cyphermox, hmm, i seeded console-conf again and upgraded ubuntu-core ... i end up with no console-conf UI but also with no serial console now [13:31] hit enter [13:32] nothing [13:32] oh, now i get some messed up stuff at the top [13:33] * ogra_ seed eth0 unconfigured ... sit0 too and wlan0 with an IP ... [13:33] * ogra_ hits "done" [13:33] hey, this gfot me further than last time [13:34] whee ! [13:34] ppisati can you also click `Update branch`/merge/rebase the branch? [13:34] ppisati indeed I forgot the units :-) [13:35] cyphermox, apart from the visual glitches uit technically seems to work ... i guess just adding a "clear" at the top of your code would greatly improve the UI [13:36] no chance you took a screenshot of what you saw garbled? [13:36] it looks fine to me, and clears as much as one would expect on serial [13:36] cyphermox, it someply has all the boot output ... and then starts the U(I in the top left (i dont have the terminal at 80x24 here) [13:37] PR snapd#1808 opened: many: add snap set and snap get commands [13:37] just clearing the terminal should be enough [13:37] not for that, but that sounds like what I'm seeing here [13:38] i guess if my terminal hade been at 80x24 i wouldnt have noticed [13:38] *had [13:38] well, mine isn't either [13:38] I have no idea why it picks that, could be some weirdness in urwid [13:39] pstolowski: for docker: https://github.com/snapcore/snapd/pull/1619/#issuecomment-239678941 (not much detail) and https://github.com/snapcore/snapd/pull/1226#discussion_r64953106 for ppp ((3rd bullet). I can't seem to find where the clear explanation is, so I'll give it to you [13:39] PR snapd#1619: interfaces/builtin: add initial docker interface [13:39] PR snapd#1226: Interface for modem manager [13:39] cyphermox, http://people.canonical.com/~ogra/serial-shot.png [13:40] this is what i see now [13:40] yep, looks good [13:40] heh [13:40] well, as good as it can when limited to 80x24 ;) [13:40] pstolowski: snapd grows a new backend, eg, KernelModule. interfaces add what modules to explicitly load via this backend. Eg, firewall-control would tell KernelModule to load iptable_filter and ip6table_filter [13:41] i'm sure there is a way to clear the tty before you fire up your UI [13:41] the problem is not the clearing though [13:41] it's the size [13:41] and size can't exactly be guessed from serial [13:41] pstolowski: then this backend creates file(s?) in /etc/modules-load.d to simply list the modules [13:41] also there was no note at all that i need to press enter [13:42] it just sat there at the end of the boot messages [13:42] ogra_: ok, I'll look into that [13:42] * ogra_ tries the dragonboard [13:42] I think we can keep this in the image now though? [13:43] pstolowski: so, firewall-control lists those two modules, on interface connect of firewall-control, snapd splats out /etc/modules-load.d/snap.modules.conf with each of those, one per line [13:43] PR snapd#1807 closed: interfaces/builtin: allow /dev/vhci on bluetooth-control [13:43] cyphermox, thats my current screen on the dragonboard before hitting enter http://paste.ubuntu.com/23116099/ [13:44] ta [13:44] yep, looks like agetty is still not complying [13:44] pstolowski: there is some question as to whether there should be one big file that is managed or one per interface. that is an implementation detail. I believe zyga said he understood how to do all this, but not sure if there is any code or anything. this functionality is not difficult [13:47]