[00:22] Bug #1674509 opened: unable to find bluetooth device on rp3 ubuntu core [01:23] haha console-conf shouldn't let you use a wifi password < 8 characters long === Elleo_ is now known as Elleo [03:56] PR snapcraft#1202 opened: python plugin: support pbr/setup.cfg projects [06:14] 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 === axino` is now known as axino [07:15] o/ [08:19] niemeyer:what is the flow that it permit interface autoconnection by gadget plus model assertion? what about update flow for model assertion? === chihchun_afk is now known as chihchun [09:59] Bug #1674634 opened: After initial 'refresh', snapd doesn't work [10:16] PR snapd#3054 closed: many: rename "snap-confine" to "snap-wrap" to workaround LP:1673247 [11:41] 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] Nicolino_: Looking through the code for flows with the snap-declaration should give a good picture [11:42] This is also the assertion that allows auto connections in general [12:02] PR snapd#3066 opened: asserts: remove some unused things [12:47] PR snapcraft#1201 closed: demos: make ROS demos support exiting after success [12:47] PR snapcraft#1203 opened: Add some initial checks to intelligently build the initial snapcraft.yaml [13:12] PR snapd#3067 opened: tests: move docker test to new nightly suite [13:40] PR snapd#3066 closed: asserts: remove some unused things [13:46] PR snapd#3068 opened: boot: log error in KernelOrOsRebootRequired [14:33] kyrofa: hey! around? [14:36] kyrofa: sent you an email with details === chihchun is now known as chihchun_afk [15:17] 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 === chihchun_afk is now known as chihchun [15:22] liuxg, just use the `options` param in the qmake plugin [15:22] lool, I'm around now, I'll take a look at the email :) [15:24] kyrofa, thanks. I am now trying ... === joedborg_ is now known as joedborg [15:38] PR snapcraft#1161 closed: channels: Add track support to commands === chihchun is now known as chihchun_afk [16:11] PR snapcraft#1197 closed: tests: increase the timeout in the shared ros test [16:23] roadmr: hey, sorry, can you pull r850 at your convenience (not critical) [16:24] jdstrand: sure! [16:24] 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] roadmr: that is totally fine, thanks [16:39] Pharaoh_Atem: hey [16:39] 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] morphis? [16:40] Pharaoh_Atem: yes [16:40] Pharaoh_Atem: I'll show him the tooling tomorrow [16:40] Pharaoh_Atem: and we'll get started with the missing dependencies [16:40] Pharaoh_Atem: I just wanted to introuduce you guys [16:40] Pharaoh_Atem: hey :-) [16:40] hello? [16:40] Ah, Pharaoh_Atem you're in good hands [16:41] morphis, nice to have you on board [16:41] am I? [16:41] 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] Bug #1668891 changed: Can install non classic snap with --classic, but classic flag isn't set

