[00:40] <liuxg> does anyone know how to use snapweb?
[02:01] <mup> PR snapd#1969 opened: Update HACKING.md <Created by niedbalski> <https://github.com/snapcore/snapd/pull/1969>
[02:24] <mup> Bug #1626359 opened: Cannot authorise quotactl syscall <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1626359>
[03:09] <mup> PR snapd#1970 opened: Adds ptrace capabilities to the system_trace interface <Created by niedbalski> <https://github.com/snapcore/snapd/pull/1970>
[03:31] <tachyons> How do I replicate same error message in snap store in local snap review ?
[03:32] <tachyons> In automated review in store , I got follwing error
[03:32] <tachyons> package contains external symlinks: gems/ruby-2.3.1@global, rubies/default lint-snap-v2_external_symlinks
[03:32] <tachyons>  0 Warnings
[03:32] <tachyons>  31 Passes
[03:32] <tachyons> But this error is not appearing in local when I run snap review
[03:47] <elopio> tachyons: install click-reviewers-tools, and then run click-review
[03:47] <tachyons> elopio: already done , But this error is not coming in my local system
[03:48] <elopio> tachyons: then probably the reviewers tool used in the store is not the same version
[03:49] <elopio> tachyons: I think that error means that in your snap you have a symlink to a path outside.
[03:49] <tachyons> elopio: which version should I try , I tried the version in 16.04 as well as trunk in bzr
[03:49] <elopio> you can ls -l in the prime directory to search for the links.
[03:50] <elopio> tachyons: I don't know what's the right version.
[03:51] <tachyons> elopio: yes there are symlinks , but those are not outside snap package
[03:51] <elopio> tachyons: can you paste the ls -l of those two files?
[03:54] <tachyons> wait
[03:54] <tachyons> total 8
[03:54] <tachyons> lrwxrwxrwx 3 tachyons tachyons   86 Sep 21 21:02 default -> /home/tachyons/projects/snappy-playpen/hello-ruby/parts/ruby/install/rubies/ruby-2.3.1
[03:54] <tachyons> drwxrwxr-x 6 tachyons tachyons 4096 Sep 21 21:03 ruby-2.3.1
[03:55] <tachyons> default is symlinked to ruby-2.3.1
[03:57] <tachyons> elopio: Is that fine ?
[03:59] <elopio> tachyons: I think it should be a relative path, not an absolute one.
[03:59] <elopio> when you mount that snap in a system, it will try to find /home/tachyons.
[04:01] <tachyons> elopio: Means I have to write a script to convert absolute path to relative path in build script?
[04:02] <elopio> tachyons: yes. Some other plugins are probably doing the same, but kyrofa is our link man and he's EOD.
[04:02] <elopio> you can send an email to the list.
[04:03] <tachyons> EOD means?
[04:04] <elopio> end-of-day. He's sleeping.
[04:07] <mup> PR snapd#1971 opened: interfaces/builtin: add rcvfrom for client connected plugs to mir interface <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1971>
[04:09] <tachyons> elopio: Thanks , https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L120 Is this what you meant ?
[04:10] <tachyons> I don't have much idea about python stuff
[04:11] <elopio> tachyons: more like this, I think: https://github.com/snapcore/snapcraft/blob/97742500ac64d44f9251983a7ac93b128901fdfa/snapcraft/plugins/dump.py#L62
[04:12] <elopio> I don't have much idea of this part of snapcraf.t
[04:15] <tachyons> elopio: Thanks :-) , Let me try
[04:40] <mup> Bug #1598657 changed: No error id for username/password error returned from snapd <Snappy:Fix Released by chipaca> <gnome-software (Ubuntu):Fix Released> <https://launchpad.net/bugs/1598657>
[05:51] <mup> PR snapd#1969 closed: Update HACKING.md <Created by niedbalski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1969>
[06:12] <mup> PR snapd#1972 opened: tests: increase timeout for key generation in create-key test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1972>
[06:37] <dholbach> good morning
[06:55] <zyga> good morning
[08:07] <mvo> ogra_: good news everyone! we have what lookds like a working "loadkeys"
[08:15] <tachyons> elopio: Thanks , it is working for files , but directories are not being copied correctly
[08:15] <tachyons> It shows empty directory instead
[08:18] <mvo> ogra_: total cost is ~3mb it seems, not great, not too terrible either
[08:28] <didrocks> mvo: hey, have you seen fgimenez's issue today? It seems that $HOME isn't anymore $SNAP_USER_DATA, but real $HOME, am I correct?
[08:29] <didrocks> (maybe when people adds the home plug?)
[08:32] <mvo> didrocks: I did not see that, that sounds like a regression
[08:33] <didrocks> mvo: yeah, I guess fgimenez can show you an easy reproducer
[08:33] <didrocks> (desktop-launch is using ~/.something) and ~ is expanded to /home/<user>/
[08:34] <fgimenez> didrocks, mvo yep, is in the test snap used in this in progress branch https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, the commands try to open files on ~/
[08:35] <mvo> fgimenez: is that with master?
[08:35] <didrocks> mvo: I did get the issue on a released snapd version on my side
[08:35] <mvo> didrocks: what version?
[08:36] <didrocks> mvo: ah, sorry, I'm wrong, I still have your ppa version :)
[08:36] <didrocks> snapd   2.14.2~16.04+ppa227-1
[08:36] <didrocks> the one with revert --devmode
[08:36] <mvo> didrocks, fgimenez: https://github.com/snapcore/snapd/blob/master/snap/snapenv/snapenv.go#L91 looks correct, let me add a spread test
[08:37] <didrocks> mvo: so, basically, we have here: command: desktop-launch <something>
[08:37] <didrocks> and desktop-launch is doing cat ~/.something
[08:37] <didrocks> and we can see (with the home slot plugged, don't know without that), that ~ is expanded to /home/user
[08:42] <ogra_> mvo, hmm, thats a lot, but you didnt use the d-i bits, right ? just the normal desktop packages
[08:42] <ogra_> i guess using the bits from the udeb would be a lot less
[08:43] <mvo> ogra_: yeah, just the regular packages
[08:43] <mup> PR snapd#1973 opened: tests: ensure HOME is also set correctly <Created by mvo5> <https://github.com/snapcore/snapd/pull/1973>
[08:44] <mvo> didrocks: -^ for you
[08:45] <didrocks> fgimenez: ^
[08:45] <didrocks> mvo: don't you think we could have some special expansion as the use case is slightly different (~ expansion from a command line application wrapped, but started from another shell?)
[08:46] <fgimenez> mvo, didrocks cool thanks a lot
[08:49] <fgimenez> didrocks, in the previous version of the test snap we were exporting HOME and pointing it to SNAP_USER_DATA in the launcher script https://github.com/snapcore/snapd/commit/358fcd544b059fc864cef93af67e7d1e7c3be40c#diff-e2c74cafe2ea8aff71bac730ee1bf0f9R10, wouldn't that have the same effect as HOME being set up from snapd?
[08:49] <mvo> ogra_: hm, just had a quick look, killing python would be huge if we want to reduce the size
[08:50] <mvo> ogra_: vim.tiny is also 1mb, systemd-analyize, perl
[08:50] <didrocks> fgimenez: yeah, but that's not needed, mvo confirms that HOME should already point to SNAP_USER_DATA
[08:50] <morphis__> mvo, ogra_: did you guys release a new beta OS snap?
[08:50] <didrocks> but as we are using ~ expansion, I really wonder if the mvo's test makes sense
[08:50] <ogra_> morphis__, not that i'm aware
[08:50] <morphis__> mvo, ogra_: saw it changing from 526 to 658
[08:51] <mup> PR snapd#1974 opened: snapd: kmod backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/1974>
[08:51] <ogra_> mvo, killing python would get us 10MB snaps :P
[08:51] <didrocks> zyga: see you are approving, but did you read above? ^
[08:51] <ogra_> (yes, i'm exaggerating ... but it would freee a lot)
[08:51] <mvo> ogra_: I think we can kill libstdc++6 from the image, its only needed by apt afaik
[08:52] <morphis__> ogra_: snap prepare-image --channel beta .. gives me 658 now where edge has 695
[08:52] <mvo> ogra_: hm, no, sorry
[08:52] <mvo> ogra_: silly me, we would still have to include it for classic
[08:52] <ogra_> yeah
[08:53] <mvo> ogra_: /usr/share/local/* might be worth a shot
[08:54] <morphis__> mvo, ogra_: any a snap refresh --beta ubuntu-core on my desktop gives me 660
[08:54] <mvo> morphis__: same architecture?
[08:55] <ogra_> mvo, we purge the lcle package at the end of the build
[08:55] <ogra_> *locale
[08:55] <ogra_> that should only be empty dirs
[08:55] <ogra_> ugh
[08:56] <morphis__> mvo: ah right
[08:56]  * ogra_ shakes fist at maintainer scripts
[08:56] <morphis__> mvo: but that still doesn't explain why the armhf one goes from 526 to 658
[08:56] <ogra_> ogra@bbb:~$ du -hcs /usr/share/locale/
[08:56] <ogra_> 7.2M	/usr/share/locale/
[08:56] <ogra_> woah
[08:57] <morphis__> mvo: can you check in the store what should be the latest for the beta channel?
[08:58]  * ogra_ is just looking
[08:58] <ogra_> 656-661 are in bet
[08:58] <ogra_> a
[08:58] <morphis__> beginning of last week I got 526 and now 658
[08:59] <morphis__> ogra_: you see when they were published?
[09:00] <ogra_> well, i didnt release anything to beta ... regarding the date ... http://people.canonical.com/~ogra/ubuntu-core-builds/ (unless they were mnul builds they will show up theere)
[09:01] <mup> PR snapd#1975 opened: tests: add test benchmark script <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1975>
[09:01] <ogra_> hmm, looks like thery were manual :/
[09:01] <ogra_> but i'd say 19th
[09:01] <ogra_> yeah, the store says "2016-09-19 12:25 - 2 days, 20 hours ago"
[09:01] <morphis__> ogra_: wait, we released an upgrade beta snap after the beta announcement?
[09:02] <ogra_> ask mvo ... he handles the beta releases ... but why wouldnt we
[09:02] <morphis__> ogra_: as it breaks stuff
[09:03] <ogra_> well, thts indeed bad, but there is no reason to not release  beta if it doesnt :)
[09:03] <ogra_> whaat does it break ?
[09:04] <morphis__> ogra_: there is no reason against that but you easily miss that if you nowhere get an announcement for that or so
[09:04] <morphis__> ogra_: however, console-conf seems to be updated and now doesn't work anymore with our manually put in place ifupdown config
[09:05] <morphis__> mwhudson: ping
[09:05] <ogra_> oh ? are you sure ?
[09:05] <ogra_> you mean you define a fixed IP and dont get that IP ?
[09:06] <ogra_> or what does not work ?
[09:06] <ogra_> (note that the device comes up automatically before console-conf ... systemd-networkd default to try DHCP)
[09:06] <ogra_> *defaults
[09:06] <morphis__> ogra_: address assignment works well, the box gets the IP via dhcp and is manged by ifupdwon but console conf still complains that "network cofngiuration failed"
[09:07] <morphis__> it shows the detected IP configuration which ifupdown put in place
[09:07] <morphis__> ogra_: no networkd here,
[09:07] <mvo> morphis__: it breaks stuff?
[09:08] <morphis__> mvo: console-conf has a regression somewhere
[09:09] <mvo> morphis__: right, thats (obviously) bad did you talk to mwhudson about it yet?
[09:09] <morphis__> and actually I was expecting beta to stay the same until we have the next announcement for an updated beta release or so
[09:09] <morphis__> mvo: just ping'ed him
[09:09] <mwhudson> hi
[09:10] <mvo> morphis__: there was an anncounement: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html
[09:10] <morphis__> oh ...
[09:10] <morphis__> my bad then that I missed that .. sorry :-)
[09:11] <mvo> no worries
[09:11] <morphis__> mwhudson: hey!
[09:11] <mwhudson> er is it possible to figure out the console-conf versions in the good and bad versions?
[09:11] <morphis__> mwhudson: let me first explain the problem I see right now
[09:12] <mvo> morphis__: I'm keen to learn more why this makes you concerned. it seems the fact that we spot the regression is a reaosn to release betas more often so that we find the bugs sooner (rather than later). but lets talk after the console-conf issue got debugged
[09:12] <morphis__> mvo: my only conern was because I missed the announcement
[09:12] <morphis__> so releasing to beta more often to fix bugs is fine for me
[09:13] <morphis__> mwhudson: so the problem I have right now is the following:
[09:13] <morphis__> mwhudson: we can't really use networkd here as it just fails badly on our 3.4 kernel
[09:13] <morphis__> mwhudson: to workaround this (its just a proof-of-concept) we put a config file into /etc/network/interfaces.d which configures the ethernet port via dhcp
[09:14] <mwhudson> morphis__: 3.4!!
[09:14] <morphis__> mwhudson: with the previous beta release console-conf was ok with accepting whatever ifupdown assigned to the interface and just let us go through the process
[09:15] <morphis__> mwhudson: now with the second beta release it shows the IP address ifupdown assigned but fails with "Network configuration failed; please verify your settings" when trying to proceed with the wizard
[09:15] <morphis__> mwhudson: yeah, 3.4
[09:16] <mwhudson> morphis__: ok, hm, so i'm not really sure why that would have changed, but i can't remember how old the old beta was
[09:16] <mwhudson> morphis__: can you get at the logs by pulling an sd card or activating a debug shell or something?
[09:16] <morphis__> mwhudson: yes, I am already doing that
[09:17] <mwhudson> morphis__: pastebin /var/log/console-conf/subiquity-debug.log pls
[09:17] <mwhudson> (filename might not be quite right)
[09:18] <morphis__> mwhudson: hm, there is no console-conf log
[09:19] <mwhudson> morphis__: nothing in /var/log/console-conf at all?
[09:19] <morphis__> nothing
[09:19] <mwhudson> special
[09:19] <morphis__> https://paste.ubuntu.com/23215029/
[09:19] <mwhudson> morphis__: initramfs?
[09:19] <morphis__> yeah, can't get into the system otherwise
[09:19] <mwhudson> oh right
[09:20] <morphis__> this is flashed on the internal flash memory
[09:20] <mwhudson> that doesn't look like a system that's booted a snappy image?
[09:20] <mwhudson> does it?
[09:20] <mwhudson> maybe, i can't remember how all this works
[09:21] <morphis__> ah
[09:21] <morphis__> mwhudson: my fault, found the log file
[09:21] <mwhudson> morphis__: isn't it going to be /root/writable/system-data/... or something?
[09:21] <morphis__> https://paste.ubuntu.com/23215037/
[09:22] <morphis__> 09/22 09:10 subiquitycore.utils:130 run_command returning: {'err': 'Error in network definition //etc/netplan/00-snapd-confi
[09:22] <morphis__> g.yaml line 9 column 6: p2p0: No access points defined\n', 'status': 1, 'output': ''}
[09:22] <mwhudson> oh
[09:22] <mwhudson> i've fixed that bug
[09:22] <mwhudson> morphis__: can you try edge ubuntu-core?
[09:22] <morphis__> so console-conf does not put any configuration in place and then netplan fails to apply that
[09:22] <morphis__> mwhudson: sure
[09:23] <mwhudson> i misunderstood a bit what netplan accepted
[09:24] <mup> PR snapd#1944 closed: many: validate refreshes against validation assertions by gating snaps <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1944>
[09:24] <morphis__> mwhudson: ah :-)
[09:24] <morphis__> mwhudson: and another one where I saw a crash of netplan: https://paste.ubuntu.com/23215041/
[09:26] <mwhudson> morphis__: looks like the same thing on first blush
[09:27] <morphis__> mwhudson: see the: AttributeError: 'BackgroundProcess' object has no attribute 'proc'
[09:28] <mwhudson> morphis__: oh, i fixed that too
[09:28] <mwhudson> (without really understanding it :/)
[09:28] <morphis__> great :-)
[09:28] <morphis__> lets see how edge goes
[09:30] <morphis__> mwhudson: ah, works again!
[09:31] <mwhudson> morphis__: hooray, sorry for the bugs
[09:33] <morphis__> mwhudson: no problem :-)
[09:35] <mup> PR snapd#1976 opened: tests: skip some tests on non-amd64 architectures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1976>
[09:36] <morphis__> mvo: is there an easy way how I can programatically determine the OS snap revision in a channel?
[09:37] <morphis__> mvo: or via the snap command
[09:40] <ogra_> only the installed snap version
[09:41] <ogra_> and for the non-manually built snaps you can look up the info at http://people.canonical.com/~ogra/ubuntu-core-builds/
[09:41] <ogra_> (i havent added manifests and changelogs yet ... that a weekend project)
[09:41] <ogra_> *that's
[09:42] <morphis__> :-)
[09:42] <pedronis> morphis__: there's no command for that atm, you can query the store directly though
[09:42] <morphis__> looks like I can abuse snap download --edge ubuntu-core for that
[09:43] <morphis__> pedronis: you have a link to the store API?
[09:43] <ogra_> i think you can also just check for upgradeability ...
[09:43] <pedronis> morphis__: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Details
[09:43] <morphis__> thanks
[09:44] <ogra_> snap refresh --list
[09:44] <ogra_> that shows if there is a newer core
[09:45] <ogra_> "snap refresh --list --beta" actually :)
[09:46] <pedronis> --list doesn't take channels atm
[09:46] <pedronis> I think
[09:47] <ogra_> ogra@bbb:~$ snap refresh --beta --list
[09:47] <ogra_> error: --list does not take mode nor channel flags
[09:47] <ogra_> yeap ... looks like you know the error msg :)
[09:48] <pedronis> morphis__: something like this:  curl -H "X-Ubuntu-Series: 16" -H "X-Ubuntu-Architecture: amd64" https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=edge
[09:48] <ogra_> but if the image is baseed on beta it will show the beta channel snaps i suppose
[09:48] <morphis__> pedronis: thanks!
[09:49] <pedronis> ogra_: yes
[09:49] <pedronis> is just that if things are up-to-date
[09:49] <pedronis> it will just say they are up to date
[09:49] <ogra_> yeah
[09:50] <ogra_> but you could turn off auto-refresh ... and then have a script to check with the above command before you decide to upgrade
[09:51] <ogra_> (and first look up the changelog before you decide upgrdaing wont break your hacked up setup ;) )
[09:52] <ogra_> thats probably better than having it auto-refresh over night and being greeted with a bricked device :)
[10:04] <mup> PR snapd#1972 closed: tests: increase timeout for key generation in create-key test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1972>
[10:14] <pitti> ogra_: did you strace -tt console-conf --help? does python3 --help also take that long?
[10:14] <pitti> ogra_: i. e. is that really just python itself, or something specific to console-conf?
[10:14] <pitti> (some expensive import or what not)
[10:14] <ogra_> pitti, sorry, i had a ton of distracting things today, u'll get to the strase soon
[10:14] <pitti> I cannot imagine that python takes an effing 20 seconds to start -- the hardware can't be *that* slow
[10:15] <ogra_> *i'll get to the strace ...
[10:15] <pitti> ogra_: no hurry, just overheard it on the ML
[10:15] <pitti> it was more like curiosity/disbelief
[10:15] <pitti> I cannot imagine that this can just  be attributed to hw slowness; there must be some bug somewhere
[10:15] <pitti> maybe the RNG hits again :)
[10:16] <ogra_> pitti, it has always been like that on embedded arm if you say python in a channel wheer mebedded people work you get laughed at ... single core arm and python have never gone well together
[10:16]  * pitti saw several long startup delays due to that recently, like bug 1622893
[10:16] <mup> Bug #1622893: NetworkManager takes very long to start, or times out, blocked on RNG <amd64> <apport-bug> <bootspeed> <regression-release> <yakkety> <Auto Package Testing:Fix Released by pitti> <gnutls28 (Ubuntu):Triaged> <network-manager (Ubuntu):New> <https://launchpad.net/bugs/1622893>
[10:17] <pitti> ogra_: well, we've run apport on arm stuff for a long time, and while that's certainly expensive, it didnt take multiple seconds to start..
[10:17] <ogra_> (this is why micropython exists)
[10:18] <ogra_> pitti, we have always disable apport on devices like this ... we use apport on desktop class devices like phones, sure ... but on the old arm images it has always been disabled
[10:18] <ogra_> (we never ran long-running python processes on the arm devboard images)
[10:19] <ogra_> technically what we'd want would be https://micropython.org/ packaged in ubuntu-core ... instead of python3
[10:25] <ppisati> where can i open a bug against ubuntu-image?
[10:25] <ogra_> https://bugs.launchpad.net/ubuntu-image
[10:35] <frederikkunze> Hello, i tried to flash Snappy on a Raspberry 3 but it ended in being stuck in the gpu-check screen of the raspi. I did read that the problem exists since a few month is there any solution for it? I could not find any.
[10:56] <Son_Goku> morning all
[11:04] <mup> PR snapd#1977 opened: interfaces/builtin: add netplan-observe interface <Created by morphis> <https://github.com/snapcore/snapd/pull/1977>
[11:18] <mup> PR snapd#1965 closed: asserts: support for maps in assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1965>
[11:39] <zyga> didrocks: didrocks I'm sorry, was this about $HOME?
[11:49] <ppisati> $ cat pi2-tvoss.model | grep kernel
[11:49] <ppisati> kernel: ubuntu-raspi2-kernel
[11:50] <ppisati> $ sudo /snap/bin/ubuntu-image --extra-snaps ./ubuntu-raspi2-kernel_4.4.0_armhf.snap -c beta -o pi2-tvoss.img pi2-tvoss.model
[11:50] <ppisati> $ unsquashfs -l ubuntu-raspi2-kernel_4.4.0_armhf.snap
[11:50] <ppisati> ...
[11:50] <ppisati> squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep
[11:50] <ppisati> squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep.bin
[11:50] <ppisati> ...
[11:51] <ppisati> notice the version: 4.4.19-xenial_raspi2+
[11:51] <didrocks> zyga: correct
[11:52] <ppisati> $ unsquashfs -l /media/flag/writable/system-data/var/lib/snapd/snaps/ubuntu-raspi2-kernel_x1.snap
[11:52] <ppisati> ...
[11:52] <ppisati> squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.builtin
[11:52] <ppisati> squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.order
[11:52] <ppisati> ...
[11:53] <ppisati> 4.4.16
[11:53] <ppisati> so it's using a different kernel, and not the one i'm passing on the command line
[11:53] <ppisati> can anyone explain why?
[12:01] <Mirv> are you all on Rocket chat too or should I generally use IRC more?
[12:03] <Son_Goku> zyga: ping
[12:04] <Mirv> Mr. Newbie just has stupid questions
[12:07] <zyga> Son_Goku: hello
[12:07] <zyga> Son_Goku: what's up?
[12:07] <Son_Goku> you're alive!!!
[12:07] <Son_Goku> I've not heard from you nearly all month
[12:07] <zyga> Son_Goku: yes, though my back hurts all day lately :/
[12:07] <Son_Goku> :(
[12:07] <Son_Goku> what happened?
[12:08] <zyga> Son_Goku: back? just the way it is, weather, more work
[12:08] <zyga> Son_Goku: test-snapd-tools
[12:08] <zyga> hmm
[12:08] <zyga> https://plus.google.com/+ZygmuntKrynicki/posts/fPj5PaDFbgk
[12:08] <zyga> that's better
[12:08] <zyga> that's why I was quiet for a while
[12:08] <zyga> remember that "small thing I need to do in snap-confine", well that too NaN minutes to do
[12:09] <Son_Goku> jeez
[12:09] <zyga> Son_Goku: I could use a hand with designing one thing
[12:09] <Son_Goku> hm?
[12:10] <zyga> Son_Goku: we'll have to release snapd once again (hopefully today) before this is doable
[12:10] <zyga> Son_Goku: but I could use a hand with /snap migration
[12:10] <Son_Goku> yes
[12:10] <zyga> Son_Goku: I realized that this is more tricky than initially assumed
[12:10] <zyga> Son_Goku: all snap services need to be stopped
[12:10] <zyga> Son_Goku: all units unmounted
[12:10] <Son_Goku> oh dear
[12:10] <zyga> Son_Goku: all units adjusted
[12:10] <zyga> Son_Goku: all units renamed as systemd requires that the file name matches the internal path
[12:10] <Son_Goku> it's essentially the same as doing an offline update
[12:10] <zyga> Son_Goku: totally
[12:11] <zyga> Son_Goku: and it's very explosive, I was just wondering how to even attempt that and test it sensibly
[12:11]  * Son_Goku has flashbacks to UsrMove
[12:11] <zyga> Son_Goku: my current plan is to use VM snapshots
[12:11] <zyga> Son_Goku: and just code this defensively
[12:11] <zyga> Son_Goku: and iterate a while until I feel it's good
[12:11] <Son_Goku> probably an okay idea
[12:11] <zyga> Son_Goku: this is obviously just for COPR
[12:11] <zyga> Son_Goku: but it has to be there first
[12:12] <zyga> Son_Goku: once copr is moved the rest is easy
[12:12] <Son_Goku> well, for copr, it might not be as horrible as you think
[12:12] <zyga> Son_Goku: if you have a VM handy I could use you do do some reviews and test migrations
[12:12] <Son_Goku> you can move everything, and just create a symlink to /snap -> new location
[12:12] <zyga> Son_Goku: ohhhh
[12:12] <zyga> Son_Goku: hmm D:
[12:12] <zyga> well, see, why didn't I think of that :D
[12:12] <Son_Goku> that's what we did for UsrMove
[12:13] <zyga> so still stop-the-world
[12:13] <zyga> do a symlink
[12:13] <Son_Goku> yep
[12:13] <zyga> perhaps rewrite state.json (need to check)
[12:13] <zyga> and bring it up
[12:13]  * zyga ponders
[12:13] <zyga> but how is the symlink useful then?
[12:13] <Son_Goku> and I *think* this can also be conditionalized as a %pretrans that occurs only if older versions of snapd are detected
[12:13] <zyga> apart from, maybe, just $PATH being still valid
[12:13] <zyga> nah, thats irrelevant, I would keep this in COPR forever and stop updating it
[12:14] <Son_Goku> ah
[12:14] <zyga> Son_Goku: all subsequent updates would be in the repo
[12:14] <Son_Goku> right
[12:14] <Son_Goku> so you'd probably still want to apply a migration to all units and whatnot
[12:14] <zyga> yes, I have to
[12:14] <zyga> everything
[12:14] <zyga> actually
[12:14] <zyga> it might be easier to say this
[12:14] <zyga> the migration removes all snaps
[12:14] <zyga> and re-installs them
[12:14] <zyga> keeping data (that could be a hack)
[12:14] <zyga> well, no I still need
[12:14] <zyga> man this is complex
[12:15] <zyga> ...
[12:15] <zyga> lots of moving parts
[12:15] <Son_Goku> no one ever thought this might be a problem, which is extraordinarily surprising, given Ubuntu's upstream?
[12:15] <zyga> ?
[12:16] <zyga> moving stuff around is hard when it is live
[12:16] <Son_Goku> the /snap path is a violation of Debian Policy
[12:16] <zyga> that's why I'd rather not do it but that cat is out of the bag
[12:16] <Son_Goku> so I was surprised that you guys even did it that way to begin with
[12:16] <zyga> well, /magic would be too because that's a new thing. doesn't mean that policy is set in stone :)
[12:16] <Son_Goku> well, it tends to be
[12:17] <zyga> if that were the case /etc would still ship executables
[12:17] <Son_Goku> I've not seen Debian Policy change significantly in the last decade or so
[12:17] <zyga> and we'd be using vms or something
[12:17] <Son_Goku> haha
[12:17] <zyga> well, back to earth, I'll draft a migration script and share it
[12:17] <Son_Goku> right
[12:17] <zyga> I'm coming back to the light, I hope :)
[12:17] <Son_Goku> I hope so too
[12:18] <Son_Goku> we were nearing the "DEADREVIEW" state for all the stuff
[12:18] <zyga> (yesterday, when I had to do some stuff away from home office I obviously had to break all of yakkety)
[12:18] <Son_Goku> :)
[12:21] <Son_Goku> mass rebuilds are good for the soul
[12:37] <mup> PR snapd#1978 opened: interfaces/builtin: network-manager: allow access to netplan conf files <Created by morphis> <https://github.com/snapcore/snapd/pull/1978>
[12:46] <mup> PR snapd#1979 opened: assertions: add system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/1979>
[13:03] <ogra_> ppisati, have you tried -c edge instead ?
[13:32] <sergiusens> Mirv the snapcraft team is on rocket, the snapd team isn't that is why you see kyrofa sometimes on or off
[13:32] <kyrofa> Hahaha
[13:32] <sergiusens> Mirv that said, I am the only snapcraft person dedicating day and night to it ;-)
[13:34] <Mirv> ok :)
[13:50] <ogra_> Mirv, all teams are kind of on IRC though
[13:50] <ogra_> (reply times are sometimes slow since we started fragmenting everything across all possible chat tools though)
[13:59] <Harshil> hello
[13:59] <Harshil> I have a lenovo x201
[13:59] <Harshil> which has a touch screen
[13:59] <Harshil> does ubuntu 16 support touch screen?
[14:01] <ppisati> ogra_: uhm nope
[14:01] <ppisati> ogra_: i'll give it shot
[14:02] <ppisati> ogra_: btw, where does the board dtb resided these days? kernel or gadget snap?
[14:02] <ppisati> *reside
[14:02] <ogra_> ppisati, you can pick ...
[14:03] <ogra_> (and if LP wouldnt 503 on me i could show you an example :P )
[14:04] <Harshil> is there any way i can  use tuch screen on ubuntu?
[14:04] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems$ grep device-tree beagleblack/meta/gadget.yaml
[14:04] <ogra_> device-tree: am335x-boneblack
[14:04] <ogra_> device-tree-origin: kernel
[14:05] <ogra_> ppisati, device-tree-origin: is either kernel or gadget ... with gadget being the default if you dont specify it at all
[14:05] <ogra_> if it is gadget you need to ship it in /dtbs/ inside the gadget
[14:06] <ogra_> Harshil, you mean snappy ? the snappy images do not have support for graphics yet ... and snappy on classic simply uses the input setup from the classic install for which you get support in #ubuntu
[14:15] <morphis__> cyphermox: ping
[14:18] <cyphermox> morphis__: hi
[14:19] <morphis__> cyphermox: I was wondering if there are any patches you did for network-manager to support config files generated from netplan
[14:20] <cyphermox> yeah, they're the few last I ever applied to NM
[14:20] <cyphermox> to be able to read files in /run and /var/lib
[14:20] <morphis__> cyphermox: ah, great
[14:21] <morphis__> cyphermox: so https://git.launchpad.net/network-manager/tree/debian/patches/Read-config-from-run.patch and https://git.launchpad.net/network-manager/tree/debian/patches/Read-system-connections-from-run.patch ?
[14:23] <cyphermox> that looks about right
[14:24] <cyphermox> look through that same upload there may be more patches from pitti that go along with that
[14:25] <morphis__> cyphermox: ok
[14:25] <morphis__> cyphermox: thanks
[14:37] <qengho> Is RPi2+ just impossible right now? My old image didn't survive upgrade, and the 6-Sept images are (I heard) broken.
[14:38] <balloons> jdstrand, ping
[14:38] <ogra_> they shouldnt be ... but nontheless there are sep 19 images :)
[14:38] <ogra_> the sep. 6th images had an issue on the pi3 which is why we withdrew it ... pi2 was faine though
[14:38] <ogra_> *fine
[14:39] <qengho> Oh. My Pi3 won't work, I gues.
[14:40] <oparoz> Can we still whitelist single syscalls in snapcraft.yaml?
[14:40] <ogra_> qengho, that would surprise me ... the sept. 19 images should surely work on all arches we released for
[14:40] <ogra_> (which includes pi3)
[14:41] <balloons> zyga, just poking again about the snap-confine SRU. Did you get stuck trying to make one?
[14:43] <ppisati> uhm
[14:43] <qengho> ogra_: I'm dumb. Where are those images?
[14:43] <ppisati> i'm pretty sure at this point that ubuntu-image caches the --extra-snap that you pass to it
[14:43] <zyga> balloons: it's in progress
[14:43] <zyga> balloons: I broke yakkety but we've learned and a new set of small releases will fix it today
[14:43] <ogra_> qengho, http://cdimage.ubuntu.com/ubuntu-snappy/xenial/current/
[14:43] <ppisati> and if you pass two times two different snap (but with the same)
[14:44] <zyga> balloons: and hopefully eventually reach xenial
[14:44] <balloons> zyga, wonderful to hear!
[14:44] <balloons> zyga, ohh, nothing is in queue for xenial yet?
[14:44] <ppisati> the image will be created using *always* the first snap with that name
[14:44] <balloons> that's where I need it
[14:44] <mup> Bug #1590219 changed: misleading error when the wrong command is passed with a flag <Snappy:Fix Released> <https://launchpad.net/bugs/1590219>
[14:45] <ogra_> ppisati, probably time for a bug
[14:48] <ppisati> ogra_: let me do another test
[14:50] <jdstrand> balloons: hey
[14:50] <balloons> jdstrand, howdy. I'm curious about your current thoughts on https://bugs.launchpad.net/snappy/+bug/1590767.
[14:50] <mup> Bug #1590767: Support snap installed completion scripts <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1590767>
[14:51] <balloons> jdstrand, it's the bash completion question :-) I know you had an idea that maybe it wasn't as crazy as it sounded for snaps
[14:51] <jdstrand> balloons: all my ideas are captured in the bug. I'm not actively working on it
[14:52] <jdstrand> balloons: I think it is probably possible, but it would need to be designed
[14:52] <jdstrand> (not necessarily by me)
[14:55] <ppisati> and while creating an image for rpi2/3, the dtbs aren't copied to the boot directory
[14:55] <ppisati> so the gadget one are kept around
[14:55] <ppisati> ...
[14:57] <balloons> jdstrand, so it still needs design / proof of concept then. Sounds like the proposed idea of a confined helper to feed strings is the most promising then
[14:59] <qengho> jdstrand: in case this was below your attention: "personality" syscall on armhf. https://bugs.launchpad.net/snappy/+bug/1614269
[14:59] <mup> Bug #1614269: tor package on ARMHF crashes on filtered syscall "personality" <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1614269>
[15:00] <qengho> I don't know what the argument to that syscall was, but I don't think we support more discrete filters anyway.
[15:06] <jdstrand> qengho: I saw the bug. I have a feeling that you'd run into other problems, but maybe not. we do support seccomp argument filtering in snap-confine these days, but nothing is using it yet (I plan to change that as soon as I get through other high priority work)
[15:07] <jdstrand> qengho: what happens if you add 'personality' to /var/lib/snapd/seccomp/profiles/snap.tor-middle-relay...
[15:07] <qengho> jdstrand: I whitelist "personality" with "sudo -e" and it works great. No complaints.
[15:08] <jdstrand> qengho: can you mention that in the bug. I suspect it is setting persona to 0xffffffff then
[15:09] <qengho> I will
[15:09] <jdstrand> thanks!
[15:10] <mup> PR snapcraft#820 closed: Fixed bug LP: #1607294 snapcraft search returns results in different order <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/820>
[15:13] <zyga> mvo: how do you feel about https://github.com/snapcore/snapd/pull/1847#pullrequestreview-1151064
[15:13] <SamYaple> hmmm sergiusens bit of an issue with the python plugin
[15:13] <mup> PR snapd#1847: many: discard preserved namespace after removing snap <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
[15:13] <sergiusens> SamYaple what issue?
[15:13] <zyga> mvo: I'd like to land it and do another release as this breaks people
[15:14] <SamYaple> sergiusens: it appears that its not installing some things and im not sure why. just discovered it
[15:14] <SamYaple> sergiusens: in a standard virtualenv on your machine, run `pip install dogpile.cache` youll notice it has more files than installing that in the snap
[15:15] <SamYaple> specifically in the snap 'lib/python2.7/site-packages/dogpile' does not contain an __init__.py
[15:15] <mvo> zyga: I would love to have niemeyer review on this branch too
[15:15] <SamYaple> and that is needed
[15:15] <mvo> zyga: but once its landed we can do a hotfix for yakkety
[15:15] <niemeyer> mvo: Which one is that?
[15:15] <niemeyer> #1847?
[15:15] <mvo> niemeyer: yes
[15:15] <sergiusens> SamYaple what if you `pip install --user dogpile.cache`?
[15:15] <niemeyer> mvo: Looking
[15:16] <balloons> mvo, might you be able to help out on getting a newer snap-confine into xenial? I've been poking zyga, but I don't think he has upload rights
[15:16] <zyga> mvo, niemeyer: understood, thank you
[15:16] <balloons> mvo, specifically the xenial version has the LXD issue which breaks juju, conjure-up, etc
[15:17] <sergiusens> SamYaple and second question since I am mad troubleshooting something else, does the upstream provide that __init__.py?
[15:18] <mvo> balloons: what bit exactly do you need? there is a pending update but its a bit delicate because it requires a new snapd and lock-step updates
[15:18] <SamYaple> sergiusens: indeed it does (as well as other files, __init__.py missing is simply blocking the import)
[15:18] <mhall119> nessita: are you on the Ubuntu rocket.chat ?
[15:18] <SamYaple> sergiusens: i can't --user in a virutalenv. stil ltesting that
[15:18] <balloons> mvo, https://bugs.launchpad.net/snap-confine/+bug/1613845
[15:18] <mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1613845>
[15:19] <nessita> mhall119, I'm not, how can I help you?
[15:19] <balloons> mvo, the PR is linked in there if you wanted to cherry-pick. But I was assuming 1.0.40 (and now 1.0.41) would come back to xenial directly
[15:19] <mhall119> nessita: Mirv had a question there about the new content interface and the store, let me copy it here
[15:19] <sergiusens> SamYaple I am guessing virtualenv does some __init__.py magic (I saw the code for virtualenv, it is full of weird things to help you out)
[15:20] <SamYaple> sergiusens: nah, its there with --user as well
[15:20] <SamYaple> sergiusens: but like i said, there are other missing files too, like api.py
[15:20] <mhall119> is there any recent documentation or examples on the content interface? I tried to add a similar slot configuration to geany-plugins to my package: https://github.com/ubuntu/snappy-playpen/blob/geany/geany-plugins/snapcraft.yaml - but when uploading to store I got "unknown attribute 'content' for interface 'content' (slots) lint-snap-v2_slots_attributes"
[15:20] <SamYaple> specific to dogpile.cache
[15:20] <mhall119> nessita: ^^ that was it
[15:20] <sergiusens> SamYaple hmph, can you log a bug, I will look at it later
[15:21] <SamYaple> sergiusens: sure. im still digging into it
[15:21] <mvo> balloons: right, if we do a new snap-confine we need to also do a new snapd with a branch that is not even in master yet, I'm just saying if this is urgent a cherry-pick might be easier
[15:22] <balloons> mvo, ack, makes sense. I would really appreciate a cherry-pick in that regards. I'm happy to help verify the SRU
[15:23] <mvo> balloons: ok, I will keep that in mind, if the branch lands soon and we can unblock the current snapd sru the full release is probably a better option. but its two *ifs* in there
[15:24] <mvo> pitti: silly question, snapd  2.15.2ubuntu1  is in xenial-proposed since ~21h but I  have not seen a autopkgtest run for it, is that expected? also not in the queue or anything. how is that scheduled?
[15:25] <nessita> mhall119, hum, I don't have the details of each interface, let me see who can help you
[15:25] <nessita> mhall119, the store until runs the click-reviewers-tools
[15:25] <nessita> we don't have the logic of the checks themselves
[15:26] <nessita> jdstrand, hi, would you know what the error that mhall119 printed above means: "unknown attribute 'content' for interface 'content' (slots) lint-snap-v2_slots_attributes"
[15:26] <mhall119> click-reviewers-tools is used against snaps as well?
[15:26] <nessita> mhall119, what app is this, so I look for it in the store?
[15:26] <nessita> mhall119, yers
[15:26] <nessita> yes*
[15:26] <pitti> mvo: ah, we had a ginormous amount of cloud breakage again, I'll just kick it
[15:26] <pitti> (to re-run again)
[15:27] <mhall119> nessita: not sure, Mirv didn't share links to his files
[15:27] <mvo> ta
[15:27] <pitti> mvo: note that it fails in y (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd)
[15:27] <nessita> mhall119, do you know the snap name?
[15:28] <pitti> mvo: (so is stuck in -proposed anyway)
[15:28] <niemeyer> zyga: Btw, if you are in a hurry, revert the changes
[15:28] <niemeyer> zyga: We don't want to rush this in
[15:29] <niemeyer> zyga: You are touching on the foundation of every single snap, and apparently there are issues.. let's take the time to do it right
[15:29] <zyga> niemeyer: ack
[15:30] <mhall119> nessita: I don't, sorry, and Mirv might be gone for the day already
[15:30] <mhall119> I can't find his developer account in the store either
[15:32] <Mirv> mhall119: nessita yes EOD but a quick link https://myapps.developer.ubuntu.com/dev/click-apps/5974/ -> 4 had the failure, in 5 the line is removed (and a new unrelated part added)
[15:32] <Mirv> sorry must go
[15:32] <niemeyer> zyga: review submitte
[15:32] <niemeyer> d
[15:33] <mhall119> thanks Mirv
[15:33] <mvo> pitti: that is fallout from a bad snap-confine version but yeah
[15:33] <nessita> Mirv, checking
[15:33] <mvo> pitti: I'm keen on the autopkgtest output because the upload targets the failures specifically, I'm keen to learn if my fixe(s) are good enough
[15:34] <mhall119> Mirv: looks like rev 5 passed, does that mean you've resolved it, or just reverted the changes from rev 4?
[15:35] <jdstrand> nessita: I do. 'content' isn't an attribute of the content interface per https://github.com/snapcore/snapd/blob/master/docs/interfaces.md. the attributes should be read, write or target
[15:35] <jdstrand> (depending on if slot or plug. in this case it is slot side so should be 'read' or 'write')
[15:37] <mhall119> jdstrand: according to my understanding of the interface, the "content" attribute is needed to make sure the plug and the slot are both talking about the same thing
[15:37] <jdstrand> there is no content attribute based on the docs
[15:37] <jdstrand> let me look at the yaml
[15:38] <jdstrand> jeez this thing is 400M
[15:38]  * jdstrand really wishes that the store showed the snap.yaml...
[15:39]  * jdstrand knows that is planned
[15:39] <mup> Bug #1626617 opened: console-conf does not allow to set up dns for static ip <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1626617>
[15:40] <mhall119> jdstrand: https://github.com/snapcore/snapd/blob/941e06e4f0eaece96e357b561013c8b7363e0068/tests/lib/snaps/content-slot/meta/snap.yaml lists a content parameter
[15:40] <mhall119> maybe it's something planned but not implemented yet
[15:41] <mhall119> https://github.com/snapcore/snapd/blob/941e06e4f0eaece96e357b561013c8b7363e0068/tests/lib/snaps/content-plug/meta/snap.yaml being the plug side
[15:41] <SamYaple> sergiusens: the import problem still exists, however the missing __init__.py is not the problem. the file difference was due to different versions of dogpile.cache
[15:42] <SamYaple> sergiusens: the fact remains that it is still an import problem and i dont know why
[15:43] <oparoz> Do we still need to "connect" something if we whitelist a syscall?
[15:44] <zyga> mhall119: hey, I need to skip the call as I have a conflict on sprint planning
[15:45] <mhall119> zyga: no worries, we had the upstreaming work call earlier, we found some blockers that will get passed on to you or jdstrand but not much
[15:45] <mhall119> jdstrand: who are you waiting for on the dbus interface review?
[15:46] <jdstrand> mhall119: niemeyer
[15:46] <jdstrand> mhall119: as for the content interface, just drop 'content: qt-ubuntu'
[15:47] <mhall119> niemeyer: a number of desktop apps are waiting on the dbus interface, do you know when we'll have that available?
[15:47] <jdstrand> mhall119: I checked the code and there is nothing in it that I can see that would honor the content attribute
[15:47] <mup> PR snapd#1976 closed: tests: skip some tests on non-amd64 architectures <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1976>
[15:48] <mhall119> Mirv: ^^ see jdstrand's fix above, it seems the 'content' parameter isn't used
[15:48] <jdstrand> mhall119: your question to niemeyer isn't phrased quite right
[15:48] <niemeyer> mhall119: After I get over the critical tasks for the impending deadlines
[15:48] <niemeyer> mhall119: I don't know what the status of this is, to be honest.. we discussed that long ago
[15:48] <jdstrand> mhall119: as you know, it was deprioritized for other high prioirty interfaces. that work is done, I came back around to it to get it in reviewable shape this week. now niemeyer and I need to iterate
[15:49] <niemeyer> Ah, nice, so jdstrand is on top o fit
[15:49] <mhall119> jdstrand: thanks, I didn't know it was deprioritized (though I did know other work was above it)
[15:49] <jdstrand> niemeyer: yeah-- we can start iterating again-- but I gave a long answer and I suspect you'll want to give it a careful read and ponder
[15:50] <jdstrand> mhall119: that is what I meant about deprioritized
[15:50] <niemeyer> mhall119: It was not consciously deprioritized.. it was naturally deprioritized because we have way too much to do on not enough time
[15:51] <balloons> should ~/snap/snapname/current exist? I only see ~/snap/snapname/buildnumber
[15:51] <jdstrand> mhall119: again, it is difficult when everything is critical priority-- nothing is. it was behind other stuff. that other stuff is mostly done, but dbus-app got picked up again and we are moving forward as best we can considering the deadlines (as niemeyer indicated)
[15:52] <jdstrand> mhall119: fyi, you are a subscriber to the trello card and I keep it up to date. not sure if those updates are getting filtered
[15:53] <mhall119> jdstrand: I saw the update, but not the detail of who had the next task on it or when it might be done
[15:53] <tachyons> successfully uploaded first ruby snap to store
[15:53] <jdstrand> the next task is in the PR
[15:53] <mup> PR snapd#1980 opened: tests: more debug around the create-key test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1980>
[15:53] <jdstrand> I don't have a timeline since we need to iterate and other deadlines are there
[15:54] <jdstrand> mhall119: note that devmode is still an option to unblock people. I realize that doesn't help with the stable channel.
[15:55] <mhall119> yeah, it also doesn't let them work on building their snap "the right way" until they know what that right way is going to be
[15:55] <mhall119> but I'm glad it's still active and getting near the top of the priority list now
[16:22] <mup> PR snapcraft#821 opened: Make copies of remote parts to avoid ordering issues <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/821>
[16:25] <Guillaume__> hello
[16:26] <Guillaume__> when they say "Try Ubuntu Core running on bare metal x86 devices" does it mean that it can run on any computer ???
[16:28] <ogra_> sure, you can dd the amd64 or i386 image onto a USB stick and should e able to boot it from there
[16:29] <mhall119> as long as the hardware doesn't prevent you from booting a different OS, yes
[16:29] <ogra_> indeed ...
[16:30] <mhall119> sergiusens: can you do 1400 utc tomorrow to talk about cmake/cpack and snaps?
[16:30] <mhall119> should only take 30 minutes
[16:34] <Guillaume__> is there a recommanded hardware or limitation ? for example, does it run on any NUC ?
[16:37] <Guillaume__> on bare metal, is there a recommanded hardware or limitation ? for example, does it run on any NUC ?
[16:38] <Pharaoh_Atem> zyga: so have you figured out the migration step yet?
[16:40] <SamYaple> sergiusens: oh. when did that get added? the problem is we are stripping the pth files
[16:40] <SamYaple> sergiusens: we should absolutely not be doing that
[16:41] <zyga> Pharaoh_Atem: I think so, I need to setup some representative env for testing though and script it all the way
[16:41] <zyga> Pharaoh_Atem: though still working on https://github.com/snapcore/snapd/pull/1847
[16:41] <mup> PR snapd#1847: many: discard preserved namespace after removing snap <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
[16:42] <SamYaple> sergiusens: https://github.com/snapcore/snapcraft/pull/765 tsk tsk tsk it was you!
[16:42] <mup> PR snapcraft#765: Use a recursive iglob for filesets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
[16:47] <jdstrand> niemeyer: hey, is there a way to retrigger travis checks? https://github.com/snapcore/snapd/pull/1968 failed for something unrelated to the PR
[16:47] <mup> PR snapd#1968: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1968>
[16:48] <niemeyer> jdstrand: Yeah, if you click on the "Details" link you'll see the three jobs.. some of them will likely have passed
[16:48] <jdstrand> yes, two of the 3 did
[16:48] <niemeyer> jdstrand: If the spread one failed, please restart just that one by clicking on it first
[16:49] <niemeyer> jdstrand: That sounds like a real failure then.. doubt a restart will make it work
[16:49] <jdstrand> ok, it was the one. it is tests/main/create-key
[16:49] <niemeyer> jdstrand: Please note we have a low tolerance for flakiness.. if there's a test that is failing on and off, we need to fix it or remove it
[16:50] <niemeyer> jdstrand: Ah, yeah, that's exactly this case then :)
[16:50] <jdstrand> 2016/09/21 22:25:37 Failed tasks: 2
[16:50] <jdstrand> - linode:ubuntu-16.04-32:tests/main/create-key
[16:50] <jdstrand> - linode:ubuntu-16.04-64:tests/main/create-key
[16:50] <niemeyer> jdstrand: mvo has been trying to stabilize this one
[16:50] <jdstrand> ok, cool
[16:50] <jdstrand> so if I click it, it might pass
[16:50] <niemeyer> jdstrand: Yeah
[16:50]  * jdstrand notices PR 1980 is being worked on
[16:50] <mectors> How does the serial-port interface work when I want to use a snap that connects to a USB device? Do I add a slot with the usb-x parameters and what do I have to do with snap connect?
[16:51] <niemeyer> mvo: any news on create-key?
[16:52] <jdstrand> niemeyer: I think I'm clicking the wrong thing. if I click 'it' or the big 'x', it just shows me the log
[16:52] <jdstrand> maybe I need to sign in
[16:53] <niemeyer> jdstrand: It's a circular thing, and there's a label next to it at the top
[16:53] <niemeyer> jdstrand: Yes, it needs to know who you are before it allows restarting a jbo
[16:54] <mup> Bug #1626652 opened: ~/snap/<name>/current/ is missing <Snappy:New> <https://launchpad.net/bugs/1626652>
[16:58] <jdstrand> niemeyer: ok, it took a while after I logged in before it should me the 'Restart build' button, but I clicked it. stuff seems to be happening :) thanks!
[16:58] <jdstrand> showed*
[17:02] <niemeyer> jdstrand: np.. again, if you click this thing too often, please let us know.. create-key we're already aware and are working on it
[17:03] <mup> Bug #1626656 opened: something isn't quoting <bold>things</bold> <Snappy:New> <https://launchpad.net/bugs/1626656>
[17:06] <mup> Bug #1626656 changed: something isn't quoting <bold>things</bold> <Snappy:Invalid> <https://launchpad.net/bugs/1626656>
[17:10] <jdstrand> niemeyer: yep. I figure I'd always ask
[17:15] <sergiusens> SamYaple you the content of the .pth be correct in any case?
[17:15] <sergiusens> SamYaple we need some code that would normalize it
[17:17] <modprobe_> Is there an easy way to include packages from a PPA in my snap? I'm trying to package an app which deps Qt 5.7
[17:18] <SamYaple> sergiusens: i dont understand the question
[17:21] <sergiusens> SamYaple hmm, I fail to see why we filter those out now
[17:22] <sergiusens> SamYaple disregard me, I entered firefighting mode since I woke up today :-)
[17:22]  * sergiusens skipped breakfast and lunch, and wondering if a late lunch would be a good idea
[17:25] <SamYaple> sergiusens: ok i responded in the github comment, but im going to submit a patch to remove that filtering and see if anyone complains
[17:25] <SamYaple> i really dont know why its filtered either
[17:27] <sergiusens> SamYaple please do
[17:33] <sergiusens> SamYaple oh, if possible in demos/snaps_tests it would be good to add a py package that maks use of pth files
[17:34]  * qengho has trouble with first startup of published pi3 image. Four CPU fruits on black, timeout to black. Heartbeat light still blinks. numlock key toggles light! and ctrl-alt-delete reboots. Weird.
[17:35] <SamYaple> sergiusens: without digging around, dogpile.cache does. ill see about adding that
[17:35] <qengho> Only weird thing in text before starting kernel is "Unable to read uEnv.txt".
[17:35] <ogra_> slangasek, ok, seems live-build is the bad guy here and removes *.pyc on all our images at build time with the exception of ubuntu-server and ubuntu-cpc ... i wonder why nobody ever sumbled over this
[17:36] <sergiusens> ogra_ slangasek I am so happy it is not snapcraft :-)
[17:37] <SamYaple> sergiusens: demos in the snapcore/snapcraft repo?
[17:37] <ogra_> slangasek, since quantal actually ...
[17:38] <sergiusens> SamYaple yeah, those get built AND their `apps/*/commands` run if specific to under snaps_tests as a real snap
[17:38] <sergiusens> SamYaple which wouldn't be the case if adding an integration test
[17:38] <ogra_> hmm, probably even longer ... cjwatson added the exception for ubuntu-server in quantal
[17:38] <sergiusens> SamYaple if it is too much trouble that's ok
[17:39] <slangasek> ogra_: probably because before now, "not ubuntu-server and not ubuntu-cpc" meant desktop, and the desktop live images were used on x86, and the byte compile penalty wasn't enough there to notice
[17:39] <SamYaple> sergiusens: not to much trouble, just something new. ill look into it right now
[17:40] <ogra_> slangasek, well, but that could explain why armhf has always been slow :) we always insisted to use the official build tools for our images :)
[17:40]  * slangasek chuckles
[17:40] <mup> PR snapcraft#822 opened: Don't filter .pth files in python plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/822>
[17:40] <slangasek> ogra_: will you make the change to live-build to fix this, then?
[17:41] <ogra_> slangasek, i'll just add ubuntu-core to the exception code in livecd-rootfs for now
[17:41] <slangasek> ogra_: wfm
[17:41] <sergiusens> ogra_ mind if I reply with a short summary to the list?
[17:41] <qengho> modprobe__: No, there isn't.  Maybe add what you think it should look like in your yaml. https://bugs.launchpad.net/snapcraft/+bug/1604671
[17:41] <mup> Bug #1604671: snapcraft doesn't support arbitrary PPAs or apt sources <Snapcraft:New> <https://launchpad.net/bugs/1604671>
[17:41] <ogra_> but we should probably consider simply ripping out that bit completely
[17:42] <ogra_> slangasek, sure, go ahead, though i first want to see if that actually improves much :)
[17:42] <ogra_> before i make a statement myself
[17:42] <sergiusens> ogra_ oh, people say pyc is needed for this to improve, let's get them those pycs ;-)
[17:43] <ogra_> sergiusens, yeah, there i'm not even a size-nazi  :P
[17:43] <sergiusens> ogra_ riiiiight
[17:44] <sergiusens> ogra_ also, check telegram ;-)
[17:44] <sergiusens> ogra_ there is a treat for you
[17:44] <ogra_> LOL
[17:44] <ogra_> ohmy !
[17:44] <ogra_> thats an oooold pic
[17:44] <sergiusens> snappy fixed it ;-)
[17:45] <ogra_> not yet :)
[17:45] <ogra_> oh man , i look so slim ...
[17:47] <zyga> ogra_: snaps make everything ... compressed ;-)
[17:47] <ogra_>  hahaha
[17:57] <modprobe__> qengho: Thanks, I've done that. :)
[18:01] <mup> PR snapd#1981 opened: tests: add a test for core about device initialization and device registration and auth <Created by pedronis> <https://github.com/snapcore/snapd/pull/1981>
[18:35] <qengho> I'm filing image bugs in snappy/snapd bug tracker. Hope that's okay.
[18:35] <ogra_> well, filing them on the project is desired ...
[18:35] <ogra_> (see topic)
[18:36] <ogra_> dont file them against snapd though ... unless it is actually a snapd prob
[18:44] <mup> PR snapd#1971 closed: interfaces/builtin: add rcvfrom for client connected plugs to mir interface <Created by kgunnfront> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/1971>
[19:02] <dobey> ogra_: unless it's a problem in the app itself, isn't it always a snapd problem? i thought that was the whole point of snapd and forcing everything to go through it
[19:03] <ogra_> well, a snappy image consiste of a lot more than snapd .. running a snap on a classic system uses snap-confine, ubuntu-core-launcher etc etc
[19:03] <ogra_> *consists
[19:03] <kyrofa> dobey, if it's image-related though, it could be ubuntu-image or a number of other things
[19:03] <ogra_> and even on classic it can be a lot more
[19:03] <kyrofa> Definitely
[19:04] <kyrofa> There are a lot of pieces associated with snaps beyond just snapd
[19:04] <ogra_> that is why we have the snappy project as catch-all bugtracker ...
[19:10] <mup> PR snapd#1956 closed: many: show snap name before the download progress bar <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1956>
[19:20] <pmcgowan> ogra_, hey, cant get my dragonboard to boot of the sd I made, will it work with a 2GB card?
[19:22] <mup> PR snapcraft#821 closed: Make copies of remote parts to avoid ordering issues <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/821>
[19:30] <ogra_> pmcgowan, i havent tried, but at least the dailies should not be to big for a 2G card
[19:31] <ogra_> (the smallest i have ever tested was 4G)
[19:32] <pmcgowan> ogra_, it errored when it reached the end of the card, when I insert it and boot I get the default android on mmc
[19:33] <pmcgowan> I did change the dip switch to sd
[19:33] <ogra_> pmcgowan, ah, well, the beta images are 3.8G ... they wont fit
[19:33] <pmcgowan> oh
[19:33] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
[19:33] <ogra_> grab one from there
[19:33] <ogra_> thats 300MB
[19:33] <ogra_> (uncompressed)
[19:34] <pmcgowan> great thanks will try it
[19:41] <pmcgowan> ogra_, btw whats the difference in the images besides the size
[19:41] <pmcgowan> or is this just new and improved
[19:43] <mup> PR snapcraft#823 opened: plainbox-provider plugin: rewrite python shebangs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/823>
[19:44] <sergiusens> SamYaple any luck with the test?
[19:45] <ogra_> pmcgowan, mine are untested daily builds from the edge channel (latest stuff and latest breakage) ... the cdimage ones are tested beta images
[19:46] <pmcgowan> ogra_, will beta images get smaller? or do I need to buy a card
[19:46] <ogra_> both ? :)
[19:46] <pmcgowan> heh
[19:46] <ogra_> i'm using ubuntu-image trunk whihc builds images only as big as their content
[19:47] <ogra_> once trunk is released the beta ones will also be small
[19:47] <pmcgowan> got it thanks
[19:49] <mup> PR snapd#1981 closed: tests: add a test for core about device initialization and device registration and auth <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1981>
[19:58] <sergiusens> mhall119 I can do one hour after or one hour before
[20:05] <zyga> jdstrand: hey
[20:06] <zyga> jdstrand: I wrote a small branch for snap-confine that I plan to cherry-pick into the release
[20:06] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/151
[20:06] <mup> PR snap-confine#151: Make snap-discard-ns fail gracefully <Created by zyga> <https://github.com/snapcore/snap-confine/pull/151>
[20:14] <ogra_> slangasek, http://paste.ubuntu.com/23217393/ ... not much improvement
[20:14] <ogra_> (and it wastes 5MB on the image)
[20:14] <slangasek> ogra_: strace itself is doing a lot of I/O, I'd be more interested in 'time console-conf --help' + strace output :)
[20:15] <slangasek> ogra_: is that 5MB of .snap size or within the filesystem?
[20:15] <slangasek> anyway
[20:15] <ogra_> the core snap got 5MB bigger
[20:15] <slangasek> strace output please, so we can see what it's spending time on now that it's *not* spending it on byte compilation
[20:16] <ogra_> (which is = filesystem size in our case)
[20:17] <ogra_> slangasek, http://paste.ubuntu.com/23217404/
[20:17] <slangasek> ta!
[20:17] <ogra_> without strace the time output varies ...
[20:17] <ogra_> between 12 and 5 secs
[20:18] <ogra_> thats is noticeable better ...
[20:18] <ogra_> i'll do a full install run with tomorrows image ... curious how that will turn out now
[20:19] <slangasek> indeed
[20:21] <ogra_> also interesting that it looks for the en_* locales ... the suystem has C.UTF-8 hardcoded
[20:21] <slangasek> huh
[20:22] <slangasek> ogra_: how's the entropy on the bbb?
[20:22] <ogra_> oh ... LANGUAGE is actually unset
[20:22] <slangasek> I notice the getrandom() in there
[20:22] <ogra_> plain SW iirc
[20:24] <ogra_> hmm, probably i'm wrong
[20:24] <ogra_> ogra@bbb:~$ lsmod|grep rng
[20:24] <ogra_> omap_rng               16384  0
[20:24] <slangasek> ogra_: also it looks like we're missing .pyc for subiquity itself, and that will be a packaging bug on our side:      0.001296 stat64("/usr/share/subiquity/subiquitycore/ui/__pycache__", 0xbeecbe10) = -1 ENOENT (No such file or directory) <0.000174>
[20:24] <slangasek> cyphermox, mwhudson: ^^
[20:25] <slangasek> not sure if that's enough files to matter
[20:35]  * ogra_ vanishes into the night
[20:41] <SamYaple> sergiusens: im still going on it, got other work pulling me away at the moment
[20:50] <cyphermox> slangasek: interesting, but I'm not overly surprised, I had all kinds of issues with packaging this
[21:08] <zyga> slangasek: hmm
[21:08] <zyga> slangasek: is that confined?
[21:08] <zyga> slangasek: AFAIR there's a silent deny rule for __pycache__ in apparmor somewhere
[21:08] <zyga> slangasek: (in the base template)
[21:08] <slangasek> zyga: this was a problem of files actually missing from the image
[21:08] <zyga> slangasek: ah, I see
[21:08] <slangasek> and if they're there, no denial
[21:20] <zyga> jdstrand: updated https://github.com/snapcore/snap-confine/pull/151 as requested
[21:20] <mup> PR snap-confine#151: Make snap-discard-ns fail gracefully <Created by zyga> <https://github.com/snapcore/snap-confine/pull/151>
[21:20] <mup> PR snapd#1982 opened: tests: disable broken create-key test <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1982>
[21:28] <mup> PR snapd#1968 closed: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1968>
[21:41] <mwhudson> slangasek: subiquity missing .pycs is not in the same league as missing them for the stdlib, i'd hazard
[21:42] <zyga> woah
[21:42] <zyga> "python slow"
[21:42] <zyga> gentoo level
[22:19] <mwhudson> heh funroll-loops.info seems to have died
[23:23] <mup> PR snapd#1982 closed: tests: disable broken create-key test <Created by niemeyer> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1982>