[00:40] does anyone know how to use snapweb? [02:01] PR snapd#1969 opened: Update HACKING.md [02:24] Bug #1626359 opened: Cannot authorise quotactl syscall === JanC is now known as Guest5754 === JanC_ is now known as JanC [03:09] PR snapd#1970 opened: Adds ptrace capabilities to the system_trace interface [03:31] How do I replicate same error message in snap store in local snap review ? [03:32] In automated review in store , I got follwing error [03:32] package contains external symlinks: gems/ruby-2.3.1@global, rubies/default lint-snap-v2_external_symlinks [03:32] 0 Warnings [03:32] 31 Passes [03:32] But this error is not appearing in local when I run snap review [03:47] tachyons: install click-reviewers-tools, and then run click-review [03:47] elopio: already done , But this error is not coming in my local system [03:48] tachyons: then probably the reviewers tool used in the store is not the same version [03:49] tachyons: I think that error means that in your snap you have a symlink to a path outside. [03:49] elopio: which version should I try , I tried the version in 16.04 as well as trunk in bzr [03:49] you can ls -l in the prime directory to search for the links. [03:50] tachyons: I don't know what's the right version. [03:51] elopio: yes there are symlinks , but those are not outside snap package [03:51] tachyons: can you paste the ls -l of those two files? [03:54] wait [03:54] total 8 [03:54] 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] drwxrwxr-x 6 tachyons tachyons 4096 Sep 21 21:03 ruby-2.3.1 [03:55] default is symlinked to ruby-2.3.1 [03:57] elopio: Is that fine ? [03:59] tachyons: I think it should be a relative path, not an absolute one. [03:59] when you mount that snap in a system, it will try to find /home/tachyons. [04:01] elopio: Means I have to write a script to convert absolute path to relative path in build script? [04:02] tachyons: yes. Some other plugins are probably doing the same, but kyrofa is our link man and he's EOD. [04:02] you can send an email to the list. [04:03] EOD means? [04:04] end-of-day. He's sleeping. [04:07] PR snapd#1971 opened: interfaces/builtin: add rcvfrom for client connected plugs to mir interface [04:09] elopio: Thanks , https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L120 Is this what you meant ? [04:10] I don't have much idea about python stuff [04:11] tachyons: more like this, I think: https://github.com/snapcore/snapcraft/blob/97742500ac64d44f9251983a7ac93b128901fdfa/snapcraft/plugins/dump.py#L62 [04:12] I don't have much idea of this part of snapcraf.t [04:15] elopio: Thanks :-) , Let me try [04:40] Bug #1598657 changed: No error id for username/password error returned from snapd

