| jdstrand | sergiusens: yikes | 00:00 |
|---|---|---|
| jdstrand | $ scmp_sys_resolver 317 | 00:00 |
| jdstrand | seccomp | 00:00 |
| jdstrand | yeah, mmm, for now the best thing to do would be to disable the seccomp sandbox in firefox | 00:01 |
| jdstrand | that is going to require some investigating to do safely (if at all). it might require seccomp arg filtering to land too | 00:02 |
| * jdstrand adds a card | 00:02 | |
| sergiusens | jdstrand that can get complicated | 00:08 |
| sergiusens | jdstrand as in, do you mean I have to install with --devmode? | 00:09 |
| sergiusens | ubottu hey | 00:09 |
| MoPac | just started trying to use the snap / snapd support in ubuntu 16.04, and I'm confused about (among other things) removing snap packages. I installed mir-server, but can't remove it. | 00:14 |
| sergiusens | MoPac as in `snap remove mir-server` did not work? | 00:15 |
| MoPac | I.e.: "sudo snap install mir-server .... error: can't install "mir-server": snap "mir-server" already installed " | 00:15 |
| MoPac | But then... | 00:15 |
| MoPac | sudo snap remove mir-server error: can't remove "mir-server": cannot find mounted snap "mir-server" at revision 4 | 00:15 |
| sergiusens | MoPac did you have an old install of snappy or experimenting with it? | 00:15 |
| MoPac | sergiusens: Not that I know of | 00:16 |
| sergiusens | MoPac I logged a bug for something similar to that I think | 00:16 |
| sergiusens | MoPac just log a new one and also add the output of `snap changes` | 00:16 |
| sergiusens | MoPac I'll forward it to the developers | 00:16 |
| MoPac | when I do locate mir-server, I do find a folder in /var/li/snapd and files in /etc/systemd/ (snapd.mir-server... and multi-user.target.wants/snap.mir-server...) | 00:18 |
| MoPac | Is it possible those are part of some other installation? | 00:18 |
| MoPac | There's also /var/snap/mir-server | 00:18 |
| MoPac | But just this week when I installed it, it did a full download and everything through the snap command line command, so I just assumed all that other stuff was how this one system works | 00:19 |
| sergiusens | MoPac those files look fine | 00:22 |
| MoPac | Alas, and I'd hoped that snap packages would help tame the problem of an installed package's stuff being fragmented all over the filesystem.. | 00:23 |
| qengho | Man, either something is broken or I don't understand these new changes. | 00:25 |
| qengho | On my classic machine, I had snappy and a few packages installed. Now, 1) "snap list" lists nothing. 2) I don't understand how to configure things. | 00:26 |
| sergiusens | qengho the new changes landed were incompatible with what once was | 00:28 |
| sergiusens | qengho I had to wipe and start from scratch | 00:29 |
| sergiusens | they introduced a state machine | 00:29 |
| qengho | Huh. I do like me some state machines. | 00:29 |
| sergiusens | MoPac it does; those files are controlled by snappy itself; snaps cannot generate those | 00:29 |
| qengho | Okay, so I'll remove debs with snap in the name, then look for filesystem artifacts, then install and start anew. | 00:30 |
| sergiusens | qengho afaik you need to stop snapd, umount everything in /snap and wipe /var/snap | 00:30 |
| sergiusens | check everything before wiping just in case :-) | 00:31 |
| sergiusens | qengho do you have any gtk xp btw? | 00:31 |
| qengho | sergiusens: some. Enough to hate ListStores | 00:32 |
| MichaelTunnell | anyone know if will Snappy work with GNOME Software in 16.04? | 00:32 |
| qengho | MichaelTunnell: 16.04 will ship with almost everything in the traditional deb format, including up-to-date Gnome. It also ships with the ability to package new stuff in the new snap format. | 00:34 |
| sergiusens | qengho well this is more of a plumbing question :-) I saw there's an envvar that tells this /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache to go somewhere else ($SNAP_USER_DATA/ is my target of choice) but what about the contents of loaders.cache; is there a way to make that installtion path independent or in defect, to make gdk-pixbuf-query-loaders to look for them somewhere else? | 00:34 |
| qengho | sergiusens: Ah, I don't know that detail. | 00:36 |
| MichaelTunnell | qengho: I meant the integration with GNOME Software will snaps be installable with GNOME Software or only in terminal? | 00:49 |
| qengho | MichaelTunnell: I'm sure snaps will be in the "store" program. That's almost like 1/4th the reason for inventing them. | 00:54 |
| qengho | sergiusens: also, plenty in /var/lib/ :\ | 00:54 |
| qengho | Bed time. Back in 14 hours. | 00:54 |
| qengho | Oh man. only 12. :( | 00:55 |
| === devil is now known as Guest29558 | ||
| Alfredo | someone could help me I want to mount a disk when system boot but fstab file overwrite on reboot | 02:28 |
| Alfredo | in ubuntu snappy | 02:29 |
| jdstrand | sergiusens: in devmode initially or compile without the seccomp sandbox. ChrisCoulson may be able to advise you on that | 02:30 |
| jdstrand | sergiusens: you could try to add 'seccomp' to /var/lib/snapd/seccomp/profiles while testing to see if you need more or less, but I don't know if that is safe yet for the general case | 02:31 |
| jdstrand | sergiusens: (consider the fact that if you can alter the seccomp sandbox, then, well, you can alter your sandbox) | 02:32 |
| jdstrand | sergiusens: in theory, it should be ok, but it will take time to verify | 02:32 |
| sergiusens | jdstrand now I follow! Thanks. I also have a bunch of gtk things to solve as well; so it is not my only blocker | 02:35 |
| sergiusens | I wasn't aware gtk turned into this huge beast | 02:35 |
| jdstrand | I can imagine | 02:35 |
| jdstrand | yeah-- I tried with gcalculator | 02:35 |
| jdstrand | it was pretty hideous | 02:35 |
| jdstrand | I set like a thousand variables | 02:35 |
| jdstrand | and then it still didn't work :\ | 02:36 |
| jdstrand | I talked to desrt about it and had more to try but had to focus on other snappy things and hadn't gotten back to it yet | 02:37 |
| sergiusens | I might pick on didier's brain tomorrow or maybe seb's | 02:37 |
| jdstrand | sergiusens: I don't know if this will help or not with firefox cause we were talking about gnome apps, but most of this is gtk stuff: http://paste.ubuntu.com/15923754/ | 02:42 |
| jdstrand | hopefully it isn't too hard to follow... | 02:43 |
| jdstrand | I haven't worked through it so best to ask a desktop guy if you have questions | 02:43 |
| jdstrand | fyi, my online-ness is going to potentially be a little odd the next couple of days, but I read backscroll | 02:45 |
| jdstrand | I'm technically off tomorrow, but I may need to swap some things around | 02:45 |
| sergiusens | jdstrand thanks | 03:33 |
| === chihchun_afk is now known as chihchun | ||
| netpheak | morning, guys! | 04:48 |
| === Guest29558 is now known as devil_ | ||
| mvo | ogra_: fyi, I uploaded a new ubuntu-device-flash with less debug output and a new alpha image for amd64 with snap 2.0 | 07:02 |
| Gunther_ | hi! Is it still mandatory to do snapcraft login for kernel builds (os.snap)? This can be a problem in our jenkins build environment ... | 08:11 |
| zyga | good morning | 08:30 |
| Gunther_ | good morning | 08:33 |
| === JamesTait is now known as Guest1123 | ||
| === Guest1123 is now known as JamesTait | ||
| _morphis | zyga: https://github.com/zyga/devtools/pull/5 | 09:07 |
| === pmp is now known as Guest10951 | ||
| davmor2 | ogra_: davmor2@davmor2-XPS-13-9343:~⟫ ubuntu-clock-app.clock /n can not find a snappy os I guess that is a bad thing right :) | 09:27 |
| Gunther_ | mvo: the new amd64-all-snap.img does not boot :(. I tested it using VirtualBox: unable to resolve 'LABEL=writeable' | 09:28 |
| mvo | Gunther_: thanks, I will take it down again, its very confusing, it boots fine in qemu/kvm :/ | 09:29 |
| mvo | Gunther_: I assume you also converted it first? what commands did you run, just trying to reproduce this now | 09:29 |
| Gunther_ | VBoxManage convertfromraw amd64-all-snap.img all_snap.vdi --format VDI --variant Fixed | 09:30 |
| mvo | ta | 09:31 |
| Gunther_ | ok it works if the vdi is attached to IDE but fails if the image is attached to SATA | 09:32 |
| mvo | Gunther_: wuut? thats strange | 09:32 |
| mvo | Gunther_: I suspect a kernel issue, let me try to reproduce and then play around with the kernel. thanks a bunch for this hint | 09:33 |
| Gunther_ | No SATA support in the kernel? | 09:33 |
| mvo | Gunther_: could be, or missing chipset or buggy or soemthing | 09:34 |
| Gunther_ | Just reproduced this on real hw: If the SATA port is set to legacy IDE in BIOS, it boots. But not if it is set to SATA. This is not only a VirtualBox issue | 09:36 |
| dholbach | bzoltan_, what kind of ldd does the copy plugin do? | 09:36 |
| bzoltan_ | dholbach: it ldd's the content of my directory and fails on many of the | 09:37 |
| stevebiscuit | Gunther_: I've had the same problem running under VirtualBox, attaching the image to the IDE controller seems to resolve it | 09:38 |
| dholbach | sergiusens, kyrofa: ^ do you know which problem bzoltan_ might be having? | 09:38 |
| dholbach | bzoltan_, you got cut off | 09:38 |
| mvo | Gunther_: thanks a bunch | 09:38 |
| bzoltan_ | dholbach: thanks | 09:38 |
| mvo | Gunther_: I can reproduce it , digging into it now | 09:41 |
| Gunther_ | mvo: the naming of the net interfaces is also back to the classic "eth0" ... | 09:46 |
| Gunther_ | is that intenionally | 09:46 |
| mvo | Gunther_: a good question, I need to investigate this too | 09:57 |
| Gunther_ | mvo: ok :) | 09:58 |
| dpm | hi all. I'm trying to clean up a desktop system after the move from /snaps to /snap. It looks like /var/lib/snappy/snaps contains a bunch of apps I installed a while ago. Is it safe to just 'rm -rf /var/lib/snappy/snaps'? | 10:01 |
| Gunther_ | mvo: we seem to got a kernel upgrade after the first boot. The net interface names are enp0sX again, | 10:05 |
| popey | dpm: that's what I did, nuke the directory after stopping snapd | 10:11 |
| dpm | thanks popey. Done that and reinstalling everything now | 10:15 |
| dpm | popey, dholbach, does the calculator app work for you? http://pastebin.ubuntu.com/15927521 | 10:17 |
| dpm | trying clock now | 10:17 |
| zyga | _morphis: thank you, merged! | 10:17 |
| popey | dpm: i get same | 10:20 |
| popey | dpm: clock fails in the same way | 10:22 |
| zyga | popey, dpm: are those snaps using unity7 plug? | 10:23 |
| dpm | popey, zyga, actually, they're still unconfined in the store. Let me see if I can update their yaml files and re-upload | 10:24 |
| dpm | zyga, mvo, do you happen to know in which folder the .desktop file and icon should be dropped in for snapcraft? | 10:27 |
| dpm | last time I talked to sergiusens it was: setup/gui/DESKTOP_FILE | 10:28 |
| dpm | setup/gui/icon.png | 10:28 |
| dpm | but I don't know if that's changed since | 10:28 |
| Gunther_ | I seem to be unable to remove a sideloaded kernel.snap. Also to try to reinstall it fails: error: cannot perform the following tasks: - Mount snap "trionet-kernel" (cannot find mounted snap "trionet-kernel" at revision 100001) | 10:29 |
| Gunther_ | sudo snap remove trionet-kernel_4.4.0_amd64.snap error: can't remove "trionet-kernel_4.4.0_amd64.snap": cannot find snap "trionet-kernel_4.4.0_amd64.snap" | 10:30 |
| Gunther_ | I am missing snappy ... | 10:30 |
| mvo | dpm: meta/gui is the folder | 10:32 |
| mvo | Gunther_: uh, oh :/ I assume all of this worked before? that are regressions that we need to tackle | 10:32 |
| === victorp_ is now known as victorp | ||
| dpm | mvo, thanks. And then do I need to remove the 'icon' field or do anything different with the in snapcraft.yaml? | 10:33 |
| mvo | I'm curious if a 4.4.0-18-generic kernel boos in virtualbox on sata | 10:33 |
| mvo | dpm: I think you can just remove it, if that does not work I will dg into the code | 10:33 |
| popey | ogra_: i see a canonical-pi3 in the store, does that mean we have a pi3 image somewhere? | 10:34 |
| dpm | thanks mvo! | 10:34 |
| Gunther_ | mvo: I had issues before, I could remove a kernel.snap, but grub failed on reboot. See my posting on the mailing list. | 10:34 |
| ogra_ | popey, you can just build one :) | 10:34 |
| popey | ogra_: but I will end up with sideloaded things I can't update? | 10:34 |
| ogra_ | popey, sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi3 -o test.img | 10:34 |
| popey | e.g. my current image has a sideloaded canonical-pi3, which refuses to be replaced | 10:34 |
| ogra_ | get the latest udf from mvo though | 10:34 |
| dpm | mvo, last question: https://github.com/ubuntu-core/snapcraft/blob/master/docs/metadata.md#snap-icon seems to indicate there should be a setup/gui directory - is that different from the meta/gui one or are the docs simply not up-to-date? | 10:35 |
| ogra_ | popey, right, because i built it from local files back then | 10:35 |
| popey | ogra_: will building it as above make it so i can store update the snaps? | 10:35 |
| ogra_ | yes | 10:35 |
| popey | sweet | 10:35 |
| popey | where's this funky udf? | 10:35 |
| ogra_ | http://people.canonical.com/~mvo/all-snaps/ | 10:35 |
| popey | tata | 10:37 |
| dpm | dholbach, popey, ok, I got a local build of clock working. I just need to figure out this stuff with the desktop file, see if I can get the x86 build as well, and then I'll upload to the store | 10:37 |
| Gunther_ | mvo: regarding you question about4.4.0-18-generic: I am running a standard Ubuntu xenial on VirtualBox + SATA | 10:38 |
| Gunther_ | mvo: uname -a Linux glaure-1604 4.4.0-18-generic #34-Ubuntu SMP Wed Apr 6 14:01:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | 10:38 |
| mvo | Gunther_: thanks! what is your lsmod output on this system? | 10:38 |
| mvo | ogra_: I think we can push updated images today (yay), however still investigating a virtualbox issue that looks like kernel or kernel modules issue | 10:39 |
| ogra_ | k | 10:39 |
| Gunther_ | mvo: http://paste.ubuntu.com/15927730/ | 10:39 |
| mvo | ogra_: its very strange, it fails to boot in virtualbox on sata, its fine on ata | 10:40 |
| mvo | thanks Gunther_ | 10:40 |
| ogra_ | uuh | 10:40 |
| mvo | ogra_: I wonder if modules are missing from the kernel | 10:40 |
| ogra_ | with our kernel ? | 10:40 |
| Gunther_ | mvo: not limited to virtualbox - it does not boot on SATA | 10:40 |
| ogra_ | Gunther_, did you try the default kernel snap too ? | 10:41 |
| Gunther_ | ogra_: no but it is easy to test for me. Which one should I use? | 10:41 |
| mvo | ogra_: its our kernel, I can reproduce it here too | 10:41 |
| ogra_ | ah | 10:42 |
| mvo | ogra_: I'm poking around in my busybox shell and it looks its very few .ko files only | 10:43 |
| ogra_ | mvo, yeah, i switched to MODULES=list ... | 10:44 |
| ogra_ | (saves up to 20MB (compressed !)) | 10:45 |
| ogra_ | i guess we'll need to add sata to the list then | 10:45 |
| mvo | ogra_: something funny going on, the unpacked kernel snap has a lot more than what I see in my initramfs shell. do we do double initramfs loading or anything fancy | 10:45 |
| Gunther_ | another issue is the naming of the network interfaces. At the first boot they are "ethX" on all following they are "enp0sX". This generates wrong entries at /etc/network/interfaces.d resulting in no valid net configuration after the first boot | 10:46 |
| ogra_ | mvo, huh ? you mean the initrd in the kernel snap ? | 10:46 |
| mvo | ogra_: oh, sorry, no, my mistake | 10:47 |
| mvo | ogra_: the initird I need to poke at next, phonecall rightnow | 10:47 |
| ogra_ | mvo, all initrds should only have squashfs nowadays | 10:47 |
| ogra_ | mvo, we either list all controller modules or i switch back to MODULES=most | 10:49 |
| mvo | ogra_: I think we miss controller modules, it seems they are =m | 10:51 |
| ogra_ | mvo, yes | 10:51 |
| ogra_ | i can add them all | 10:51 |
| daker | kyrofa: what's the equilvant to "environment" in snapcraft 2.x ? | 10:52 |
| sergiusens | bzoltan dholbach log a bug please or give a pastebin at least. In the end we ldd and copy everything not in Ubuntu core and if it fails due to missing libs it will probably fail on install as well | 10:52 |
| ogra_ | mvo, seems it is just "ahci.ko", i'll add that to the list ... if thats not enough we can switch back to MODULES=most | 10:53 |
| mvo | ogra_: thanks | 10:54 |
| ogra_ | Gunther_, wiould you mind trying that ? (adding ahci to your initrd modules in the kernel snapcraft.yaml so you end up with it installed ) | 10:54 |
| sergiusens | dpm those paths are correct | 10:54 |
| mvo | ogra_: will you regenerate the image once you did that? | 10:54 |
| ogra_ | mvo, indeed | 10:54 |
| Gunther_ | ogra_: sure I can try that | 10:55 |
| mvo | ogra_: \o/ | 10:55 |
| dpm | hi sergiusens - which ones are correct? meta/gui? setup/gui? Or both? | 10:55 |
| ogra_ | to sad that the modules code is non arch specific in initramfs-tools ... we'll never need ahci on other arches i guess | 10:55 |
| ogra_ | (arm and friends i mean) | 10:56 |
| dholbach | dpm, excellent | 10:57 |
| sergiusens | setup/gui | 10:58 |
| sergiusens | Unless you are doing raw packaging which you aren't | 10:59 |
| zyga | dpm: try setup/foo.desktop | 11:07 |
| zyga | dpm: the icon should be in the main part of the snap, you can refer to it with $SNAP/some/path/icon.png | 11:08 |
| zyga | dpm: the desktop file is correctly parsed and sanitized, copied to the right spot | 11:08 |
| kalikiana | So... as of today's upgrade on my Xenial, "snappy" is gone, "snap" installs and runs snaps to /snap/ - but the snaps stop working after reboot and disappear from "snap list" - is this the right place to ask how to solve it? | 11:08 |
| zyga | dpm: the icon is not copied there so it has to live with the main body of the snap | 11:09 |
| zyga | kalikiana: yes, | 11:09 |
| zyga | kalikiana: which snaps did you install? | 11:09 |
| kalikiana | zyga: I had hello-world for example. I was able to run the commands from it. Now it's gone and I can't exec it anymore: execv failed: No such file or directory | 11:10 |
| kalikiana | It seems like there are no mounts anymore | 11:10 |
| zyga | kalikiana: do you hvae the snappy PPA or is that all from xenial proper? | 11:10 |
| zyga | kalikiana: oh, interesting | 11:10 |
| kalikiana | zyga: no snappy PPA, just Xenial | 11:10 |
| zyga | mvo: I recall you mentioned this in the telegram channel, is that a bug in xanial that we don't mount snaps on reboot? | 11:10 |
| kalikiana | zyga: I do have two mounts from the previous "snappy" command which is now gone, hello-world and docker | 11:12 |
| kalikiana | Maybe that conflicts somehow? | 11:12 |
| kalikiana | But I have no way of removing those now | 11:12 |
| zyga | kalikiana: I'm not sure but I would recommend a resetting your state, snap remove everything (if you can), remove snapd, remove everything in /var/lib/snapd and in a few other places | 11:12 |
| * zyga should publish that reset-snappy script | 11:12 | |
| zyga | kalikiana: can you wait 20 minutes? I'll do this properly and then help you out | 11:13 |
| kalikiana | remove doesn't work: error: can't remove "hello-world": cannot find mounted snap "hello-world" at revision 23 | 11:13 |
| kalikiana | zyga: Sure, no hurry | 11:13 |
| Gunther_ | ogra_: adding ahci seems to be non trivial for me. Please have a look at http://paste.ubuntu.com/15928133/ | 11:16 |
| bzoltan_ | Would somebody show me the simplest example of the copy plugin use? | 11:16 |
| Gunther_ | ogra_: I am getting the error: modprobe -n --show-depends -d /home/jenkins/Mercurial/SW_APP/snap/driver/trion/parts/kernel/install -S 4.4.5-trion+ squashfs ahci [Errno 2] No such file or directory: 'ahci' -> '/home/jenkins/Mercuria l/SW_APP/snap/driver/trion/parts/kernel/build/initrd- staging/../../../ahci' | 11:16 |
| ogra_ | Gunther_, might be you also need libahci | 11:17 |
| ogra_ | Gunther_, is ahci enabled in your initrd ? | 11:17 |
| ogra_ | err | 11:17 |
| ogra_ | in your kernel config ... sorry | 11:17 |
| ogra_ | oh, i see it | 11:17 |
| * ogra_ wonders if the two optiojns are actually enough | 11:18 | |
| ogra_ | aha, you need CONFIG_ATA too | 11:20 |
| Gunther_ | ok | 11:20 |
| ogra_ | sergiusens, ^^^ how does the kernel plugin check config dependencies in snapcraft ? | 11:20 |
| ogra_ | seems if i enable a high level config the low level deps are not getting enabled is the plugin just mangling .config or does it use some kernel config script ? | 11:21 |
| Gunther_ | afaik the kernel plugins does nothing else than to run make "defconfig" and adding the given configuration from snapcraft.yaml | 11:25 |
| Gunther_ | if no config file is given | 11:26 |
| ogra_ | yeah, that wouldnt select the dependencies | 11:29 |
| dpm | zyga, sorry, I was on the phone, reading the backlog now, thanks | 11:30 |
| sergiusens | ogra_ we don't, you are in charge | 11:31 |
| ogra_ | sergiusens, ouch | 11:32 |
| sergiusens | mvo zyga please don't talk to people about internal layouts | 11:32 |
| zyga | sergiusens: do you mean setup? | 11:32 |
| sergiusens | zyga I mean `meta/gui` | 11:32 |
| zyga | ah, sorry | 11:32 |
| zyga | I will focus on the setup/ side | 11:33 |
| sergiusens | zyga if you do that, then you have to go into details of how the process works and I get questions from dpm of the type "which one is it?" | 11:33 |
| mvo | sergiusens: well, I was asked about it, but yeah, I missed the context, of course dpm should just use the snapcraft primitives for this | 11:33 |
| dpm | sergiusens, zyga I'm totally confused. | 11:34 |
| dpm | could someone just tell me: | 11:34 |
| dpm | - where should the desktop file go? | 11:34 |
| sergiusens | also making him think he has to put something manually in snap/meta | 11:34 |
| dpm | - where should the icon file go? | 11:34 |
| sergiusens | that is impossible and not feasable | 11:34 |
| sergiusens | mvo anyone asking about packaging setup here would ask about it from the snapcraft side here ;-) | 11:34 |
| sergiusens | mvo zyga which is why I wanted you guys to start using it ;-) | 11:35 |
| sergiusens | dpm so TOPDIR/snapcraft.yaml; TOPDIR/setup/gui/icon.png | 11:35 |
| zyga | hmmm | 11:35 |
| dpm | sergiusens, ok, that makes sense, thanks. And which location for the desktop file? | 11:36 |
| sergiusens | the docs were pretty clear in that respect, unless of course someone took you down the rabbit hole of looking in snap/meta ;-) | 11:36 |
| zyga | sergiusens: please also explain how the desktop file should correctly relate to the icon file because that's non-obvious | 11:36 |
| sergiusens | dpm same TOPDIR/setup/gui/<desktop>.desktop | 11:36 |
| dpm | perfect | 11:36 |
| dpm | sergiusens, hm, but are there docs about it already? I couldn't find any mentions to the .desktop file in docs | 11:37 |
| sergiusens | zyga from your point of view; anything that is by convention goes into `setup`; the by convention for desktop files is going to suck a bit, but it is what we ended up with | 11:37 |
| dpm | anyway, that's the answer I was looking for, I'll add that to the clock app, thanks! | 11:37 |
| sergiusens | dpm no, desktop file is probably not mentioned. Let me check | 11:37 |
| dpm | sergiusens, I was looking at https://github.com/ubuntu-core/snapcraft/blob/master/docs/metadata.md#snap-icon | 11:38 |
| zyga | sergiusens: I'm not disputing that, just the Icon=... line is tricky and requires voodoo to decuce by onself; we should just say how it should look like for things to wokr | 11:38 |
| zyga | sergiusens: (AFAIR it should say Icon=$SNAP/meta/gui/icon.png) | 11:38 |
| zyga | sergiusens: i.e. using $SNAP is mandatory for the icon to work in practice | 11:39 |
| sergiusens | zyga I thought you'd fix that on snap install | 11:39 |
| zyga | sergiusens: but I may be wrong, plesae correct me | 11:39 |
| zyga | sergiusens: I don't know :) | 11:39 |
| sergiusens | zyga I have no idea; but if someone who has no idea has to do Icon=$SNAP/meta/gui that is indeed crappy | 11:40 |
| kyrofa | Good morning | 11:40 |
| zyga | sergiusens: later on I'll try and get back to you | 11:40 |
| sergiusens | kyrofa morning | 11:40 |
| kyrofa | Hey sergiusens :) | 11:40 |
| zyga | hey kyrofa | 11:40 |
| * sergiusens is still chatting from his ubuntu phone hooked up to a bt keyboard using shout as a snap on digital ocean | 11:41 | |
| sergiusens | I'm all in | 11:41 |
| dpm | mvo, do you have the sources for cap-test.xbomb somewhere? I'd like to see how Icon= is specified in the .desktop file ^^ | 11:41 |
| kyrofa | sergiusens, nice | 11:41 |
| zyga | dpm: AFAIR just unsquasfs it, there is no source | 11:41 |
| dpm | ok, thanks | 11:42 |
| dpm | zyga, sergiusens, can I use the copy plugin to copy the generated .desktop file and icon to setup/gui to avoid duplicating files in the clock app sources? | 11:42 |
| * zyga doesn't know | 11:43 | |
| dpm | or does the desktop/icon file voodoo happen before the plugin is run? | 11:43 |
| sergiusens | dpm no, and this is the sucky part about files with convention | 11:43 |
| mvo | dpm: no sources unfortunately only the unpacked squashfs, you can look at /snap/cap-test/current/meta/gui/xbomb.desktop to see the "source" of the desktop file | 11:43 |
| dpm | ok, thanks all | 11:44 |
| sergiusens | dpm so, I'll prepare a fix so you can use relative paths from the desktop file to find the icon | 11:44 |
| dpm | ok | 11:45 |
| dpm | so cap-test specifies: | 11:45 |
| dpm | Icon=${SNAP}/xbomb.png | 11:45 |
| dpm | on the .desktop file, so I'll go for that for now | 11:45 |
| sergiusens | dpm I guess the desktop icon can point to anywhere, but the package icon has to be in the location I mentioned | 11:45 |
| sergiusens | if you want a nice icon in the store or whatever UI | 11:46 |
| dpm | sergiusens, ack | 11:48 |
| dpm | mvo, on the cap-test desktop file I also see a "StartupNotify=true" key. Do I need to add that to the clock app's desktop file as well? | 11:48 |
| mvo | dpm: I'm not sure, it won't hurt but if upstream does not have it, you can probably ignore it | 11:49 |
| zyga | dpm: that used to make icons bounce but I don't know if unity even implements that nowadays | 11:52 |
| ogra_ | mvo, bah, on x86 it isnt possible to easily inject your own initrd into an image, right ? | 11:52 |
| Gunther_ | sergiusens, ogra_ : I think I have found a kernel build issue in snapcraft. If a add more modules as kernel-initrd-modules like here: http://paste.ubuntu.com/15928133/ this information is used in the kernel plugin like this: modprobe -n --show-depends -d /home/jenkins/Mercurial/SW_APP/snap/driver/trion/parts/kernel/install -S 4.4.5-trion+ squashfs ahci | 11:52 |
| dpm | ack, thanks zyga | 11:53 |
| Gunther_ | but only squashfs will generate valid output: modprobe -n --show-depends -d /home/jenkins/Mercurial/SW_APP/snap/driver/trion/parts/kernel/install -S 4.4.5-trion+ squashfs ahci | 11:53 |
| dpm | sergiusens, mvo, does this look ok in terms of adding the .desktop file + icon to the clock app? -> http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/revision/468 | 11:53 |
| mvo | dpm: looks good | 11:54 |
| dpm | awesome, thanks! | 11:54 |
| ogra_ | Gunther_, yeah, that bneeds to be a per-module loop | 11:56 |
| ogra_ | modprobe cant take a list in this case | 11:56 |
| Gunther_ | ogra_: I will patch the kernel.py plugin and try that | 11:56 |
| ogra_ | ogra@styx:~/all-snaps/amd64$ modprobe -n --show-depends squashfs ahci | 11:57 |
| ogra_ | insmod /lib/modules/4.4.0-18-generic/kernel/fs/squashfs/squashfs.ko ahci | 11:57 |
| Gunther_ | exactly | 11:57 |
| ogra_ | it thinks the second module name is a parameter | 11:57 |
| Gunther_ | Should I report this as a bug? | 11:59 |
| ogra_ | yes | 11:59 |
| * dpm starts building clock app with desktop file support | 12:18 | |
| dpm | mvo, sergiusens, am I supposed to see the icon in the dash and launcher for sideloaded apps? I built clock adding the desktop and icon files, sideloaded it, and I can only see a blank icon in the dash and launcher | 12:23 |
| zyga | dpm: look at the dekstop file | 12:25 |
| zyga | dpm: and see what it referes to | 12:25 |
| dpm | zyga, http://pastebin.ubuntu.com/15928862/ | 12:26 |
| zyga | dpm: thanks, let me check | 12:27 |
| dpm | zyga, so it seems I still need to manually put the icon file in $TOPDIR in addition to setup/gui? | 12:27 |
| zyga | dpm: wait, I think something is wrong | 12:28 |
| zyga | dpm: ${SNAP} should have been expanded | 12:29 |
| zyga | dpm: looks like a bug somewhere | 12:29 |
| dpm | zyga, weird, for cap-test I can see the icon, though, and the ${SNAP} in the desktop file is not expanded either | 12:31 |
| dpm | zyga, but the difference there is that cap-test does ship an icon in the top directory | 12:31 |
| zyga | ahh | 12:32 |
| zyga | I'm dumb | 12:32 |
| zyga | dpm: of course -- that content is read only | 12:32 |
| zyga | dpm: look at /var/lib/snapd/desktop/ | 12:32 |
| zyga | dpm: that will be what you want | 12:33 |
| zyga | dpm: how does your desktop file look like there? | 12:33 |
| * dpm looks | 12:34 | |
| dpm | zyga, http://pastebin.ubuntu.com/15928960/ | 12:35 |
| zyga | dpm: then rebuild the snap with Icon=${SNAP}/meta/gui/icon.png | 12:36 |
| zyga | and put the icon in setup/gui/icon.png | 12:36 |
| dpm | zyga, yeah, the icon is already there, I'll just need to update Icon= | 12:36 |
| dpm | let me give it a go | 12:37 |
| zyga | \o/ | 12:37 |
| Gunther_ | ogra_: https://bugs.launchpad.net/snapcraft/+bug/1572118 | 12:38 |
| ubottu | Launchpad bug 1572118 in Snapcraft "kernel plugin _make_initrd fails to add given modules" [Undecided,New] | 12:38 |
| zyga | sergiusens: can you patch snapcraft to generate: exec ... "$@" | 12:40 |
| zyga | sergiusens: $* is a bug | 12:40 |
| dpm | zyga, it worked! :-) | 12:42 |
| dpm | zyga, but I guess that's still a bug in the sense developers should not know about meta/gui, right? | 12:43 |
| ogra_ | Gunther_, thanks | 12:43 |
| zyga | dpm: perhaps | 12:43 |
| xorrr | hi, in the snappy 15.04 img for raspberrypi2 there was apt-get in /usr/bin, i have use this to install wget to download scripts, in the 16.04 img apt-get seems to not be present anymore, what would be my alternative to have access to non-snap tools? | 12:43 |
| jibel | seb128, I had cap-test, clock and calculator installed from software center and after a reboot they are all gone. | 12:45 |
| zyga | xorrr: use classic dimension | 12:45 |
| zyga | jibel: there's a bug where we don't mount snaps on reboot apparently | 12:45 |
| jibel | nice | 12:45 |
| seb128 | jibel, ubuntu software you mean? ;-) | 12:45 |
| seb128 | jibel, is snap list listing those? | 12:45 |
| jibel | seb128, yeah .*sofware.* | 12:45 |
| sergiusens | zyga yes we can; we already have a PR even | 12:45 |
| jibel | seb128, nope | 12:45 |
| seb128 | k | 12:45 |
| zyga | sergiusens: fantastic, thank you :) | 12:46 |
| jibel | zyga, you have a bug #? | 12:46 |
| seb128 | so what zyga said I guess | 12:46 |
| zyga | jibel: no sorry | 12:46 |
| * ogra_ curses ... | 12:47 | |
| sergiusens | ogra_ use a gui or ncurses instead | 12:47 |
| ogra_ | mvo, what was the exact line for the task override ? was that "XB-Task: ubuntu-core" ? | 12:47 |
| ogra_ | sergiusens, i prefera a good dialog :P | 12:48 |
| mvo | ogra_: yeah | 12:48 |
| ogra_ | damn thing ... always gets in my way | 12:48 |
| * ogra_ ponders if waiting for 30min for the archive publisher or if uploading another package to the PPA ... | 12:49 | |
| ogra_ | i guess the time it takes will be the same now | 12:49 |
| mvo | ogra_: yeah, the task header is anoying | 12:49 |
| jibel | zyga, I filed bug 1572125 | 12:49 |
| ubottu | bug 1572125 in ubuntu-snappy (Ubuntu) "install snaps are gone after a reboot" [Undecided,New] https://launchpad.net/bugs/1572125 | 12:49 |
| zyga | jibel: thank you | 12:49 |
| xorrr | zyga, can't follow, classic dimension? is this a tool? | 12:49 |
| ogra_ | who reboots anyway ... this is linux, not windows | 12:50 |
| * ogra_ grins evil | 12:50 | |
| zyga | xorrr: it's a way to use classic ubuntu on snappy | 12:50 |
| * zyga reboots to test that bug | 12:51 | |
| mvo | jibel: what does /etc/systemd/system/multi-user-target.wants/snap-*.mount looks like? | 12:51 |
| jibel | mvo, snap-*.mount or snaps-*.mount ? | 12:52 |
| mvo | jibel: all of them, should be snap-* but if you have snaps instead that might be a clue too | 12:53 |
| jibel | mvo, http://paste.ubuntu.com/15929159/ | 12:53 |
| jibel | mvo, there is no snap-*.mount | 12:53 |
| mvo | ta | 12:54 |
| zyga | jibel: reproduced and confirmed | 12:58 |
| * ogra_ taps foot | 12:59 | |
| === davidcalle_ is now known as davidcalle | ||
| ysionneau | zyga: I think the hash of ubuntu-device-flash (from mvo) changed again | 13:01 |
| ysionneau | I get integrity issues when using ubuntu-image | 13:02 |
| zyga | ysionneau: would you mind sending a pull request, I'm in a call | 13:02 |
| ysionneau | ok | 13:03 |
| === zyga_ is now known as zyga | ||
| Gunther_ | ogra_: the initrd now contains ahci.ko, still no success -> i will add libahci.ko too | 13:08 |
| ysionneau | zyga: done: https://github.com/zyga/devtools/pull/6 | 13:08 |
| ogra_ | Gunther_, yeah | 13:09 |
| dpm | dholbach, popey, I just uploaded a working ubuntu-clock-app, would you mind reviewing it and approving if it works for you? | 13:15 |
| kalikiana | zyga: Can you elaborate on how to "reset" snap/snappy? I'm happy to just remove all local data and try again to see if that resolves things. | 13:15 |
| dholbach | dpm, sure | 13:15 |
| zyga | kalikiana: working on it | 13:16 |
| zyga | kalikiana: in a call, give me a moment | 13:17 |
| sergiusens | kyrofa and zyga https://github.com/ubuntu-core/snapcraft/pull/473 | 13:17 |
| kalikiana | Okay | 13:17 |
| dpm | dholbach, thanks! it seems the store still doesn't yet have the opengl interface? | 13:17 |
| sergiusens | kyrofa and zyga https://github.com/ubuntu-core/snapcraft/pull/473 | 13:17 |
| zyga | sergiusens: thanks :) | 13:18 |
| dholbach | dpm, click-reviewers-tools don't have it | 13:23 |
| dholbach | I have the same problem locally | 13:23 |
| dholbach | let me see if it's updated in the branch | 13:23 |
| dholbach | no, it doesn't seem to be in there either | 13:24 |
| dholbach | filing a bug | 13:24 |
| dholbach | https://bugs.launchpad.net/click-reviewers-tools/+bug/1572140 | 13:26 |
| ubottu | Launchpad bug 1572140 in Canonical Click Reviewers tools "click-reviewers-tools don't know opengl interface" [Undecided,New] | 13:26 |
| dholbach | known issues doc updated as well | 13:27 |
| dpm | thanks dholbach | 13:27 |
| dholbach | dpm, hohum... | 13:28 |
| dholbach | error: cannot perform the following tasks: | 13:28 |
| dholbach | - Mount snap "ubuntu-clock-app" (cannot find mounted snap "ubuntu-clock-app" at revision 100001) | 13:28 |
| dpm | dholbach, what's that the output of? | 13:28 |
| dholbach | sudo snap install <snap> | 13:29 |
| dpm | dholbach, is that perhaps the result of rebooting and the issue with sideloaded apps? | 13:29 |
| dholbach | maybe | 13:30 |
| dholbach | this morning I had an issue like this when the state.json file was in an inconsistent state | 13:30 |
| popey | uh | 13:30 |
| popey | you need to sudo snap install ./snap | 13:30 |
| popey | not sudo snap install snap | 13:30 |
| dholbach | that was fixed | 13:30 |
| popey | or it tries to get it from the store | 13:30 |
| popey | oh | 13:30 |
| qengho | "./" | 13:30 |
| popey | things move fast here :) | 13:30 |
| dholbach | https://github.com/ubuntu-core/snappy/pull/908 | 13:31 |
| dpm | I generally give it the full *.snap filename when I sideload | 13:31 |
| qengho | Is it a test for a slash? | 13:31 |
| _morphis | zyga: ping | 13:37 |
| zyga | hey | 13:37 |
| ogra_ | mvo, fixed kernel snap works fine (with ahci added to the initrd) | 13:39 |
| qengho | Okay, it's a new world. Where did "snappy config" and "snappy activate" functionality go? | 13:40 |
| ogra_ | once all arches are done i'll push to the store | 13:40 |
| zyga | _morphis: I assume you are asking about bluez/nm interfaces | 13:41 |
| Gunther_ | ogra_: Are you sure? Can look intp the kerne config? | 13:41 |
| ogra_ | Gunther_, it is the linux-generic default config ... i just made sure ahci and libahci end up inside the initrd | 13:42 |
| ogra_ | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/58503 | 13:42 |
| ogra_ | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/58503/+files/livecd.ubuntu-core.kernel.snap has the changed initrd | 13:42 |
| _morphis | zyga: yes, jdstrand said he gave you a patch to get the plug names into the policy | 13:42 |
| popey | dpm: clock app launches here | 13:42 |
| zyga | _morphis: yes, for bluez, I didn't do it yet but I have a TODO for today to do it | 13:42 |
| zyga | _morphis: we're doing another relase now | 13:42 |
| Gunther_ | ogra_: ok. I have both in but still no success. | 13:43 |
| popey | dpm: some apparmor issues, but launches http://paste.ubuntu.com/15929760/ | 13:43 |
| ogra_ | Gunther_, well, works just fine here | 13:43 |
| _morphis | zyga: we should get ssweeny bluez interface fix in for that | 13:43 |
| zyga | _morphis: we've been fighting bugs and I was also really taking a slow day today | 13:43 |
| _morphis | zyga: :-) | 13:43 |
| ogra_ | i'm looking at a booted vbox | 13:43 |
| _morphis | zyga: you have that patch available? can take a look at it too | 13:43 |
| zyga | _morphis: I've +1d it; it may get merged today, if not we're also planning 0-day SRU | 13:43 |
| Gunther_ | ogra_: I must have done something different/wrong. I ll investigate | 13:43 |
| zyga | _morphis: the priority today is to not break the 16.04 release and fix critical bugs | 13:43 |
| dpm | popey, indeed, these are known issues that might need a fix in the toolkit | 13:43 |
| _morphis | zyga: aye | 13:44 |
| zyga | _morphis: I'll ping you when I'll get back to bluez | 13:44 |
| dpm | popey, dholbach, ok to approve clock, then? Calculator is building and I'll upload it next | 13:44 |
| popey | it must have been approved if I got it from the store :) | 13:44 |
| _morphis | zyga: thanks | 13:44 |
| dholbach | dpm, it's approved | 13:47 |
| sergiusens | dpm dholbach have you guys tried any gtk apps? Those seem to be more complicated than anticipated :-) | 13:50 |
| mvo | ogra_: \o/ | 13:50 |
| mvo | ogra_: thanks for fixing this | 13:50 |
| sergiusens | well, I know less about gtk than Qt at least | 13:50 |
| dpm | sergiusens, we have IIRC, it seems getting the theming to not look like 1990 is one of the biggest issues | 13:51 |
| ogra_ | oh, whee !!! | 13:51 |
| ogra_ | http://i.imgur.com/gSPT5uj.png | 13:51 |
| ogra_ | sergiusens, ^^^ | 13:54 |
| zyga | ogra_: is that m10? | 13:54 |
| dpm | ogra_, hangouts working? :-) | 13:54 |
| ogra_ | yep | 13:54 |
| ogra_ | and yep :D | 13:54 |
| dpm | \o/ | 13:54 |
| zyga | woooow | 13:54 |
| Gunther_ | ogra_: Which config do I have to add to the kernel config to get /proc/config.gz ? | 13:55 |
| Gunther_ | ogra_: I think my problem is related with EXT4 filesystem upport | 13:55 |
| ogra_ | CONFIG_IKCONFIG_PROC | 13:56 |
| ogra_ | you want ext4 compiled in | 13:56 |
| Gunther_ | ogra_: thanks and thanks | 13:56 |
| sergiusens | ogra_ you even have video on! wow | 14:01 |
| ogra_ | sergiusens, yeah, fully working | 14:01 |
| sergiusens | ogra_ not surprised that it works, only surprised that you have video on :-P | 14:01 |
| sergiusens | ogra_ this means it should eventually work on my phone; I want oSoMon to SRU the change into xenial; I'm using the webbrowser on desktop too; so much more light weight :-) | 14:02 |
| popey | 14:51 < ogra_> http://i.imgur.com/gSPT5uj.png | 14:03 |
| popey | that is the _first_ time I have ever seen ogra in a hangout :) | 14:03 |
| ogra_ | LOL | 14:03 |
| ogra_ | sergiusens, it is just three lines in the UA override file, worst case you can hack that in yourself | 14:08 |
| _morphis | jdstrand: pushed a reworked version of the networkmanager interface | 14:10 |
| qengho | Okay, so looks like "config" and "activate" are being reimplemented. Foo. | 14:15 |
| dholbach | Did anyone ever seen an issue like this? | 14:21 |
| dholbach | daniel@daydream:/tmp/2048.qml$ sudo snap install 2048-qml_1_amd64.snap | 14:21 |
| dholbach | error: change finished in status "Hold" with no error message | 14:21 |
| dholbach | or is this related to the current state issues which are being investigated? | 14:21 |
| dholbach | zyga, ^? | 14:21 |
| zyga | one sec | 14:24 |
| Gunther_ | where should I report a bug concering "snap"? https://bugs.launchpad.net/snappy ? | 14:26 |
| zyga | dholbach: we saw it but it's still unclear what's going on | 14:29 |
| zyga | Gunther_: yes | 14:29 |
| dholbach | zyga, shall I file a separate bug for it? | 14:29 |
| zyga | dholbach: yes, I think so | 14:31 |
| zyga | dholbach: that one looks a bit different | 14:31 |
| dholbach | ok, will do | 14:31 |
| zyga | thank you | 14:31 |
| dholbach | zyga, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175 | 14:34 |
| ubottu | Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New] | 14:34 |
| zyga | dholbach: could you try this script https://github.com/zyga/devtools/pull/7/files | 14:34 |
| zyga | dholbach: use it to reset your state | 14:34 |
| zyga | dholbach: reboot | 14:35 |
| zyga | dholbach: and see if you can reproduce the issue | 14:35 |
| dholbach | zyga, I reset it this morningg already | 14:35 |
| dholbach | but can try | 14:35 |
| dholbach | but can try again | 14:35 |
| zyga | dholbach: don't reboot again (that will trigger another bug) | 14:35 |
| zyga | dholbach: if you can reproduce on top of that "clean slate" I will check it out locally | 14:35 |
| pedronis | dholbach: zyga: that one is weird it means all tasks for a change are in hold | 14:35 |
| pedronis | more interesting would | 14:36 |
| pedronis | what snap changes gives | 14:36 |
| pedronis | before resetting everything | 14:36 |
| zyga | dholbach: ^^^ | 14:36 |
| zyga | pedronis: (good point) | 14:36 |
| ppisati | ogra_: i'm testing some custom kernel with snappy, but i'm having an hard time debugging why it fails in initrd | 14:36 |
| dholbach | I'm not sure I understand | 14:36 |
| dholbach | what am I supposed to do? | 14:36 |
| zyga | dholbach: pastebin snap changes | 14:36 |
| pedronis | dholbach: sorry there's command called "snap changes" | 14:36 |
| ogra_ | ppisati, why is that ? | 14:36 |
| dholbach | ah ok, thanks | 14:36 |
| Gunther_ | ppisati: welcome to my world :) | 14:36 |
| dholbach | zyga, pedronis: http://paste.ubuntu.com/15930423/ | 14:37 |
| ppisati | ogra_: basically, it fails while mounting root in /tmp_writable/system-data/var/lib/snappy/... /root | 14:37 |
| ppisati | ogra_: and i noticed that .../snappy/... is not there | 14:37 |
| ogra_ | ppisati, old initrd then | 14:37 |
| ppisati | ogra_: before that i don't see any error | 14:37 |
| ogra_ | the path changed a while ago | 14:37 |
| zyga | ppisati: it's now /var/lib/snapd | 14:37 |
| ppisati | ogra_: ok, so, what am i doing wrong? | 14:37 |
| ogra_ | use a recent initrd | 14:38 |
| ppisati | ogra_: i'm building thekernel using snapcraft kernel pluging on a 4.4 kernel | 14:38 |
| ppisati | ogra_: on a xenial chroot | 14:38 |
| ppisati | *in | 14:38 |
| ogra_ | latest snapcraft on xenial ? | 14:38 |
| ppisati | ogra_: from github | 14:38 |
| ogra_ | with all your snapcraft login data present ? | 14:38 |
| ppisati | ogra_: yes | 14:38 |
| ogra_ | weird | 14:39 |
| ogra_ | sergiusens, you should realöly pull from cdimage :P | 14:39 |
| ppisati | ogra_: how do i check if i'm using an old initrd? | 14:39 |
| popey | jdstrand: sorry, realised i asked that in the wrong channel - 15:36 < popey> jdstrand: did we get an answer about what we do with apps which need w access to /var/cache/fontconfig/ ? | 14:39 |
| ppisati | just to be sure | 14:39 |
| ogra_ | well the initrd has a version attached to the file inside the os snap ... not sure the plugin prints that somewhere | 14:40 |
| ogra_ | *attached to the filename | 14:40 |
| pedronis | dholbach: what does "snap changes 8" "snap changes 9" and "snap changes 10" and "snap changes 11" give ? | 14:40 |
| dholbach | pedronis, http://paste.ubuntu.com/15930491/ | 14:40 |
| dholbach | sorry, forgot 11 | 14:41 |
| dholbach | http://paste.ubuntu.com/15930498/ | 14:41 |
| ogra_ | ppisati, i think Gunther_ added a patch that allows you to use a local os snap for this ... | 14:41 |
| ogra_ | not sure if that landed already | 14:41 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the most recent one | 14:42 |
| * ppisati checks | 14:42 | |
| pedronis | dholbach: 11 is empty super weird | 14:43 |
| zyga | kalikiana: hey, sorry ofr the delay | 14:44 |
| zyga | kalikiana: can you please try this: https://github.com/zyga/devtools/blob/master/reset-state | 14:44 |
| pedronis | dholbach: what do you have in ls /snap/ubuntu-clock-app/ and /snap/ubuntu-clock-app/100001 ? | 14:44 |
| zyga | kalikiana: this will give you a clean slate for experiments and reporting bugs | 14:45 |
| dholbach | pedronis, http://paste.ubuntu.com/15930578/ | 14:45 |
| pedronis | dholbach: you 100001 is empty | 14:45 |
| pedronis | that seems the reboot bug | 14:45 |
| dholbach | yep, it looks like it | 14:46 |
| pedronis | I mean the mount/reboot bug | 14:46 |
| pedronis | dholbach: so all you errors are accounted for | 14:46 |
| pedronis | dholbach: the empty 11 on Hold is super strange though | 14:46 |
| dholbach | ok, cool - thanks a lot | 14:46 |
| pedronis | seems like a crash or something | 14:46 |
| pedronis | dholbach: anything interesting in the snapd logs ? | 14:47 |
| popey | dpm: dholbach have you packaged any non-qml graphical apps? | 14:48 |
| dholbach | can you remind me how I check again? something with journalctl? | 14:48 |
| zyga | dholbach: journalctl -u snapd | 14:48 |
| dholbach | thanks | 14:48 |
| zyga | pedronis: perhaps we should add some instructions for people reporting bugs on lauchpad, to pastebin $ snap changes, journalctl, etc | 14:49 |
| sergiusens | ogra_ I could and I wanted to but I couldn't find the snaps | 14:49 |
| ogra_ | sergiusens, oh ? | 14:49 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 14:49 |
| dholbach | pedronis, http://paste.ubuntu.com/15930649/ | 14:49 |
| ogra_ | sergiusens, you want the *.os.snap files ... | 14:50 |
| sergiusens | ogra_ I need it tied to xenial though | 14:51 |
| ogra_ | ah | 14:51 |
| ogra_ | that might only happen post release | 14:52 |
| sergiusens | If not, once Y opens we will start picking from there and will have to SRU | 14:52 |
| ogra_ | (unless you want to first check the default path and then fall back to a xenial one) | 14:52 |
| ogra_ | well, fo Y the files will have the Y name as prefix | 14:52 |
| dholbach | popey, no, sorry | 14:53 |
| dholbach | I tried, but failed | 14:53 |
| popey | hm, same | 14:53 |
| popey | ok | 14:53 |
| popey | ta | 14:53 |
| sergiusens | I would rather leave it complicated as it is now so people get the fact that most of the kernel snaps they build are bound to break | 14:53 |
| ogra_ | well, you are heavily relying on the assumption the dual initrd approach will actually work :) | 14:54 |
| ogra_ | something nobody tested yet :) | 14:54 |
| ogra_ | geez, uploading one set ofr snaps for all arches takes 1h of my day ... so annoying | 14:55 |
| ppisati | FWIW, using the xenial src tree and the exact xenial config, i was able to build a working kernel | 14:55 |
| ppisati | but when i started to reduce the config (start from x86_64_defconfig and add the systemd/ubuntu core options etc) | 14:56 |
| ppisati | i always end up in the initrd shell | 14:56 |
| ogra_ | that sounds liek you disable something you shouldnt disable :) | 14:56 |
| ppisati | cause iit can't mound the root snap in /tmp_writable etcetct | 14:56 |
| ppisati | ogra_: yep | 14:56 |
| ogra_ | moving ext4 to a module ? | 14:56 |
| ogra_ | or some such | 14:56 |
| ppisati | ogra_: nope | 14:56 |
| ogra_ | do you have squashfs defined in your initrd mopdules ? | 14:57 |
| zyga | dholbach: could you please link/attach all the pastebins to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175 | 14:57 |
| ubottu | Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New] | 14:57 |
| dholbach | zyga, sure | 14:57 |
| zyga | dholbach: thanks! | 14:57 |
| ppisati | ogra_: yes, it's there and it's loaded | 14:57 |
| dpm | popey, I haven't myself, no | 14:57 |
| ppisati | ogra_: the question is: i'm missing a part of | 14:57 |
| dpm | popey, while dholbach are on a call, would you mind doing the calculator review on the store? | 14:58 |
| ppisati | ogra_: /tmp_writable/system-data/var/lib/snappy/... | 14:58 |
| ppisati | ogra_: where does it reside? | 14:58 |
| dholbach | dpm, already done | 14:58 |
| pedronis | dholbach: those in Hold (no Error) you should have got a message from snap the command, they are just left over of us creating the change before all the pre checks are done | 14:58 |
| ogra_ | ppisati, inside the initrd ubuntu-core script | 14:59 |
| dpm | awesome, thanks dholbach | 14:59 |
| pedronis | nothing too serious we will fix | 14:59 |
| * dpm updates spreadsheet | 14:59 | |
| ogra_ | ppisati, you definitely have an old initrd | 14:59 |
| ppisati | ogra_: but then why it works with the full config? | 14:59 |
| ppisati | ogra_: do you mind if i pass a kernel to test and you can confirm me it's an old initrd problem? | 14:59 |
| ppisati | ogra_: amd64 for kvm | 15:00 |
| ogra_ | sure | 15:00 |
| ppisati | ok, one sec | 15:00 |
| dholbach | zyga, pedronis: so you suggest I run the reset-state script now and try again? or reboot? | 15:00 |
| dholbach | sorry if I'm a bit unconcentrated - I was in calls while we were looking at the problem | 15:01 |
| ogra_ | mvo, (or beuno) ... please approve the set of http://paste.ubuntu.com/15930802/ (thats the full set of snaps with the fixed initrd) | 15:01 |
| pedronis | dholbach: the reset will not help I think | 15:01 |
| dholbach | ok | 15:01 |
| pedronis | dholbach: what you need is the fix for the mount issues | 15:01 |
| dholbach | that's 2.0.2 which went to the archive earlier? | 15:01 |
| pedronis | dholbach: mvo can tell you more about how to work with that | 15:01 |
| pedronis | dholbach: I think so, but not sure, mvo can tell | 15:01 |
| dholbach | ok cool | 15:02 |
| * zyga checks to offload mvo | 15:02 | |
| pedronis | dholbach: you may need to cleanup snaps manually or fix some systemd units | 15:02 |
| ppisati | ogra_: http://people.canonical.com/~ppisati/xenialsnappyfuffa2defconfig_4.4.0_amd64.snap | 15:02 |
| ppisati | yeah, the name is stupid, i know... | 15:02 |
| dholbach | so just installing 2.0.2 didn't fix it | 15:03 |
| zyga | dholbach: use my reset script after installing 2.0.2 | 15:03 |
| * zyga doesn't have 2.0.2 yet | 15:03 | |
| dholbach | ah ok | 15:03 |
| dholbach | will do | 15:03 |
| zyga | dholbach: then reinstall snaps you had | 15:03 |
| pedronis | dholbach: because the old units need fixing | 15:03 |
| dholbach | zyga, https://launchpad.net/ubuntu/+source/snapd/2.0.2/+build/9597800 | 15:03 |
| zyga | pedronis: the script removes those units too | 15:04 |
| pedronis | ah ok | 15:04 |
| zyga | ah, it's in proposed | 15:04 |
| zyga | dholbach: how does that promote to non-proposed? | 15:04 |
| dholbach | I think it's in binary NEW | 15:04 |
| * Gunther_ is trying fuffa2defconfig :) | 15:04 | |
| dholbach | so there's the first gate | 15:04 |
| dholbach | so there's the first gate: the review queue of uploaded source packages | 15:05 |
| dholbach | then there's built binary packages in a queue | 15:05 |
| dpm | jibel, kgunn, ok, the new calculator and clock are now both installable from the store. They should be launchable from command line, the dash and the launcher | 15:05 |
| dholbach | both of them are now in place since we're in final freeze and stuff | 15:05 |
| beuno | ogra_, can you make sure you requested a manual review for all of them? | 15:05 |
| ogra_ | phew ... in a few | 15:05 |
| dholbach | zyga, pedronis: http://paste.ubuntu.com/15930918/ | 15:05 |
| sergiusens | ogra_ it has been tested. And in any case, snappy can do the mashing on install if not | 15:06 |
| dholbach | zyga, pedronis: (after installing 2.0.2 and running reset-state) | 15:06 |
| Gunther_ | ppisati: the same as with my kernel | 15:06 |
| ogra_ | sergiusens, really ? show me the uboot changes then | 15:06 |
| dholbach | zyga, pedronis: maybe reboot? | 15:06 |
| pedronis | the 2nd thing seems a store isse not sure | 15:06 |
| zyga | hmmm | 15:06 |
| zyga | store issue | 15:06 |
| pedronis | it's not finding ubuntu-core | 15:06 |
| ogra_ | (and no, chainloading grub is not an option until someone showed me how the DTs get handed over from bootloader to bootloader) | 15:06 |
| dholbach | ok | 15:06 |
| zyga | dholbach: with 2.0.2 your release will be looking for 16 | 15:06 |
| zyga | dholbach: I'm not sure if the store was changed yet | 15:07 |
| zyga | beuno: ^^ | 15:07 |
| dholbach | ok... | 15:07 |
| dholbach | I guess I'll hang in there then | 15:07 |
| * zyga goes to make some snaps for testing | 15:07 | |
| ogra_ | yeah, make some schnaps ! | 15:08 |
| kgunn | dpm: yep, worked for me no prob | 15:09 |
| sergiusens | ogra_ then my if not part of the sentence applies | 15:11 |
| ogra_ | heh, k | 15:11 |
| mvo | dholbach: store needs to be update to use the new "16" series | 15:11 |
| dholbach | ok... so I guess I roll back to 2.0.1 then | 15:11 |
| ogra_ | ppisati, i get the same error here ... werid | 15:11 |
| dpm | kgunn, great | 15:12 |
| ogra_ | i wish i could see all messages ... i guess the error is scrolled off screen | 15:12 |
| zyga | dholbach: 2.0.1 has the mount bug, you want 2.0.2 and you want beuno to tweak the store | 15:12 |
| dholbach | ok | 15:14 |
| beuno | we're updating to 16 today | 15:14 |
| ppisati | Gunther_: are you having the same issue? | 15:15 |
| Gunther_ | ppisati: yes it looks like that | 15:15 |
| * zyga hugs sergiusens for "snapcraft help <plugin>" | 15:15 | |
| ppisati | http://pastebin.ubuntu.com/15931130/ | 15:16 |
| ppisati | Gunther_: ogra_ ^ | 15:16 |
| ppisati | this a snapcraft.yaml | 15:16 |
| ppisati | for an exact copy of the amd64 that we use in xenial | 15:16 |
| ppisati | and it works fine | 15:17 |
| ppisati | if you want to try it out | 15:17 |
| Gunther_ | looks very similar to mine. but ogra_ and I add ahci.ko and libahci.ko to initrd | 15:18 |
| ogra_ | right, but thats a different issue | 15:18 |
| ogra_ | i doubt ppisati uses VBox | 15:18 |
| ppisati | nope | 15:18 |
| Gunther_ | you re right | 15:19 |
| ppisati | qemu-kvm | 15:19 |
| ogra_ | the the disk is found too | 15:19 |
| ogra_ | sigh, how do i get kvm to actually output everything to serial | 15:19 |
| ogra_ | booting with -nographic doesnt seem to get me the initrd errors | 15:19 |
| dholbach | dpm, I'm working on 2048 right now, but unfortunately my snapd state is broken right now (https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175) and the new snapd (2.0.2 from the archive admin queue, which fixes a bunch other issues) depends on a change which is going into the store, so I'm a bit stuck (just a quick summary) | 15:20 |
| ubottu | Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New] | 15:20 |
| dpm | dholbach, argh, np, thanks for the update | 15:21 |
| dholbach | dpm, if your snapd still works, maybe you can try http://paste.ubuntu.com/15931236/? | 15:21 |
| === charles_ is now known as charles | ||
| dpm | dholbach, cool, thanks | 15:22 |
| dholbach | dpm, shall I add it to the snappy-desktop-examples branch already? | 15:22 |
| dpm | dholbach, yes please. It will also need the wrapper to set the environment variables, I think. | 15:22 |
| dpm | unless it already worked for you without the wrapper? | 15:23 |
| dholbach | dpm, ok... I didn't get that far - "qmlscene 2048.qml" locally works | 15:23 |
| * dpm tries | 15:23 | |
| Gunther_ | ogra_, ppisati : I try to use the https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/58503/+files/livecd.ubuntu-core.os.snap now and not the os.snap coming from the store | 15:24 |
| dholbach | dpm, added to the branch | 15:24 |
| dpm | dholbach, argh: http://pastebin.ubuntu.com/15931341/ | 15:26 |
| dholbach | dpm, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175 | 15:28 |
| ubottu | Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New] | 15:28 |
| dpm | that's a bit of a big blocker :/ | 15:29 |
| Gunther_ | ogra_: it worked! | 15:29 |
| ogra_ | awesome | 15:30 |
| mvo | dholbach, dpm: the store is moving to the new 16 series and we need to reupload our snaps for this, this means for the next couple of hours the 2.0.2 release is a bit bumpy | 15:30 |
| zyga | mvo: reupload or republish? | 15:30 |
| dpm | mvo, thanks. Do you happen to know if there is a workaround for that "Hold with no error message" bug? | 15:31 |
| Gunther_ | ppisati: its os.snap. the one downloaded by the snapcraft kernel.plugin is not "current" enough | 15:31 |
| ogra_ | yeah | 15:31 |
| mvo | zyga: I thnk its reupload, beuno will know for sure | 15:31 |
| dholbach | dpm, I think 2.0.2 from https://launchpad.net/ubuntu/+source/snapd/2.0.2 helps, but as mvo said that won't work as we're waiting for a store fix to land | 15:31 |
| ogra_ | let me switch them to manual approval and get beuno to approve them, that should fix you | 15:31 |
| mvo | dpm: not right now afaik | 15:32 |
| * ogra_ goes on a clicking spree | 15:32 | |
| mvo | dholbach: I'm publishing some snaps now (go-example-webserver) may already be available | 15:32 |
| ogra_ | oh, seems someone approved the ubuntu-core ones without requesting | 15:34 |
| ogra_ | beuno, http://paste.ubuntu.com/15931482/ ... all in manual queue now | 15:34 |
| beuno | ogra_, I did! | 15:35 |
| beuno | they were indeed requested, somehow :) | 15:35 |
| ogra_ | ah, awesome :) | 15:35 |
| beuno | approving the rest | 15:35 |
| ogra_ | ppisati, so try again ... | 15:36 |
| beuno | package contains external symlinks: lib/modules/4.4.0-1004-raspi2/build lint-snap-v2_external_symlinks | 15:36 |
| beuno | ogra_, I assume that's expected, yes? | 15:36 |
| ogra_ | indeed | 15:36 |
| ogra_ | thats our kernel package | 15:36 |
| ppisati | ogra_: a new os.snap has landed? | 15:36 |
| ogra_ | they all have that danglinmg symlink | 15:36 |
| ogra_ | ppisati, yes | 15:36 |
| ppisati | k, /me tries | 15:36 |
| beuno | ogra_, right, so the reason the other ones made it to the queue is because they only triggered the OS flag, which sends it to manual review automatically | 15:37 |
| beuno | ogra_, these ones trigger an error due to these symlinks | 15:37 |
| === Guest10951 is now known as pmp | ||
| ogra_ | ah | 15:37 |
| ogra_ | ubuntu@localhost:~$ sudo snap refresh ubuntu-core | 15:37 |
| ogra_ | error: can't update "ubuntu-core": cannot find snap "ubuntu-core" | 15:37 |
| ogra_ | bah ! | 15:37 |
| beuno | ogra_, you can work with jdstrand maybe to improve the reviewer tools | 15:37 |
| beuno | so that doesn't happen | 15:37 |
| ogra_ | beuno, yeah, kernel snaps should be handled special :) | 15:38 |
| ogra_ | so how do i get my updated rootfs now | 15:38 |
| beuno | we're all special in some way | 15:38 |
| ogra_ | snap find shows the new one | 15:38 |
| ogra_ | but snap refresh doesnt | 15:38 |
| pedronis | ogra_: in which channel is the new one? | 15:39 |
| pedronis | mvo: ^ | 15:39 |
| ogra_ | pedronis, shoudl all be edge | 15:39 |
| pedronis | you need to do snap refresh --channel=edge ubuntu-core | 15:39 |
| ogra_ | the image is built from edge (sideloaded gadget though) | 15:39 |
| pedronis | maybe | 15:39 |
| pedronis | (default is stable) | 15:39 |
| ogra_ | ubuntu@localhost:~$ sudo snap refresh --channel=edge ubuntu-core | 15:40 |
| ogra_ | error: can't update "ubuntu-core": cannot find snap "ubuntu-core" | 15:40 |
| ogra_ | nope | 15:40 |
| pedronis | then don't know | 15:40 |
| ogra_ | ubuntu@localhost:~$ snap find|grep ^ubuntu-core | 15:40 |
| ogra_ | ubuntu-core 16.04+20160419.13-38 The ubuntu-core OS snap | 15:40 |
| pedronis | mvo: ^ is that a new store issue? or things aren't published yet in the right places? | 15:40 |
| ogra_ | ubuntu@localhost:~$ snap list|grep ^ubuntu-core | 15:40 |
| ogra_ | ubuntu-core 16.04+20160415.05-15 canonical | 15:40 |
| ogra_ | so list and find know about it | 15:40 |
| ogra_ | same issue with the kernel snap btw | 15:42 |
| ogra_ | ubuntu@localhost:~$ snap list|grep ^canonical-pi2-linux | 15:42 |
| ogra_ | canonical-pi2-linux 4.4.0-1004-raspi2+20160410.15-31 canonical | 15:42 |
| ogra_ | ubuntu@localhost:~$ snap find|grep ^canonical-pi2-linux | 15:42 |
| ogra_ | canonical-pi2-linux 4.4.0-1004-raspi2+20160419.13-51 The ubuntu-core kernel snap | 15:42 |
| mvo | ogra_: I don't see a 16.04+20160415 in the store yet, let me double check | 15:44 |
| ogra_ | mvo, i want to upgrade to 16.04+20160419.13-38 | 15:44 |
| ogra_ | 16.04+20160415 is the local version | 15:44 |
| ogra_ | (this is armhf btw, so the timestamp varies a bit) | 15:45 |
| plars | elopio: fgimenez: Hi, any thoughts on the errors I sent you? Are you still hitting those as well? | 15:45 |
| ppisati | it's stuck there trying to download ubuntu-core | 15:45 |
| mvo | ogra_: so this is store and side load? | 15:45 |
| ogra_ | mvo, store os and kernel, sideloaded gadget ... from yesterady | 15:46 |
| * ogra_ tries the dragonboard instaed ... i think there i dont have any sideloading | 15:46 | |
| elopio | ;5~;5~ | 15:47 |
| ogra_ | elopio, ! | 15:47 |
| ogra_ | elopio, "internet by bucket" ? | 15:47 |
| ogra_ | mvo, same behaviour on dragfonboard without any sideloaded snaps | 15:47 |
| ogra_ | (so it isnt the sideloading) | 15:48 |
| pedronis | ogra_: do you have content in you /snap/ubuntu-core ? | 15:49 |
| elopio | ogra_: what's that internet thing you are talking about? In this little town we just share the latest news sundays in the church. | 15:49 |
| pedronis | your | 15:49 |
| pedronis | I mean the one you are trying to update | 15:49 |
| ogra_ | ubuntu@localhost:~$ ls /snap/ubuntu-core/ | 15:49 |
| ogra_ | 92 current | 15:49 |
| mvo | ogra_: so you have an os snap and you call snap refresh ubuntu-core and it claims it can not find it? is that what you see? | 15:49 |
| elopio | plars: sorry, I have crappy connection. Will try to reproduce your problems in the afternoon. | 15:49 |
| ogra_ | ubuntu@localhost:~$ ls /snap/ubuntu-core/current/ | 15:49 |
| ogra_ | apps bin boot dev etc home lib media meta mnt opt proc root run sbin snap snaps srv sys tmp usr var writable | 15:49 |
| plars | elopio: no problem, I'm not in a rush. Just curious | 15:50 |
| ogra_ | mvo, right, the same goes for the kernel snap | 15:50 |
| ogra_ | mvo, but find and list work fine ... seems to be refresh only | 15:51 |
| mvo | ogra_: what version of snapd do you see in /usr/share/snappy/dpkg.list? | 15:54 |
| ogra_ | ubuntu@localhost:~$ grep snapd /usr/share/snappy/dpkg.list | 15:55 |
| ogra_ | ii snapd 1.9.3~ppa65-1 arm64 Tool to interact with Ubuntu Core Snappy. | 15:55 |
| ogra_ | ii ubuntu-core-snapd-units 1.9.3~ppa65-1 arm64 Scripts for snapd that should only run on ubuntu core systems. | 15:55 |
| ogra_ | the image was built yesterday afternoon | 15:55 |
| pedronis | ah this is pre 2.0 | 15:55 |
| ogra_ | lates core from the store | 15:55 |
| pedronis | so doesn't work with the store anymore | 15:55 |
| ogra_ | fun | 15:55 |
| ogra_ | we really need auto-uploads to work :/ | 15:56 |
| pedronis | it's complicated story | 15:56 |
| mvo | ogra_: in rolling? | 15:56 |
| mvo | ogra_: eh, edge? | 15:56 |
| mvo | ogra_: sorry, stable is super outdated right now | 15:56 |
| pedronis | it's the store that stopped working for it to be precise | 15:56 |
| mvo | ogra_: I will fix this soon but I had hoped to release stable with a 16 channel | 15:56 |
| ogra_ | manually uploading all snaps for and image refresh is a job for someone who killed mother and father with an axe | 15:56 |
| ogra_ | (takes easily 1-2h) | 15:56 |
| ogra_ | mvo, thats all edge | 15:57 |
| mvo | ogra_: tell me about it! | 15:57 |
| pedronis | edge but old edge | 15:57 |
| pedronis | no edge | 15:57 |
| ogra_ | i havent used stable in 6 months or so | 15:57 |
| mvo | ogra_: uh, then its matter of reuploading to edge, *sigh* amd64 is up-to-date | 15:57 |
| mvo | ogra_: I thought I did update today all ubuntu-core snaps in edge | 15:57 |
| ogra_ | mvo, you mean beaond what i uploaded qh ago ? | 15:57 |
| ogra_ | *1h | 15:57 |
| mvo | ogra_: maybe I was dreaming :/ or your image is build this monring before I did that | 15:57 |
| pedronis | mvo: yes, but they cannot be updated | 15:57 |
| pedronis | because remember the store changed and they can't find things there | 15:57 |
| mvo | pedronis: yes | 15:58 |
| mvo | ogra_: oh, you did not do a reflash? | 15:58 |
| pedronis | well he has 1.9 for snapd | 15:58 |
| mvo | pedronis: sorry, misunderstood, I assumed he did a reflash not just an update | 15:58 |
| pedronis | that doesn't sound reflashed | 15:58 |
| mvo | ogra_: sorry, please reflash | 15:58 |
| ogra_ | mvo, no, i did an image re-build and uploaded all snaps to the store about 1h ago ... about 30min ago beuno released all of them | 15:58 |
| ogra_ | the image is from yesterday | 15:59 |
| mvo | ogra_: and you got version 1.9.x, let me check the build logs | 15:59 |
| pedronis | ppa vs archive? | 15:59 |
| pedronis | we didn't udpate the ppa in a while? | 15:59 |
| mvo | ogra_: right, the image needs to be rebuild | 15:59 |
| ogra_ | task header ? | 15:59 |
| mvo | pedronis: I did update the ppa today | 15:59 |
| mvo | ogra_: hmmm | 15:59 |
| ogra_ | the rootfs build alwaqys prerfers the archive if you dont have the task header | 15:59 |
| mvo | ogra_: build log for armhf shows 2.0.2+ppa70-1 | 16:00 |
| mvo | same on arm64 | 16:00 |
| ogra_ | mvo, yes, for todays build ... | 16:00 |
| ogra_ | my image is yesterdays | 16:00 |
| mvo | ogra_: thats too old, sorry | 16:00 |
| mvo | ogra_: you need to rebuild the image with todays snaps for this to work | 16:00 |
| ogra_ | well, fine then ... but we need some auto-upload going ... | 16:01 |
| mvo | ogra_: updates from yesterday to today won't work, its complicated (like pedronis said) and has to do with store interaction | 16:01 |
| * ogra_ ponders to simply route it through a local PC for now | 16:01 | |
| dpm | popey, for ffmpeg in snappy-playpen, are all the files around snapcraft.yaml needed for the build? If I understand it correctly, we need the *.launcher files, but the clean_build and rebuild files are just convenience scripts to run manually to make packaging easier, right? | 16:17 |
| popey | dpm: convenience | 16:17 |
| popey | probably don't need any of the launchers, as it looks like snapcraft makes a binary for the app name automatically | 16:17 |
| popey | dpm: I'd just grab the 'part' for ffmpeg | 16:20 |
| ogra_ | jdstrand, tyhicks, FYI i unseeded tpm-tools today (since the MIR is unlikely to get through due to opencryptoki) http://people.canonical.com/~ogra/core-image-stats/20160419.4.changes | 16:28 |
| ogra_ | ricmm, ^^^ | 16:28 |
| elopio | kyrofa: sergiusens: how do we deal with projects that are in sourceforge? | 17:08 |
| dpm | zyga, still around? | 17:09 |
| ogra_ | mvo, where does that stuff come from ? http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ | 17:11 |
| mvo | ogra_: I don't know, I would assume its a snapshot of my all-snaps page | 17:18 |
| ogra_ | hwo can that happen if not you or me put it there ? | 17:23 |
| ogra_ | having random images show up at a semi-official place without you or me knowing isnt actually great | 17:23 |
| dpm | popey, btw, adding the ffmpeg part to the youtube-dl snap worked great to overcome the initial bug :). Now I'm looking at another part that's not quite working yet. | 17:25 |
| ogra_ | slangasek, i assume you dont know either how the images at http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ got there ? | 17:25 |
| popey | dpm: yay! | 17:25 |
| dpm | :) | 17:25 |
| jamiebennett | ogra_, mvo, would be nice to sort this out | 17:26 |
| slangasek | ogra_: I put them there | 17:27 |
| slangasek | ogra_: by taking a snapshot of the people.c.c stuff that we were pointed to, yes | 17:28 |
| slangasek | more permanent solution still in progress | 17:28 |
| ogra_ | slangasek, well, they are not actually usable :) | 17:28 |
| slangasek | ogra_, mvo: one snag I became aware of in talking with infinity, seems that the udf needed for these builds is not in the archive? why not? | 17:28 |
| ogra_ | nor upgradeable | 17:28 |
| slangasek | ogra_: well, they are what I was pointed at when we discussed one-off publishing of snappy images and no one had rescinded that order. I can certainly take them down again if that's the right answer | 17:29 |
| slangasek | or does someone have one I can replace them with that is upgradeable? | 17:29 |
| ogra_ | slangasek, seems that someone wants to completely re-define gadget and kernel before we release images ... so that udf would be broken again in the archive | 17:29 |
| ogra_ | slangasek, i usually ask people to build their own image nowadays ... and i think mvo also wiped them from the people.c.c page because they were always behind | 17:30 |
| ogra_ | now with the last snapd and store changes they wont be upgradeable at all | 17:30 |
| ogra_ | and these changes are still not final | 17:31 |
| dpm | niemeyer, I'm not sure I'm interpreting the output of 'snap interfaces' correctly. Does this mean that L19 is not connected? -> http://pastebin.ubuntu.com/15934268/ | 17:31 |
| slangasek | ogra_: ok; so you understand that we've been asked to publish pre-built images to cdimage.u.c ASAP? | 17:31 |
| ogra_ | slangasek, we shoudl simply not release images yet ... they arent ready and might still change in incompatible ways ... especially if kernel and gadget get changed massively again | 17:31 |
| slangasek | and are not being given the tools to do so | 17:31 |
| ogra_ | slangasek, well, not my decision ... | 17:32 |
| * ogra_ was in fact asking for u-d-f in the archive for the last few months ... but the prob is really that the format changes all the time .... | 17:32 | |
| ogra_ | *especially* with the nearly-rewrite that snappy has seen in the last weeks for desktop inclusion | 17:33 |
| slangasek | ogra_: well, I would appreciate some consistency here; either we're "not ready" to publish images and Foundations should deprioritize this, or it's important to publish them and so the tools should be in place to support this | 17:33 |
| ogra_ | slangasek, afaik snappy release date is some time in july ... | 17:33 |
| ogra_ | and i'd say we're not ready currently ... with luck we can have an alpha state image by end of the week | 17:34 |
| slangasek | and so we'll have a working udf in the archive by...? | 17:34 |
| ogra_ | probably mvo or niemeyer want to chime in here | 17:34 |
| kyrofa | elopio, sorry I was grabbing lunch | 17:34 |
| ogra_ | since all relevant discussions happen in telegram where i'm not part of | 17:34 |
| ogra_ | slangasek, by SRU (i guess) :) | 17:35 |
| kyrofa | elopio, however, I don't quite understand the question. How do we deal with them? Are they special in some way? | 17:35 |
| slangasek | ogra_: I meant "by" as in "by what date" | 17:36 |
| ogra_ | yes, i know ... cant tell you | 17:36 |
| ogra_ | mvo ^^ | 17:36 |
| niemeyer | dpm: Yes, that means it was disconnected at that time | 17:37 |
| niemeyer | slangasek: We believe we'll have working images by tomorrow | 17:38 |
| slangasek | niemeyer: what does that mean exactly? you'll be building the images locally and we should do a one-off copy again to cdimage.u.c? | 17:38 |
| dpm | niemeyer, thanks. So that seems to confirm that the home interface is not autoconnected, if I understand it correctly. After manually running 'sudo snap connect youtube-dl:home ubuntu-core:home' it all seems to work | 17:39 |
| ogra_ | slangasek, btw, we have a release process that images need to go through, documented in a trello board ... that includes the minimal amount of QA | 17:39 |
| niemeyer | slangasek: Sorry, I actually meant we'll have Snappy code capable of being run in an image built by udf tomorrow | 17:40 |
| ogra_ | https://trello.com/c/PUpWXouz/89-stable-release-checkpoints | 17:40 |
| niemeyer | dpm: Sweet! | 17:40 |
| slangasek | niemeyer: ok; AIUI that still doesn't give me a udf in xenial that I can use for official image mastering | 17:40 |
| ogra_ | niemeyer, the question was if we can get the u-d-f that produces usable images in the archive | 17:40 |
| ogra_ | since the server that builds them will most likely use the archive to obtain all build tools | 17:41 |
| ogra_ | slangasek, the prob with udf is that it also needs to be tied to http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ and to the store itself | 17:41 |
| ogra_ | the build setu we need is pretty complex | 17:42 |
| ogra_ | (cdimage produces the snaps ... the snaps need to go to the edge channel in the store, need to get approved and only then u-d-f can kick in and create images) | 17:42 |
| slangasek | niemeyer: and I guess ogra_ is raising concerns about the images currently published to http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ , which we've published there by request of olli/dholbach because not having images in an official location was blocking updating of the documentation for 16.04; so it's not clear to me if we need to be removing the images currently there or if we should just | 17:43 |
| slangasek | leave them alone and replace them with tomorrow's images once available / QAed | 17:43 |
| ogra_ | there are multiple infrastructure parties involved | 17:43 |
| ogra_ | slangasek, well, did any docs get updated to point to them ? | 17:43 |
| slangasek | ogra_: I am aware of the overall architecture, I am only asking for udf in xenial | 17:43 |
| ogra_ | if not we can leave them there ... | 17:43 |
| slangasek | ogra_: and if the docs *did* get updated you would instead pull them and leave dangling doc links? | 17:44 |
| ogra_ | if there are actually docs pointing to them they should warn that the majority of stuff doesnt work and that they are not upgradeable | 17:44 |
| ogra_ | or we should wipe them for now | 17:44 |
| ogra_ | neither is a good way ... | 17:44 |
| niemeyer | slangasek: are these snappy 2.0 images, 16.04, or something in between? | 17:46 |
| ogra_ | niemeyer, 1.9 | 17:46 |
| niemeyer | If it's something in between, I think we should remove them | 17:46 |
| ogra_ | 16.04 | 17:46 |
| ogra_ | from beginning of the month | 17:46 |
| niemeyer | Yeah, that sounds like more pain than gain | 17:47 |
| ogra_ | they wont be upgradeable and only have half of the interfaces implementation | 17:47 |
| niemeyer | I'd remove and ship new ones with 2.0 tomorrow | 17:47 |
| ogra_ | if they pass QA :) | 17:47 |
| niemeyer | Yep | 17:47 |
| * ogra_ was aiming for friday ... then the worst release stuff is over and people have a brain agaiin | 17:47 | |
| ogra_ | for alpha quality images that is | 17:48 |
| ogra_ | and i think mvo was on the same page | 17:48 |
| dpm | davidcalle, youtube-dl example working | 17:48 |
| mvo | yeah, image with snapd 2.0 this week, my goal was actually today and we almost made it | 17:48 |
| mvo | then came the store change to 16 | 17:48 |
| ogra_ | and vritualbox explosions :) | 17:49 |
| mvo | beuno: no pressure but in order for snap 2.0.2 with the series=16 change we need a working autopkg test which means we need a working 16 series because the autopkgtest tries to install stuff from 16 :/ | 17:49 |
| ogra_ | mvo, slangasek's main point is u-d-f though | 17:49 |
| ogra_ | mvo, whatever will build future images will have to pull u-d-f from the archive | 17:50 |
| mvo | ogra_: we have that only in a ppa currently :/ | 17:50 |
| ogra_ | which means we need some working version landed before release | 17:50 |
| mvo | beuno: I think we will need ubuntu-core and hello-world in there | 17:50 |
| mvo | ogra_: in the archive? | 17:50 |
| slangasek | mvo: what blocks uploading it to the archive? | 17:50 |
| ogra_ | mvo, why are we holding back (apart from expected changes) it snt like udf for core is in any way usable in the archive right now | 17:51 |
| ogra_ | 15.04 will soon be deprecated and for 16.04 the archive u-d-f would actually try to use system-image | 17:51 |
| ogra_ | just upload the PPA one so we at least have a semi working snapshot ... | 17:52 |
| * ogra_ can do that if you fear TIL :) | 17:53 | |
| ogra_ | slangasek, another thing ... due to bug hunting i didnt manage to write my MIRs, is there still time ( i dropped tpm-tools from the image but still need libnss-extrausers, watchdog and ubuntu-core-libs in main) ? | 17:55 |
| slangasek | ogra_: whether there's time or not, please work on these so we can have sane archive state for release | 17:55 |
| * ogra_ will write them today before EOD | 17:55 | |
| ogra_ | yeah, understood | 17:56 |
| beuno | nessita, ^^^^^ | 17:56 |
| beuno | (otp) | 17:56 |
| ogra_ | i guess worst case we can also drop watchdog ... extrausers is kind of essential though | 17:56 |
| nessita | beuno, ogra_, a little lost from the backlog, how can I help? | 18:00 |
| ogra_ | nessita, mvo> beuno: no pressure but in order for snap 2.0.2 with the series=16 change we need a working autopkg test which means we need a working 16 series because the autopkgtest tries to install stuff from 16 :/ | 18:01 |
| ogra_ | nessita, <mvo> beuno: I think we will need ubuntu-core and hello-world in there | 18:01 |
| nessita | ogra_, beuno, mvo I know, I'm on this since this morning, but still not available, working actively in this | 18:05 |
| mvo | nessita: yeah, sorry for rushing this all | 18:22 |
| mvo | slangasek: we expect changes to the kernel and gadget snap definitions so a u-d-f that is uploaded today is probably not the final result. I don't know the details or scope of the changes, just that its unlikely that the archive u-d-f would be able to create images for snappy core 16 devices. | 18:23 |
| mvo | ogra_: see above, we have a u-d-f branch that can create images today, however the format of the kernel/gadget is not finalized | 18:24 |
| ogra_ | mvo, i know that :) | 18:25 |
| ogra_ | but the diff we need to SRU will at least be smaller and whoever works on the image generation in foundations can move on | 18:25 |
| ogra_ | (i didnt even know someone in foundations does :P ) | 18:25 |
| sergiusens | kyrofa hey your autopackage tests failed | 18:27 |
| kyrofa | sergiusens, hrmm | 18:27 |
| kyrofa | sergiusens, OSError: [Errno 5] Input/output error | 18:29 |
| kyrofa | sergiusens, running them again | 18:29 |
| sergiusens | mvo niemeyer ogra_ slangasek I am not super happy about publishing images AT all fwiw; the work that is going to happen later with gadget and kernel will probably break these same images. I publish them only once the final sutff is done and dust has settled | 18:38 |
| ogra_ | slangasek, fully with you here :) | 18:39 |
| sergiusens | unless we can guarantee an upgrade path, I would really deprioritize | 18:39 |
| ogra_ | (that is why i brought it up in the first place) | 18:39 |
| niemeyer_ | sergiusens: Why will it break these images? | 18:39 |
| ogra_ | sergiusens, yeah, how would we guarantee that if we dont even know how the changes will look like | 18:40 |
| ogra_ | niemeyer_, the point is that we dont know if we will have any upgrade path from todays kernel/gadget at all yet | 18:40 |
| slangasek | sergiusens: this is essentially an argument for not documenting 16.04 at all until later because you don't want people to use it. That's not my call, just want to be clear about the implications | 18:41 |
| ogra_ | its isnt that we know it will break ... bt it is very likely | 18:41 |
| niemeyer_ | ogra_, sergiusens: We can name the snaps as legacy-kernel and legacy-gadget | 18:41 |
| niemeyer_ | We don't need to break the images, strictly speaking | 18:41 |
| ogra_ | niemeyer_, how does that help me to upgrade an image i install today (to use in production asap) | 18:41 |
| ogra_ | (i mean how does the renaming help) | 18:42 |
| niemeyer_ | ogra_: It helps because we can keep the old using the old | 18:42 |
| ogra_ | niemeyer_, and maintain two snaps per gadget/kernel ? | 18:43 |
| ogra_ | note that releasing a single image is over 1h of work with manual uploads and manual approval in the store today | 18:43 |
| niemeyer_ | ogra_: No.. and to be honest the goal wasn't to provide long term support for these initial images | 18:43 |
| ogra_ | right | 18:43 |
| niemeyer_ | ogra_: But rather to allow people to start playing | 18:43 |
| pedronis | also these wouldn't be meant for production either way, they are more to start getting used to the other aspects of snappy that won't change as much | 18:43 |
| ogra_ | so we shouldnt have them at all | 18:43 |
| niemeyer_ | So what is best? | 18:43 |
| ogra_ | until we can provide an upgrade path | 18:43 |
| ogra_ | if people want images they should use u-d-f and roll their own for playing | 18:44 |
| niemeyer_ | That seems a bit harsh.. | 18:44 |
| niemeyer_ | We can simply label the images as preview, and implement a mechanism that tells them when they cannot update | 18:44 |
| ogra_ | better than giving them broken stuff they can not upgrade | 18:44 |
| ogra_ | "implement a mechanism" | 18:45 |
| niemeyer_ | ogra_: Better for whom? | 18:45 |
| ogra_ | do we have time for that ? | 18:45 |
| niemeyer_ | ogra_: LOL | 18:45 |
| ogra_ | :) | 18:45 |
| niemeyer_ | ogra_: Have you seen the last two weeks? | 18:45 |
| ogra_ | yes | 18:45 |
| ogra_ | i suffered too :) | 18:45 |
| ogra_ | if i build an image using u-d-f i'll likely talk to someone before ... who tzhen tells me it will be an interim image that i can not upgrade ... | 18:46 |
| niemeyer_ | ogra_: That's not the point.. pedronis or mvo could likely implement something like that while they're having an icecream on the other hand | 18:46 |
| niemeyer_ | We just need to understand what we want | 18:46 |
| ogra_ | if i download some image from cdimage that some G+ post pointed to i wont know that | 18:46 |
| ogra_ | niemeyer_, videos or it didnt happen :P | 18:46 |
| niemeyer_ | ogra_: The fact it's labeled as "preview" tells you | 18:46 |
| ogra_ | niemeyer_, http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ | 18:47 |
| niemeyer_ | ogra_: Seriously.. I just got errors on my 16.04 upgade. Let's not pretend everything needs to be perfect or we don't ship | 18:47 |
| ogra_ | currently nothing tells me | 18:47 |
| ogra_ | but indeed we could add rthat there | 18:47 |
| ogra_ | niemeyer_, you got errors ... i only get "snap not found" for any snap i try to upgrade on an image i freshly built yesterday | 18:48 |
| niemeyer_ | The goal here is to unblock people to experiment, even if they're explicitly told the image may need reflashing once it's final | 18:48 |
| ogra_ | and i was told it wont work anyway, i need to re-do the image and re-flash | 18:48 |
| ogra_ | had i actually done any work on these images i would perhaps been pissed off now (as an enduser) | 18:48 |
| niemeyer_ | ogra_: Yep, that's part of the fun of being involved on a fast moving project | 18:49 |
| ogra_ | if we release anything this week it clearly needs to be marked alpha or pre-alpha | 18:49 |
| ogra_ | niemeyer_, sure, and i personally dont mind ... but users will | 18:49 |
| mvo | labeling it alpha is fine and I think we need to have something for people to play with | 18:50 |
| niemeyer_ | ogra_: That's one of the reasons why we don't have an image out yet.. the image you built and got snap not found was built locally, with your own udf, right? | 18:50 |
| niemeyer_ | ogra_: We want to build an image that sort of works for people to experiment with, even if we need to cook a mechanism that will blacklist it against updates when we choose to | 18:50 |
| ogra_ | niemeyer_, with the most official u-d-f ... the point is that the store changed and that the snaps in the sotre werev weeks outdated because it is a pain to release an image (as i said, took me over 1h to even upload all bits manually today) | 18:51 |
| niemeyer_ | ogra_: Oliver, you should see when they broke the API last week, just while the integration test servers stopped responding.. | 18:52 |
| ogra_ | niemeyer_, so lest do an alpha image by end of the week (have something ready tomorrow to give it to QA) | 18:52 |
| ogra_ | and very very clearly promote it as alpha everywhere | 18:52 |
| niemeyer_ | ogra_: We have the same goal.. working and stable software. Take a deep breath and please give us a hand getting there. | 18:52 |
| niemeyer_ | ogra_: Not releasing anything is not helpful towards that. | 18:52 |
| ogra_ | do i get across liek i need a deep breath ? | 18:52 |
| ogra_ | :) | 18:52 |
| niemeyer_ | ogra_: I heard you.. tomorrow will meet with mvo so we figure which caveats we want in place. | 18:52 |
| * ogra_ is totally calm :) | 18:53 | |
| ogra_ | i just want to get this sorted ... and in a way that fits us all ... | 18:53 |
| niemeyer_ | ogra_: Yep, we'll get it sorted, and will have images for people to play with. They will be experimental, and that's okay. | 18:54 |
| ogra_ | niemeyer_, one point is that whatever will finally do the image build in the infrastructure willl need to pull the build tool from the archive | 18:54 |
| ogra_ | niemeyer_, so we need to get u-d-f in ... even if it isnt finished that will at least create a smaller SRU diff | 18:54 |
| niemeyer_ | ogra_: Tomorrow, with more time and out of mvo's evening, I will meet with him and discuss how to get experimental images in place. | 18:55 |
| ogra_ | niemeyer_, and we also need to check the communication breakdown we had with http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ ... but thats something for the monday meeting | 18:55 |
| ogra_ | niemeyer_, sure | 18:55 |
| * ogra_ has been discussion with mvo all wee on that topic :) all this just got triggered by images showing up on cdimage out of the blue and nobody knowing why :) | 18:56 | |
| ogra_ | *discussing | 18:56 |
| niemeyer_ | ogra_: Yep, I know, and your input is appreciated. | 18:56 |
| ogra_ | :) | 18:56 |
| niemeyer_ | and sergiusens's | 18:56 |
| niemeyer_ | ogra_: We'll be more careful as a side effect. | 18:56 |
| niemeyer_ | ogra_, sergiusens: For the record, we already have a mechanism in place, today, that enables us to ship snaps that will refuse to work on an old revision of ubuntu-core. | 18:57 |
| niemeyer_ | Forcing ubuntu-core itself to be updated first | 18:58 |
| ogra_ | niemeyer_, well, but thats indeed requires ubuntu-core to be upgradeable :) | 18:58 |
| ogra_ | which is todays issue | 18:58 |
| niemeyer_ | ogra_: and it isn't!? | 18:58 |
| ogra_ | (or was ... tomorrows images will now work) | 18:58 |
| ogra_ | niemeyer_, not when buuilding from yesterdays snaps in the store | 18:59 |
| ogra_ | i pushed a complete set of snaps today ... so now that should work | 18:59 |
| niemeyer_ | ogra_: Because we decided to change the series while coordinating the store team, the 16.04 release team, and the snappy core team..? | 18:59 |
| niemeyer_ | ogra_: This wasn't made out of the blue..? | 18:59 |
| ogra_ | right ... so snap list and snap find show you upgardeable snaps but snap refresh ends up with "no snaps foound" | 19:00 |
| niemeyer_ | ogra_: So if you say "snap refresh ubuntu-core" on the snapd that is being shipped with 16.04, what happens? | 19:00 |
| ogra_ | niemeyer_, well, nothing of that seemed to be known by anyone when i first asked about the "no snaps found" issue here | 19:01 |
| ogra_ | niemeyer_, you mean on a desktop ? | 19:01 |
| ogra_ | lets see ... i havent upgraded my desktop in a few days now ... | 19:01 |
| ogra_ | ogra@styx:~/all-snaps$ sudo snap refresh ubuntu-core | 19:02 |
| ogra_ | [sudo] Passwort für ogra: | 19:02 |
| ogra_ | error: can't refresh "ubuntu-core": snap "ubuntu-core" has changes in progress | 19:02 |
| ogra_ | ogra@styx:~/all-snaps$ | 19:02 |
| niemeyer_ | ogra_: I mean on the 16.04 image that is being released tomorrow.. or the equivalent snapd 2.0.2 that is being shipped with it | 19:02 |
| ogra_ | thats what i get on my system that i upgraded to 16.04 on sat. | 19:02 |
| niemeyer_ | ogra_: That won't work.. you need to start with 2.0.2 | 19:02 |
| niemeyer_ | ogra_: Or clean your old state | 19:02 |
| ogra_ | niemeyer_, i have to fill some MIRs first, but i can test an image later ... seemingly there are more store changes needed according to the backlog | 19:03 |
| ogra_ | (which will also require a complete re-upload of all snaps we use ) | 19:03 |
| niemeyer_ | ogra_: Possibly, but the point is that there's no reason why refreshing ubuntu-core would not work work | 19:03 |
| === pat_ is now known as pmcgowan | ||
| ogra_ | well, i need to build a complete image ... that takes time i dont have atm ... the one i run from yeterday isnt upgardeable | 19:04 |
| ogra_ | (simply because ubuntu-core in the store had 1.9.x in it til today) | 19:05 |
| sergiusens | niemeyer ogra_ I'm ok with an image released as long as there is some upgrade path or some way to get the latest kernel and gadget snaps in the future. Also marking it as not production ready somewhere so people trying it are crystal clear on what they are getting into | 19:05 |
| * sergiusens dropped a bombed 30 minutes ago and left for lunch | 19:06 | |
| sergiusens | I won't do that next time :-) | 19:06 |
| ogra_ | heh | 19:06 |
| ogra_ | do what you need ... thats the baeuty of IRC ... it is asycnronous :) | 19:06 |
| niemeyer_ | sergiusens: There may not be an upgrade path.. we can look into that, but we won't stop releasing an experimental image for people to try it out just because we may have to ask them to reflash. | 19:06 |
| ogra_ | *beauty | 19:06 |
| niemeyer_ | Yeah, and the other beauty is that you may just loggout so you can claim you didn't read the log | 19:07 |
| ogra_ | i dont think the point is releasing experimental ones ... but releasing experimental ones under an official release url | 19:07 |
| ogra_ | which we did | 19:07 |
| niemeyer_ | Sure, too bad.. let's take it down as they shouldn't be there.. no sweat | 19:07 |
| ogra_ | exactly | 19:08 |
| niemeyer_ | Let's then cook something we're happy with, label it as experimental, and do put it there because we want people to try it out | 19:08 |
| sergiusens | niemeyer_ oh, I don't mind reflashing; I just want people using it to know before hand :-) | 19:08 |
| niemeyer_ | Of course | 19:08 |
| ogra_ | +1 | 19:08 |
| niemeyer_ | "preview" | 19:09 |
| sergiusens | niemeyer_ ogra_ wrt logs and irc; I can also claim a network error and since you get no ack can't prove I read it or not :-P | 19:09 |
| * sergiusens knows how to play dumb ;-) | 19:09 | |
| ogra_ | niemeyer_, the prob is now that the released images were put into place because someone (dholbach) updated or wanted to update the docs to point to them | 19:09 |
| niemeyer_ | All good.. we'll get that fixed.. | 19:09 |
| ogra_ | i dont know if any docs were changed ... so i dont feel comfortable to just wipe the dir on cdimage | 19:09 |
| niemeyer_ | ogra_: Just wipe it.. it's better than having people using something bad | 19:10 |
| ogra_ | ok | 19:10 |
| niemeyer_ | ogra_: We can then catch up with Daniel to fix doc, and politely respond to any reports | 19:10 |
| ogra_ | yeah, and we need to talk to olli to actually coordinate such stuff instead of pinging slangasek directly :) | 19:11 |
| ogra_ | but as i said, thats something for monday | 19:11 |
| niemeyer_ | ogra_: .. and finally re-release the image we do want and understand the caveats, and release docs with it mentioning those caveats | 19:11 |
| niemeyer_ | Yep | 19:11 |
| ogra_ | yup | 19:11 |
| niemeyer_ | Anyway, need to step out.. | 19:11 |
| niemeyer_ | talk soon | 19:11 |
| ogra_ | slangasek, FYI i wiped the subdirs under http://cdimage.ubuntu.com/ubuntu-snappy/daily/ now | 19:18 |
| zyga | dpm: re | 19:18 |
| ogra_ | til we have some usanble image | 19:18 |
| ogra_ | *usable | 19:19 |
| dpm | zyga, all sorted now, thanks :) I just wanted to confirm that a) the 'home' interface is not autoconnected (it's not) and b) how to manually connect it (done it now) | 19:19 |
| zyga | :D | 19:19 |
| dpm | :) | 19:20 |
| zyga | dpm: cool, both confirmed :) | 19:20 |
| zyga | dpm: what did you make that requires home? | 19:20 |
| dpm | zyga, http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/youtube-dl/ | 19:20 |
| dpm | oh, I haven't pushed yet, just a sec | 19:21 |
| dpm | zyga, ok, the branch should now be up-to-date | 19:21 |
| dpm | davidcalle, ^^ | 19:21 |
| zyga | nice! | 19:22 |
| zyga | I hope that over time we can create more fine-tuned interfaces | 19:22 |
| zyga | specifically those that give a slice of home | 19:22 |
| zyga | e.g. home with some attributes that specify, e.g. the XDG music directory for media player | 19:22 |
| popey | sergiusens: do you know how my desktop app snapped can use/see /var/cache/fontconfig and udev stuff (for access to enumerate input devices)? | 19:25 |
| zyga | popey: which udev stuff? | 19:26 |
| zyga | popey: the answer is *interfaces* | 19:26 |
| popey | zyga: http://paste.ubuntu.com/15936638/ | 19:27 |
| zyga | popey: use unity7 to get /var/cache/fontconfig | 19:27 |
| popey | i have specified unity7 | 19:28 |
| zyga | #include <abstractions/fonts> | 19:28 |
| zyga | /var/cache/fontconfig/ r, | 19:28 |
| zyga | /var/cache/fontconfig/** mr, | 19:28 |
| popey | http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/view/head:/mame/mamedeb/snapcraft.yaml | 19:28 |
| zyga | that's unity7, you can confirm you have that by looking at /var/lib/snapd/apparmor/profiles/snap.mame.run | 19:28 |
| zyga | popey: FYI I'd suggest naming the main app in a snap after the snap | 19:28 |
| zyga | popey: then the executable on path is a nice short "mame", not "mame.run" | 19:29 |
| sergiusens | zyga popey you have to maybe get the difference between Ubuntu and Ubuntu Core | 19:29 |
| zyga | popey: why does mame want to chmod [180438.835798] audit: type=1400 audit(1461075883.106:144): apparmor="DENIED" operation="chmod" profile="snap.mame.run" name="/var/cache/fontconfig/" pid=2174 comm="mame" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0 | 19:29 |
| sergiusens | is /var/cache/fontconfig/ Ubuntu's or Ubuntu Core's? | 19:29 |
| zyga | sergiusens: there is no difference | 19:29 |
| ogra_ | zyga, doesnt that then come out as mame.mame (it used to in the past) | 19:30 |
| sergiusens | zyga really? | 19:30 |
| zyga | ogra_: no, now that will be just "mame" | 19:30 |
| ogra_ | yay | 19:30 |
| popey | ok, will simplify that | 19:30 |
| zyga | sergiusens: interfaces work the same way everywhere | 19:30 |
| ogra_ | since when is that ? | 19:30 |
| popey | one thing at a time :) | 19:30 |
| zyga | ogra_: we talked about it half a year ago, it happened like 6 weeks ago | 19:30 |
| ogra_ | cool | 19:30 |
| zyga | popey: you know about --devmode, right? | 19:30 |
| zyga | ogra_: yes, it gives apps a nice CLI UX | 19:31 |
| * ogra_ is still waiting for snap config to re-appear ... sadly my snaps are useless without it | 19:31 | |
| ogra_ | so i didnt touch snaps in recent times | 19:31 |
| popey | zyga: no | 19:31 |
| zyga | popey: remove your snap and install with --devmode | 19:31 |
| sergiusens | zyga try and snap a gtk app then come back ;-) | 19:31 |
| zyga | ogra_: config is coming back soon, muuuch better | 19:31 |
| ogra_ | as long as i can port my stuff :) | 19:32 |
| * ogra_ liked the old implementation actually :) | 19:32 | |
| zyga | sergiusens: what do you mean? | 19:33 |
| zyga | sergiusens: I miss pulseaudio interface, I'll add one locally for games | 19:33 |
| zyga | ogra_: it will be easier on snaps to handle | 19:33 |
| ogra_ | well, i handle it through shell scripts ... as long as i can go on doing that i'm fine | 19:34 |
| zyga | ogra_: it will be _far_ easier to handle, especially in shell scripts | 19:34 |
| ogra_ | (read: please keep it flexible on the programmers side) | 19:34 |
| qengho | ogra_: "activate" too! | 19:35 |
| popey | zyga: what does devmode do? | 19:38 |
| ogra_ | it calls a developer ... | 19:38 |
| ogra_ | :) | 19:38 |
| qengho | Makes apparmor warn instead of block. Probably something with seccomp too. | 19:38 |
| ogra_ | (listen for your doorbell) | 19:39 |
| popey | hm, still barfs | 19:39 |
| popey | FATALERROR: Unable to load opengl library: <default> | 19:39 |
| popey | http://paste.ubuntu.com/15936814/ http://paste.ubuntu.com/15936827/ | 19:40 |
| qengho | Are there any interface docs? I don't understand them yet. | 19:43 |
| ogra_ | qengho, we need to attach a printer to zyga's brain | 19:45 |
| zyga | popey: installs the snap with non-enforcing confinement for figuring out missing interfaces | 19:45 |
| zyga | qengho: I'm wrinting one now | 19:45 |
| zyga | qengho: the first will go live todayt | 19:45 |
| zyga | popey: did you use the opengl interface? | 19:46 |
| popey | zyga: plugs: [network, network-bind, unity7, opengl] | 19:47 |
| popey | like that? | 19:47 |
| zyga | popey: yep | 19:47 |
| popey | yes then :) | 19:47 |
| zyga | popey: does mame need network? | 19:47 |
| popey | no | 19:47 |
| zyga | popey: does it work in devmode? (I assume it doesn't) | 19:47 |
| zyga | popey: with devmode you have no security blockers | 19:48 |
| popey | no | 19:48 |
| zyga | popey: if it doesn't work it's broken in some other way | 19:48 |
| popey | yeah, the opengl thing looks to be the main issue now | 19:54 |
| zyga | popey: before you report it, which gpu do you have? | 19:54 |
| popey | intel | 19:54 |
| nessita | ogra_, release 16 is ready in the store | 20:04 |
| sergiusens | elopio this is what you want https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/internal/meta.py#L215 | 20:05 |
| elopio | kyrofa: pexepect.expect takes a pattern | 20:06 |
| elopio | sergiusens: thank you | 20:06 |
| kyrofa | elopio, yeah and it seems strings get turned into regex as well-- works great, thanks :) | 20:06 |
| zyga | popey: does mame work on your desktop normally? | 20:13 |
| zyga | popey: as a last hint, add a 2nd app (mame.sh) that runs /bin/sh and see how the libs you get in the snap differ from what you get on the outside | 20:13 |
| kyrofa | sergiusens, elopio you guys should give the colors a run on an example to make sure you like them-- several to choose from | 20:21 |
| elopio | dpm: can you give me a link to your qt calculator snap? | 20:22 |
| dpm | elopio, https://launchpad.net/~dpm/+snap/ubuntu-calculator-app | 20:25 |
| elopio | dpm: ty | 20:26 |
| popey | zyga: yes, mame works normally | 20:31 |
| popey | zyga: in fact if I manually run the executable exactly from the snap, but not via the snap ubuntu app launcher, it works | 20:31 |
| popey | it's only when launched via the snap ubuntu app launcher it fails | 20:31 |
| qengho | popey: I get that too. | 20:33 |
| zyga | popey: does it really fail because of the app launcher? there's also the extra environment | 20:34 |
| zyga | popey: (which changes path resolution and libraies) | 20:34 |
| niemeyer_ | popey: Do we have a mame snap working confined already? | 20:35 |
| niemeyer_ | popey: (sorry, didn't track the conversation) | 20:35 |
| popey | niemeyer_: that's what I'm working on | 20:35 |
| niemeyer_ | popey: Sweet | 20:36 |
| popey | zyga: well, without the snap environment it works | 20:36 |
| zyga | popey: right, I'm sorry, I'm trying to figure out what makes it not work | 20:37 |
| qengho | Has anyone hit a limit on number of loop devices yet? | 20:37 |
| popey | heheh, I wondered when someone would ask that qengho :) | 20:38 |
| zyga | qengho: hmm, no? | 20:39 |
| zyga | qengho: when doing what? | 20:39 |
| qengho | zyga: Adding packages. Last I recall, the default limit is something like 2**8. If I have 50 packages, I think a few months of version churn should hit that limit. | 20:41 |
| zyga | qengho: snap recycles | 20:41 |
| zyga | qengho: when you sideload that doesn't perhaps happen but store installs/refreshes will recycle | 20:42 |
| zyga | qengho: so you shound't hit the limt | 20:42 |
| * popey makes a note of this day | 20:43 | |
| qengho | Oh good. | 20:44 |
| qengho | I think the limit is pretty arbitrary so the snapd package could change it. | 20:45 |
| popey | zyga: https://www.youtube.com/watch?v=xqIu4gJa1jA showing where I am | 20:46 |
| popey | sorry the bit that shows what happens is at ~1m10s in | 20:48 |
| zyga | popey: interesting | 20:48 |
| zyga | popey: I don't understand that apparmor denial at the end | 20:49 |
| zyga | popey: is that with or without --devmode? | 20:49 |
| popey | with | 20:49 |
| zyga | hmm | 20:49 |
| zyga | something for us to investigate | 20:49 |
| zyga | right now I have no idea | 20:49 |
| popey | seems to be the opengl thing | 20:49 |
| zyga | popey: yes but the denial should not be there in the first place | 20:50 |
| zyga | popey: how big is your snap? | 20:50 |
| popey | -rw-r--r-- 1 alan alan 47M Apr 19 20:35 mame_0.160_amd64.snap | 20:50 |
| zyga | popey: I'll check that out tomorrow | 20:50 |
| zyga | popey: I'll finish writin an article and EOD | 20:51 |
| popey | kk thanks for the help zyga | 20:51 |
| kyrofa | Alright sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/474 is green | 20:57 |
| kyrofa | Have you guys played with it at all? | 20:57 |
| sergiusens | kyrofa I have | 21:01 |
| sergiusens | kyrofa in some future a --no-colors or --no-colours option would be good | 21:01 |
| sergiusens | kyrofa elopio also https://github.com/ubuntu-core/snapcraft/pull/475 | 21:01 |
| kyrofa | sergiusens, easy to add | 21:02 |
| sergiusens | kyrofa the debate is on how to write colour ;-) | 21:05 |
| kyrofa | sergiusens, or support both :P | 21:05 |
| qengho | sergiusens: ... |cat | 21:05 |
| === chihchun is now known as chihchun_afk | ||
| mvo | ogra_: new u-d-f uploaded, new 16 series is there, I push a new amd64 image now and will continue with the other arches tomorrow but it looks very promising (fingers crossed and all that) | 21:26 |
| mvo | ogra_: http://people.canonical.com/~mvo/all-snaps/ has new amd64 image and new u-d-f if anyone wants to give it a go | 21:32 |
| mvo | latest snappy, using the new 16 series in the store | 21:32 |
| zyga | qengho: hey | 22:57 |
| zyga | qengho: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html | 22:58 |
| sergiusens | elopio kyrofa from what I read somewhere else matiasb seems to be hinting we will need macaroon support to upload/register using snapcraft; we should take a minute or two to analyze vila's PR tonight if possible | 23:30 |
| sergiusens | nessita hey, a little bird told me you can migrate packages to 16; would you mind migrating `shout`? | 23:32 |
| sergiusens | ubottu hey | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
