=== LiX is now known as Guest33445 [05:09] jdstrand, mhall119: about KDE dbus usage... org.kde.$name-$pid is used when the application can have multiple instances running at the same time. they all claim their own address on the bus due to their pid, but you can still find them all due to the basename. applications where multiple instances make no sense do simply not use the pid extension. that being said we do generally know which of the two forms an application will use and we do generally [05:09] know the basename [07:47] hey hey [07:58] PR snapd#2366 closed: interfaces: apparmor support for classic confinement [08:00] Bug #1645605 opened: No alsa module on ubuntu core image [08:03] PR snapd#2361 closed: snap: fix try command when daemon linie is added [08:09] renato__: hey! Did you open a bug for snap connect not working after the first run of a snap using the content interface? If not, do you mind opening one? [08:09] Bug #1645606 opened: Default ubuntu core Pi2 configuration doesn't allow to use fullscreen browser === chihchun_afk is now known as chihchun [08:30] ogra_: hey, I was thinking about simplifying the various repos on https://code.launchpad.net/snappy-hub [08:30] ogra_: specifically I'd like to move the gadget snaps for reference platforms over to github.com/snapcore/ [08:31] and to give them their proper projects on launchpad so that they can have bugs associated with them === JanC is now known as Guest13710 === JanC_ is now known as JanC [09:08] zyga, well, i'd like to start auto-builds for the gadgets before end of year ... i dont think we have that for github projects yet (ICBW though) [09:09] i'd prefer to wait with the move til github is fully supported [09:12] ogra_: my idea is to mirror them to launchpad [09:12] ogra_: but use git in both places [09:12] ogra_: and to really make the reference code discoverable [09:13] ogra_: can you show me which of the 50 branches on snappy-hub contains the published pi2 and pi3 gadgets? I'd like to start with those [09:13] dunno, do we have auto-buiollds for that in place (i.e. you can bump the version and out comes a snap ) [09:13] huh ? 50 branches ? [09:13] ogra_: github -> (git mirror) -> launchpad project -> (snapcraft.yaml auto build to edge) -> store [09:13] https://code.launchpad.net/snappy-hub [09:14] doesnt open here [09:15] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files [09:15] odd, this works here: https://code.launchpad.net/snappy-hub [09:15] thats the master branch we always used [09:15] ok [09:15] thanks, I'll use that [09:15] i didnt even know that there was anything else under snappy-hub :P [09:15] how does it auto build [09:16] but i had plabnned to re-work it comp,ltely to use archive packages for the bootloader binaries etc [09:16] and for auto builds [09:16] (we dont have that yet ... this move kind of trashes my plans then) [09:16] ogra_: hmm, why? [09:16] why what ? [09:16] ogra_: (it's not a plan, I want to make the sources for gadgets discoverable) [09:16] why does it trash that plan? [09:17] I want people to be able to find them, report bugs against them and fork them for local tinkering [09:17] well, it adds complexity, it doesnt "trash"them ... sorry :) [09:17] ah [09:17] I hope you just use git [09:17] and that's it [09:17] the rest should be automatic [09:17] ogra_: later on we should be able to build them with snapcraft as well [09:17] ogra_: right now I'll just add a readme file and we can work from there [09:18] ogra_: does that sound good to you? anything I'm missing" [09:18] well, i'd like to sdo the snapcraft (and first of all the deb part) first [09:18] we dont have sources for some of the uboot builds etc [09:18] and foundations insists these should all be deb based in the archive [09:19] i think it would make sense to have a meeting before we change the world [09:19] hmm [09:20] i.e. we need all the binaries in these trees packaged and reviewed (which is partially their responsibiliry) [09:20] the archive part is interesting, I suspect we're going to use archives but everyone building their own won't care about that [09:20] exactly [09:20] right now it's pretty hard to find our gadgets and even harder to make sense of this all and how to tweak e.g. the pi2 one [09:20] apart from BBB these are all official bits that need a classic image equivalent [09:20] I think the git move is separate and should not wait on this [09:20] which means they need to have debs for the bootloader [09:21] so to not do the work twice we should start with the debs [09:21] I think I'm still missing something [09:21] If all I do is move the current branch to git and publish it on snapcore/* [09:21] turning on auto-builds and have snapcraft builds is indeed a side job but moving away from LP adds a lot of complexity [09:21] then everyone working on this can continue to do what they do there [09:21] and it's easier to find [09:22] no [09:22] i'd prefer to have everything ready and done and*then*Ü do the move) [09:22] remember: lp can mirror git! [09:22] we can do the move in 3 hours and then all git commits on github show up in launchpad (as git) and can be acted upon [09:22] without any intervention now ? [09:22] yes, I think so [09:22] last i chercked you needed to manually do that first every time [09:23] manually do the git mirrors? [09:23] I can check, give me a sec [09:23] yes [09:23] ogra_: btw, I also feel this should be a repo-per-gadget [09:24] we should have a reference repo for porters ... but i like to have all bits in one place for the official images [09:24] though if you insist ... [09:24] ogra_: this means no snapcraft builds [09:24] ogra_: one repo per snapcraft.yaml I think [09:24] (makes everything harder imho) [09:24] ogra_: and also, bbb is not officially supported so it'd have to be somewhere else [09:25] ogra_: I understand the transition is difficult but current situation is very bad for everyone trying to figure out how this works and fork something to expeirment [09:25] well, irt is the only one that can use unpartitioned bootloader paertitions ... which makes it a good example [09:26] but well, go ahead and rip it apart ... it will take me a lot longer to sort everything then though [09:26] ogra_: that's all fair, we need to just find a spot for all the (large) number of non-officially supported devices [09:26] ogra_: don't get me wrong, I don't want to make your life harder [09:26] ogra_: I hope we can all benefit from this [09:26] ogra_: please help me help everyone [09:26] (kind of trashes my planning ... but it wasnt high on my TODO (i.e. notz before EOY) anyway) [09:27] mvo, hi, I re-pushed https://github.com/snapcore/snapd/pull/2252 to re-run the tests, most of them worked this time. The few that did not seem to be due to infrastructure: "cannot connect to linode:..." etc [09:27] PR snapd#2252: interfaces: add unconfined access to modem-manager [09:27] ogra_: can you still execute your plan the way you want when this is on git on github in snapcrore? [09:27] sure, i just need more time to adapt to the new stuff first [09:28] ogra_: to git vs bzr or is there something else? [09:28] to a completely new setup and all the possible (and unplanned) differences in that [09:29] ogra_: but all I want to do is to move the repository, is that what you mean? [09:29] my plan was simply a different order and not to sit down and find out how/if auto-builds work, to re-arrange the world etc etc as the first step [09:29] i.e. make things work first and *then* do the chasnges [09:30] ogra_: I see, if we waited till next year would that make it eaier for you? [09:30] but as i said, i only have two weeks before EOY ... i wont finish that stuff in that time anyway [09:31] and we need to coordinate with foundations somehow for everything but BBB [09:31] since they will want a central place for the binaries that also the debs can use [09:32] (uboot, blobs etc) [09:32] ogra_: can that be the git repo perhaps? [09:32] no [09:32] zyga: on alsa: if I'm correct, there are multiple sound modules and they have different names depending on the card [09:32] ogra_: why not? [09:32] not if the git repo has not been completely changed from what the LP one contains today [09:33] ogra_: do you know if this is correct? ^ [09:33] didrocks: interesting, how does it work on classic? [09:33] the repo will end up to only have a snapcraft.yaml in the end [09:33] zyga: it's a very good question, I never dive into this part, pulseaudio worked for me :p [09:33] ogra_: interesting, and where will all the source code be? [09:33] zyga, preferably debs in the archive [09:33] so the classic images can use them [09:34] ogra_: hmm, I see [09:34] ogra_: I think this is somewhat difficult for others (poor reference) because they will start with uboot tree [09:34] ogra_: not with any debss [09:34] ogra_: but perhaps we can find a way to accomodate that somehow [09:34] zyga: can you try to lsmod | grep snd on your machine? [09:34] I do have: [09:34] snd 81920 18 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,thinkpad_acpi,snd_seq_device [09:34] (notice the thinkpad_acpi) [09:34] zyga, the only arch that can use a uboot tree only is the BBB [09:35] zyga, all others need additional blobs [09:35] ogra_: that's fine but my point is that the snapcraft.yaml that is deb based is not aligned with people that want to create a gadget for their board that uses some bootloader and they build it from sources [09:35] zyga: ah, the machine-dependant one for me is: cat /proc/asound/modules [09:35] 0 snd_hda_intel [09:35] didrocks, there are /usr/share/alsa/cards and /usr/share/alsa/ucm [09:36] didrocks: I'm on a VM here, on my thinkpad natively I'd probably get the same thing [09:36] they have the default configs for certain cards [09:36] zyga, yes, so using our official gadget trees as reference is perhaops the wrong thing altogether [09:36] zyga: and look at /etc/modprobe.d/alsa-base.conf [09:36] those are the rules [09:36] zyga, like our kernel snaps are not even remotely related to what the kernel snapcraft plugin gives you [09:37] abeato: aha, I have a look, thank you [09:37] great, np [09:37] ogra_: context is bug #1645605 [09:37] Bug #1645605: No alsa module on ubuntu core image === chihchun is now known as chihchun_afk [09:38] zyga, anyway, do what you feel you need to do ... [09:38] didrocks: hey, thanks for the additional info in the download bug \o/ I'm going through it now and try to make sense of it [09:39] didrocks, BSPs usually have their sound bits builtin ... also arm boards usually use UCM [09:39] mvo: thanks! If there is anything else I can do to help debugging, I have my setup started here === chihchun_afk is now known as chihchun [09:46] didrocks, anyway ... your alsa bug is a kernbel bug in the first place [09:47] (if you dont find a soundcard there is either the UCM setup or the module missing in the kernel) [09:47] i thought we had that enabled but /proc/asound/cards is empty on all boards here [09:48] so first of all the kernel needs the bits enabled to turn on UCM ... and it should ship the right UCM config [09:51] re [09:51] ogra_: that's true [09:51] ogra_: I guess we have to decide what to do then [09:51] ogra_: perhaps we need "both" to the point where those are identical (long term plan) [09:51] ogra_: perhaps something else entirely [09:52] well, rolling a gadget isnt "have that ubioot tree and drop a snbapcraft.yaml in" [09:52] it is sadly a lot more complex [09:53] ogra_: indeed [09:53] ogra_: do you think it can be, eventually, a snapcraft.yaml in a tree of sources (and blobs if there's no source for them) that builds all the way? [09:53] anyway, if you feel it is urgent to do that github move and split of trees right now, go ahead [09:53] no [09:54] you need a lot of manual work, tinkering and testing to find the right setup before being able to build your first gadget if it is a completely new arch [09:54] ogra_: oh, sure, I mean our references [09:54] we should have a reference tree for every bigger setup imho [09:54] ogra_: do you think we can eventually build them from source all the way? [09:55] (i.e. we dont have anything for sunxi boards ... proting to that will be a pain for users) [09:55] we can surely build parts opf them from source ... really depends on the board [09:55] ogra_: I see, thanks for the input [09:55] ogra_: I'm not going to do anything right now, I've added a card to track this [09:55] the only arches where booting does nto depend on binary blobs are x86 and BBB thogh [09:56] *not [09:56] ogra_: I'd like to improve the visibility of the gadgets [09:56] ogra_: and perhaps de-mystify them a little [09:56] +1 [09:56] ogra_: but it's a complex topic and I don't want to just break more than I improve [09:57] is there any documentation about the dump plugin? [09:57] well, i think forst of all we should have a meeting or so with foundations [09:57] http://snapcraft.io/docs/reference/plugins/dump is virtually empty [09:57] to clearly line out a plan ... [09:57] ogra_: that's a good idea [09:57] the "examples" also sends you to an empty page [09:57] ogra_: preferably early so that everyone can think about this over xmas [09:57] i had hoped to do that in the hague ... but there was not much foundations there [09:58] (i want steve and adam in that meeting) [10:01] ogra_: so slangasek and ... (slipped my head) [10:01] (and looking at /names doesn't help) [10:01] the infinite one ;) [10:02] infinity in case that wasnt clear :) [10:15] PR snapd#2369 opened: snap: disable support for socket activation [10:29] does adt-buildvm-ubuntu-cloud on xenial not work to build yakkety images? [10:30] Chipaca: you need the version from xenial-backports iirc [10:31] Chipaca: apt install autopkgtest/xenial-backports [10:32] mvo, ah! thanks [10:33] that works, indeed [10:33] PR snapd#2363 closed: snap: support "daemon: notify" in snap.yaml [10:49] ogra_: right, that was clear, thanks :) [10:50] :) [11:05] PR snapd#2370 opened: i18n: use github.com/ojii/gettext.go (pure go) for i18n to avoid cgo === chihchun is now known as chihchun_afk [11:23] snappy-debug suggestion "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" anybody have any idea how to do this? [11:26] Bug #1402536 changed: snappy install should support version/hash to get specific version from the store [11:26] Bug #1413185 changed: Snappy remote install requires password three times [11:35] Bug #1457491 changed: Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode) [11:35] Bug #1459642 changed: If a gadget install fails, udev is not cleaned up [11:50] Bug #1464944 changed: no way to configure keyboard layout [11:50] Bug #1466682 changed: Docker unix socket permission issue on ubuntu-core update [11:50] ogra_: invinte sent, let me know if that's that's too late for you [11:53] Bug #1468958 changed: selftests print "no such file or directory" on error [11:53] didrocks, hey, I saw someone complaining about that on the ml, I think there is a bug already. Let me find it [11:54] zyga, hmm, its ok ... are you sure that short of a notice works for the others though ? [11:56] Bug #1472721 changed: snappy update shows no message when there are no updates [11:57] PR snapd#2371 opened: daemon, store: let snap info find things in any channel [11:59] Bug #1472802 changed: ubuntu-core timezone config has no effect [12:01] ogra_: if not we can move [12:02] Bug #1474125 changed: Image got in a broken state after update -> rollback -> update (wrong kernel) [12:03] didrocks, ohh, just saw that you replied the e-mail asking to open the bug, but did not get reply. Let me open it [12:08] Bug #1479027 changed: package.yaml docs missing releases OR frameworks fields [12:08] Bug #1481086 changed: Need API/cli method to know if "is_snappy" [12:11] Bug #1484982 changed: service description whitelist unnecessarily strict === hikiko is now known as hikiko|ln [12:14] Bug #1495059 changed: cannot add new sudo users [12:17] Bug #1495452 changed: auto upgrade unintentionally updates /etc/udev/rules.d/70-persistent-net.rules [12:17] Bug #1495662 changed: Services and binaries allow _ # [12:20] hi I have this suggestion by snappy-debug: "* adjust program to not require 'CAP_DAC_OVERRIDE' (see 'man 7 capabilities')" anybody have experience of this? [12:20] Bug #1496319 changed: Could not create symlink to hw device with udev rules [12:20] Bug #1499109 changed: hw-assign and oem assign are inconsistent [12:23] Bug #1499478 changed: snappy install failure if service doesn't start does not cleanup [12:23] Bug #1499662 changed: boot partition size should be configurable [12:26] Bug #1499993 changed: U-d-f uses hardcoded names for kernel and initrd instead of the ones defined in hardware.yaml [12:26] Bug #1500020 changed: /var/lib/opencryptoki needs to be in /etc/system-image/writable-paths