[16:41] kyrofa: thanks! [16:42] 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] Pharaoh_Atem: replace names, hashes and stuff [16:42] go for it [16:42] 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] Pharaoh_Atem: and we'll see what it would take to pass the unit tests on fedora [16:43] well, it currently doesn't build with vendorized stuff [16:43] Pharaoh_Atem: then some look at CI (but not all tomorrow ;) [16:43] it fails to link [16:43] Pharaoh_Atem: right [16:43] Pharaoh_Atem: but the COPR package could, just to see where we are [16:45] 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] maybe [16:48] Pharaoh_Atem, zyga: I am sure we will [16:49] need some time to get started with this but we should get good results along the way :-) [16:53] PR snapcraft#1204 opened: target-arch: decouple target arch from deb, and use a separate field … [16:55] morphis: we're going to need to get you up to speed in Fedora-land [16:57] Pharaoh_Atem: yeah, just registered my account and waiting for approval now [16:57] Pharaoh_Atem: zyga will give me some more in depth introduction tomorrow and then we will get this going [16:58] then I should have a better overview of what we need to do and how we can get this forward [17:01] hi all is it possible set the log level for snapd? [17:04] NicolinoCuralli, theer is a way to enable debug messages ... but i forgot the exact runes [17:04] Chipaca, might know [17:04] i know nuthin' [17:05] NicolinoCuralli— yes [17:05] hah, lies! [17:05] :D [17:05] NicolinoCuralli— not particularly granular, except for http requests [17:05] NicolinoCuralli— what are you needing? [17:07] NicolinoCuralli— journalctl already has DEBUG logs in it; you can add HTTP debug logs via the SNAPD_DEBUG_HTTP environ [17:08] 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] 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] if the daemon run in devmode [17:09] ah. ogra_ back to you :-D [17:09] if anything runs in devmode, every execution will spill a löot of "ALLOWED" apparmor messages [17:10] 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] ogra_: yes i see it :D [17:12] thats crazy talk ... who would connect interfaces in devmode :P [17:12] PR snapd#2877 closed: interfaces: add chroot to base templates [17:13] (wow, i didnt knwo you could do that) [17:13] devmode logs violations against policy so if you don't connect your interfaces, there are a lot of policy violations :) [17:13] you might be thinking of classic confinement-- you may not plugs/slots with classic confinement, but devmode you are meant to [17:14] 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] as opposed to everything not in the default policy [17:17] Hi =) It's Renat from Screenly=) [17:17] I have a new question for you=) [17:18] and you always have the most interesting ones ! [17:18] :) [17:19] https://paste.ubuntu.com/24222873/ [17:19] We' re trying to install our custom gadget snap from the store. === genii_ is now known as genii [17:19] renat, that is during ubuntu-image ? [17:20] No. Image is created successfully [17:20] (you cant install a custom gadget on an installed image afaik) [17:20] It's during the first boot. [17:20] ah [17:20] jdstrand: can you repeat your explanation? [17:21] PR snapd#3069 opened: snapstate: restart as needed if we undid unlinking aka relinked core or kernel snap [17:21] 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] Official pi3 gadget snap works fine. === tinwood_ is now known as tinwood [17:22] renat, did you use your own model assertion as well ? [17:22] afaik the signature needs to match [17:22] Yes. [17:23] When we provide our gadget snap to the ubuntu-image using the --extra-snaps option - everything works fine. [17:23] and it doesnt if you get the same snap from the store [17:24] ? [17:25] Yes. [17:25] 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] now thats weird [17:26] theoretically the process should be exactly the same in both cases [17:26] just one more download step [17:27] 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] 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] elopio, that'd be great, would links to the github repos work? [17:36] coreycb: yes, please. [17:38] elopio, this is what we have so far: http://paste.ubuntu.com/24222988/ === JanC_ is now known as JanC [17:45] coreycb: thanks! [17:46] elopio, thank you! [17:55] renat, can you file a bug ? [17:55] renat, i'll gather some poeople to look at it tomorrow [17:59] 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] orga_, okay, I will do, thanks! [18:08] niemeyer, thanks! [18:08] ogra_, sorry. [18:08] no worries :) [18:09] PR snapcraft#1199 closed: cleanbuild: packaging independent detection [18:09] 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] i can give you my account data to transfer your money to ... [18:10] (though 35 is a rather old revision ... not sure i'd pay for that ... we're in the 1500s nowadays) [18:12] ogra_: http://paste.ubuntu.com/24223144/ [18:12] ogra_: could it be that the 'core' in staging is different than production. [18:17] Bug #1674778 opened: snapd hangs with 100% CPU usage when image has a custom gadget snap [18:31] 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] om26er, could be, i never used staging and dont know how it ends up there [18:34] renat, i fear that would have to happen through an option in the core config hook ... [18:34] renat, i just have disabling syslog in the works, nothing for journald yet though [18:35] 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] ogra_, what I need is changing journald storage from auto to volatile [18:35] cachio, what image did you flash ? [18:35] ogra_, the dragonboard one [18:36] ogra_, okay, thanks for the answer, have a good day=) [18:36] ogra_, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz [18:36] cachio, there is only one partition your PC could see ... system-boot [18:37] 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] 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] renat, file a bug about that as well please, else i forget :) [18:38] ogra_, I laready boot this SD card in the board, and it is working properly [18:40] cachio, well, then your PC should mount system-boot and writable ... [18:40] ogra_, it is not mounting nothing [18:40] it surely does here on my xenial machines [18:40] anything in dmesg right after you plug it ? [18:41] ogra_, let me check again, I was trying to find something useful [18:41] [ 380.505317] mmc0: error -110 whilst initialising SD card [18:41] [ 382.879924] mmc0: card never left busy state [18:42] ogra_, this is the only interesting thing I saw [18:42] that sounds more like a controller issue on your laptop to be honest [18:42] ogra_, it is happening with 2 sd cards [18:42] i'd blame the yakkety kernel/mmc driver there [18:43] is that any special type of SD ? [18:43] sdxc or plain sd or sdhc [18:43] ogra_, sdhc [18:43] compared to the cards that are recognized [18:44] ogra_, all of them are the same type [18:44] weird [18:44] well, there is nothing special about the GPT partition table used on the dragonboard SD cards [18:45] your PC should just read it and mount the partitions ... as i said, this works for me [18:45] but i use an USB card reader [18:45] ogra_, perhaps the last update has wroken something in my yakkety [18:45] i dont have any builtin MMC slot here [18:46] and with that it usually works for all my SD cards [18:47] ogra_, it was working for me too, but from yesterday I could not make it work it again [18:47] well, i'd blame yakkety then :) [18:48] ogra_, :), thanks [18:48] 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] Bug #1674794 opened: journald.conf storage=volatile config support [19:33] 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] Non-classic snaps build just fine. [19:36] Is there a way around that? [19:36] ryebot, yeah, set the SNAPCRAFT_SETUP_CORE environment variable to 1 [19:36] magic! [19:36] ryebot, instead of assuming you have the core snap, it'll download it itself and unpack it locally [19:36] thanks :D [19:36] does that require snapd to be running? [19:37] ryebot, nope [19:37] excellent, thanks [19:37] ryebot, it just unsquashes the snap itself, no mounting/running or anything [19:38] kyrofa: perfect, thanks [19:38] ryebot, any time! [20:45] PR snapcraft#1205 opened: asset-tracking: track source VCS details [20:48] PR snapcraft#1188 closed: store: set User-Agent header in store requests === jkridner|pd is now known as jkridner [21:06] kyrofa: that doesn't seem to work if I use --target-arch= [21:06] kyrofa: any workaround there? [21:06] ryebot, hmm, is it pulling the core snap for the wrong arch? [21:07] hmm I'm not sure [21:07] says: [21:07] Setting target machine to 'arm64' [21:07] ryebot, what doesn't work? [21:07] Preparing to pull kubectl [21:07] classic confinement requires the core snap to be installed. Install it by running `snap install core`. [21:07] Oh interesting [21:07] And you have that env var still set? [21:07] yeah [21:07] SNAPCRAFT_SETUP_CORE=1 snapcraft --target-arch=arm64 [21:08] ryebot, I will say that support for --target-arch is a little shaky. It's typically only used for kernels [21:08] ryebot, but please do log a bug so we can discuss and investigate [21:08] alright [21:08] thanks kyrofa! [21:18] kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1674828 [21:18] Bug #1674828: SNAPCRAFT_SETUP_CORE=1 doesn't work for foreign architectures [21:18] let me know if you need more details [21:18] Thanks ryebot [21:18] thank you! [21:19] anyone with an idea why I can't install a snap on a xenial box? http://pastebin.ubuntu.com/24224369/ [21:20] Saviq, you're sure the kernel you're on supports apparmor? [21:20] 4.4.0-65-generic, I'd have hoped... [21:20] standard xenial kernel [21:20] Saviq, that's nasty. Can you pastebin /var/lib/snapd/apparmor/profiles/snap.core.hook.configure? [21:21] kyrofa, http://paste.ubuntu.com/24224381/ [21:22] Saviq, huh, I was expecting it to be corrupted or something with that error, but that looks fine [21:23] kyrofa, any idea where the abstractions/openssl file should come from? [21:23] jdstrand, are you around? Not sure what that error entails ^^ [21:23] /etc/apparmor.d [21:23] I just downloaded the paste and it parses fine [21:27] 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] Ah [21:28] 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] jdstrand, FWIW there is no /etc/apparmor.d/abstractions/openssl ... [21:30] I suppose my apparmor installation got broken, /me reinstalls [21:30] Saviq: oh, that is not good [21:30] jdstrand, I had some filesystem issues on this box, that's probably what happened [21:31] yes, that file is presumed to exist [21:31] $ dpkg -S /etc/apparmor.d/abstractions/openssl [21:31] apparmor: /etc/apparmor.d/abstractions/openssl [21:31] I wonder what can I do to recover those, --reinstall doesn't do [21:35] ok a bit of purge and install got them back [21:35] back in business [21:36] ryebot: kyrofa --target-arch and classic will not work at all [21:37] sergiusens, since we would need to run the other arch's linker? [21:38] sergiusens, a decent error message will probably solve that bug, then [21:39] kyrofa: yeah === sarnold_ is now known as sarnold === balloons27 is now known as balloons [22:56] sergiusens: what if the build target is a static binary, like some golang artifact? [22:57] sergiusens: maybe a better question is, what is getting linked with what? [23:04] Bug #1674847 opened: produce package lists for Ubuntu Core versions on the web [23:31] Bug #1674505 changed: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build