| === cmars` is now known as cmars | ||
| mup | Bug #1616833 changed: need new interface: time-hardware <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1616833> | 04:20 |
|---|---|---|
| === hikiko|off is now known as hikiko | ||
| mup | Bug #1616833 opened: need new interface: time-hardware <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616833> | 05:50 |
| liuxg | does anyone know a configure hook example for snappy? I want to make use of it in my project. thanks | 06:19 |
| liuxg | didrocks, ping | 06:26 |
| didrocks | hey liuxg | 06:28 |
| dholbach | good morning | 06:28 |
| didrocks | liuxg: do you run snapd master? | 06:28 |
| didrocks | you need it to have configure hook support | 06:28 |
| didrocks | hey dholbach | 06:28 |
| dholbach | salut didrocks | 06:28 |
| liuxg | didrocks, it was nice to meet you there in Netherlands. yes, I just read the doc at https://github.com/snapcore/snapd/blob/master/docs/hooks.md. it was not so clear to me. | 06:28 |
| didrocks | liuxg: yeah, it's not in the current xenial snapd version, but will be in next release | 06:29 |
| liuxg | didrocks, what should I do in the snapcraft.yaml file? How to implement it in practice? should I create a directory like the "setup" in for the desktop file? or I need to do sth in the snapcraft.yaml file? | 06:30 |
| liuxg | didrocks, the document is not clear to me, and I think it may be confusing to others as well. | 06:31 |
| didrocks | liuxg: documentation remarks is for davidcalle :) | 06:31 |
| didrocks | liuxg: but you can contribute to them as well! | 06:31 |
| didrocks | liuxg: you were in the session about hook and snapcraft IIRC | 06:31 |
| didrocks | as told there, nothing is supported yet | 06:31 |
| liuxg | didrocks, yeah, I know. if I know how to do it, I can definitely contribute to it. | 06:31 |
| liuxg | didrocks, ok. then it is clear to me. | 06:31 |
| didrocks | for now, the only thing right now is to ship a "configure" file in the correct place | 06:32 |
| didrocks | and it will be executed | 06:32 |
| liuxg | didrocks, I see. thanks | 06:32 |
| didrocks | liuxg: then snap set <snap_name> key value will execute it | 06:32 |
| liuxg | didrocks, I think I can use "dump" to set the file into the right place. do you mean that the current snapd does not support it yet, right? if this is the case, I have no way to test it. | 06:33 |
| didrocks | liuxg: IIRC, there was a piece missing for the current snapd to execute it (I didn't test it myself). You can compile master git version and replace your snapd with it though | 06:34 |
| didrocks | liuxg: yeah, dump plugin is possible | 06:34 |
| didrocks | liuxg: I'll spend some times in the following week to provide an example and shape best practices FYI | 06:35 |
| liuxg | didrocks, ok. I'll try it to see how it goes. | 06:35 |
| liuxg | didrocks, that would be cool :) | 06:35 |
| didrocks | liuxg: keep me posted! ;) | 06:35 |
| didrocks | yep | 06:35 |
| mup | Bug #1636383 opened: autoupdate.md needs an update <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1636383> | 06:35 |
| didrocks | we need best practices to have all hooks similars | 06:36 |
| liuxg | didrocks, yes, definitely | 06:36 |
| liuxg | didrocks, I used to use config to do that in 15.04 | 06:37 |
| didrocks | right! It's not that different | 06:37 |
| === darrenwu_ is now known as darrenwu | ||
| === ondra_ is now known as ondra | ||
| zyga | o/ | 07:14 |
| === mbriza_ is now known as mbriza | ||
| liuxg | didrocks, I did not update the snapd, when I tried to configure my hello example. it complained that "- Run configure hook for hello (cannot snap-exec: cannot find hook "configure" in "hello")". The configure file is located inside the package http://paste.ubuntu.com/23377809/ | 07:51 |
| didrocks | liuxg: yeah, so I guess you need latest tip master | 07:53 |
| liuxg | didrocks, I think I might need to wait for the latest snapd. interestingly, it did search for the hook. | 07:55 |
| morphis_ | mwhudson: you know when subiquity 0.20 will land in xenial-updates? | 08:05 |
| === seb128_ is now known as seb128 | ||
| ogra_ | morphis_, it is in the image PPA since friday | 08:50 |
| ogra_ | so in all recent core snaps | 08:50 |
| ogra_ | morphis_, i also dont see any upload to xenial at all for 0.20 beyond this | 08:52 |
| mvo | ogra_: hey, how are things looking today on pi2/pi3/dragon - anything new? or still network issues? if so, what are the details? just wifi or wired as well? | 08:52 |
| ogra_ | mvo, only wifi ... though ewhen you try to config wifi the whole network setup breaks (cant configure wired anymore, needs reboot) | 08:53 |
| ogra_ | mvo, it seems also that console-conf never actually applies the changed config (i get the default network setup that was applied during boot before console-conf ran unless i call "netplan apply" or do a reboot) | 08:54 |
| ogra_ | so it looks like two issues ... wifi ... and applying the config without reboot | 08:55 |
| mvo | ogra_: hmm, ok. do we have bugs for this yet? if so, I will add them to trello to ensure we have it as a blocker | 08:55 |
| ogra_ | beyond this, there is still the slowness when creating the user that i try to dig down since a while | 08:55 |
| mvo | ogra_: thanks! so wifi means its not possible to configure it at all? or does it crash? | 08:55 |
| ogra_ | both ... | 08:56 |
| ogra_ | it is not possible at all ... if you then restart the network config often enough you finally get a traceback (10-20x) | 08:56 |
| mvo | hrm hrm | 08:57 |
| ogra_ | (but i guess most people reboot before they get into that area to actually see a crash, since you cant really do anything) | 08:57 |
| mup | PR snapd#2209 opened: interface hooks: confirm plug slot hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2209> | 08:57 |
| ogra_ | there is definitely interaction issuesbetween netplan and console-conf on some layer ... | 08:57 |
| ogra_ | what seems to work is: configure with wired interface, reboot and then run sudo console-conf again, that actually lets you re-configure to use wlan only | 08:59 |
| ogra_ | there is something in the firstboot that plays into the wlan issue here ... on second boot the interface is there | 08:59 |
| ogra_ | (all very obscure) | 08:59 |
| ogra_ | mvo, bug 1632387 | 09:01 |
| mup | Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632387> | 09:01 |
| ogra_ | bug 1624322 | 09:02 |
| mup | Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1624322> | 09:02 |
| morphis_ | ogra_: hm, then we need to get it into xenial-updates soon otherwise the release on thursday is without it | 09:03 |
| ogra_ | morphis_, ? | 09:03 |
| rvr | ogra_: Is the Dragonboard network problem fixed? | 09:04 |
| ogra_ | morphis_, it is in the core snap | 09:04 |
| ogra_ | morphis_, in the one we'll push to stable | 09:04 |
| morphis_ | ogra_: from what I've heard stable will be be only build from xenial and not the overlay ppa | 09:04 |
| morphis_ | so everything from the overlay needs to go into the archive | 09:04 |
| ogra_ | morphis_, yeah, we wish to do that ... but if that doesnt work we wont artificially regress the core rootfs :) | 09:04 |
| morphis_ | ogra_: its just a wish? :-) | 09:05 |
| morphis_ | niemeyer sounded different on this last week | 09:05 |
| ogra_ | we'll try our best ... but do you really think we'll rip things out on release day if they dont land in time ? | 09:06 |
| morphis_ | not really :-) | 09:06 |
| mwhudson | morphis_: np | 09:07 |
| mwhudson | er | 09:07 |
| mwhudson | morphis_: no | 09:07 |
| morphis_ | mwhudson: ok | 09:08 |
| mwhudson | morphis_: i didn't realize that it was particularly desired | 09:09 |
| ogra_ | well, we want stable images to come from the archive | 09:09 |
| mvo | mwhudson: hey, nice to see you :) did you/your team had a chance to look at the issues that ogra outlined with networking with console-conf? | 09:09 |
| mwhudson | mvo: the only issues i've seen mention of seem completely inscrutable | 09:09 |
| mwhudson | mvo: but to be clear, which issues do you mean? | 09:10 |
| ogra_ | mwhudson, see the two bugs above as a start | 09:10 |
| mwhudson | ogra_: so https://bugs.launchpad.net/snappy/+bug/1632387 is the one that makes no sense at all | 09:10 |
| mup | Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632387> | 09:10 |
| mvo | mwhudson: I'm just the messanger, I don't have a pi3/dragonboard but AIUI from ogra_ these are blockers on these boards | 09:11 |
| mwhudson | ogra_: i have a plan for https://bugs.launchpad.net/snappy/+bug/1624322 but going to be quite involved | 09:11 |
| mup | Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1624322> | 09:11 |
| mwhudson | (i.e not this week) | 09:11 |
| ogra_ | mwhudson, i think either console-conf starts to early or there is something missing in the first boot at all ... that might be a systemic thing | 09:11 |
| ogra_ | mwhudson, but in general wifi config is impossible since last subiquity update | 09:12 |
| ogra_ | for that we dont have a bug yet | 09:12 |
| mwhudson | i can try it on my (still serial-less :-( ) dragonboard tomorrow | 09:12 |
| mwhudson | filing a bug definitely makes it more likely that i will not forget | 09:13 |
| ogra_ | indeed ... i spent all day digging into that yesterday, sorry, havent filed that one yet | 09:13 |
| ogra_ | mwhudson, also if you restart the network config bit often enough (cancel->start) you eventually get greetet with a two page traceback | 09:14 |
| ogra_ | (only found that one yesterday evening) | 09:14 |
| mwhudson | ogra_: huh | 09:14 |
| mwhudson | i don't suppose you were actually able to read the traceback? | 09:15 |
| mwhudson | (for some reason you get this annoying doubled traceback whenever console-conf crashes) | 09:15 |
| ogra_ | something about "file exists" ... seemed to come from netplan | 09:16 |
| ogra_ | or from netplan interaction at least | 09:16 |
| ogra_ | it only happens on failed config if you repeat it a few times | 09:17 |
| ogra_ | (and i have only seen it with multiple network devices (dragon + USB NIC or rpi3 which has two by default) | 09:18 |
| ogra_ | ) | 09:18 |
| mwhudson | the file exists thing is the "extra" traceback | 09:18 |
| mwhudson | there would have been one about that | 09:18 |
| ogra_ | mwhudson, also, netplan apply is never called when console-conf finishes ... | 09:19 |
| mwhudson | it's probably something stupid in probert | 09:19 |
| mwhudson | *one above that | 09:19 |
| mwhudson | ogra_: ?? | 09:19 |
| ogra_ | i can see the /etc/netplan config changed, but not the interface setiup | 09:19 |
| vigo | ogra_, I hit bug #1624322 also with dragonboard, with an image build by me wlan0 was not offered and when using your latest image it gives me the network timeout | 09:19 |
| mup | Bug #1624322: console-conf wlan race on pi3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1624322> | 09:19 |
| ogra_ | mwhudson, it keeps the same setup i got from the initial boot before console-conf was up ... if i call "netplan apply" manually after ssh'ing in for the first time, it applies it | 09:20 |
| ogra_ | mwhudson, or on reboot | 09:20 |
| mwhudson | ogra_: i definitely did not deliberately delete the code to call netplan apply... | 09:20 |
| ogra_ | no, i can definitely see it in the tasks enumeration in the code | 09:21 |
| ogra_ | vigo, thanks for confirming ! | 09:21 |
| rvr | https://bugs.launchpad.net/snappy/+bug/1636419 | 09:21 |
| mwhudson | if for some reason it's not being called that would certainly explain why the wlan is never connecting... | 09:21 |
| mup | Bug #1636419: Network settings aren't set in Dragonboard <Snappy:New> <https://launchpad.net/bugs/1636419> | 09:21 |
| mup | Bug #1636419 opened: Network settings aren't set in Dragonboard <Snappy:New> <https://launchpad.net/bugs/1636419> | 09:21 |
| mwhudson | ogra_: can you dig out the /var/log/console-conf/subiquity-debug.log file? | 09:22 |
| ogra_ | mwhudson, right ... if i reboot it shows me the SSID ... but if i re-rty without going to "configure wlan" again it tries to apply it without key | 09:22 |
| deadlock | Hello, guys. Someone knows how to install snap on openSUSE Tumbleweed correctly? That doesn't works here: http://snapcraft.io/docs/core/install#opensuse The snapd service doesn't starts. | 09:23 |
| vigo | rvr, I passed the network screen | 09:26 |
| rvr | vigo: With today's image? | 09:26 |
| rvr | vigo: Without rebooting? | 09:26 |
| vigo | rvr, just after reboot ehehe | 09:26 |
| vigo | yes | 09:26 |
| rvr | vigo: Then it's not the same test case ;) | 09:26 |
| rvr | vigo: Yeah, I could too after rebooting, because the credentials are stored and applied | 09:27 |
| ogra_ | mwhudson, http://paste.ubuntu.com/23378076/ ... btw ... you should really hide the WPA key from that log :) | 09:27 |
| vigo | rvr, that's it | 09:27 |
| mwhudson | ogra_: yeah, probably, at least its -r-------- now | 09:27 |
| ogra_ | deadlock, i guess zyga could help, but i dont know if he is around today | 09:27 |
| rvr | mwhudson: ogra_: Yeah, he should, I sent you mine WPA password yesterday :D | 09:28 |
| rvr | s/mine/my/ | 09:28 |
| ogra_ | mwhudson, right, but i have to edit it to attach it to bugs or pastebin | 09:28 |
| mwhudson | ogra_: yes, fair, file a bug pls? | 09:28 |
| ogra_ | will do | 09:28 |
| rvr | ogra_: mwhudson: I already did, see above | 09:29 |
| mwhudson | well it sure looks like it calls netplan apply and it returns status == 0 and nothing on stdout or stderr | 09:29 |
| mwhudson | rvr: about the WPA PSK being in the log? | 09:29 |
| rvr | mwhudson: Nope, about the network in the Dragonboard | 09:30 |
| mwhudson | rvr: right, that's not what i meant | 09:30 |
| deadlock | ogra_, thank you. | 09:30 |
| deadlock | zyga, can you help me? | 09:30 |
| jgdx | question: if I were to snap latexlive-full, how would one use pdflatex on an all-snappy system? Would some content transfer be necessary? Usually there's a bunch of files involved, not just the .tex file | 09:31 |
| ogra_ | mwhudson, bug 1636421 | 09:31 |
| mup | Bug #1636421: console-conf should hide WLAN keys from logfiles <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636421> | 09:31 |
| ogra_ | rvr, ^^^ feel free to confirm | 09:32 |
| * ogra_ is afk for 20min | 09:32 | |
| rvr | ogra_: Done | 09:33 |
| mup | Bug #1636421 opened: console-conf should hide WLAN keys from logfiles <Snappy:Confirmed> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636421> | 09:34 |
| mwhudson | ogra_: ta | 09:35 |
| vigo | rvr, I'm confirming your bug ok? | 09:36 |
| rvr | vigo: Thanks! | 09:36 |
| mvo | deadlock: hello, zyga may be able to help with snapd on suse | 09:41 |
| deadlock | mvo, thank you | 09:42 |
| zyga | re | 09:47 |
| zyga | ah, sorry, lost connection there for a sec | 09:47 |
| zyga | deadlock: how can I help you | 09:48 |
| mup | PR snapd#2203 closed: snap: switch the auto-import dir to /run/snapd/auto-import <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2203> | 09:59 |
| mup | Bug #1635604 opened: console-conf should be localized <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1635604> | 10:04 |
| Son_Goku | deadlock & zyga: snapd has been FTBFS for Tumbleweed for a while now | 10:14 |
| Son_Goku | as has snap-confine | 10:14 |
| Son_Goku | actually, most of the snappy project is broken across Leap and Tumbleweed: https://build.opensuse.org/project/monitor/system:snappy | 10:14 |
| zyga | Son_Goku: yep, I'm guiding deadlock on fixing that | 10:14 |
| deadlock | Son_Goku, thank you. I'm talking with zyga in private | 10:15 |
| Son_Goku | okay, :) | 10:15 |
| zyga | Son_Goku: I'm looking at https://github.com/zyga/mounted-fs-memory-checker | 10:16 |
| zyga | Son_Goku: there's something super weird going on | 10:16 |
| zyga | Son_Goku: same kernel, same snap, memory usage on UP system is 131MB per mounted snap vs 7MB on a 4-core system | 10:16 |
| zyga | Son_Goku: no idea why yet | 10:16 |
| Son_Goku | ~_~ | 10:16 |
| mup | PR snapd#2210 opened: debian: only install share/locale if available (missing on powerpc) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2210> | 10:17 |
| zyga | Son_Goku: I'm checking on fedora kernel now | 10:20 |
| morphis_ | mvo: where do you guys get the -core image for spread from you have configured in https://github.com/snapcore/snapd/blob/master/spread.yaml#L44 ? | 10:26 |
| mvo | morphis_: the qemu ones? check https://github.com/snapcore/snapd/blob/master/HACKING.md#running-the-spread-tests | 10:27 |
| morphis_ | let me see | 10:27 |
| morphis_ | mvo: so they are no real core images? | 10:28 |
| morphis_ | with kernel and gadget snap etc. | 10:28 |
| === e is now known as deadk | ||
| zyga | morphis_: they are but they are made each time | 10:29 |
| morphis_ | interesting | 10:30 |
| mvo | morphis_: they are morphed into them, we need to modify some key aspects (like the snapd) of the image to generate them | 10:30 |
| mvo | morphis_: you should look at the code, its quite fun how we do it | 10:30 |
| morphis_ | looking already but that gives me a idea of what the code is doing | 10:31 |
| mvo | morphis_: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L80 | 10:31 |
| morphis_ | wow, you boot a classic image first and then reflash the image on the firstboot? | 10:32 |
| Son_Goku | mvo, is the core snap still called "ubuntu-core" or is it just called "core"? | 10:33 |
| morphis_ | mvo: one other quick thing, joc_ currently has problems importing a key into the snap keyring, is that something you can help with? | 10:33 |
| joc_ | looks like i need to be using --homedir to get to the correct keyring | 10:35 |
| joc_ | yep that did it | 10:37 |
| ogra_ | Son_Goku, you should only use "core" for anything new ... the ubuntu-core is still built in parallel but will eventually vanish | 10:40 |
| Son_Goku | ah okay | 10:40 |
| Son_Goku | how is the core snap built? | 10:40 |
| ogra_ | https://code.launchpad.net/~snappy-dev/+snap/core | 10:41 |
| ogra_ | http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/files has the Makefile this uses | 10:41 |
| ogra_ | (there is also a readme) | 10:42 |
| ogra_ | Son_Goku, we use livecd-rootfs/live-build as our creator backend ... i guess for fedora you want to use sommething like anaconda (or whatever the successor is since i had to deal last with that stuff) | 10:43 |
| Son_Goku | we have lorax for building things like this: http://lorax.readthedocs.io/en/latest/intro.html | 10:43 |
| Son_Goku | it uses anaconda as the engine | 10:43 |
| ogra_ | ah, k | 10:44 |
| ogra_ | on the first link, if you click on any of the "Successfully built" links you get to the build details, there is a manifest file that lists all the debs included | 10:44 |
| Son_Goku | cool | 10:45 |
| ogra_ | i also have a summary page (mainaly for my own overview) that screen-scrapes launchpad and summarizes everything at http://people.canonical.com/~ogra/core-builds/ | 10:45 |
| ogra_ | (super hackish, but helpful :) ) | 10:46 |
| Son_Goku | that's useful | 10:46 |
| zyga | Son_Goku: any luck with the policy? I wanted to see if we can push snapd forward today | 10:47 |
| Son_Goku | not yet, no | 10:47 |
| Son_Goku | I'm about to send an email asking for some help with this | 10:48 |
| zyga | thank you, that would be very useful! | 10:48 |
| morphis_ | joc_: great! | 10:49 |
| zyga | morphis_: hey did you guys get a chance to try udisks2 last week? | 10:49 |
| ogra_ | rvr, regarding bug 1636419 ... it works for me on second boot (but you need to do all of the configuration again, even if console-conf seems to already have your WLAN credentials) | 10:50 |
| mup | Bug #1636419: Network settings aren't set in Dragonboard <Snappy:Confirmed> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1636419> | 10:50 |
| morphis_ | zyga: I started with it but I am testing it again today | 10:50 |
| zyga | morphis_: anything broken yet? | 10:51 |
| rvr | ogra_: Yes, after reboot it works | 10:51 |
| morphis_ | zyga: not yet :-) | 10:51 |
| ogra_ | rvr, mention that in the bug then ;) | 10:51 |
| rvr | ogra_: vigo did in a comment | 10:51 |
| ogra_ | oh, i see it now ... sorry ... blind man here | 10:51 |
| zyga | morphis_: knock on wood, let's hope it stays okay | 10:52 |
| zyga | morphis_: there's some odd memory usage I'm still debugging | 10:52 |
| morphis_ | zyga: flashing the rc image for x86 again right now, lets see what comes then | 10:52 |
| vigo | ogra_, hehe for me sometimes it takes more than just one reboot I don't know why sometimes is not saving the network conf | 10:52 |
| ogra_ | vigo, i noted that it doesnt apply the ppassword if i dont go through the whole wlan config again on second boot | 10:53 |
| vigo | ogra_, yeap :( | 10:54 |
| ogra_ | (i.e.. it has the SSID in the config file in /etc/netplan but not the password) | 10:54 |
| mup | Bug #1624913 changed: Ubuntu-Core does not list any snaps on newly installed device <Snappy:New> <https://launchpad.net/bugs/1624913> | 10:58 |
| === Guest95404 is now known as ahasenack | ||
| === ahasenack is now known as Guest59736 | ||
| mup | PR snapcraft#869 closed: Bring docs/upload-your-snap.md in line with http://snapcraft.io/docs/… <Created by dholbach> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/869> | 11:18 |
| mup | Bug #1635170 opened: No warnings of what's unclean paths leads to terrible UX <Snappy:Triaged> <https://launchpad.net/bugs/1635170> | 11:31 |
| Son_Goku | zyga, gah | 11:37 |
| Son_Goku | this is all your fault! | 11:37 |
| Son_Goku | the label never applies to /run/snapd.sock | 11:37 |
| Son_Goku | that's where snapd.socket is creating the file | 11:37 |
| Son_Goku | GAHHH | 11:40 |
| zyga | Son_Goku: why and how is that my fault? | 11:42 |
| Son_Goku | your snapd.socket file has the wrong path | 11:42 |
| Son_Goku | which broke everything :P | 11:42 |
| Son_Goku | also apparently the hello snap can't find the core snap | 11:42 |
| Son_Goku | it pulled in ubuntu-core instead of core, as well | 11:42 |
| Son_Goku | [root@f24-kde-skuld-vm run]# snap run hello | 11:42 |
| Son_Goku | cannot locate the core snap. errmsg: No such file or directory | 11:42 |
| zyga | Son_Goku: I still don't see how that's my fault or how finger pointing helps but lets not dwell ;) | 11:43 |
| ogra_ | there is no coire in the stable channel yet ... | 11:43 |
| zyga | Son_Goku: are you using the new snap-confine from master? | 11:43 |
| Son_Goku | no | 11:43 |
| ogra_ | it might be looking for stable ... | 11:43 |
| Son_Goku | I'm using the latest you built in Koji | 11:43 |
| zyga | Son_Goku: that's the right one | 11:43 |
| zyga | Son_Goku: can you run anything with SNAP_CONFINE_DEBUG=yes please | 11:43 |
| zyga | Son_Goku: it is probably something very trivial | 11:44 |
| Son_Goku | sure | 11:44 |
| Son_Goku | https://paste.fedoraproject.org/460616/39587114/ | 11:44 |
| Son_Goku | zyga ^ | 11:44 |
| zyga | and the output of "snap list" please | 11:45 |
| zyga | and lastly see the mounted snaps please | 11:47 |
| Son_Goku | with the debug stuff, right? | 11:47 |
| zyga | that is separate | 11:47 |
| Son_Goku | [root@f24-kde-skuld-vm run]# snap list | 11:47 |
| Son_Goku | Name Version Rev Developer Notes | 11:47 |
| zyga | I mean, the environment variable above only affects snap-confine | 11:47 |
| Son_Goku | hello 2.10 20 canonical devmode | 11:47 |
| Son_Goku | ubuntu-core 16.04.1 423 canonical - | 11:47 |
| zyga | ok | 11:47 |
| zyga | where is it mounted? | 11:48 |
| Son_Goku | tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,seclabel,mode=755) | 11:48 |
| zyga | ubuntu-core | 11:48 |
| Son_Goku | /var/lib/snapd/snaps/ubuntu-core_423.snap on /var/lib/snapd/snap/ubuntu-core/423 type squashfs (ro,relatime,seclabel) | 11:48 |
| Son_Goku | /var/lib/snapd/snaps/hello_20.snap on /var/lib/snapd/snap/hello/20 type squashfs (ro,relatime,seclabel) | 11:48 |
| zyga | that looks good | 11:48 |
| zyga | can you check if snap-confine is built with /var/lib/snapd/snap | 11:48 |
| zyga | no typos or anything | 11:48 |
| zyga | or mising trailing slash | 11:48 |
| Son_Goku | certainly | 11:48 |
| zyga | it might be something as trivial as this | 11:49 |
| Son_Goku | also, debugging selinux policy module in #fedora-selinux now too :) | 11:49 |
| Son_Goku | ugh | 11:49 |
| Son_Goku | yeah, I know what happened | 11:50 |
| Son_Goku | [root@f24-kde-skuld-vm run]# rpm -E "%{_sharedstatedir}/lib/snapd/snap" | 11:50 |
| Son_Goku | /var/lib/lib/snapd/snap | 11:50 |
| Son_Goku | zyga, take off the "/lib" in http://pkgs.fedoraproject.org/cgit/rpms/snap-confine.git/tree/snap-confine.spec#n41 | 11:50 |
| Son_Goku | it should be "%{_sharedstatedir}/snapd/snap" | 11:50 |
| zyga | ah :D | 11:52 |
| zyga | do we need the trailing slash? | 11:53 |
| zyga | Son_Goku: so? :) does it work? | 11:58 |
| Son_Goku | dunno, I'm about to rebuild and try | 11:59 |
| zyga | ++ thank you | 11:59 |
| Son_Goku | no trailing slash required | 12:02 |
| Son_Goku | it works | 12:02 |
| zyga | !!! | 12:03 |
| zyga | wooooot | 12:03 |
| Son_Goku | also... https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/eefa7cedd11ad91da8e240732e474124282f5846 | 12:03 |
| zyga | merge it back! | 12:03 |
| Son_Goku | I will, one sec | 12:03 |
| zyga | what's -s vs -- | 12:03 |
| Son_Goku | socket vs regular file | 12:06 |
| zyga | ah, I see | 12:08 |
| Son_Goku | I've pushed new snap-confine builds to koji | 12:11 |
| Son_Goku | I'm going to test my changes for the selinux policy | 12:11 |
| zyga | Son_Goku: thank you | 12:14 |
| popey | ogra_: you recall I re-flashed my busted pi3 again yesterday. Today I wake to find it's no longer on the network. Serial console shows localhost login: | 12:14 |
| popey | ogra_: I think it did an update overnight. | 12:14 |
| abeato | jdstrand, hi, https://github.com/snapcore/snapd/pull/2058 should be ready when you have a slot to take a look :) | 12:15 |
| mup | PR snapd#2058: interfaces: add ofono interface <Created by alfonsosanchezbeato> <Conflict> <https://github.com/snapcore/snapd/pull/2058> | 12:15 |
| diddledan_ | does cleanbuild create multiple architectures if they're defined in the yaml file? | 12:16 |
| diddledan_ | I'm investigating a snap just build and it seems to only have the amd64 stuff | 12:16 |
| Son_Goku | zyga, did you contact the package maintainer of the dep that's broken in f23 for snapd? | 12:16 |
| diddledan_ | I've added `architectures: [amd64, i386]` to the yaml | 12:16 |
| zyga | Son_Goku: not yet | 12:17 |
| zyga | Son_Goku: I don't know which one it is | 12:17 |
| zyga | Son_Goku: it was network related but that's all I know | 12:17 |
| zyga | diddledan_: no, there's no general cross-building | 12:18 |
| zyga | diddledan_: you can use launchpad to build your snap for any architecture if that helps | 12:18 |
| diddledan_ | ok. feature request :-) | 12:18 |
| diddledan_ | thanks zyga | 12:18 |
| zyga | well, hard to do | 12:19 |
| diddledan_ | yeah, I've done manual cross compiling in the distant past and it was painful | 12:20 |
| Son_Goku | cross compiling is always painful | 12:20 |
| Son_Goku | most tooling isn't designed to handle host and target being different :/ | 12:20 |
| Son_Goku | nope, still not working | 12:22 |
| Son_Goku | yay, I broke the hello snap by simply uninstalling and reinstalling snapd | 12:32 |
| jdstrand | abeato: ack | 12:36 |
| abeato | thnaks | 12:36 |
| === mhall119_ is now known as mhall119 | ||
| ogra_ | popey, wired or wlan ? | 12:49 |
| zyga | Son_Goku: what happened when you did that? | 12:52 |
| Son_Goku | I get "command not found" | 12:52 |
| zyga | isn't the snap removed when you do that? | 12:53 |
| Son_Goku | yes, but it's not removed | 12:53 |
| Son_Goku | all the mounts are broken now, though | 12:53 |
| zyga | Son_Goku: the postup script probably needs to be adjusted | 12:54 |
| popey | ogra_: wired, it came back after a reboot. | 12:55 |
| ogra_ | weird | 12:55 |
| zyga | Son_Goku: anything I can merge? | 12:55 |
| Son_Goku | not yet | 12:55 |
| Son_Goku | hopefully soon, though | 12:55 |
| ogra_ | popey, did you ever reboot it before (i.e. after console-conf) | 12:55 |
| Son_Goku | still working out kinks in initial policy | 12:55 |
| popey | ogra_: don't think so. | 12:56 |
| ogra_ | popey, might be fallout of console-conf not running netplan apply | 12:57 |
| ogra_ | (which is then called on reboot apparently) | 12:57 |
| diddledan_ | this bug #1580740 is marked as fixed for xenial but seems to have been missed for yakkety | 13:08 |
| mup | Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-done> <xenial> <yakkety> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Fix Released> <snapd-xdg-open (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1580740> | 13:08 |
| diddledan_ | oic, it's present in the archive but hasn't been pulled automatically | 13:13 |
| diddledan_ | I think it should be depended upon by something? | 13:13 |
| zyga | Son_Goku: thank you! | 13:14 |
| morphis_ | ogra_: you had a site where you listed all content of all core snaps, can you give me the link again? | 13:16 |
| === ubuntu is now known as Guest74698 | ||
| ogra_ | morphis_, http://people.canonical.com/~ogra/ubuntu-core-builds/ ? | 13:18 |
| morphis_ | ogra_: yea! | 13:18 |
| ogra_ | morphis_, note though that this only lists auto-built snaps ... if mvo uses the LP ui for a build that wont show up | 13:19 |
| morphis_ | hm | 13:19 |
| ogra_ | (it only parses the log of the auto-build script) | 13:19 |
| ogra_ | so there can be gaps | 13:19 |
| === tyhicks` is now known as tyhicks | ||
| zyga | jdstrand: hey, good morning | 13:42 |
| zyga | jdstrand: how are you doing? | 13:42 |
| jdstrand | hey zyga :) | 13:42 |
| jdstrand | zyga: I'm good. glad to be back home. trying to get through a mount of email and sprint outcomes to translate to actual work items :) | 13:43 |
| jdstrand | zyga: how are you? | 13:43 |
| zyga | jdstrand: do you remember our converstation? I ran some tests and ended up with ... for the same .snap, 1MB all the way up to 131MB | 13:43 |
| zyga | jdstrand: my health is not very good after that week but I hope it improves, usual issues with my spine, but mood is good | 13:43 |
| jdstrand | zyga: sorry to here-- hope you feel better soon | 13:44 |
| zyga | jdstrand: I asked the kerel team for assistance and I'm working on measuring memory usage with snap-confine environment set up for each snap | 13:44 |
| jdstrand | hear* | 13:44 |
| jdstrand | sounds good | 13:44 |
| zyga | jdstrand: I made https://github.com/zyga/mounted-fs-memory-checker in case you want to try | 13:45 |
| zyga | jdstrand: the numbers I get are consistent in each VM/box but differ widely for no apparent reason | 13:45 |
| jdstrand | oh neat | 13:46 |
| mup | PR snapd#2211 opened: tests: test-snapd-fuse-consumer needs python-fuse as a build-package <Created by mvo5> <https://github.com/snapcore/snapd/pull/2211> | 13:49 |
| jdstrand | zyga: fyi, I passed this information on to the security team. I know they were interested in this topic | 13:51 |
| jdstrand | (the rest of the security team that is) | 13:51 |
| zyga | jdstrand: thanks! | 13:52 |
| ogra_ | ppisati, hmm, any idea why i end up with evbug auto-loaded all the time on the rpi ? its spilling a lot of crap to the logs | 14:00 |
| mup | PR snapd#2212 opened: spread tests: fix snap mode check <Created by stolowski> <https://github.com/snapcore/snapd/pull/2212> | 14:01 |
| ppisati | ogra_: nope | 14:03 |
| mup | PR snapd#2213 opened: tests: skip tests that use expect when expect is not working (like on ppc64el) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2213> | 14:05 |
| ogra_ | ppisati, also ... i just booted the pi3 with systemd debug console and see that despite having the brcmfmac module loaded there is no wlan device in /proc/net/dev ... that happens only on first boot though ... the devices shows up once i modprobe -r/modprobe the module | 14:06 |
| ogra_ | mvo, when exactly do we bind mount /lib/firmware in the boot process ? | 14:06 |
| ppisati | ogra_: do you see any message of fmac complaining about the lack of fw files? | 14:07 |
| ogra_ | nope | 14:07 |
| mvo | ogra_: pretty early, right after we mounted writable rw | 14:08 |
| ogra_ | the output actually looks all happy in dmesg and syslog | 14:08 |
| ogra_ | mvo, so initrd ? or systemd ? | 14:08 |
| mvo | ogra_: initrd | 14:08 |
| ogra_ | k | 14:08 |
| ogra_ | then its not that | 14:08 |
| mvo | ogra_: unless there are bugs of course, but nothing indicates that | 14:08 |
| ppisati | dmesg | grep brcm | 14:08 |
| ogra_ | i would really like to know why it only happens on first boot | 14:08 |
| ogra_ | i just re-flashed, gimme a sec | 14:09 |
| ppisati | k | 14:09 |
| ogra_ | (pretty annoying that i can only repro it on the very first boot, so if i manage to get the device show up i need to re-flash) | 14:10 |
| ppisati | even better | 14:10 |
| ppisati | dmesg | grep -e fmac -e brcm | 14:10 |
| tyhicks | zyga: I have been wondering if spitting the snap (squashfs image) out to disk on each boot is acceptable instead of mounting the snap on each boot | 14:11 |
| ogra_ | i get 4 lines ... (cant copy paste from tty console) | 14:11 |
| ogra_ | first one is usbcore telling me it loads the module | 14:11 |
| ogra_ | second is the firmware loading which looks all fine | 14:11 |
| zyga | tyhicks: I don't think we want that, we want to know what's broken | 14:12 |
| tyhicks | zyga: I don't see much of an advantage to actually have these things mounted versus unsquashed | 14:12 |
| zyga | tyhicks: my tests include ext4 and even vfat and there memory usage is next to nothing | 14:12 |
| zyga | tyhicks: integrity, simplicity, efficiency | 14:12 |
| ogra_ | ppisati, the next two are "brcmf_cfg80211_reg_notifier: not a ISO3166 code" | 14:12 |
| zyga | tyhicks: I've started comitting traces to the tree | 14:13 |
| zyga | tyhicks: you can now run the simple analyze.py script to see | 14:13 |
| tyhicks | zyga: I think these results are an argument against efficiency | 14:13 |
| tyhicks | zyga: I do agree with simplicity | 14:13 |
| zyga | tyhicks: well, efficiency vs copying | 14:13 |
| zyga | tyhicks: but honestly we need to know more, why is squashfs different from all the other fs'es | 14:14 |
| zyga | tyhicks: I asked the kernel team for support | 14:14 |
| * tyhicks nods | 14:14 | |
| tyhicks | zyga: I peeked through the code a bit - there's quite a bit of overhead involved in the squashfs metadata cache | 14:14 |
| ppisati | ogra_: something like this? | 14:15 |
| ppisati | ogra_: http://pastebin.ubuntu.com/23379090/ | 14:15 |
| tyhicks | zyga: the metadata is read from the image, decompressed, and sorted appropriately in an internal-to-squashfs cache | 14:15 |
| ogra_ | ppisati, yes, exactly this | 14:15 |
| ppisati | ogra_: good, then the wlan was initiliazed correctly | 14:16 |
| zyga | tyhicks: what is considered meta-data? my snaps have two files inside | 14:16 |
| zyga | and one directory | 14:16 |
| tyhicks | zyga: it is cached so that they, hopefully, don't have to go through decompression again later when something like an inode needs to be read in from the squashfs image | 14:16 |
| ppisati | ogra_: is the module still loaded? | 14:16 |
| ogra_ | yep | 14:16 |
| ppisati | me thinks | 14:16 |
| ppisati | maybe we can check via the dt tree | 14:17 |
| ogra_ | i see the module, have that output, but no trace of wlan0 in /proc/net/dev | 14:17 |
| tyhicks | zyga: see "3. SQUASHFS FILESYSTEM DESIGN" in https://www.kernel.org/doc/Documentation/filesystems/squashfs.txt | 14:17 |
| ppisati | let me reach for my board | 14:17 |
| zyga | tyhicks: hmmm | 14:17 |
| zyga | tyhicks: my 1MB snap caues 131 of memory to be used on mounting | 14:17 |
| zyga | tyhicks: thanks, I'll have a look | 14:17 |
| zyga | (1MB decompressed) | 14:17 |
| zyga | tyhicks: pull the project and run | 14:19 |
| zyga | ./analyze.py ubuntu 16.04 4.4.0-45-generic size-1m.squashfs.xz.heavy | 14:19 |
| zyga | tyhicks: now compare that to 0m (empty snap) | 14:19 |
| zyga | there's no difference | 14:20 |
| zyga | with smallest possible block size and dictionary size (size-1m.squashfs.xz.smallest) I get 1.3MB | 14:20 |
| zyga | with ext4 I get close to 0 | 14:21 |
| zyga | anyway | 14:21 |
| zyga | time for dinner | 14:21 |
| tyhicks | crazy | 14:21 |
| tyhicks | I'll poke at the project a bit | 14:21 |
| ogra_ | pitti, what reads /run/systemd/netif/leases on boot ... i get a bunch of shell errors (seems nothing checks if the dir is empty and sed is tried to run) | 14:21 |
| ogra_ | i wonder if that blocks my wlan0 (like basic networking not coming up or so) | 14:21 |
| pitti | ogra_: ah, that's our xenial hack for updating resolvconf with networkd-picked up DNS servers; can you please file a bug? should be simple to fix | 14:22 |
| pitti | (but also just cosmetical) | 14:22 |
| ogra_ | pitti, ok, nothing that could cause my issue then apparently | 14:22 |
| pitti | that service doesn't block anything, it's just being triggered via inotify | 14:22 |
| ogra_ | ok | 14:22 |
| pitti | ogra_: it could cause missing DNS servers in /etc/resolv.conf | 14:23 |
| mup | PR snapd#2214 opened: overlrod/snapstate: fix revert followed by refresh to old-current <Created by chipaca> <https://github.com/snapcore/snapd/pull/2214> | 14:23 |
| * ogra_ sighs ... what a mystery | 14:23 | |
| pitti | if that's what you mean by "block" | 14:23 |
| pitti | i. e. the interface could be up and you can talk to stuff by IP address, but no DNS resolution | 14:23 |
| ogra_ | pitti, nah ... i dont get wlan0 in /proc/net/dev on a very first boot of a snappy image ... | 14:23 |
| ogra_ | the driver is loaded, firmware too | 14:23 |
| pitti | dmesg? | 14:24 |
| ogra_ | but only the second boot gives me the actual device | 14:24 |
| mup | PR snapd#2215 opened: tests: spread system user autoimport <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2215> | 14:24 |
| ogra_ | nothing in dmesg | 14:24 |
| pitti | does the first boot install some firmware or so? | 14:24 |
| ogra_ | (beyond the expected lines for the driver) | 14:24 |
| ogra_ | nope | 14:24 |
| pitti | there isn't anything in userspace other than providing firmware files (or kernel .ko drivers) which would influence that | 14:24 |
| ogra_ | shouldnt | 14:24 |
| ogra_ | but i'm not sure, thats why i poke around a little blindly | 14:25 |
| pitti | ... or rfkill | 14:25 |
| ogra_ | thats why i asked you before ... but it comes up with 0 in the file (we dont have the rfkill binary on the image though) | 14:25 |
| pitti | ogra_: no need for the binary, you can check in /sys/class/rfkill/ | 14:26 |
| ogra_ | empty | 14:26 |
| pitti | hm, that's a bit surprising | 14:27 |
| pitti | ogra_: /sys/class/net/w* ? | 14:27 |
| ogra_ | yeah | 14:27 |
| ogra_ | nope | 14:27 |
| pitti | if the kernel says something about the detection of it (as you said above), there should at least be a device for it | 14:27 |
| ogra_ | then it would also be in /proc/net/dev | 14:27 |
| pitti | ogra_ | (beyond the expected lines for the driver) | 14:27 |
| pitti | i. e. just the driver, but no detected devices | 14:28 |
| ogra_ | well, the kernel doesnt talkj about "wlan0" or anything | 14:28 |
| ogra_ | (but it never does that to my knowledge) | 14:28 |
| pitti | ogra_: maybe the first boot loads the firmware, and then on the next reboot the device actaully works and is detected? | 14:28 |
| pitti | but loading the fw doesn't bring it up immediately or so? | 14:28 |
| ogra_ | and the driver isnt in /etc/modules or anything, so something triggered the loading | 14:28 |
| pitti | but I'm a n00b on the kernel side of this, I'm afraid | 14:29 |
| ogra_ | nah, i think that works in classic images | 14:29 |
| ogra_ | i suspect it is caused by userspace | 14:29 |
| mup | Bug #1587448 opened: Can't reboot device from snap <snapd-interface> <Snappy:Fix Committed> <https://launchpad.net/bugs/1587448> | 14:29 |
| ogra_ | but i'm running out of clues where to look | 14:29 |
| ogra_ | re-loading the module fixes it ... | 14:30 |
| ogra_ | but we cant do that indeed | 14:30 |
| ogra_ | (as a default) | 14:30 |
| pitti | oh | 14:31 |
| pitti | ogra_: so maybe it is due to not re-poking the device after loading the firmware, or the latter doesn't cause the driver to re-attempt detection | 14:32 |
| ogra_ | i also tried an udevadm trigger ... in the hope there is a race or some such ... but no result either | 14:32 |
| pitti | no, that wouldn't help | 14:32 |
| pitti | that only would do the userspace reaction to new kernel devices | 14:32 |
| zyga | tyhicks: on fedora I get 4MB instead of 131 | 14:32 |
| pitti | but the problem is lower, the kernel device doesn't exist at all | 14:32 |
| ogra_ | right, but only on first boot of an ubuntu core all-snap image | 14:33 |
| ogra_ | second boot is fine ... classic images are fine | 14:33 |
| zyga | tyhicks: I just pushed the trace | 14:33 |
| zyga | pull and run this to see: ./analyze.py fedora 24 4.7.9-200.fc24.x86_64 size-1m.squashfs.xz.heavy | 14:33 |
| ogra_ | to me it looks more like something is created on the filesystem on that first boot ... and ignored | 14:33 |
| ogra_ | until i re-load the module or reboot | 14:34 |
| pitti | ogra_: any crazy bind mounts on the root partition that are done in userspace again? | 14:34 |
| pitti | I mean "during boot as opposed to initrd" | 14:34 |
| ogra_ | well, systemd processes the fstab ... for everything but /etc | 14:34 |
| pitti | although device detection happens during initrd alread | 14:34 |
| ogra_ | we dont have network modules there | 14:35 |
| ogra_ | so it wouldnt have any effect | 14:35 |
| ogra_ | (we only have a handfull of hardcoded modules for disk controllers in there by default) | 14:35 |
| tyhicks | zyga: wow, that's quite a difference :) | 14:36 |
| * ogra_ wonders why we bind mount /var/lib7initramfs-tools | 14:37 | |
| iliv | where do I check what $HOME is set to from perspective of a program shipped as a snap package? | 14:38 |
| ogra_ | iliv, snap install hello-world ... then run hello-world.env | 14:38 |
| ogra_ | pitti, hmmm ... machine-id is only generated after systemd did the /var/lib/dbus bindmount, could that have any effect ? | 14:39 |
| pitti | if /etc/machine-id is not there, systemd generates a temporary one and bind-mounts it if it cannot be written | 14:40 |
| pitti | but I wouldn't know how that would affect device detection by kernel drivers | 14:41 |
| ogra_ | right, i just wonder if a driver could depend on it | 14:41 |
| iliv | ogra_, uh, looks like a custom program? | 14:46 |
| ogra_ | ? | 14:47 |
| iliv | env | 14:47 |
| iliv | I mean, my packages don't have it. Am I supposed to include one? | 14:47 |
| ogra_ | it calls "env" indoes a snap environment and prints it | 14:47 |
| ogra_ | *inside | 14:47 |
| ogra_ | it is just the shell env command | 14:47 |
| ogra_ | you can also try hello-world.sh | 14:48 |
| ogra_ | that starts a shell inside the snap environment | 14:48 |
| iliv | are env, evil, sh and echo part of snap environment and avaiable to all packages by default? | 14:48 |
| ogra_ | (exist it with ctrl-d or the exit command) | 14:48 |
| ogra_ | no, they are scripts shipped in hello-world | 14:48 |
| ogra_ | you can just read them in /snap/hello-world/current/ | 14:49 |
| iliv | does that mean if my package doesn't include those AND hello-world isn't installed there is no (easy?) way to see what $HOME is set to? | 14:49 |
| ogra_ | you can always call env from a wrapper script in your snap to have it printed | 14:50 |
| ogra_ | pitti, hmm, some dependency pulled wireless-regdb and crda into the image ... i wonder if that could cause it | 14:50 |
| * ogra_ sees crda udev rules | 14:50 | |
| pitti | ooh | 14:50 |
| pitti | ogra_: yes, that's very plausible -- some drivers refuse to work until you set a CRDA area | 14:50 |
| ogra_ | well, nothing sets an area code (and actually the config dirs are all readonly) .,... also it works on second boot/load of the module ... but perhaps it blocks altogether if it cant write or so | 14:51 |
| ogra_ | aha ! | 14:52 |
| ogra_ | systemd-udevd "/sbin/crda" failed with exit code 234 | 14:52 |
| ogra_ | hmm, that just measn "no country code set" | 14:53 |
| pitti | I have a /sys/devices/platform/regulatory.0/ on my laptop, so /lib/udev/rules.d/85-regulatory.rules woudl call /sbin/crda | 14:55 |
| pitti | and for sure /lib/crda/setregdomain runs to (from /lib/udev/rules.d/40-crda.rules) | 14:56 |
| pitti | but I don't see any crda error codes in the logs | 14:56 |
| pitti | REGDOMAIN= in /etc/default/crda (i. e. unchanged file) | 14:56 |
| ogra_ | yeah, same here | 14:56 |
| pitti | ogra_: do you still have that exit code 234 on the second boot when it works? if so, it's a red herring, if not it's a strong clue that crda is the reason? | 14:57 |
| ogra_ | well, let me try | 14:57 |
| ogra_ | (that means i need to re-flash though ... i can only test once) | 14:58 |
| pitti | ogra_: or search through teh writable area for anything that looks crda related or REGDOMAIN etc? | 14:58 |
| ogra_ | pitti, definitely no crda error on second boot | 15:00 |
| ogra_ | pitti, http://paste.ubuntu.com/23379264/ i dont see anything that could be realted :/ | 15:05 |
| mup | Bug #1636540 opened: please support creating pipes via mknod <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1636540> | 15:06 |
| pitti | ogra_: not /media/ogra/writable/system-data/etc/modprobe.d/modprobe.d/iwlwifi.conf or so? | 15:08 |
| pitti | /media/ogra/writable/system-data/etc/dbus-1/system.d/org.freedesktop.timedate1.conf o_O | 15:08 |
| pitti | why would this be writable, and not in the r/o section? | 15:08 |
| ogra_ | would be surprising if that had any influence on a rpi | 15:08 |
| pitti | (unrelated, but caught my eye) | 15:09 |
| ogra_ | (iwlwifi is intel only, no ?) | 15:09 |
| pitti | ah, yes | 15:10 |
| ogra_ | hmm ... seems "iw reg get" is what i should try after first boot ... to see if there is anything at all | 15:11 |
| * ogra_ re-flashes once again ... poor SD ... | 15:11 | |
| ogra_ | well | 15:20 |
| ogra_ | iw reg get doesnt show any different output | 15:20 |
| ogra_ | lol | 15:21 |
| ogra_ | the output of "crda --help" is highly informative | 15:21 |
| mup | PR snapd#2204 closed: interfaces/builtin: network-manager and bluez can change hostname <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2204> | 15:26 |
| MikeB | I posted a question to devices mailing list last week but no answers. https://www.mail-archive.com/devices@lists.snapcraft.io/msg00145.html Anyone here think they could help? | 15:27 |
| MikeB | Basically creating custom kernel snap and custom image. Boots fine, but snapd failes to start after I install my first snap. | 15:27 |
| tyhicks | zyga: how many CPU cores did your ubuntu test machine have and how many did the fedora machine have? | 15:30 |
| Croepha | f | 15:32 |
| Croepha | f | 15:32 |
| Croepha | oops, disregard that pls :( | 15:32 |
| zyga | tyhicks: UP machines had one | 15:33 |
| tyhicks | zyga: they all had 1 cpu core? | 15:35 |
| zyga | tyhicks: 16.10 system had dual cores | 15:36 |
| ogra_ | MikeB, and you are building from edge or beta channel ? (note that there has not been a stable core snap in a long time, you dont want to use stable until there has actually been a series 16 snappy release) | 15:38 |
| tyhicks | zyga: the ubuntu kernels have CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y | 15:38 |
| zyga | tyhicks: yes, I saw that | 15:39 |
| tyhicks | zyga: that results in squashfs creating one set of internal caches per possible CPU | 15:39 |
| zyga | tyhicks: lots of buffers | 15:39 |
| zyga | tyhicks: I'm running on 4 core system to compare now | 15:39 |
| MikeB | ogra_ I tried both edge and beta. | 15:39 |
| MikeB | Same results. | 15:39 |
| zyga | (also xenial) | 15:39 |
| tyhicks | zyga: it looks like the fedora kernel config uses the default (CONFIG_SQUASHFS_DECOMP_SINGLE), which only uses one set of caches | 15:40 |
| MikeB | I'm unable to build from stable since the gadgest aren't available. | 15:40 |
| ogra_ | MikeB, using the snapcraft kernel plugin to create your kernel ? | 15:40 |
| MikeB | I have a workaround to grab the gadgests from ~vorlon, but that one fails too. | 15:40 |
| zyga | tyhicks: woah!?! | 15:41 |
| ogra_ | i think they are outdated ... slangasek (vorlon) might be able to comment | 15:41 |
| zyga | tyhicks: on 4 way system I get _less_ memory than on UP | 15:41 |
| MikeB | Yes, snapcraft 2.19 kernel plugin. I have some changes to the config which is why I need the custom kernel. | 15:41 |
| zyga | tyhicks: 7MB per size-1m.squashfs.xz.heavy | 15:41 |
| ogra_ | right, my question was more to make sure you get the right initrd | 15:41 |
| zyga | tyhicks: I'll adjust the test to embed the number of CPUs in the directory | 15:41 |
| zyga | tyhicks: does this make any sense to you, less CPUs, way more buffers? | 15:41 |
| ogra_ | though ... hmmm | 15:41 |
| tyhicks | zyga: it doesn't - that's something for the kernel team to figure out :/ | 15:42 |
| ogra_ | sergiusens, ppisati, does the current snapcraft kernel plugin pull from stable or from edge ? | 15:42 |
| zyga | tyhicks: I'm cross-checking the fedora config now | 15:42 |
| zyga | tyhicks: CONFIG_SQUASHFS_DECOMP_SINGLE=y | 15:42 |
| zyga | that checks out, good hunch | 15:42 |
| ogra_ | could indeed be that you have an outdated initrd ... which can result in having a totally wrong clock ... which in turn fails to use the certificates for the initial setup of snapd | 15:42 |
| zyga | may be a bug in the CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU | 15:42 |
| tyhicks | could be | 15:43 |
| MikeB | ogra_ I was thinking it was something like that. The kernel plugin doesn;t give option to pull from alternate channels. I get what I get. | 15:44 |
| ogra_ | yes, i never use it so i dont know which one it pulls | 15:44 |
| slangasek | ogra_: I don't know if they're outdated, because there's no official publication of the signed model assertions so I only know if they're outdated if I poll. I gather there is now a way to download them from the store by name, perhaps we should be migrating everybody to that | 15:46 |
| ogra_ | yeah | 15:46 |
| MikeB | Looking at the source for kernel.py, it looks like it is pulling from edge | 15:47 |
| ogra_ | ppisati, fyi, i'm pretty sure the regulatory subsystem is getting in our way with the wlan0 device ... not sure why yet though | 15:48 |
| ogra_ | "iw reg get" looks identical no matter if wifi works or not | 15:49 |
| MikeB | That is, it is pulling ubuntu-core from the edge. | 15:49 |
| ogra_ | then it should be fine | 15:50 |
| ogra_ | what arch is that ? | 15:50 |
| MikeB | amd64 | 15:51 |
| ogra_ | ah, then the initrd shouldnt have so much influence anyway (regarding the clock etc) | 15:52 |
| liuxg | kyrofa, good evening. May I check with you whether configure hook is fully working? thanks | 15:53 |
| MikeB | using canonical-pc-amd64 for for model and 'pc' for gadget | 15:53 |
| kyrofa | liuxg, it is as of 2.16 | 16:00 |
| MikeB | snapd version on first-boot is 2.16+ppa64.70c490f6-1 when I build the image from edge. | 16:01 |
| liuxg | kyrofa, thanks for your reply. my desktop installed the version 2.16. However, it seems not working in my place. I have a test project at https://github.com/liu-xiao-guo/helloworld-configure. would you please help to take a look? thanks | 16:02 |
| kyrofa | liuxg, ah, snapcraft doesn't support hooks yet | 16:03 |
| kyrofa | liuxg, if you want to use them, you need to place them yourself | 16:03 |
| liuxg | kyrofa, I have place the a configure file located at meta/hooks/configure. I used the same code as in the hooks.md document. it does not work for me. | 16:05 |
| kyrofa | liuxg, is it executable | 16:05 |
| kyrofa | ? | 16:05 |
| liuxg | kyrofa, let me check. ... | 16:06 |
| liuxg | kyrofa, yes, I just changed it to executable, it gave me "Run configure hook for hello (cannot snap-exec: cannot find hook "configure" in "hello")" | 16:09 |
| liuxg | kyrofa, this is how it looks like http://paste.ubuntu.com/23379594/ in my place | 16:11 |
| ppisati | ogra_: if you saw those 'fw loading ...' and 'ISO code blabla' in dmesg, it means wlan0 was setup correctly, but then something removes it | 16:13 |
| ppisati | ogra_: i'm more inclined to think it's a PM issue | 16:13 |
| ppisati | ogra_: like, someone puts the interface to sleep and it gets removed | 16:13 |
| ogra_ | ppisati, hmm | 16:13 |
| ogra_ | can i force it to stay on somehow ? | 16:14 |
| ppisati | ogra_: that's what if was happening in BBB image with the oops | 16:14 |
| ppisati | uhm | 16:14 |
| ogra_ | ah, right, i remember | 16:14 |
| ogra_ | we probably dont really want it to sleep by default at all | 16:14 |
| ogra_ | given it is our only way to access a provisioned device | 16:14 |
| liuxg | kyrofa, after installing the snap, it looks like http://paste.ubuntu.com/23379606/ | 16:15 |
| kyrofa | liuxg, yeah I've duplicated here... not sure what's happening, I'm investigating | 16:15 |
| ogra_ | (i.e. the default for PM should be off ... but witjh the option that people can toggle it if needed) | 16:15 |
| ogra_ | ppisati, though why only on very first boot and never again ? | 16:16 |
| liuxg | kyrofa, OK. thanks for your help. do you mean snapcraft will support it in the future, and it will put the file into the right place, right? | 16:16 |
| kyrofa | liuxg, indeed | 16:16 |
| ppisati | ogra_: IMO is netplan/netconf/the configuration thing/ that puts all the interfaces to sleep | 16:16 |
| ogra_ | pitti, ^^^ ? | 16:17 |
| ogra_ | is that a possibility ? | 16:17 |
| liuxg | kyrofa, thanks for letting me know. I am going to sleep. have a nice day. | 16:18 |
| ogra_ | ppisati, neither runs before you press enter ... | 16:18 |
| kyrofa | liuxg, you as well! | 16:18 |
| ogra_ | (the "press enter" is just a shell script wrapped around getty ... only if you actualyl press the console-conf/netplan stuff starts) | 16:19 |
| ogra_ | i am on a system where enter has not been pressed yet | 16:19 |
| sergiusens | ogra_ stable, always stable | 16:26 |
| ogra_ | sergiusens, well, MikeB says edge | 16:27 |
| sergiusens | darn | 16:27 |
| ogra_ | :) | 16:27 |
| sergiusens | indeed " 'ubuntu-core', 'edge', self.os_snap, self.project.deb_arch)" | 16:27 |
| sergiusens | this is wrong | 16:27 |
| ogra_ | well, you really dont want the initrd from ubuntu-core 425 | 16:27 |
| ogra_ | thats half a year old or so | 16:27 |
| sergiusens | well, I don't want any of this | 16:27 |
| ogra_ | hold back the fix til we have something modern in stable | 16:28 |
| sergiusens | I want to not need to do this intrd dance and have core take care of it | 16:28 |
| ogra_ | yeah | 16:28 |
| ogra_ | add some more hours to my days :P | 16:28 |
| iliv | jdstrand, hey, I'm here as well so if you prefer to discuss that bugreport here just send me a pm or highlight me in this channel | 16:28 |
| rharper | ogra_: do you know mounts the second partition to /boot/grub (or /boot/uboot) ? | 16:32 |
| rharper | *what* mounts the second partition | 16:32 |
| ogra_ | rharper, the initrd | 16:32 |
| rharper | is that in the initramfs packages in core snap ? | 16:32 |
| rharper | or part of the kernel snap build ? | 16:32 |
| ogra_ | in the binary initrd in the kernel snap | 16:33 |
| rharper | ok, but the scripts in the initrd are found in which source? | 16:33 |
| ogra_ | but the binary initrd is created during build of the core snap currently | 16:33 |
| ogra_ | initramfs-tools-ubuntu-core in the image ppa | 16:33 |
| rharper | ogra_: excellent, thanks! | 16:33 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 16:34 |
| ogra_ | the script itself also lives on disk of a running system in /usr/share/initramfs-tools/ | 16:35 |
| ogra_ | (under scripts/ubuntu-core-rootfs ) | 16:35 |
| rharper | triple thanks ! | 16:35 |
| kyrofa | sergiusens, learned something interesting | 16:42 |
| kyrofa | sergiusens, you can indeed add other Nextcloud instances as external storage, which means you might be able to get some replication going | 16:42 |
| niemeyer | dasjoe: Thanks for the note on DMARC | 16:55 |
| niemeyer | dasjoe: Given the docs on https://wiki.list.org/DEV/DMARC, I'm not sure how much we can improve the situation, I've sent a note to our admin team to see what they might be able to pull off | 16:55 |
| pitti | ogra_: not sure -- what would tell the interface to go to sleep at boot? "sleep" as in "suspend"? | 17:30 |
| ogra_ | pitti, good question ... i dont think ppisati's idea flies though ... nothing should touch the state before console-conf even runs and it only happens on very first boot | 17:32 |
| ogra_ | i still find crda more plausible | 17:32 |
| ogra_ | i'll do a bit more debugging tomorrow, my post-sprint-cold is really hitting badly today | 17:33 |
| * ogra_ goes to find some hot tea and honey | 17:34 | |
| kyrofa | ogra_, yeah it sucked huh? | 17:36 |
| kyrofa | ogra_, just on the tail end here | 17:36 |
| ogra_ | me too ... luckily no fever ... but it is at a point where the coughing hurts in the muscules | 17:37 |
| kyrofa | ogra_, yep, same cold it seems | 17:37 |
| mup | PR snapd#2214 closed: overlord/snapstate: fix revert followed by refresh to old-current <Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2214> | 17:50 |
| mup | PR snapd#2210 closed: debian: only install share/locale if available (missing on powerpc) <Critical> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2210> | 17:57 |
| zyga | OerHeks: hey, how are you feeling? | 18:16 |
| zyga | hmm | 18:16 |
| zyga | ogra_: ^^ | 18:16 |
| zyga | OerHeks: (sorry0 | 18:16 |
| mvo | ogra_: quick question - pi2 from edge seems busted for me, no networking. do you see that as well or am I just unlucky? | 19:24 |
| ogra_ | mvo, using my daily ? | 19:36 |
| ogra_ | mvo, it worked for me on sunday, havent tested pi2 since | 19:36 |
| mvo | ogra_: freshyl build, I explore it a bit | 19:40 |
| ogra_ | no networking at all ? like no eth0 in console-conf ? | 19:41 |
| mvo | ogra_: still exploring, no console-conf, but maybe a bad sd card, let me re-run, especially if its not anything known | 19:42 |
| ogra_ | no console-conf ? | 19:42 |
| ogra_ | how long did you wait ? | 19:43 |
| * mvo reflashes | 19:45 | |
| mup | PR snapd#2216 opened: snap: skip all ram disks when auto-importing assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2216> | 19:51 |
| mvo | ogra_: aha, new flash on fresh card looks much better | 19:52 |
| ogra_ | phew | 19:52 |
| mvo | ys | 19:53 |
| mvo | yes | 19:53 |
| ogra_ | pi2 should be pretty good ... (at least that was my impression on sunday) | 19:58 |
| mvo | ogra_: yeah, I think there was a short hickup but edge is looking good, I will wait for QA to verify but I think new images can be released soon (hopefully tomorrow) with the final fixes. and then I guess we will need something later for pi3/dragonboard. unless mwhudson gets your two bugs under control while I sleep :) I would love to see that! | 20:01 |
| ogra_ | mvo, well, GA is not this week :) | 20:02 |
| ogra_ | see the ML thread | 20:02 |
| * mwhudson waves | 20:02 | |
| ogra_ | mvo, we have some time left for the arm images | 20:02 |
| mwhudson | ogra_: so because i'm lazy and to save time, which image should i use to reproduce wlan issues on dragonboard? | 20:03 |
| ogra_ | if we have the fixes by next monday we're fine i'd say | 20:03 |
| mvo | mwhudson: hey, good morning! you are up early(?) | 20:03 |
| mwhudson | ogra_: http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz | 20:03 |
| mwhudson | mvo: it's 0900 so not really | 20:03 |
| mvo | (me is confused about TZ) | 20:03 |
| mvo | mwhudson: oh, then I'm just confused :) | 20:03 |
| ogra_ | mwhudson, http://people.canonical.com/~ogra/snappy/all-snaps/daily/ | 20:03 |
| mwhudson | mvo: we're in summer time now, you are not any more? | 20:03 |
| ogra_ | whatever latest you find there | 20:03 |
| mwhudson | ogra_: ok | 20:04 |
| ogra_ | mwhudson, regarding the rpi i have a strong suspicion that we do not set up some bits for crda that are only in place on second boot (which is why the device then has a wlan0) ... but i'm to sick to move on today and need some rest | 20:05 |
| mvo | mwhudson: I think I just looked at the wrong city :) in any case, great to hear that you are looking into it | 20:05 |
| ogra_ | there is a small possibility that the wifi timeout on the dragonboard is related ... but debugging the dragon is a lot harder | 20:06 |
| mwhudson | ogra_: i don't have any pi hardware | 20:06 |
| ogra_ | yeah | 20:06 |
| ogra_ | well, the systemd.debug-shell arg helps a lot ... but for that you need to change uboot.env on the SD | 20:06 |
| mwhudson | yeah | 20:07 |
| mwhudson | can i just edit that with vi or do i have to clown about with mkimage and stuff? | 20:07 |
| ogra_ | you can re-generate it http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/README | 20:07 |
| mwhudson | ah, thanks | 20:08 |
| ogra_ | grab the uboot.env.in from that tree, edit mmcargs between the quotes and re-generate the uboot.env ... then copy it on the system-boot partition | 20:08 |
| * ogra_ needs to go ... | 20:09 | |
| mwhudson | ogra_: sleep well | 20:09 |
| mup | Bug #1613572 changed: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1613572> | 20:11 |
| mup | Bug #1627309 changed: bluetooth-control noble.js not working <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1627309> | 20:32 |
| mwhudson | cyphermox: hey | 20:38 |
| cyphermox | mwhudson: hey | 20:39 |
| mwhudson | cyphermox: i've reproduced the wlan problem on my dragonboard too | 20:39 |
| mwhudson | pretty sure it's not console-conf's fault, the config looks fine | 20:40 |
| cyphermox | right | 20:40 |
| mwhudson | cyphermox: do you know what "sed: can't read /run/systemd/netif/leases/*: No such file or directory" in syslog is about? | 20:40 |
| cyphermox | mwhudson: there is no file in that directory? | 21:00 |
| cyphermox | no idea what tries to do that though | 21:00 |
| mwhudson | well sure but why is it in syslog | 21:00 |
| mwhudson | bah my board doesn't boot when i try to enable debug shell, i guess i'm doing something wrong | 21:00 |
| cyphermox | what's before that line in syslog? | 21:01 |
| cyphermox | like, what is the full context? | 21:01 |
| mwhudson | ah sorry gone now | 21:01 |
| mwhudson | it was after the wlan associated though | 21:01 |
| mwhudson | mmcargs=setenv bootargs "${args} console=ttyMSM0,115200n8 root=${mmcroot} systemd.debug-shell" | 21:02 |
| mwhudson | <- looks right? | 21:02 |
| cyphermox | yeah, looks fine | 21:06 |
| mwhudson | actually i think it's the uboot.env.in -> uboot.env thing that's breaking me | 21:07 |
| mwhudson | maybe | 21:07 |
| rharper | mmm, core boot debugging fun; misery loves company | 21:07 |
| mwhudson | heh | 21:10 |
| bschaefer | hello, so for the snap cmake plugin the root level CMakeLists.txt file is not in the root dir ... and slightly dependent on its location. Any news on that coming to the plugin anytime soon :)? | 21:14 |
| mwhudson | cyphermox: so stranger and stranger, i rebooted and the device was associated but it fell off the network when i tried to enter my email address | 21:19 |
| mwhudson | Oct 25 21:16:00 localhost systemd-networkd[1510]: Could not load configuration files: Permission denied | 21:21 |
| mwhudson | waaait umask is inherited, right? | 21:21 |
| mwhudson | yes | 21:35 |
| mwhudson | ok this is all my fault | 21:35 |
| mwhudson | ogra_: sorry! | 21:36 |
| mup | Bug #1611978 changed: Incomplete x11 interface <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1611978> | 21:53 |
| mup | Bug #1636633 opened: Content interface supports multiple sources, but only one destination <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1636633> | 22:05 |
| mwhudson | cyphermox: https://github.com/CanonicalLtd/subiquity/pull/176 if you want a look | 22:22 |
| mup | PR CanonicalLtd/subiquity#176: remove setting of umask, redact wifi password from log file <Created by mwhudson> <https://github.com/CanonicalLtd/subiquity/pull/176> | 22:22 |
| mwhudson | uh do i have to run ubuntu-image as root ? | 22:39 |
| mwhudson | it was working as me for a long time | 22:40 |
| mup | Bug #1636229 opened: Allow programs to write hidden files in home directory <snapd-interface> <Snappy:Incomplete> <https://launchpad.net/bugs/1636229> | 22:42 |
| cyphermox | mwhudson: +1 on the merge, thanks | 22:49 |
| mwhudson | cyphermox: going to cut a release, do we want anything else? | 22:50 |
| cyphermox | don't think so | 22:51 |
| cyphermox | make sure to make it without ~xenial | 22:51 |
| cyphermox | only change it after ;) | 22:51 |
| mwhudson | yeah ok :) | 22:51 |
| cyphermox | ie. the real tag shouldn't have a tilda, etc. etc. | 22:51 |
| mwhudson | ok uploading to zesty | 22:52 |
| mwhudson | and the ppa | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!