[05:51] PR snapd#1969 closed: Update HACKING.md [06:12] PR snapd#1972 opened: tests: increase timeout for key generation in create-key test [06:37] good morning [06:55] good morning === hikiko is now known as hikiko|bbiab === braderhart is now known as techntoke === techntoke is now known as braderhart === braderhart is now known as techntoke [08:07] ogra_: good news everyone! we have what lookds like a working "loadkeys" [08:15] elopio: Thanks , it is working for files , but directories are not being copied correctly [08:15] It shows empty directory instead [08:18] ogra_: total cost is ~3mb it seems, not great, not too terrible either === hikiko|bbiab is now known as hikiko [08:28] 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] (maybe when people adds the home plug?) [08:32] didrocks: I did not see that, that sounds like a regression [08:33] mvo: yeah, I guess fgimenez can show you an easy reproducer [08:33] (desktop-launch is using ~/.something) and ~ is expanded to /home// [08:34] 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] fgimenez: is that with master? [08:35] mvo: I did get the issue on a released snapd version on my side [08:35] didrocks: what version? [08:36] mvo: ah, sorry, I'm wrong, I still have your ppa version :) [08:36] snapd 2.14.2~16.04+ppa227-1 [08:36] the one with revert --devmode [08:36] didrocks, fgimenez: https://github.com/snapcore/snapd/blob/master/snap/snapenv/snapenv.go#L91 looks correct, let me add a spread test [08:37] mvo: so, basically, we have here: command: desktop-launch [08:37] and desktop-launch is doing cat ~/.something [08:37] and we can see (with the home slot plugged, don't know without that), that ~ is expanded to /home/user [08:42] mvo, hmm, thats a lot, but you didnt use the d-i bits, right ? just the normal desktop packages [08:42] i guess using the bits from the udeb would be a lot less [08:43] ogra_: yeah, just the regular packages [08:43] PR snapd#1973 opened: tests: ensure HOME is also set correctly [08:44] didrocks: -^ for you [08:45] fgimenez: ^ [08:45] 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] mvo, didrocks cool thanks a lot [08:49] 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] ogra_: hm, just had a quick look, killing python would be huge if we want to reduce the size [08:50] ogra_: vim.tiny is also 1mb, systemd-analyize, perl [08:50] fgimenez: yeah, but that's not needed, mvo confirms that HOME should already point to SNAP_USER_DATA [08:50] mvo, ogra_: did you guys release a new beta OS snap? [08:50] but as we are using ~ expansion, I really wonder if the mvo's test makes sense [08:50] morphis__, not that i'm aware [08:50] mvo, ogra_: saw it changing from 526 to 658 [08:51] PR snapd#1974 opened: snapd: kmod backend [08:51] mvo, killing python would get us 10MB snaps :P [08:51] zyga: see you are approving, but did you read above? ^ [08:51] (yes, i'm exaggerating ... but it would freee a lot) [08:51] ogra_: I think we can kill libstdc++6 from the image, its only needed by apt afaik [08:52] ogra_: snap prepare-image --channel beta .. gives me 658 now where edge has 695 [08:52] ogra_: hm, no, sorry [08:52] ogra_: silly me, we would still have to include it for classic [08:52] yeah [08:53] ogra_: /usr/share/local/* might be worth a shot [08:54] mvo, ogra_: any a snap refresh --beta ubuntu-core on my desktop gives me 660 [08:54] morphis__: same architecture? [08:55] mvo, we purge the lcle package at the end of the build [08:55] *locale [08:55] that should only be empty dirs [08:55] ugh [08:56] mvo: ah right [08:56] * ogra_ shakes fist at maintainer scripts [08:56] mvo: but that still doesn't explain why the armhf one goes from 526 to 658 [08:56] ogra@bbb:~$ du -hcs /usr/share/locale/ [08:56] 7.2M /usr/share/locale/ [08:56] woah [08:57] mvo: can you check in the store what should be the latest for the beta channel? [08:58] * ogra_ is just looking [08:58] 656-661 are in bet [08:58] a [08:58] beginning of last week I got 526 and now 658 [08:59] ogra_: you see when they were published? [09:00] 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] PR snapd#1975 opened: tests: add test benchmark script [09:01] hmm, looks like thery were manual :/ [09:01] but i'd say 19th [09:01] yeah, the store says "2016-09-19 12:25 - 2 days, 20 hours ago" [09:01] ogra_: wait, we released an upgrade beta snap after the beta announcement? [09:02] ask mvo ... he handles the beta releases ... but why wouldnt we [09:02] ogra_: as it breaks stuff [09:03] well, thts indeed bad, but there is no reason to not release beta if it doesnt :) [09:03] whaat does it break ? [09:04] ogra_: there is no reason against that but you easily miss that if you nowhere get an announcement for that or so [09:04] ogra_: however, console-conf seems to be updated and now doesn't work anymore with our manually put in place ifupdown config [09:05] mwhudson: ping [09:05] oh ? are you sure ? [09:05] you mean you define a fixed IP and dont get that IP ? [09:06] or what does not work ? [09:06] (note that the device comes up automatically before console-conf ... systemd-networkd default to try DHCP) [09:06] *defaults [09:06] 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] it shows the detected IP configuration which ifupdown put in place [09:07] ogra_: no networkd here, [09:07] morphis__: it breaks stuff? [09:08] mvo: console-conf has a regression somewhere [09:09] morphis__: right, thats (obviously) bad did you talk to mwhudson about it yet? [09:09] 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] mvo: just ping'ed him [09:09] hi [09:10] morphis__: there was an anncounement: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html [09:10] oh ... [09:10] my bad then that I missed that .. sorry :-) [09:11] no worries [09:11] mwhudson: hey! [09:11] er is it possible to figure out the console-conf versions in the good and bad versions? [09:11] mwhudson: let me first explain the problem I see right now [09:12] 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] mvo: my only conern was because I missed the announcement [09:12] so releasing to beta more often to fix bugs is fine for me [09:13] mwhudson: so the problem I have right now is the following: [09:13] mwhudson: we can't really use networkd here as it just fails badly on our 3.4 kernel [09:13] 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] morphis__: 3.4!! [09:14] 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] 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] mwhudson: yeah, 3.4 [09:16] 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] morphis__: can you get at the logs by pulling an sd card or activating a debug shell or something? [09:16] mwhudson: yes, I am already doing that [09:17] morphis__: pastebin /var/log/console-conf/subiquity-debug.log pls [09:17] (filename might not be quite right) [09:18] mwhudson: hm, there is no console-conf log [09:19] morphis__: nothing in /var/log/console-conf at all? [09:19] nothing [09:19] special [09:19] https://paste.ubuntu.com/23215029/ [09:19] morphis__: initramfs? [09:19] yeah, can't get into the system otherwise [09:19] oh right [09:20] this is flashed on the internal flash memory [09:20] that doesn't look like a system that's booted a snappy image? [09:20] does it? [09:20] maybe, i can't remember how all this works [09:21] ah [09:21] mwhudson: my fault, found the log file [09:21] morphis__: isn't it going to be /root/writable/system-data/... or something? [09:21] https://paste.ubuntu.com/23215037/ [09:22] 09/22 09:10 subiquitycore.utils:130 run_command returning: {'err': 'Error in network definition //etc/netplan/00-snapd-confi [09:22] g.yaml line 9 column 6: p2p0: No access points defined\n', 'status': 1, 'output': ''} [09:22] oh [09:22] i've fixed that bug [09:22] morphis__: can you try edge ubuntu-core? [09:22] so console-conf does not put any configuration in place and then netplan fails to apply that [09:22] mwhudson: sure [09:23] i misunderstood a bit what netplan accepted [09:24] PR snapd#1944 closed: many: validate refreshes against validation assertions by gating snaps [09:24] mwhudson: ah :-) [09:24] mwhudson: and another one where I saw a crash of netplan: https://paste.ubuntu.com/23215041/ [09:26] morphis__: looks like the same thing on first blush [09:27] mwhudson: see the: AttributeError: 'BackgroundProcess' object has no attribute 'proc' [09:28] morphis__: oh, i fixed that too [09:28] (without really understanding it :/) [09:28] great :-) [09:28] lets see how edge goes [09:30] mwhudson: ah, works again! [09:31] morphis__: hooray, sorry for the bugs [09:33] mwhudson: no problem :-) [09:35] PR snapd#1976 opened: tests: skip some tests on non-amd64 architectures [09:36] mvo: is there an easy way how I can programatically determine the OS snap revision in a channel? [09:37] mvo: or via the snap command [09:40] only the installed snap version [09:41] and for the non-manually built snaps you can look up the info at http://people.canonical.com/~ogra/ubuntu-core-builds/ [09:41] (i havent added manifests and changelogs yet ... that a weekend project) [09:41] *that's [09:42] :-) [09:42] morphis__: there's no command for that atm, you can query the store directly though [09:42] looks like I can abuse snap download --edge ubuntu-core for that [09:43] pedronis: you have a link to the store API? [09:43] i think you can also just check for upgradeability ... [09:43] morphis__: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Details [09:43] thanks [09:44] snap refresh --list [09:44] that shows if there is a newer core [09:45] "snap refresh --list --beta" actually :) [09:46] --list doesn't take channels atm [09:46] I think [09:47] ogra@bbb:~$ snap refresh --beta --list [09:47] error: --list does not take mode nor channel flags [09:47] yeap ... looks like you know the error msg :) [09:48] 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] but if the image is baseed on beta it will show the beta channel snaps i suppose [09:48] pedronis: thanks! [09:49] ogra_: yes [09:49] is just that if things are up-to-date [09:49] it will just say they are up to date [09:49] yeah [09:50] 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] (and first look up the changelog before you decide upgrdaing wont break your hacked up setup ;) ) [09:52] thats probably better than having it auto-refresh over night and being greeted with a bricked device :) [10:04] PR snapd#1972 closed: tests: increase timeout for key generation in create-key test === mup_ is now known as mup [10:14] ogra_: did you strace -tt console-conf --help? does python3 --help also take that long? [10:14] ogra_: i. e. is that really just python itself, or something specific to console-conf? [10:14] (some expensive import or what not) [10:14] pitti, sorry, i had a ton of distracting things today, u'll get to the strase soon [10:14] I cannot imagine that python takes an effing 20 seconds to start -- the hardware can't be *that* slow [10:15] *i'll get to the strace ... [10:15] ogra_: no hurry, just overheard it on the ML [10:15] it was more like curiosity/disbelief [10:15] I cannot imagine that this can just be attributed to hw slowness; there must be some bug somewhere [10:15] maybe the RNG hits again :) [10:16] 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] Bug #1622893: NetworkManager takes very long to start, or times out, blocked on RNG