[12:29] bonjello [12:29] Bug #1502810 changed: Implement "snappy try" [12:44] zyga: i tried snap-confine from the use-aa-support branch but it segfaults : http://paste.ubuntu.com/23553160/ - do you have any suggestion? [12:47] longsleep: looking [12:48] longsleep: any chance to get a backtrace? [12:48] zyga: yeah let me install gdb [12:54] Bug #1504649 changed: dns-nameserver, dns-nameservers and dns-search not documented for snappy config for static ip addresses [12:55] PR snapd#2372 opened: interfaces/seccomp: add support for classic confinement [12:55] zyga: here you go: http://paste.ubuntu.com/23553195/ [12:55] longsleep: checking [12:55] not much in there :/ [12:55] longsleep: oh, nice [12:56] longsleep: up [12:56] longsleep: (one sec, switching branches) [12:56] longsleep: print label [12:57] Bug #1504938 changed: invalid character '<' looking for beginning of value [12:57] Bug #1505696 changed: SquashfsTestSuite.TestRunCommandUgly fails if you have a non-english locale [12:57] Bug #1505717 changed: prefer vmlinuz-*.efi.signed over vmlinuz in device tarball [12:57] longsleep: print mode [12:57] longsleep: perhaps something I dind't account for, I can fix that quickly [12:58] zyga: http://paste.ubuntu.com/23553198/ [12:58] longsleep: let me cook a patch === hikiko|ln is now known as hikiko [12:58] longsleep: nice, thanks [12:58] zyga: let me see if i can resolve the not found [12:58] longsleep: nah, that's all good [12:58] longsleep: I know what the bug is already [12:58] longsleep: thank you!!! :) [12:58] zyga: awesome :) [13:00] Bug #1507607 changed: move boot-ok to before sessions [13:01] zyga: fixed the not-found - see here http://paste.ubuntu.com/23553206/ [13:02] longsleep: I just pushed a fix [13:02] zyga: rebuilding [13:02] longsleep: feel free to comment on the pull request as well once you get this working [13:03] Bug #1511435 changed: ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap [13:04] zyga: looks better now [13:04] /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env [13:04] SNAP_NAME is not set [13:04] zyga: so do you have a suggestion how i could fully test this now? [13:05] zyga: still does not seem to work though [13:05] SNAP_NAME=hello-world /root/xenial/root/snap-confine/src/snap-confine snap.hello-world.env /snap/hello-world/27/bin/env [13:05] cannot change apparmor hat. errmsg: Operation not permitted [13:05] support process for mount namespace capture exited abnormally [13:05] [157896.731125] type=1400 audit(1480424709.523:33): apparmor="DENIED" operation="change_hat" info="unconfined" error=-1 profile="unconfined" pid=17652 comm="snap-confine" [13:09] longsleep: (just in a call now, I'll be with you in 15 minutes0 [13:09] zyga: all right thanks - take your time and just ping me when you are available [13:09] PR snapcraft#918 closed: create the deltas package/class with xdetal generation implementation [13:16] longsleep: nice [13:16] longsleep: you now need snapd and snap-run to get this to work [13:16] longsleep: oh, that's super odd, let me check why this happens (the hat thing which is what this was supposed to fix) [13:18] zyga: is there a way i can make snapd/snap-run use my custom snap-confine? [13:18] longsleep: fixed again [13:18] zyga: you are awesome, rebuilding [13:19] longsleep: yes, do a bind mount so it shows up in /usr/lib/snapd [13:19] longsleep: sudo mount --bind some/custom/snap-confine /usr/lib/snapd/snap-confine [13:19] longsleep: and make sure it's stuid root [13:19] setuid* [13:19] longsleep: (no wonder this doens't work, there's no spread test for it yet) [13:19] longsleep: thank you for trying this [13:20] zyga: seems to work now [13:21] longsleep: great! [13:21] zyga: http://paste.ubuntu.com/23553265/ so what does that tell us now? [13:21] longsleep: thank you! [13:21] Bug #1511447 changed: snapcraft stage does not work with Go and Launchpad [13:21] zyga: that branch will get merged into release eventually and it wont matter that my kernel does what it does? [13:21] longsleep: that it should be good [13:21] longsleep: you can set SNAP_CONFINE_DEBUG=yes [13:21] longsleep: to see what's going on [13:21] longsleep: yes [13:22] longsleep: I plan to merge it as soon as I get a review from security [13:22] longsleep: well.. [13:22] longsleep: if your snap-confine is unconfined it won't try to switch hat [13:22] longsleep: there are other places that care about apparmor [13:22] longsleep: (in snapd) [13:22] longsleep: but some of the work I'm doing will make that more flexible [13:22] longsleep: I want to know one more thing [13:22] longsleep: can you run [13:23]