[00:22] <mup> Bug #1674509 opened: unable to find bluetooth device on rp3 ubuntu core <Snappy:New> <https://launchpad.net/bugs/1674509>
[01:23] <mwhudson> haha console-conf shouldn't let you use a wifi password < 8 characters long
[03:56] <mup> PR snapcraft#1202 opened: python plugin: support pbr/setup.cfg projects <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1202>
[06:14] <Rumple> Snap core has an old version of libstdc++, supporting only up to GLIBCXX_3.4.21 where as Ubuntu 16.10 provides GLIBCXX_3.4.22
[07:15] <zyga> o/
[08:19] <NicolinoCuralli> niemeyer:what is the flow that it permit interface autoconnection by gadget plus model assertion? what about update flow for model assertion?
[09:59] <mup> Bug #1674634 opened: After initial 'refresh', snapd doesn't work <Snappy:New> <https://launchpad.net/bugs/1674634>
[10:16] <mup> PR snapd#3054 closed: many: rename "snap-confine" to "snap-wrap" to workaround LP:1673247 <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3054>
[11:41] <niemeyer> Nicolino_: The model assertion must be updated together with the other assertions.. I don't think we're doing that today, but it's easy to fix
[11:42] <niemeyer> Nicolino_: Looking through the code for flows with the snap-declaration should give a good picture
[11:42] <niemeyer> This is also the assertion that allows auto connections in general
[12:02] <mup> PR snapd#3066 opened: asserts: remove some unused things <Created by emgee> <https://github.com/snapcore/snapd/pull/3066>
[12:47] <mup> PR snapcraft#1201 closed: demos: make ROS demos support exiting after success <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1201>
[12:47] <mup> PR snapcraft#1203 opened: Add some initial checks to intelligently build the initial snapcraft.yaml <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/1203>
[13:12] <mup> PR snapd#3067 opened: tests: move docker test to new nightly suite <Created by zyga> <https://github.com/snapcore/snapd/pull/3067>
[13:40] <mup> PR snapd#3066 closed: asserts: remove some unused things <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3066>
[13:46] <mup> PR snapd#3068 opened: boot: log error in KernelOrOsRebootRequired <Created by zyga> <https://github.com/snapcore/snapd/pull/3068>
[14:33] <lool> kyrofa: hey! around?
[14:36] <lool> kyrofa: sent you an email with details
[15:17] <liuxg> For qt project, does anyone know how to set CONFIG in snapcraft.yaml? I do not want to change the original .pro file in the upstream. thanks
[15:22] <kyrofa> liuxg, just use the `options` param in the qmake plugin
[15:22] <kyrofa> lool, I'm around now, I'll take a look at the email :)
[15:24] <liuxg> kyrofa, thanks. I am now trying ...
[15:38] <mup> PR snapcraft#1161 closed: channels: Add track support to commands <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1161>
[16:11] <mup> PR snapcraft#1197 closed: tests: increase the timeout in the shared ros test <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1197>
[16:23] <jdstrand> roadmr: hey, sorry, can you pull r850 at your convenience (not critical)
[16:24] <roadmr> jdstrand: sure!
[16:24] <roadmr> jdstrand: the pipeline is a bit clogged right now, may be a couple of days until I get this deployed, but do let me know if I should try to push it a bit
[16:29] <jdstrand> roadmr: that is totally fine, thanks
[16:39] <zyga> Pharaoh_Atem: hey
[16:39] <zyga> Pharaoh_Atem: morphis here will be looking after distributions, he's not going to be stolen for more upstream work like I was
[16:39] <Pharaoh_Atem> morphis?
[16:40] <zyga> Pharaoh_Atem: yes
[16:40] <zyga> Pharaoh_Atem: I'll show him the tooling tomorrow
[16:40] <zyga> Pharaoh_Atem: and we'll get started with the missing dependencies
[16:40] <zyga> Pharaoh_Atem: I just wanted to introuduce you guys
[16:40] <morphis> Pharaoh_Atem: hey :-)
[16:40] <Pharaoh_Atem> hello?
[16:40] <kyrofa> Ah, Pharaoh_Atem you're in good hands
[16:41] <kyrofa> morphis, nice to have you on board
[16:41] <Pharaoh_Atem> am I?
[16:41] <morphis> Pharaoh_Atem: I think we were sitting at the same table back in november talking about airlines other stuff in the late evening :-)
[16:41] <mup> Bug #1668891 changed: Can install non classic snap with --classic, but classic flag isn't set <amd64> <apport-bug> <xenial> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1668891>
[16:41] <morphis> kyrofa: thanks!
[16:42] <zyga> Pharaoh_Atem: btw, about those packages, no reply from gofed upstream, I think we should just hand-roll packages from copy-pasted gopkg.in examples in other places
[16:42] <zyga> Pharaoh_Atem: replace names, hashes and stuff
[16:42] <Pharaoh_Atem> go for it
[16:42] <zyga> Pharaoh_Atem: we'll also do a build in COPR that has vendorized dependencies as a sanity check (if that thing works and main package doesn't it's the deps)
[16:42] <zyga> Pharaoh_Atem: and we'll see what it would take to pass the unit tests on fedora
[16:43] <Pharaoh_Atem> well, it currently doesn't build with vendorized stuff
[16:43] <zyga> Pharaoh_Atem: then some look at CI (but not all tomorrow ;)
[16:43] <Pharaoh_Atem> it fails to link
[16:43] <zyga> Pharaoh_Atem: right
[16:43] <zyga> Pharaoh_Atem: but the COPR package could, just to see where we are
[16:45] <zyga> Pharaoh_Atem: so sorry for the extremely long wait (and endless fires) but hopefully with the extra pair of hands we'll get it to work :-)
[16:45] <Pharaoh_Atem> maybe
[16:48] <morphis> Pharaoh_Atem, zyga: I am sure we will
[16:49] <morphis> need some time to get started with this but we should get good results along the way :-)
[16:53] <mup> PR snapcraft#1204 opened: target-arch: decouple target arch from deb, and use a separate field … <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1204>
[16:55] <Pharaoh_Atem> morphis: we're going to need to get you up to speed in Fedora-land
[16:57] <morphis> Pharaoh_Atem: yeah, just registered my account and waiting for approval now
[16:57] <morphis> Pharaoh_Atem: zyga will give me some more in depth introduction tomorrow and then we will get this going
[16:58] <morphis> then I should have a better overview of what we need to do and how we can get this forward
[17:01] <NicolinoCuralli> hi all is it possible set the log level for snapd?
[17:04] <ogra_> NicolinoCuralli, theer is a way to enable debug messages ... but i forgot the exact runes
[17:04] <ogra_> Chipaca, might know
[17:04] <Chipaca> i know nuthin'
[17:05] <Chipaca> NicolinoCuralli— yes
[17:05] <ogra_> hah, lies!
[17:05] <NicolinoCuralli> :D
[17:05] <Chipaca> NicolinoCuralli— not particularly granular, except for http requests
[17:05] <Chipaca> NicolinoCuralli— what are you needing?
[17:07] <Chipaca> NicolinoCuralli— journalctl already has DEBUG logs in it; you can add HTTP debug logs via the SNAPD_DEBUG_HTTP environ
[17:08] <Chipaca> it's a bitmask, because we're lazy like that. Set it to 7 for it to log everything except for the actual snap download content
[17:08] <NicolinoCuralli> perhaps i don't need to set the log level but understand if log of snapd are persistent and how much i/o can generate for a daemon that make network scan each 30 seconds
[17:09] <NicolinoCuralli> if the daemon run in devmode
[17:09] <Chipaca> ah. ogra_ back to you :-D
[17:09] <ogra_> if anything runs in devmode, every execution will spill a löot of "ALLOWED" apparmor messages
[17:10] <ogra_> and there is no way to avoid that since the assumption is that devmode is only used during development and debugging
[17:12]  * jdstrand notes that if you connect your interfaces in devmode, you can get rid of a lot of ALLOWED messages
[17:12] <NicolinoCuralli> ogra_: yes i see it :D
[17:12] <ogra_> thats crazy talk ... who would connect interfaces in devmode :P
[17:12] <mup> PR snapd#2877 closed: interfaces: add chroot to base templates <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2877>
[17:13] <ogra_> (wow, i didnt knwo you could do that)
[17:13] <jdstrand> devmode logs violations against policy so if you don't connect your interfaces, there are a lot of policy violations :)
[17:13] <jdstrand> you might be thinking of classic confinement-- you may not plugs/slots with classic confinement, but devmode you are meant to
[17:14] <jdstrand> the idea is you have an access or two or 10 that are not in snapd yet, but you connect them and only those violations are ignored
[17:14] <jdstrand> as opposed to everything not in the default policy
[17:17] <renat> Hi =) It's Renat from Screenly=)
[17:17] <renat> I have a new question for you=)
[17:18] <ogra_> and you always have the most interesting ones !
[17:18] <ogra_> :)
[17:19] <renat> https://paste.ubuntu.com/24222873/
[17:19] <renat> We' re trying to install our custom gadget snap from the store.
[17:19] <ogra_> renat, that is during ubuntu-image ?
[17:20] <renat> No. Image is created successfully
[17:20] <ogra_> (you cant install a custom gadget on an installed image afaik)
[17:20] <renat> It's during the first boot.
[17:20] <ogra_> ah
[17:20] <NicolinoCuralli> jdstrand: can you repeat your explanation?
[17:21] <mup> PR snapd#3069 opened: snapstate: restart as needed if we undid unlinking aka relinked core or kernel snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3069>
[17:21] <renat> So, there is one more thing - snapd tries to mount it (as I can see from logs) and starts to use all the CPU
[17:22] <renat> Official pi3 gadget snap works fine.
[17:22] <ogra_> renat, did you use your own model assertion as well ?
[17:22] <ogra_> afaik the signature needs to match
[17:22] <renat> Yes.
[17:23] <renat> When we provide our gadget snap to the ubuntu-image using the --extra-snaps option - everything works fine.
[17:23] <ogra_> and it doesnt if you get the same snap from the store
[17:24] <ogra_> ?
[17:25] <renat> Yes.
[17:25] <renat> As far as I can understand - if I install the snap using the extra-snaps cmd option - it doesn't try to mount the gadget snap.
[17:25] <ogra_> now thats weird
[17:26] <ogra_> theoretically the process should be exactly the same in both cases
[17:26] <ogra_> just one more download step
[17:27] <elopio> coreycb: can you give me the links to your snaps? We'll put them in the nightly test suite to make sure that snapcraft master can always build the snap.
[17:28] <renat> Could you, please, see the logs I posted above? Maybe it would be good to show an error message to make debugging easier?
[17:28] <coreycb> elopio, that'd be great, would links to the github repos work?
[17:36] <elopio> coreycb: yes, please.
[17:38] <coreycb> elopio, this is what we have so far: http://paste.ubuntu.com/24222988/
[17:45] <elopio> coreycb: thanks!
[17:46] <coreycb> elopio, thank you!
[17:55] <ogra_> renat, can you file a bug ?
[17:55] <ogra_> renat, i'll gather some poeople to look at it tomorrow
[17:59] <niemeyer> renat: Yeah, sorry for the trouble there.. today was a bit busy due to issues with the stable release, but fire is all under control now.. we'll dig into your issue tomorrow
[18:08] <renat> orga_, okay, I will do, thanks!
[18:08] <renat> niemeyer, thanks!
[18:08] <renat> ogra_, sorry.
[18:08] <ogra_> no worries :)
[18:09] <mup> PR snapcraft#1199 closed: cleanbuild: packaging independent detection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1199>
[18:09] <om26er> I see this error: - Download snap "core" (35) from channel "stable" (Please buy core before installing it.) -- Note: I have snapd pointing to staging.
[18:09] <ogra_> i can give you my account data to transfer your money to ...
[18:10] <ogra_> (though 35 is a rather old revision ... not sure i'd pay for that ... we're in the 1500s nowadays)
[18:12] <om26er> ogra_: http://paste.ubuntu.com/24223144/
[18:12] <om26er> ogra_: could it be that the 'core' in staging is different than production.
[18:17] <mup> Bug #1674778 opened: snapd hangs with 100% CPU usage when image has a custom gadget snap <gadget> <snapd> <Snappy:New> <https://launchpad.net/bugs/1674778>
[18:31] <renat> ogra_, again me=) I have another question. I want to supply a custom journald.conf in my gadget snap. But just adding it to the gadget snap (in the etc/systemd/ directory) doesn't help. Is there a preferred way to change journald.conf in Ubuntu-core?
[18:31] <ogra_> om26er, could be, i never used staging and dont know how it ends up there
[18:34] <ogra_> renat, i fear that would have to happen through an option in the core config hook ...
[18:34] <ogra_> renat, i just have disabling syslog in the works, nothing for journald yet though
[18:35] <cachio> ogra_, hey, any idea about this problem? My machine with yakkety is not detecting the sdcard when I flashed that with a ubuntu core image, but if I insert any other sdcard, it detects the card
[18:35] <renat> ogra_, what I need is changing journald storage from auto to volatile
[18:35] <ogra_> cachio, what image did you flash ?
[18:35] <cachio> ogra_, the dragonboard one
[18:36] <renat> ogra_, okay, thanks for the answer, have a good day=)
[18:36] <cachio> ogra_, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
[18:36] <ogra_> cachio, there is only one partition your PC could see ... system-boot
[18:37] <ogra_> the writable partition is invalid until the first boot of the SD on a board happened (then it will be properly resized to the whole of the SD)
[18:37] <ogra_> so you could really only see the vfat called system-boot when plugging it in to a PC if you never booted from that SD
[18:37] <ogra_> renat, file a bug about that as well please, else i forget :)
[18:38] <cachio> ogra_, I laready boot this SD card in the board, and it is working properly
[18:40] <ogra_> cachio, well, then your PC should mount system-boot and writable ...
[18:40] <cachio> ogra_, it is not mounting nothing
[18:40] <ogra_> it surely does here on my xenial machines
[18:40] <ogra_> anything in dmesg right after you plug it ?
[18:41] <cachio> ogra_, let me check again, I was trying to find something useful
[18:41] <cachio> [  380.505317] mmc0: error -110 whilst initialising SD card
[18:41] <cachio> [  382.879924] mmc0: card never left busy state
[18:42] <cachio> ogra_, this is the only interesting thing I saw
[18:42] <ogra_> that sounds more like a controller issue on your laptop to be honest
[18:42] <cachio> ogra_, it is happening with 2 sd cards
[18:42] <ogra_> i'd blame the yakkety kernel/mmc driver there
[18:43] <ogra_> is that any special type of SD ?
[18:43] <ogra_> sdxc or plain sd or sdhc
[18:43] <cachio> ogra_, sdhc
[18:43] <ogra_> compared to the cards that are recognized
[18:44] <cachio> ogra_, all of them are the same type
[18:44] <ogra_> weird
[18:44] <ogra_> well, there is nothing special about the GPT partition table used on the dragonboard SD cards
[18:45] <ogra_> your PC should just read it and mount the partitions ... as i said, this works for me
[18:45] <ogra_> but i use an USB card reader
[18:45] <cachio> ogra_, perhaps the last update has wroken something in my yakkety
[18:45] <ogra_> i dont have any builtin MMC slot here
[18:46] <ogra_> and with that it usually works for all my SD cards
[18:47] <cachio> ogra_, it was working for me too, but from yesterday I could not make it work it again
[18:47] <ogra_> well, i'd blame yakkety then :)
[18:48] <cachio> ogra_, :), thanks
[18:48] <ogra_> if the SD worked and you didnt re-flash or anything ... we dont change anything on a booted SD regarding partitions r formatting after you did your first boot
[18:57] <mup> Bug #1674794 opened: journald.conf storage=volatile config support <Snappy:New> <https://launchpad.net/bugs/1674794>
[19:33] <ryebot> When I try to build a classic snap without snapd installed, I get this message: "classic confinement requires the core snap to be installed. Install it by running `snap install core`."
[19:34] <ryebot> Non-classic snaps build just fine.
[19:36] <ryebot> Is there a way around that?
[19:36] <kyrofa> ryebot, yeah, set the SNAPCRAFT_SETUP_CORE environment variable to 1
[19:36] <ryebot> magic!
[19:36] <kyrofa> ryebot, instead of assuming you have the core snap, it'll download it itself and unpack it locally
[19:36] <ryebot> thanks :D
[19:36] <ryebot> does that require snapd to be running?
[19:37] <kyrofa> ryebot, nope
[19:37] <ryebot> excellent, thanks
[19:37] <kyrofa> ryebot, it just unsquashes the snap itself, no mounting/running or anything
[19:38] <ryebot> kyrofa: perfect, thanks
[19:38] <kyrofa> ryebot, any time!
[20:45] <mup> PR snapcraft#1205 opened: asset-tracking: track source VCS details <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1205>
[20:48] <mup> PR snapcraft#1188 closed: store: set User-Agent header in store requests <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1188>
[21:06] <ryebot> kyrofa: that doesn't seem to work if I use --target-arch=<not-my-arch>
[21:06] <ryebot> kyrofa: any workaround there?
[21:06] <kyrofa> ryebot, hmm, is it pulling the core snap for the wrong arch?
[21:07] <ryebot> hmm I'm not sure
[21:07] <ryebot> says:
[21:07] <ryebot> Setting target machine to 'arm64'
[21:07] <kyrofa> ryebot, what doesn't work?
[21:07] <ryebot> Preparing to pull kubectl
[21:07] <ryebot> classic confinement requires the core snap to be installed. Install it by running `snap install core`.
[21:07] <kyrofa> Oh interesting
[21:07] <kyrofa> And you have that env var still set?
[21:07] <ryebot> yeah
[21:07] <ryebot> SNAPCRAFT_SETUP_CORE=1 snapcraft --target-arch=arm64
[21:08] <kyrofa> ryebot, I will say that support for --target-arch is a little shaky. It's typically only used for kernels
[21:08] <kyrofa> ryebot, but please do log a bug so we can discuss and investigate
[21:08] <ryebot> alright
[21:08] <ryebot> thanks kyrofa!
[21:18] <ryebot> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1674828
[21:18] <mup> Bug #1674828: SNAPCRAFT_SETUP_CORE=1 doesn't work for foreign architectures <Snapcraft:New> <https://launchpad.net/bugs/1674828>
[21:18] <ryebot> let me know if you need more details
[21:18] <kyrofa> Thanks ryebot
[21:18] <ryebot> thank you!
[21:19] <Saviq> anyone with an idea why I can't install a snap on a xenial box? http://pastebin.ubuntu.com/24224369/
[21:20] <kyrofa> Saviq, you're sure the kernel you're on supports apparmor?
[21:20] <Saviq> 4.4.0-65-generic, I'd have hoped...
[21:20] <Saviq> standard xenial kernel
[21:20] <kyrofa> Saviq, that's nasty. Can you pastebin /var/lib/snapd/apparmor/profiles/snap.core.hook.configure?
[21:21] <Saviq> kyrofa, http://paste.ubuntu.com/24224381/
[21:22] <kyrofa> Saviq, huh, I was expecting it to be corrupted or something with that error, but that looks fine
[21:23] <Saviq> kyrofa, any idea where the abstractions/openssl file should come from?
[21:23] <kyrofa> jdstrand, are you around? Not sure what that error entails ^^
[21:23] <jdstrand> /etc/apparmor.d
[21:23] <jdstrand> I just downloaded the paste and it parses fine
[21:27] <jdstrand> what is possibly happening is that the /var/lib/snapd/apparmor/profiles/snap.core.hook.configure was pasted failed to parse, then snapd reverted
[21:27] <kyrofa> Ah
[21:28] <jdstrand> note that ondra and I couldn't update to r1441 with snap refresh. it would spin over and over again phase 2 security profile generation (or something)
[21:30] <Saviq> jdstrand, FWIW there is no /etc/apparmor.d/abstractions/openssl ...
[21:30] <Saviq> I suppose my apparmor installation got broken, /me reinstalls
[21:30] <jdstrand> Saviq: oh, that is not good
[21:30] <Saviq> jdstrand, I had some filesystem issues on this box, that's probably what happened
[21:31] <jdstrand> yes, that file is presumed to exist
[21:31] <jdstrand> $ dpkg -S /etc/apparmor.d/abstractions/openssl
[21:31] <jdstrand> apparmor: /etc/apparmor.d/abstractions/openssl
[21:31] <Saviq> I wonder what can I do to recover those, --reinstall doesn't do
[21:35] <Saviq> ok a bit of purge and install got them back
[21:35] <Saviq> back in business
[21:36] <sergiusens> ryebot: kyrofa --target-arch and classic will not work at all
[21:37] <kyrofa> sergiusens, since we would need to run the other arch's linker?
[21:38] <kyrofa> sergiusens, a decent error message will probably solve that bug, then
[21:39] <sergiusens> kyrofa: yeah
[22:56] <ryebot> sergiusens: what if the build target is a static binary, like some golang artifact?
[22:57] <ryebot> sergiusens: maybe a better question is, what is getting linked with what?
[23:04] <mup> Bug #1674847 opened: produce package lists for Ubuntu Core versions on the web <Snappy:New> <https://launchpad.net/bugs/1674847>
[23:31] <mup> Bug #1674505 changed: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:Invalid> <https://launchpad.net/bugs/1674505>