[10:17] 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] (this is why micropython exists) [10:18] 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] (we never ran long-running python processes on the arm devboard images) [10:19] technically what we'd want would be https://micropython.org/ packaged in ubuntu-core ... instead of python3 [10:25] where can i open a bug against ubuntu-image? [10:25] https://bugs.launchpad.net/ubuntu-image [10:35] 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] morning all [11:04] PR snapd#1977 opened: interfaces/builtin: add netplan-observe interface [11:18] PR snapd#1965 closed: asserts: support for maps in assertions [11:39] didrocks: didrocks I'm sorry, was this about $HOME? [11:49] $ cat pi2-tvoss.model | grep kernel [11:49] kernel: ubuntu-raspi2-kernel [11:50] $ 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] $ unsquashfs -l ubuntu-raspi2-kernel_4.4.0_armhf.snap [11:50] ... [11:50] squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep [11:50] squashfs-root/lib/modules/4.4.19-xenial_raspi2+/modules.dep.bin [11:50] ... [11:51] notice the version: 4.4.19-xenial_raspi2+ [11:51] zyga: correct [11:52] $ unsquashfs -l /media/flag/writable/system-data/var/lib/snapd/snaps/ubuntu-raspi2-kernel_x1.snap [11:52] ... [11:52] squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.builtin [11:52] squashfs-root/lib/modules/4.4.16-xenial_raspi2+/modules.order [11:52] ... [11:53] 4.4.16 [11:53] so it's using a different kernel, and not the one i'm passing on the command line [11:53] can anyone explain why? [12:01] are you all on Rocket chat too or should I generally use IRC more? [12:03] zyga: ping [12:04] Mr. Newbie just has stupid questions [12:07] Son_Goku: hello [12:07] Son_Goku: what's up? [12:07] you're alive!!! [12:07] I've not heard from you nearly all month [12:07] Son_Goku: yes, though my back hurts all day lately :/ [12:07] :( [12:07] what happened? [12:08] Son_Goku: back? just the way it is, weather, more work [12:08] Son_Goku: test-snapd-tools [12:08] hmm [12:08] https://plus.google.com/+ZygmuntKrynicki/posts/fPj5PaDFbgk [12:08] that's better [12:08] that's why I was quiet for a while [12:08] remember that "small thing I need to do in snap-confine", well that too NaN minutes to do [12:09] jeez [12:09] Son_Goku: I could use a hand with designing one thing [12:09] hm? [12:10] Son_Goku: we'll have to release snapd once again (hopefully today) before this is doable [12:10] Son_Goku: but I could use a hand with /snap migration [12:10] yes [12:10] Son_Goku: I realized that this is more tricky than initially assumed [12:10] Son_Goku: all snap services need to be stopped [12:10] Son_Goku: all units unmounted [12:10] oh dear [12:10] Son_Goku: all units adjusted [12:10] Son_Goku: all units renamed as systemd requires that the file name matches the internal path [12:10] it's essentially the same as doing an offline update [12:10] Son_Goku: totally [12:11] 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] Son_Goku: my current plan is to use VM snapshots [12:11] Son_Goku: and just code this defensively [12:11] Son_Goku: and iterate a while until I feel it's good [12:11] probably an okay idea [12:11] Son_Goku: this is obviously just for COPR [12:11] Son_Goku: but it has to be there first [12:12] Son_Goku: once copr is moved the rest is easy [12:12] well, for copr, it might not be as horrible as you think [12:12] Son_Goku: if you have a VM handy I could use you do do some reviews and test migrations [12:12] you can move everything, and just create a symlink to /snap -> new location [12:12] Son_Goku: ohhhh [12:12] Son_Goku: hmm D: [12:12] well, see, why didn't I think of that :D [12:12] that's what we did for UsrMove [12:13] so still stop-the-world [12:13] do a symlink [12:13] yep [12:13] perhaps rewrite state.json (need to check) [12:13] and bring it up [12:13] * zyga ponders [12:13] but how is the symlink useful then? [12:13] and I *think* this can also be conditionalized as a %pretrans that occurs only if older versions of snapd are detected [12:13] apart from, maybe, just $PATH being still valid [12:13] nah, thats irrelevant, I would keep this in COPR forever and stop updating it [12:14] ah [12:14] Son_Goku: all subsequent updates would be in the repo [12:14] right [12:14] so you'd probably still want to apply a migration to all units and whatnot [12:14] yes, I have to [12:14] everything [12:14] actually [12:14] it might be easier to say this [12:14] the migration removes all snaps [12:14] and re-installs them [12:14] keeping data (that could be a hack) [12:14] well, no I still need [12:14] man this is complex [12:15] ... [12:15] lots of moving parts [12:15] no one ever thought this might be a problem, which is extraordinarily surprising, given Ubuntu's upstream? [12:15] ? [12:16] moving stuff around is hard when it is live [12:16] the /snap path is a violation of Debian Policy [12:16] that's why I'd rather not do it but that cat is out of the bag [12:16] so I was surprised that you guys even did it that way to begin with [12:16] well, /magic would be too because that's a new thing. doesn't mean that policy is set in stone :) [12:16] well, it tends to be [12:17] if that were the case /etc would still ship executables [12:17] I've not seen Debian Policy change significantly in the last decade or so [12:17] and we'd be using vms or something [12:17] haha [12:17] well, back to earth, I'll draft a migration script and share it [12:17] right [12:17] I'm coming back to the light, I hope :) [12:17] I hope so too [12:18] we were nearing the "DEADREVIEW" state for all the stuff [12:18]