[00:17] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[00:17] <mup> PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
[00:18] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[00:18] <mup> PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
[03:06] <kyrofa> elopio, I suppose you're in bed by now
[03:06] <kyrofa> elopio, but for tomorrow: I've got a problem with the ros2 snapd test: it sits with no output for more than 10 minutes, so Travis kills it thinking it stalled
[03:07] <kyrofa> elopio, do we need to show some sort of output? Even a spinner would probably do it
[03:07] <kyrofa> I'll comment on the PR as well
[06:38] <mup> PR snapcraft#1584 opened: style: use dedent for multiline strings <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1584>
[06:39] <zyga-ubuntu> good morning
[06:39] <Skip> Join
[06:58] <zyga-ubuntu> mvo: hello
[06:58] <zyga-ubuntu> mvo: how are you doing?
[07:00] <mvo> hey zyga-ubuntu
[07:00] <mvo> zyga-ubuntu: I'm doing well, thank you. tired but well
[07:03] <zyga-ubuntu> mvo: what's the outlook on 2.28, shall I allocate some time this week to work on releases?
[07:05] <mvo> zyga-ubuntu: I need to talk to cachio but I heard of no failures so far (but I'm behind mail). so it should get released this Monday
[07:06] <zyga-ubuntu> that sounds good
[07:15] <mvo> zyga-ubuntu: we need a second review for 3984, then this one can go in. maybe Chipaca can have a look when he is around?
[07:18] <davidcalle> good morning
[07:19] <zyga-ubuntu> mvo: thank you for the review on 3971
[07:22] <mvo> zyga-ubuntu: ta, #3993 also needs a second review
[07:22] <mup> PR #3993: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3993>
[07:22] <mvo> zyga-ubuntu: and you did the first one already so 3993 is also someting for Chipaca or pawel
[07:26] <mup> PR snapd#3996 closed: snap: refrain from running filepath.Base on random strings <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3996>
[07:34] <zyga-ubuntu> mvo: updated https://github.com/snapcore/snapd/pull/3971 as requested
[07:34] <mup> PR #3971: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <https://github.com/snapcore/snapd/pull/3971>
[07:48] <mup> PR snapd#4000 opened: snap-confine: add new SC_CLEANUP and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4000>
[07:48] <zyga-ubuntu> mvo: nice
[07:48] <zyga-ubuntu> mvo: I was meaning to do it, thank you for making it faster :)
[07:49] <mvo> zyga-ubuntu: still slightly jetlagged so the right level of complexity for me this morning :)
[07:49] <mvo> zyga-ubuntu: thanks for approving of it, I was not sure if you would like the macro or not
[07:49] <zyga-ubuntu> mvo: tyler recommended it and I think he has a point
[07:49] <mvo> zyga-ubuntu: I like it too
[07:50] <mvo> zyga-ubuntu: I just noticed my base git branch was old and I did not caught them all, will push a new commit with the remaining ones in a minute or so
[07:50] <zyga-ubuntu> mvo: sure, thank you!
[08:07] <kalikiana_> o/
[08:33] <zyga-ubuntu> mvo: is this intentional? https://github.com/snapcore/snapd/pull/4000/files/da0c1770f70d42b27c55a0b79c9320f250a46b77..287e8d2f2b2508c8e0e558f92aecfde30b8ce951#r142608335
[08:33] <mup> PR #4000: snap-confine: add new SC_CLEANUP and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4000>
[08:42] <mvo> zyga-ubuntu: meh, no, merge conflict error :(
[08:42] <mvo> zyga-ubuntu: sorry for that, fixing
[09:15] <mup> PR snapcraft#1585 opened: lxd: pass SNAPCRAFT_PARTS_URI through into container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1585>
[09:29]  * __chip__ takes a break
[10:02] <mup> PR snapd#4000 closed: snap-confine: add new SC_CLEANUP and use it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4000>
[10:03] <mup> PR snapcraft#1586 opened: repo: friendly, helpful error for unsupported distros <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1586>
[10:20] <ogra_> xnox, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1721223
[10:20] <mup> Bug #1721223: Networkd fail to set ip address between leases if ip address changes <systemd (Ubuntu):New> <https://launchpad.net/bugs/1721223>
[10:25] <mup> Bug #1721223 opened: Networkd fail to set ip address between leases if ip address changes on UbuntuCore <Snappy:New> <systemd (Ubuntu):New> <systemd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1721223>
[10:51] <ppisati_> - Mount snap "dragonboard-kernel" (unset) (cannot replace signed kernel snap with an unasserted one)
[10:51] <ppisati_> is there a way to workaround it or do i need to roll a new image from scatch?
[10:52] <ppisati_> ogra_: ^
[10:52] <ogra_> ppisati_, i think this only works if you initially built the image with the kernel as --extra-snap
[10:53] <ogra_> on regular images it is denied
[10:53] <ppisati_> ogra_: i vaguely remember that if you built the image with some cli flags, then you could replace the running kernel snap
[10:53] <ogra_> so if you didnt initially built it like that you will have to build a new one, yes
[10:53] <ppisati_> uhm ok, i'll roll a new image
[11:00] <mup> PR snapcraft#1587 opened: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587>
[11:30] <ppisati_> ogra_: snapdragon image from -edge are broken
[11:32] <ppisati_> ogra_: and is there a way to get the countdown back in uboot? i need to stop by and do a couple of modifications to the live dtb
[11:38] <rogpeppe> i was trying to use a unix-domain socket to connect to a snappy daemon, but it seems that it's not possible. My understanding of this thread (https://forum.snapcraft.io/t/socket-activation-support/2050/12) is that it will be allowed eventually. Anyone know the likely timeline for that?
[11:41]  * sergiusens waves good morning
[11:41] <sergiusens> apol_ I am working on the extract info thing fwiw ;-)
[11:43] <rogpeppe> sergiusens: hiya
[11:43] <rogpeppe> sergiusens: i was wondering about status of unix domain sockets above
[11:43] <rogpeppe> sergiusens: for the time being i've just gone with a localhost tcp port
[11:45] <rogpeppe> sergiusens: (in case you're interested, I published the snap in question to "macaroon" - it's an experimental command line tool for playing with macaroons)
[11:48] <mup> PR snapcraft#1588 opened: lxd: use SUDO_UID for ID mapping <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1588>
[11:50] <sergiusens> rogpeppe socket support is in the snapd domain, someone like Chipaca could provide more information; this topic https://forum.snapcraft.io/t/the-snapd-roadmap/1973 has all the information
[11:50] <sergiusens> on the when's, I suppose since it is under upcoming it means that it is planned for "soon" but not tied to any release yet
[11:51] <rogpeppe> sergiusens: i don't see it under upcoming, but I guess I don't know what topic it counts as
[11:52] <rogpeppe> sergiusens: are "wayland sockets" the same thing as unix sockets?
[11:52] <rogpeppe> sergiusens: (i get "access denied" if I try to follow the topic link)
[11:52]  * kalikiana_ heading out for lunch shortly, back in a bit - getting close to pushing the code from last week to GitHub
[11:53] <kalikiana_> ("having pushed" I guess is the correct tense here, meh, can't English now)
[12:01] <iAmSlow> hi
[12:01] <iAmSlow> where can i check for packages
[12:01] <iAmSlow> is there working visual studio code
[12:01] <iAmSlow> ?
[12:03] <ogra_> ppisati_, oh, in what way ?
[12:04] <ogra_> ppisati_, we'll need to rebuild the gadget with a bootdelay value to get the countdown back, prob is that this breaks with some addon boards that send data over serial as soon as they are powered
[12:10]  * zyga-ubuntu -> afk for a moment, need to get warm tea
[12:17] <apol_> sergiusens: :D awesome
[12:18] <ogra_> iAmSlow, try: "snap info vscode" ;)
[12:18] <iAmSlow> i dont have snap atm, am on void linux
[12:19] <iAmSlow> thats why i asked
[12:20] <ogra_> there is uappexplorer.com as an interim web UI it allows to search for snaps (despite being a tool for the ubuntu phone)
[12:20] <ogra_> a proper web frontend for the store is in the works, not sure where that stands though
[12:22] <davidcalle> ogra_: iAmSlow: https://snapcraft.io/vscode
[12:22] <davidcalle> Still a wip, but it's live ^
[12:22] <ogra_> davidcalle, yeah, but no search iterface yet :)
[12:22] <iAmSlow> ty
[12:22] <ogra_> works if you know the snap name though
[12:23] <iAmSlow> i found on that uappexplorer
[12:23] <ogra_> davidcalle, uh ... "develope website" is a mailto link ...
[12:23] <davidcalle> ogra_: there is a bug for that
[12:23] <ogra_> should pehaps say "developer contact"
[12:23] <ogra_> ah, great
[12:23] <davidcalle> ogra_: not involved in the impl/design, but yeah, QA is ongoing
[12:24] <ogra_> good
[12:57] <zyga-ubuntu> niemeyer: I'd like to skip today's standup, I feel sick and haven't done much today; I'll file a day off with jamie
[12:58] <jdstrand> zyga-ubuntu: hope you feel better soon
[12:59] <zyga-ubuntu> thank you :)
[12:59] <Chipaca> zyga-ubuntu: file a day sick, not a day off, dude
[12:59] <zyga-ubuntu> oh, I didn't know we have those
[12:59] <zyga-ubuntu> I never filed one
[12:59] <Chipaca> zyga-ubuntu: remind me to walk through the other things we have, once you're back and better
[13:00] <niemeyer> zyga-ubuntu: Ack, go get some rest
[13:00] <sergiusens> zyga-ubuntu it's documented in the manual dude!
[13:00] <sergiusens> get better
[13:01] <jdstrand> stgraber: hey-- today I found the lxc command behaving a little weird. It is trying to access /var/lib/snapd/hostfs/usr/lib/os-release (something I happened to plan on adding this week for unrelated reasons) and it is trying to chroot to /var/lib/snapd/hostfs
[13:01] <jdstrand> $ lxc list
[13:01] <jdstrand> chroot: cannot change root directory to '/var/lib/snapd/hostfs': Operation not permitted
[13:01] <jdstrand> stgraber: no apparmor denials (if I add something for os-release). it works under sudo
[13:02] <jdstrand> stgraber: lxd r4375, core r3017 (2.28.1 from candidate)
[13:03] <jdstrand> stgraber: guessing when running the lxc command as non-root, it is still trying to chroot
[13:03] <jdstrand> let me try a revert
[13:05] <jdstrand> stgraber: yes, if I revert to r4279, lxc starts working again
[13:06] <jdstrand> stgraber: I think the /var/lib/snapd/hostfs/usr/lib/os-release denial is a red herring, that is in r4279 (I'll also fix this in the default template)
[13:17] <ppisati_> ogra_: http://pastebin.ubuntu.com/25673213/
[13:17] <ppisati_> ogra_: snapdragon edge image
[13:19]  * kalikiana_ having (apparently) sweet greek mokka, yum
[13:28] <mvo> meh, looks like the ppc build is broken currently again: https://launchpadlibrarian.net/339707110/buildlog_ubuntu-xenial-powerpc.snapd_2.28.1+git401.a19ed0b~ubuntu16.04.1_BUILDING.txt.gz :( /<<BUILDDIR>>/snapd-2.28.1+git401.a19ed0b~ubuntu16.04.1/_build/pkg/gccgo_linux_ppc/github.com/snapcore/snapd/libosutil.a: member /<<BUILDDIR>>/snapd-2.28.1+git401.a19ed0b~ubuntu16.04.1/_build/pkg/gccgo_linux_ppc/github.com/snapcore/snapd/libosutil.a(_cgo_flags
[13:28] <mvo> ) in archive is not an object
[13:36] <jdstrand> stgraber: fyi, https://forum.snapcraft.io/t/chroot-cannot-change-root-directory-to-var-lib-snapd-hostfs-operation-not-permitted/2355/1
[13:43] <mup> PR snapd#3997 closed: cmd/snap: completion for alias and unalias <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3997>
[13:46] <__chip__> i'ma going to go for a run unless somebody needs me to do something right now
[13:56]  * __chip__ failed to go
[14:09] <Son_Goku> mvo: yay, you're back :)
[14:10] <Son_Goku> mvo: can you look at merging this? https://github.com/snapcore/snapd/pull/3984
[14:10] <mup> PR #3984: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3984>
[14:10] <Son_Goku> zyga-ubuntu has already approved it since tests pass now
[14:17] <ogra_> ppisati_, (sorry, was in meetings) ... ouch that looks like ondra's last chaneg broke it ... i thought he tested that before submitting
[14:18] <mvo> niemeyer: re 3951> did we agree on `snap pack` ?
[14:18] <mvo> Son_Goku: looking
[14:18] <mvo> Son_Goku: it needs two +1, maybe Chipaca can have a look at 3951 for the second review?
[14:19] <mvo> Chipaca: if you also could check 3993 that would be great, should be trivial
[14:19] <Son_Goku> mvo, I don't know what PR 3951 is
[14:19] <mup> PR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
[14:19] <Son_Goku> well.. now I do
[14:20] <mvo> Son_Goku: ups, sorry
[14:20] <mvo> Son_Goku: what I mean is we need two +1 for 3984 - I think its fine and just a formality. then we can squash merge it and cherry pick into 2.28
[14:21] <Son_Goku> okay
[14:21] <mvo> Son_Goku: lots of people out today (vac, sick, whatnot) so things are slightly slower than usual
[14:21] <ondra> ogra_ what happened?
[14:22] <jacekn> hello. any idea when "channels 2.0" will be available via dashboard.snapcraft.io? I'd like to create them for my snap
[14:25] <ogra_> ondra, http://pastebin.ubuntu.com/25673213/ is what ppisati_ seess when booting db ... havent had the time to try yet but will before EOD ...
[14:25] <ogra_> ondra, looks like sd blb and mmc blob got mixed up or so
[14:25] <elopio>  mvo do you have some time this week to talk about mutt? My problem is that on my canonical gmail account, I can't see the inbox, just "all mail". This is my config: https://github.com/elopio/dotfiles/tree/master/email 😔
[14:28] <mvo> elopio: sure, keep reminding me about it if I don't get back to you :) but happy to help
[14:28] <ondra> ogra_ no if blobs would be mixed up, you will not get to uboot at all
[14:28] <ogra_> hmm, indeed
[14:28] <ogra_> well, something is wrong with eading from the fat
[14:29] <elopio> mvo: thanks. I will get back to you in a couple of days :)
[14:30] <ondra> ogra_ ppisati_ this is booting from sd card right?
[14:30] <ogra_> ondra, i woould guess so, paolo didnt reply yet... all backlog is above
[14:31] <ondra> ogra_ let me try edge image
[14:31] <ogra_> still setting up my board here .. i was in meetings til nw
[14:34] <__chip__> cachio: snapd#3951 needs you to unblock it
[14:34] <mup> PR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
[14:35] <Son_Goku> mvo: Chipaca approved :D
[14:35] <cachio> __chip__, I'll take a look
[14:35] <__chip__> Son_Goku: that Chipaca sounds like a cool guy
[14:35] <Son_Goku> heh, indeed
[14:36]  * __chip__ still working mostly on his travel computer, for some strange reason
[14:36] <ppisati_> ondra: yep, sd card
[14:37] <mvo> Son_Goku: yay
[14:37] <kalikiana_> __chip__: I do the same, but in fairness, I don't have a non-travel computer :-P
[14:37] <mvo> Son_Goku: I do the merge/cherry-pick in a little bit
[14:37] <Son_Goku> mvo: awesome
[14:37] <Son_Goku> I tried to do the cherry pick myself, but git got mad at me and said it can't apply
[14:37] <__chip__> kalikiana_: my eyes object if i work for too long on the 12"
[14:37] <Son_Goku> which is why 2.28.1 hasn't been released into Fedora yet...
[14:41] <cachio> __chip__, still tests failinf on that PR
[14:41] <cachio> seem to be related to the change itself
[14:43] <mup> PR snapd#3984 closed: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3984>
[14:44] <ondra> ogra_ strange, I get same thing as attila reported once, nothing at all on uart
[14:48] <__chip__> cachio: it looks like something is reexecing when it shouldn't (or viceversa)
[14:50] <mup> PR snapd#4001 opened: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by mvo5> <https://github.com/snapcore/snapd/pull/4001>
[15:05] <kyrofa> Hey elopio, beyond the snapd tests lacking output, my particular test is dying with this: https://pastebin.ubuntu.com/25673818/ . Any ideas on that one?
[15:05] <__chip__> mvo: where do i send the wine for the review of snapd#3964?
[15:05] <mup> PR #3964: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <https://github.com/snapcore/snapd/pull/3964>
[15:08] <mvo> __chip__: I am probably the right person, I can do it next
[15:08] <__chip__> mvo: :-)
[15:08] <__chip__> mvo: i was starting to wonder if your comment about needing to do that review with a nice glass of wine was a request :-D
[15:09] <mvo> __chip__: heh, no, its a matter of just doing it, will do so in a little bit
[15:15] <__chip__> mvo: okie doke
[15:15] <__chip__> i think i will now once again try to go for a run
[15:15]  * __chip__ hopes to make it to the door this time
[15:15] <elopio> @kyrofa we need to capture the output to see what went wrong
[15:15] <nothal> elopio: No such command!
[15:15] <mvo> __chip__: *go* for it
[15:15] <mvo> __chip__: I take a short break and attack this branch then
[15:15] <mvo> __chip__: lets see what my jetlag brain can manage
[15:15] <kyrofa> elopio, ah, okay
[15:16] <jacekn> hello. any idea when "channels 2.0" will be available via dashboard.snapcraft.io? I'd like to create them for my snap
[15:16] <elopio> Does it fail only in travis?
[15:17] <kyrofa> elopio, no, I got that one locally
[15:17] <kyrofa> But still don't know what it means :P
[15:17] <kyrofa> elopio, so if I understand your comment on GH correctly, we just need to use pipes?
[15:18] <elopio> Yes, handle the stdout and stderr on our own.
[15:18] <niemeyer> mvo: Yeah, snap pack it is (and unpack)
[15:19] <elopio> Print and safe in case we need to addDetails for an error.
[15:20] <kyrofa> elopio, alright, I'll see if I can get that working
[15:20] <kyrofa> elopio, quick question: what is the benefit of addDetails if we're printing the output?
[15:21] <elopio> The output could be huge, and the error hidden somewhere. In theory, details are nicely printed in the error report at the end of the run.
[15:27] <kyrofa> Ah, okay
[15:27] <kyrofa> elopio, should we only addDetails stderr?
[15:28] <kyrofa> Or both?
[15:30] <sergiusens> jacekn creation of channels is done per request on the store category on https;//forum.snapcraft.io ... once granted it should show up on the dashboard
[15:31] <jacekn> sergiusens: thanks. Do you know how to login using ubuntu SSO by any chance?
[15:31] <sergiusens> jacekn you can read more about that here https://forum.snapcraft.io/t/channel-terminology-and-policy/551
[15:31] <sergiusens> jacekn I am not sure about that, niemeyer might have more details on it
[15:32] <niemeyer> jacekn: You mean from code to interact with the store?
[15:34] <jacekn> niemeyer: no, I mean to use login.ubuntu.com openid, same as dashboard.snapcraft.io uses (requirement to create new account for snapcraft forums is an obstackle for users)
[15:35] <elopio> kyrofa: after talking with mpt, it seems to me that we can make stderr good enough to understand errors, and look at the full output for details. But, we are not there, I guess for now it depends on each case. Maybe add only stderr, and if it's not good enough, file a bug?
[15:36] <kyrofa> elopio, good deal
[15:36] <kyrofa> And agreed
[15:36] <niemeyer> jacekn: Sorry I'm a bit out of context.. what's the issue again? Do we have someone trying to login and they can't?
[15:38] <jacekn> niemeyer: context is me trying to get channels 2.0 set up and I was told that to do that I have to post on forum.snapcraft.io but I can't see any option to log in with ubuntu SSO (or any other open id)
[15:39] <ondra> ogra_ my dragonboard is refusing to boot at all
[15:39] <niemeyer> jacekn: If you click on Sign In and enter your email and password you should be able to quickly get in
[15:39] <ogra_> ondra, i have some massive issues with my SD reader ... it refuses to detect any cards
[15:40] <ogra_> ondra, wsell, i suspect we need to roll back the last gadget commit then
[15:40] <niemeyer> jacekn: Please let me know if you have any issues there
[15:40] <ogra_> (though i'd really like to test myself first ... damned)
[15:40] <niemeyer> We'll likely enable more login systems at some point
[15:40] <jacekn> niemeyer: sorry but I won't enter my 3rd party password on forum.snapcraft.io, openid shoudl send me to the right place
[15:41] <niemeyer> jacekn: You can enter whatever password you want...
[15:42] <jacekn> niemeyer: right so I need to create an account. Understood
[15:43] <niemeyer> jacekn: Yep, email and password and you're up
[15:44] <jacekn> ack. Running out of time but might do that next time. I'll also try to file a bug to support SSO for convenience and consistency with the dashboard
[15:45] <niemeyer> Thanks!
[15:46] <mup> PR snapcraft#1589 opened: Update default node engine to 6.11.3 <Created by flexiondotorg> <https://github.com/snapcore/snapcraft/pull/1589>
[15:58] <ppisati_> ogra_: please, don't rollback without reproducing my issue - if i start from an old -edge image, and i let it update, it appears to be fine
[15:58] <ppisati_> ogra_: while when buiding a fresh -edge image locally, i hit the problem above
[15:58] <ogra_> ppisati_, because we never update gadget content
[15:59] <ogra_> its a regression in ondra's last change, i see the same issue over here
[15:59] <ppisati_> ok
[16:00] <ondra> ogra_ that is strange as I did test fresh image, I almost never update
[16:00] <ogra_> http://paste.ubuntu.com/25674091/
[16:01] <ogra_> ondra, same output that ppisati_ got above
[16:01] <ogra_> well
[16:01] <ondra> ogra_ let me check one thing
[16:01] <ogra_> in fact ...
[16:01] <ogra_> ubooot.env seems to be broken
[16:01] <ogra_> printenv doesnt list a single snappy_ var
[16:02] <ogra_> dragonboard410c => fatls mmc 0
[16:02] <ogra_> sdhci_transfer_data: Transfer data timeout
[16:02] <ogra_> mmc_init: -70, time 10653
[16:02] <ogra_> ** Bad device mmc 0 **
[16:03] <ogra_> dragonboard410c => fatls mmc 1
[16:03] <ogra_> ** Unrecognized filesystem type **
[16:03] <ogra_> ah, wait
[16:03] <ogra_> dragonboard410c => fatls mmc 1:8
[16:03] <ogra_>             blobs/
[16:03] <ogra_>    131072   uboot.env
[16:03] <ogra_>             dragonboard-kernel_37.snap/
[16:03] <ogra_> it sees the file but doesnt load it
[16:04] <mup> PR snapcraft#1590 opened: setuptools: conditional Debian-specific deps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1590>
[16:04] <ogra_> aha
[16:04] <ogra_> - #define BOOT_TARGET_DEVICES(func) \
[16:04] <ogra_> - 	func(USB, usb, 0) \
[16:04] <ogra_> --	func(MMC, mmc, 1) \
[16:04] <ogra_> - 	func(MMC, mmc, 0) \
[16:04] <ogra_> -+	func(MMC, mmc, 1) \
[16:04] <ogra_> - 	func(DHCP, dhcp, na)
[16:04] <ogra_> ondra, ^^^ i bet thats the issue
[16:05] <ogra_> yo switched the boot devices around with your patches somehow
[16:05] <ondra> ogra_ but I did not change patches
[16:05] <ogra_> err
[16:05] <ondra> ogra_ I only split them
[16:05] <ogra_> you prretty much reworked all of them
[16:06] <ogra_> https://github.com/snapcore/dragonboard-gadget/pull/6/files
[16:06] <mup> PR dragonboard-gadget#6: gadget snap build improvements <Created by kubiko> <Merged by ogra1> <https://github.com/snapcore/dragonboard-gadget/pull/6>
[16:09] <ogra_> ondra, are you sure "git am --3way ../../../u-boot-generic*.patch" will actually apply both generic patches ?
[16:12] <stgraber> jdstrand: I believe I've got a fix for that one already, might just need promotion
[16:25] <ondra> ogra_ it will
[16:25] <ondra> ogra_ just testing it here
[16:25] <ogra_> ondra, well ...
[16:25] <ondra> ogra_ I think I found something
[16:25] <ogra_> U-Boot 2017.05-dirty (Sep 21 2017 - 17:41:37 +0000)
[16:25] <ogra_> Qualcomm-DragonBoard 410C
[16:25] <ogra_> DRAM:  986 MiB
[16:25] <ogra_> MMC:   sdhci@07824000: 0, sdhci@07864000: 1
[16:25] <ogra_> Using default environment
[16:25] <ogra_> it definitely doesnt read uboot.env
[16:26] <ondra> ogra_ I did it manually now and there is difference, #define CONFIG_SYS_BOOTM_LEN           0x1000000 <> #define CONFIG_SYS_BOOTM_LEN           SZ_32M
[16:26] <ogra_> even though i can see it with fatls
[16:26] <ogra_> but bootm is way later
[16:26] <ondra> ogra_ but we are not hitting that at all
[16:26] <ondra> ogra_ yes and we still fit in 16M anyway
[16:26] <ogra_> the issue is that it never loads the env
[16:27] <ogra_> "Using default environment" is a clear indicator
[16:29] <kyrofa> elopio, something else is slurping up the stdout, even the prints in the test
[16:29] <kyrofa> I don't remember where that is
[16:29] <ondra> ogra_ I understand, just trying to figure out what is the reason for that
[16:30] <ogra_> mvo, hrm ...
[16:30] <ogra_> ogra@anubis:~$ snapcraft-forum
[16:30] <ogra_> udev_enumerate_scan failed
[16:30] <ogra_> ogra@anubis:~$
[16:30] <ogra_> mvo, my snaps dont start anymore after a reboot
[16:30] <kyrofa> elopio, I suppose it's just unittest
[16:31] <kyrofa> Because then it prints stdout/stderr upon failure
[16:31] <ogra_> mvo, i'm on the beta core
[16:31] <ogra_> ogra@anubis:~$ rocketchat-desktop
[16:31] <ogra_> udev_enumerate_scan failed
[16:31] <mvo> ogra_: when did this start to happen? what revision and what is in the journal/systemd status for the given snaps?
[16:31] <kyrofa> Er, testtools
[16:31] <mvo> ogra_: uhhh, that sounds like something from either snap-confine or kernel
[16:31] <ogra_> mvo, i just rebooted, (xeniall desktop all up to date)
[16:31] <mvo> ogra_: desktop even, hmmm
[16:32] <ogra_> it worked befoore the reboot
[16:32] <ogra_> not sure what came in with the recent updates ... surely a kernel though
[16:32] <ogra_> (i had not rebooted for a while)
[16:33] <ondra> ogra_ building gadget here again, to make sure all the patches are correct
[16:33] <ogra_> ondra, yeah, i just did the same ... the code loks correct ...
[16:33] <ondra> ogra_ yep I pulled old patch and compared and looks all as expected
[16:34] <ondra> ogra_ also I did 10+ runs from sdcard here on that code
[16:34] <ogra_> i was guessing that when i merged it ... yet .. it is broken
[16:37] <ogra_> ondra, since fatls mmc 1:8 shoows uboot.env just fine theer must be something with the patch
[16:37] <ogra_> uboot.env is definitely where it should be
[16:38]  * kalikiana_ going to wrap up for the day...
[16:40] <ondra> ogra_ any idea how can I restore dragoboard, my one seems to be buggered, so I can't test any
[16:40] <ogra_> ondra, no idea what yoou mean ? wiping the emmc ?
[16:40] <ondra> ogra_ can't boot from sd or emms, nothing at all coming on console
[16:40] <ondra> ogra_ nothing even from aboot
[16:41] <ogra_> ondra, hmm, inteesting fact ... building a local image with the gadget i built locally seems to boot
[16:41] <ogra_> that sounds more like your mezzanine board doesnt work
[16:41] <ondra> ogra_ and user led does not even show that it's trying to boor from sd card when there is sd card
[16:41] <ondra> ogra_ no I connected uart directly and no luck either
[16:42] <ogra_> does the led on the mezzanine board light up at all ?
[16:42] <ondra> ogra_ plus I did try another mezzanine board  and same
[16:42] <ondra> ogra_ yeah only red one though
[16:42] <ogra_> how do you connect to uart directly ? i dnt thhink the db supports that
[16:42] <ogra_> thats fine ...
[16:42] <ogra_> red here too
[16:42] <ondra> ogra_ not one which will show trafic
[16:42] <ondra> ogra_ TX and Rx are on Pin 11 and 13
[16:43] <ondra> ogra_ https://github.com/96boards/documentation/blob/master/ConsumerEdition/DragonBoard-410c/Guides/uart-serial-console.md
[16:43] <ogra_> well, did you play with the dip switches at the bottom of the board ?
[16:43] <ondra> ogra_ I did not wear safety glassed when installing it though :)
[16:44] <ondra> ogra_ no, nothing it was here on the desk since I used it last time and then it was running fine
[16:44] <ogra_> weird
[16:45] <kyrofa> elopio, ah ha! runtests.sh uses -b
[16:45] <kyrofa> elopio, removing it starts printing stuff
[16:45] <ondra> ogra_ tell me about it, it packed itself up while it was not even connected to power
[16:45] <kyrofa> elopio, is that what you have in mind?
[16:46] <ogra_> mvo, hmm, even switching to stable coe ... noo luck ... and nothing in dmesg, syslog or journalctl .... all i get is "udev_enumerate_scan failed" when tying to un any snap
[16:46] <ogra_> *stable core
[16:47]  * ogra_ tries another rebot 
[16:50] <ogra_> mvo, hrm, so whatever it was, another reboot fixed it
[16:50] <mvo> ogra_: hm, so the error comes from snap-confine and it happens when enumerating udev fails, now that might be a bug on our side if we add a incorrect udev tag somehow
[16:51] <ogra_> mvo, yeah, but i cant reproduce it anymore after refreshing to stable and rebooting
[16:51] <ogra_> ondra, so given my locally built gadget works over here, i think i'll just upload that one by hand to the store and we can take care of the rest tomorrow
[16:53] <ondra> ogra_ so if you build it locally it works fine?
[16:53] <ogra_> ondra, yes
[16:53] <ondra> ogra_ OK upload that one and let me check one thing
[16:53] <ogra_> uploaded
[16:54] <ogra_> (waiting for the store to actually release it, then i'll do another testbuild)
[16:55] <ondra> ogra_ I think I know what happened
[16:55] <ondra> ogra_ so when you call git am, it will commit those changes
[16:56] <ogra_> why dont you just use --apply
[16:56] <ondra> ogra_ which works fine on your/mine machine, as we have set up user
[16:56] <ogra_> like we do in all other gadgets
[16:56] <ondra> ogra_ it failed on LP, as git it not set
[16:56] <ondra> ogra_ because then you need one gadget, or can you do that on multiple patches?
[16:56] <mvo> ogra_: hm, strange
[16:56] <ogra_> yeah, use apply :)
[16:57] <ondra> ogra_ check here https://launchpadlibrarian.net/337810269/buildlog_snap_ubuntu_xenial_arm64_dragonboard_BUILDING.txt.gz
[16:57] <ondra> ogra_ search for *** Please tell me who you are.
[16:57] <ogra_> ondra, you use a shell script to call git am ... just make it a loop that calls apply
[16:57] <ondra> ogra_ that's where it's suppose to say Applying: suport patch for dragonboard410c for ubuntu-core
[16:58] <ondra> ogra_ and my dragoboard went to 96 board heaven, no fastboot, neither recovery sd card working
[16:58] <ogra_> ondra, that should noot be possible, there is a ROM that should be recoverable
[16:58] <ogra_> unless you caused some electrical damage
[16:59] <ogra_> ask in #96boards
[16:59] <mup> PR #96: Move architecture handling into its own package <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/96>
[16:59]  * ogra_ whacks mup
[16:59] <ondra> ogra_ lol
[16:59] <ogra_> cprov, http://people.canonical.com/~ogra/snappy/dragonboard-gadget.png why do i have two edge entries there ?
[17:00] <ondra> ogra_ I'm gonna prepare PR replacing am with apply, seems to working as expected
[17:00] <ogra_> i assume that shouldnt be possible
[17:00] <ogra_> ondra, +1 ... take your time though, we should be safe for the dalies now with the manual upload
[17:00] <ogra_> so tomorrow is enough
[17:01] <ondra> ogra_ well I can't even test, as my board is dead now
[17:01] <ogra_> (well, we should be fine if the store behaves ... that screenshot above is a bit worrying)
[17:02] <ondra> ppisati_ thanks for bringing this up! defo problem with LP build
[17:02] <ogra_> yeah
[17:02] <ogra_> ondra, we seem to have a user that uses our gadget as input on the forrum whoo saw it too
[17:02] <ondra> ogra_ I did not know we have armhf build for dragoboard :)
[17:03] <ogra_> (i was kind of assuming he broke it with his own patch ... )
[17:03] <ogra_> ondra, oh,. hah
[17:03] <ogra_> blind me
[17:03] <ondra> ogra_ yeah that second edge is different arch
[17:03] <ogra_> yeah
[17:03] <ondra> ogra_ which is even more amusing :D
[17:03] <ogra_> let me unrelease that
[17:03] <ppisati_> ondra: not at all
[17:03] <ondra> ogra_ I really want to know where that build came from
[17:03]  * ppisati_ goes to the gym, back in ~1hr
[17:04] <ogra_> ondra, most likely a test build of mine in snapcraft.io
[17:04] <ondra> ogra_ lol
[17:04] <ogra_> i was tinkering with the possibilities of auto-builds without syncing to LP
[17:04] <ondra> ogra_ yeah there are only 3 builds
[17:04] <ogra_> bah
[17:04] <ogra_> and i cant unelease it
[17:04] <ondra> ogra_ so we should have also one for amd64 then :P
[17:05] <ogra_> build.snapcraft.io doesnt do arm64 yet
[17:05] <ondra> ogra_ I was so many times asking id snapcraft.io can control architectures, here you have reason why
[17:05] <ogra_> thats the prob ...
[17:05] <ogra_> we could hardcode cross building
[17:05] <ogra_> so an amd64 build would always produce an arm64 snap
[17:06] <ogra_> but that seems a bit evil in case someone wants to build natively
[17:06] <ondra> ogra_ yeah, but look to snapcraft.yaml, it has specifically defined only arm64 architecture, so we have fail on multiple levels
[17:06] <ogra_> anyway, myth solved ...
[17:06] <ogra_> well, that arm64 only applies to the snap metadata
[17:06] <ondra> ogra_ so build.snapcraft.io  ignored arch in snapcraft.yaml and store does same, and takes file name instead
[17:06] <ogra_> snaps doont care if the binaries actually match whats written on the box
[17:07] <ogra_> b.s.io will elease an arm64 snap
[17:07] <ogra_> no matter whats inside
[17:07] <ogra_> snapcraft.yaml rules here
[17:07] <ogra_> the trick is to make sure the binaries inside are actually arm64
[17:07] <ondra> ogra_ but it build armhf, from recipe which says "arm64 only". magic
[17:08] <ogra_> my nanopi gadgets all just do cross build on amd64
[17:08] <ogra_> but out comes armhf as the snap
[17:08] <ondra> ogra_ snapcraft.yaml says arm64 only
[17:08] <ogra_> yes
[17:08] <ogra_> but snapcraft doesnt care
[17:08] <ogra_> it just uses the local native arch
[17:09] <ogra_> now ... if you force install a cross compiler and spürinkle some magic into the build scripts you will get an armhf or arm64 binary inside
[17:09] <ogra_> anyway ... i goot called for dinner ...
[17:09]  * ogra_ is afk
[17:09] <ondra> ogra_ but we already have armhf binary in there :P
[17:10] <ogra_> yes
[17:10] <ondra> ogra_ remember we set arch to arm
[17:10] <ogra_> likely a bug ...
[17:10] <ogra_> anyway ... off now ...
[17:25] <kyrofa> flexiondotorg, can you give me a pointer to the user-story-oriented documentation you guys have been working on? I have two to add
[17:25] <kyrofa> But I can't remember where they are
[17:25] <kyrofa> popey, that might be a question for you as well ^^
[17:26] <kyrofa> Also, are those docs live anywhere?
[17:26] <sergiusens> kyrofa https://docs.snapcraft.io/build-snaps/languages
[17:27] <kyrofa> Ah ha, snappy-docs then, got it
[17:28] <kyrofa> Those are not quite as findable as I expected
[17:29] <flexiondotorg> kyrofa: There were on the site. But apparently are not currently?!
[17:29] <kyrofa> flexiondotorg, they are, but you have to know where to look
[17:29] <flexiondotorg> I mean the top level navigation.
[17:29] <kyrofa> Ah indeed
[17:29] <flexiondotorg> I'll raise this.
[17:29] <kyrofa> The snapcraft hooks docs were blown away as well
[17:30] <kyrofa> Things have been shuffling there recently
[17:33] <davidcalle> Kyrofa, blown away?
[17:33] <kyrofa> davidcalle, replaced with snapd docs :P
[17:34] <davidcalle> Oh no, with brand new docs
[17:34] <davidcalle> Kyrofa, feel free to tweak and add
[17:35] <kyrofa> flexiondotorg, I was going to add MOOS/ROS docs, but they're more... technologies, not languages. Is that okay?
[17:36] <davidcalle> sergiusens: kyrofa: let's move languages up in the tree, right after first snap
[17:37] <kyrofa> I guess "node" isn't really a language either
[17:37] <davidcalle> Kyrofa : looks like the only requirement so far is having a logo for it
[17:37] <davidcalle> :p
[17:37] <kyrofa> davidcalle, sounds good
[17:37] <kyrofa> davidcalle, hahaha
[17:59] <mup> PR snapd#4002 opened: interfaces: misc updates for default, browser-support, home and system-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4002>
[18:03] <kyrofa> Alright elopio, sergiusens take a look at snapcraft#1591
[18:03] <mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[18:04] <mup> PR snapcraft#1591 opened: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[18:13] <mup> PR snapd#4003 opened: interfaces: deny lttng by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4003>
[18:30] <mup> PR snapd#4004 opened: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4004>
[19:07] <sergiusens> kyrofa I'll look in a bit
[19:44] <Mikael> I have a bunch of Dell 2001 running ubuntu core and is concerned about the system time being syncronized. Is there a snap to sync time? I've seen timedatectl mentioned...
[19:45] <Mikael> Dell3001
[19:53] <mup> PR snapd#4005 opened: Add an exception for Firefox's access to /dev/shm, <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/4005>
[19:55] <__chip__> Mikael: I think the people that can answer that are in a different timezone -- maybe use forum.snapcraft.io so you don't miss eachother
[19:58] <Mikael> Thanks Chip
[20:04] <kyrofa> davidcalle, flexiondotorg can I get a new project created on https://github.com/snapcraft-docs ?
[20:14] <kyrofa> sergiusens, any chance you have access to that group?
[20:15] <sergiusens> kyrofa maybe, why do you ask? :-)
[20:15] <kyrofa> sergiusens, every language document has its example hosted there
[20:15] <sergiusens> kyrofa so, what do you want me to create?
[20:15] <sergiusens> I was being tongue in cheek btw ;-)
[20:16] <kyrofa> sergiusens, if you would be so kind as to create a moos-ping-example repo there to which I have access
[20:17] <sergiusens> sure thing
[20:22] <sergiusens> kyrofa moos-ping or moos-ping-example?
[20:22] <sergiusens> moos-ping feels a bit better
[20:22] <kyrofa> sergiusens, I'm good with it
[20:22] <sergiusens> with which kyrofa? ;-)
[20:22] <kyrofa> Ha!
[20:22] <kyrofa> With moos-ping
[20:23] <kyrofa> sergiusens, sadly, there are no generically useful MOOS or ROS utilities out there, so the examples we need to use are overbearingly boring
[20:23] <kyrofa> Anything not boring is way too complex for this :P
[20:23] <kyrofa> But it'll do the job
[20:23] <sergiusens> kyrofa done, git@github.com:snapcraft-docs/-moos-ping.git
[20:24] <sergiusens> kyrofa the code for moos you mean and not the snapcraft.yaml itself ;-)
[20:25] <kyrofa> sergiusens, of course ;)
[20:25] <kyrofa> sergiusens, hmm... the leading hyphen? A typo?
[20:26] <kyrofa> sergiusens, also, can you give me commit access? Happy to do PRs if you prefer
[20:26] <kyrofa> Oh, I have to accept the invite, how fancy
[20:27] <kyrofa> Okay all good on the commit access. Fix the hyphen and we're good
[20:29] <sergiusens> strange, not sure how that hyphen got there
[20:29] <sergiusens> kyrofa you cannot commit?
[20:30] <kyrofa> sergiusens, all good now, thank you!
[20:35] <sergiusens> kyrofa btw, snapcraft#1578 could use your attention
[20:35] <mup> PR snapcraft#1578: project_loader: quote more environment variable values <Created by malept> <https://github.com/snapcore/snapcraft/pull/1578>
[20:35] <kyrofa> Ah yes, okay
[20:41] <mup> PR snapcraft#1586 closed: repo: friendly, helpful error for unsupported distros <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1586>
[20:42] <sergiusens> kyrofa and snapcraft#1591 is failing
[20:42] <mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[20:43] <kyrofa> Nooooooo
[20:44] <mup> Issue snapcraft#1556 closed: build-snaps recording <design-required> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1556>
[20:44] <mup> PR snapcraft#1567 closed: recording: record the snaps installed on the machine <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1567>
[20:44] <sergiusens> elopio mind resolving the conflicts on snapcraft#1584 ?
[20:44] <mup> PR snapcraft#1584: style: use dedent for multiline strings <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1584>
[20:52] <kyrofa> sergiusens, if you by chance have some downtime to proofread: https://github.com/CanonicalLtd/snappy-docs/pull/131
[20:52] <mup> PR CanonicalLtd/snappy-docs#131: languages: add MOOS guide <Created by kyrofa> <https://github.com/CanonicalLtd/snappy-docs/pull/131>
[20:53] <sergiusens> kyrofa downtime is a rare commodity now that I am alone with my son this week ;-)
[20:53] <kyrofa> sergiusens, haha, hence the phrasing
[20:54] <kyrofa> ROS one should be up by tomorrow at the latest
[20:54] <sergiusens> but I will indeed review later tonight, after bed the bed time shift; we have a tent in his room where we do the first try to get sleeping
[20:55] <kyrofa> Going back to PRs and reviews for now
[21:00]  * sergiusens mini EODs until later in the evening/night
[21:13] <kyrofa> sergiusens, snapcraft#1591 should be fixed
[21:13] <mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[21:13] <elopio> sergiusens: I see no conflicts there. I updated the quotes in the docs
[21:17] <elopio> oh damn, there are many in the fake refactor. That might be hard.
[21:41] <mup> PR snapcraft#1565 closed: cli: add the pack command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1565>
[22:58] <kyrofa> sergiusens, when you're able, can you fork https://github.com/ros/ros_tutorials into snapcraft-docs, please?
[23:01] <kyrofa> sergiusens, wait... no. Don't do that
[23:02] <kyrofa> sergiusens, just create a ros-talker-listener repo, or something similar
[23:34] <kyrofa> sergiusens, https://github.com/CanonicalLtd/snappy-docs/pull/132 for the ROS one
[23:34] <mup> PR CanonicalLtd/snappy-docs#132: languages: add ROS guide <Created by kyrofa> <https://github.com/CanonicalLtd/snappy-docs/pull/132>