[06:29] good morning [06:29] Good morning zyga-ubuntu [06:30] JamieBennett: hey :) [06:30] how are you doing? you're up early! [06:30] nah, in Germany today so I've gain an hour ;) [06:30] aha, I see [06:32] * zyga-ubuntu looks at PRs [06:32] JamieBennett: is it as hot in Germany as it is in Poland this week? [06:33] 35 degrees or so [06:33] who needs Spain with weather like that ;-) [06:33] indeed [07:22] ogra: do you understand the impact of https://github.com/snapcore/core-build/pull/15 ? [07:42] * zyga-ubuntu looks at https://github.com/snapcore/snapd/pull/3260 [09:07] zyga-ubuntu, no, but i think enough cloud people spoke up there to merge it [09:07] ogra: any luck with the nano pi kernel update? :) [09:07] popey, sorry, not yet [09:07] ok, no worries [09:08] i'll let you know [09:08] * popey puts it back on the shelf for now [09:09] * zyga-ubuntu reads through endless reviews [09:09] tests are somewhat unhappy late [09:09] lately* [09:10] download speeds from DC are low [09:10] (or from CDN) [09:10] 111KB/s [09:10] then tests time out [09:25] Chipaca: can you please look at https://github.com/snapcore/core-build/pull/15#pullrequestreview-53445957 [09:25] PR core-build#15: cloud-init: fix strict mode, ensure cloud-init only runs on positive id [09:27] no [09:27] * Chipaca lies [09:28] zyga-ubuntu: +1 [09:33] morphis: hey [09:33] morphis: I reviewed the userd branch [09:33] yeah! [09:33] morphis: I marked is as needed changes because there were a few details [09:33] finally I got a review on it :-) [09:33] morphis: but overal it is good [09:33] thanks very much! [09:33] morphis: I plan to try it on real hardware but I don't think there are packaging changes done yet [09:33] (are there?) [09:34] and lastly I'm melting (warmest day of the year here) [09:34] zyga-ubuntu: there are [09:34] so please forgive me if I missed something [09:34] those are in the PR [09:34] excellent [09:34] for fedora/suse/ubuntu [09:34] zyga-ubuntu: any progress on the debian upgrade? [09:34] (i haven't made any) [09:35] mwhudson: no, but slowly getting there [09:35] mwhudson: I need to fix 32bit builds and give it a try first [09:36] mwhudson: and there's a bug on debian that I worked on reproducing (successfully) yesterday with new spread tests [09:37] zyga-ubuntu: cool [09:38] mwhudson: also I miss winter [09:38] ;) [09:38] zyga-ubuntu: anything you need from me? i guess i could/should check that the golang deps in the archive are appropriately close to the version in snapd [09:38] zyga-ubuntu: heh, i am kind of tired of winter now [09:38] mwhudson: I didn't check any deps and I expect us to grow some more items [09:39] although the days are getting noticeably longer now [09:39] mwhudson: if you want you can do a pass over that [09:41] i keep getting mails "Waiting for previous upload(s) to complete their review process. If you want to prioritize this last one, go to the other upload(s) page in https://dashboard.snapcraft.io/ and click on the 'Reject and remove from review queue' button." [09:41] hmmm [09:41] mwhudson: which snap were you uploading? [09:41] zyga-ubuntu: go-tip [09:41] mwhudson: is it a classic confinement snap? [09:41] yes [09:41] aha [09:41] was it approved before? [09:41] yes [09:42] odd [09:42] it seems to happen to one arch each upload [09:42] maybe the review database state got lsot [09:42] (it's built daily) [09:42] lost* [09:42] jdstrand and roadmr can probably help you out [09:42] but timezone :/ [09:42] and i *think* the snap gets approved in the end [09:42] ondra: hey, any plan to iterate on 3624? [09:42] or do you want me to? [09:42] oh yeah i wonder which architecture this is [09:43] (store emails do not mention the arch :() [09:45] oh wait no they don't get approved [09:45] and it's a different grab bag of arches each day i think [09:46] I think at this point you want to open a forum topic and CC daniel and jamie [09:46] btw, do you get snow down there? [09:50] zyga-ubuntu: ack [09:51] zyga-ubuntu: nah, not where we are, too close to the sea, it's very moderate temperature wise [09:51] sounds perfect :) [09:51] it snowed in 2010 or so, for the first time in 40 years [09:51] mwhudson: if you want please CC me on debian bits, I'm a bit rusty on the process I bet [09:51] and I'd love to help [09:52] zyga-ubuntu: all i want from you is an appropriate debian directory :) [09:52] i can do the other bits [09:52] aha [09:53] ah hahaha i bet github.com/mvo5/libseccomp-golang is not in debian [09:53] pstolowski: ey [09:53] zyga-ubuntu, hey! did you get my email? [09:54] hmm, maybe [09:54] * zyga-ubuntu looks [09:55] oh! I have it now [10:00] PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id [10:06] zyga-ubuntu: i think all of github.com/mvo5/libseccomp-golang, github.com/mvo5/net/bpf, github.com/ojii/gettext.go will need packaging [10:07] zyga-ubuntu: how come both github.com/ojii/gettext.go and github.com/ojii/gettext.go/pluralforms are in vendor.json? [10:07] don't you get the latter along with the former [10:09] mmmm [10:09] * zyga-ubuntu looks [10:09] I don't know [10:09] interesting [10:10] zyga-ubuntu: at least they specify the same revision :-) [10:10] mwhudson: I think this is how it works (oddly) [10:10] same is done for mgo.v2 [10:10] oh you have to least each package? [10:10] oh yeah [10:10] or go-systemd/ [10:10] seems like a stupid feature but well [10:10] not an actual problem [10:11] it seems more of "this is the subset I care about" but yeah, I didn't expect this either [10:17] zyga-ubuntu, mwhudson, maybe you can use this feature to make things more interesting for people [10:19] Chipaca: because snapd development is too boring [10:19] ? [10:19] mwhudson: "and here we see an adult snapd developer, luring a mate by making the code less boring" [10:20] also if you do use different revs of packages in the same repo i, as a debian packager, will kneecap you [10:24] but... but... i like my knobbly knees [10:26] Chipaca: so you know what to do! [10:26] (or not do) [10:26] I'm being repressed! [10:26] i'm going to bed [10:27] mwhudson: enjoy [10:28] hmpf [10:29] so wlan-only installs on the pi3 work fine but now i end up with a systemd service timeout counter that stalls the boot for 2min :( [10:29] funnily that doesnt happen on the dragonboard [10:30] * ogra guesses the unconfigured wired device causes it ... since there is no wired on the db [10:31] ogra@pi3:~$ systemd-analyze blame [10:31] 2min 230ms systemd-networkd-wait-online.service [10:31] 6.473s snapd.service [10:31] 5.658s apparmor.service [10:31] hrm [10:31] not really informative [10:31] ogra: which timer? [10:31] ah [10:31] systemd-networkd-wait-online.service [10:32] ogra: journalctl -u systemd-networkwwhatever-bork-bork? [10:32] does analyze list the services in the order they were started or just ordered by duration ? [10:33] Jul 31 09:45:11 pi3 systemd-networkd-wait-online[837]: ignoring: lo [10:33] Aug 01 10:28:36 pi3 systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [10:33] Aug 01 10:28:36 pi3 systemd[1]: Failed to start Wait for Network to be Configured. [10:33] Aug 01 10:28:36 pi3 systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state. [10:33] Aug 01 10:28:36 pi3 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. [10:33] ogra: try: systemd-analyze plot [10:33] PR snapcraft#1432 opened: kbuild: Support Makefile without install target [10:33] Chipaca, i was to lazy to shovel the picture around :P [10:33] aw [10:34] obviously the system wasnt online though ... the clock isnt set in the first line [10:34] aargh [10:34] so it waiting may be correct [10:34] my impression is that systemd-networkd-wait-online is rarely what you actually want [10:34] ogra: python3 -m http.server and dump it into a file in the local dir [10:35] mwhudson: bed! [10:35] Chipaca: thanks [10:35] yeah! [10:35] goo'boy [10:36] ogra: of course if you don't actually have network, no http server will help :-) [10:36] i do have network, everything is fine ... [10:36] its just that the boot stalls for 2 min [10:37] ogra: tbh it looks like a bug in the wait thing [10:37] ogra: "crash and burn" does not sound like "wait" [10:37] well, it doesnt crash and burn and eventually moves [10:37] systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [10:38] ^ crashing [10:39] hmm [10:39] ogra: https://bugzilla.redhat.com/show_bug.cgi?id=1277257 [10:39] although that's NetworkManager-wait-online [10:39] hrmph [10:40] ogra: ah! maybe the problem is that by default systemd-networkd-wait-online waits for _all_ devices to be online? [10:40] ouch [10:41] yeah, that would be it [10:42] ogra: man systemd-networkd-wotsit [10:42] yeah, just reading it [10:42] k === chihchun_afk is now known as chihchun [10:43] it has --ignore and --interface [10:43] additionally https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1673092, which is not fixed on xenial [10:43] Bug #1673092: systemd doesn't wait until the tentative flag isn't removed before firing units depending on network-online.target [10:45] * ogra blames xnox for closing the xenial task [10:45] we dont configure v6 by default though [10:47] ogra, i keep the list of tasks in systemd down, as I do look at /ubuntu/series/+source/systemd as my todo list for things to SRU. [10:48] ogra, if you prefer, i can reopen xenial task and mark it as won't-fix [10:48] ogra, somebody needs to bisect that bug, if they want/need that fix. [10:49] xnox: you do you [10:49] i dont "want" it but customers wont be happy if their devices wait for 2min during boot :P [10:49] xnox: as long as you include some of that coleslaw in the you you do [10:49] :-D [10:49] ogra: if we don't enable v6 that bug won't bite though [10:49] well, actually [10:49] i'm sure i didnt configure v6 in console-conf [10:50] is this the same thing that smb compalained about?! [10:50] but that probably says nothing ... [10:50] i see that my wlan0 device actually has a v6 ip [10:50] Chipaca, ogra - in that bug do you per chance receive RA advertisements, that are not true at all? [10:50] wlan0 Link encap:Ethernet HWaddr b8:27:eb:e1:ab:81 [10:50] inet addr:192.168.2.45 Bcast:192.168.2.255 Mask:255.255.255.0 [10:50] inet6 addr: fe80::ba27:ebff:fee1:ab81/64 Scope:Link [10:50] xnox, how would i check [10:52] xnox, this setup only started working with the last netplan backport ... before you could only configure wlan after already having a working eth0 ... now you can configure wlan standalone and leave eth completely out [10:53] ogra: fe80 i think means it's not up [10:53] but i might be wrong [10:53] * Chipaca knows too little v6, needs to fix this [10:54] this is not ipv6.... fe80 address is like 127.0.0.1 [10:54] ok [10:54] note the mac address..... [10:54] fe80::macaddress [10:54] ah [10:55] wopw [10:56] wow even [10:56] http://paste.ubuntu.com/25219497/ [10:57] so netplan actually configures it even though i told console-conf not to [10:57] and systemd-networkd-wait-online.service does not check the cable state [10:59] these are the moments where i miss the event based upstart :P [11:01] * ogra tries something [11:02] ok .... kind of a mix between a UX and a user error [11:02] console-conf defaults to keep ethernet enabled and configured for dhcp ... even if you never touch its config and only configure wlan [11:03] re-running console-conf and explicitly turning off everythiong around the ethernet device fixes everything ... the defaults are broken [11:04] * ogra files a subiquity bug [11:11] go has no support for dbm files :-( [11:14] * ogra files Bug #1707888 [11:14] Bug #1707888: ethernet defaults for unconnected device are wrong === alan_g is now known as alan_g|lunch [12:17] Hi, I hadf queried on the forum about the availablilty of a snappy core specific SDK for a given HW platform. One of the members responded that there was no such SDK availables and that we could work with standard SDKs meant for the HW. This is fine. But my question - sounds a bit trivial but I don't know - is that if I were to use astandard sdk, how are I to make use of snappy core interfaces such as the ones meant to access physical memory [12:17] etc? [12:17] zyga-ubuntu yeah, I made changes you asked, but now two tests panic for me and I can't see reason why [12:18] I mean are there some libraries that I can include while developing my snap? [12:20] Vamsi, creating a snap is basically a single yaml file ... there isnt really a need for an SDK for that ... just use whatever SDK you use for your normal development, once done drop a snapcraft.yaml in and run snapcraft [12:20] ondra: can you push, I'll have a look [12:21] zyga-ubuntu sure [12:21] (having hooks in different SDKs to call snapcraft might surely make sense though ... but some dedicated SDK wouldnt) [12:21] well... snapcraft itself counts as an SDK [12:21] it does a crapload of things [12:21] or rather a toolchain [12:23] ogra: I got that. So in the interface, I would just be detailing what methods could be used for the communication? [12:23] Vamsi: note that interfaces don't do anything new or require new APIs, instead they model existing interactions with the system [12:24] Vamsi: interfaces can control available system calls, acccess to files, access to dbus, etc [12:24] Vamsi: if you give me an example that you care about we can discuss how the interface would look like [12:25] zyga-ubuntu: Got it. I shall get back to you shortly with my requirement. [12:31] cachio, did you get my reply from last night btw ? [12:37] mwhudson (cc zyga-ubuntu): I looked in the store for 'go-tip' and could not find the snap. do you have a store url? [12:44] zyga-ubuntu it's updated now [12:44] mwhudson: fyi, I asked in https://forum.snapcraft.io/t/go-snap-getting-stuck-in-review/1512/5 so feel free to respond there [12:47] ondra: thanks, [12:48] zyga-ubuntu I get this https://paste.ubuntu.com/25219883/ [12:53] right [12:53] let me fix that [12:57] ogra, no [12:59] PR snapd#3623 closed: interfaces/builtin: implement broadcom-asic-control interface [12:59] cachio, all images except amd64 (for kvm) do not have any free space at all until first boot, they all resize to full space before mounting writable for the first time ... seems the resize failed for some reason in your pi2 and setup [13:00] cachio, the resize hook of the initrd atually writes a log into /dev/.initramfs (thats not saved, so you need to capture it right after first boot) [13:01] cachio, err ... sorry thats /run/initramfs actually [13:02] ogra, ok, I'll try to reproduce it again [13:02] and see what happened [13:02] Chipaca: standup? [13:02] cachio, try to capture the logs when it happens [13:02] ogra, so far all the tries that I did with the pi2 and 3 have failed [13:03] because of this error or other errors as I showed before [13:03] what kind of Sd is that ? how do you write to it ? [13:03] (and do you do any modifications before the first boot) [13:04] man i'm terrible at the standup [13:19] ogra, microsd card [13:20] I use dd to write on it [13:20] heh, yeah, i guessed that [13:20] (given there is only a microSD slot :) ) [13:20] how big is that card ... what brand etc [13:21] 8GB [13:21] and do you modify anything or do you let it boot straight away ? [13:21] kingston [13:21] I don't touch it [13:21] * ogra will check if he finds such a card in his drawer [13:21] I just boot it [13:22] ok ... well, the resizing definitely failed for whatever reason [13:22] there are two steps to it ... [13:22] ogra, with the sandisk cards that I tried yesterday I got the error doing tar that I showed yesterday [13:22] first it adjusts the partition table, second it runs resizefs [13:22] I reproduced that with 3 different cards [13:23] would be good to know which of the two steps fails (and indeed why ... ) [13:24] the logs should tell ... i havent seen resize fail in ages here in my tests [13:25] ogra@pi3:~$ df -h|grep writable [13:25] /dev/mmcblk0p2 3.6G 1.4G 2.1G 40% /writable [13:25] ogra@pi3:~$ === alan_g|lunch is now known as alan_g [13:25] (from last wed.) [13:28] ogra, ok, I am writting again the card === mup_ is now known as mup === sergiusens_ is now known as sergiusens [14:29] ogra, I used a sandisk card and got the same results [14:30] it is after I run console conf and connect through ssh to the pi2 [14:30] >> /dev/mmcblk0p2 496M 345M 116M 75% /writable [14:30] always using 8GB cards [14:30] cachio, did you capture the logs ? [14:31] also the output of "sudo sgdisk -p /dev/mmcblk0" would be interesting [14:31] (note the logs are gone after the first reboot) [14:32] ogra, yes https://paste.ubuntu.com/25220346/ [14:32] ogra, https://paste.ubuntu.com/25220352/ [14:33] cachio, wow [14:33] that smells like the first sector of the SD is broken ... (though then you should not see it if you use another SD) [14:34] mmm, I got the same with 2 sdcards [14:34] ogra, I can try with a different one, np [14:34] cachio, http://paste.ubuntu.com/25220363/ is roughly what you should see [14:35] (except for the sizes indeed, that should match your phys. size) [14:36] ogra, should I format the cards in any specific way previous to run dd? [14:36] no [14:36] dd should binary overwrite anything you do to the card [14:37] so whatever you would do would be wiped anyway [14:44] cachio, oh, where exactly do you write the SD, is that an ubuntu desktop machine ? [14:44] if so ... did you make sure that auto-mounting of the SD didnt happen ... dd'ing to a mounted SD can indeed cause weird unexpected issues [14:50] https://paste.ubuntu.com/25220436/ [14:51] ogra, the same happened with the other card [14:51] ogra, it is automounting [14:51] and do you manually unmount it ? [14:51] before dd'ing [14:53] i always have to do "sudo umount /dev/sdc1; sudo umount /dev/sdc2, dd ...." when writing an SD here [14:53] ogra, I am umounting the cards [14:53] hmm [14:54] * ogra is baffled ... i havent seen such behaviour in about a year ... and i use SDs from 4GB up to 256GB randomly here when testing my edge images [14:55] I am trygin again with no flags for dd [14:55] what are the flags you use ? [14:55] (should only be bs= to speed up the write ...) [14:56] bs=4M oflag=sync status=noxfer [14:56] I removed thost [14:56] those [14:56] keep bs [14:56] ok [14:57] (though if you have a lot of ram actually raise the 4M a bit ... i use 64M on my desktop machine with 16GB ram and 2M on my laptop ... that gets me the fastest write rates) [14:57] err [14:57] s/2M/32M [14:58] (bs defines the size of the chunks dd pulls iinto ram before dumping it to disk) [14:58] ogra, yes [14:58] writting [15:01] * ogra wonders if ubuntu-image changed in any way that could cause a corrupt partition table [15:03] cachio, i'd be interested to know if you see such bahaviour with http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ as well ... (which is what i regulary test) [15:03] (thats edge though) [15:07] ogra, ok, I'll try [15:08] i can really not explain what happens there ... the resize log doesnt show any particularly bad errors or anything and you should see a proper partition table [15:13] ogra, well, it worked well just with bs=4M [15:14] and nothing else [15:14] you mean the resize worked ? [15:14] yes [15:14] phew [15:14] ok [15:15] >> /dev/mmcblk0p2 3.6G 345M 3.0G 11% /writable [15:15] status=noxfer should really only suppress the final output though [15:15] not sure why oflag=sync would mess u anything either [15:15] *up [15:17] I don't understand neither [15:18] ogra, I am running the tests now, I'll see how they go [15:19] * ogra goes to read up about oflag=sync [15:30] zyga, abaut your comment of --disable-seccomp [15:30] in the opensuse branch [15:30] I uncommented this and all the tests passed [15:30] zyga-ubuntu, is it enough? [15:32] cachio: yes, I think that's good [15:40] PR snapd#3634 closed: interfaces/many, cmd/snap-confine: miscellaneous policy updates === chihchun is now known as chihchun_afk [16:23] jdstrand: hey, tools r892 are now deployed! [16:23] r893 is in the queue, should be there in the next couple of days [16:58] Hi, following https://tutorials.ubuntu.com/tutorial/create-your-first-snap#0 .. and it's not working.. anyone else had any problem at all with this tutorial? "hello" doesn't run after I've installed the snap [16:58] bub_: what happens when you try to run it? [16:59] -bash: hello: command not found [16:59] uhm, thinking of it, do I have to get out of classic-mode? [17:00] bub_: can you provide a trace of what you did so far? [17:00] bub_: also, what is in PATH currently? [17:01] https://tutorials.ubuntu.com/tutorial/create-your-first-snap#3 .. and down to typing 'hello' [17:01] bub_: are you doing this *on* a all-snap/core device with the classic snap installed? [17:01] bub_: can you run "snap version" to make sure we know some basics? [17:01] /home/admin/bin:/home/admin/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin [17:02] zyga, yes, I'm in classic-mode, creating the snap [17:02] bub_: aha, you may need to go out to run it [17:02] not sure, I never tried it this way [17:02] haha, that was it [17:02] 'exit' first.. then 'hello' worked as intented [17:03] tyty all! [17:03] first snap, now.. to build our proprietary software, using Qt.. I think I might be in for a lot of pain [17:04] bub_: I think it should be fairly easy [17:04] bub_: snapcraft has support for lots of things [17:04] bub_: if I can suggest something though [17:04] bub_: build a version that works on classic ubuntu first [17:05] bub_: so built a snap that runs on your desktop [17:05] bub_: are you making software for an embedded product or for desktop devices? [17:05] embedded [17:05] dell edge actually [17:05] bub_: does it have a GUI? [17:05] bub_: or is it a web/remote software? [17:05] nopes [17:05] ah [17:05] no GUI, afaik [17:05] headless is very easy [17:05] you should be just fine [17:05] we just got it, hehe.. [17:05] but [17:05] still [17:05] dell is x86 AFAIK [17:06] yeah [17:06] so just do it all on your destkop [17:06] once it works there you can just try it on the gateway [17:06] and it's much easier to iterate this way [17:06] bub_: in case you need help see forum.snapcraft.io [17:06] bub_: lots of people making or using snaps there [17:07] ah, my bad.. some of the executables in our software is GUI.. but first we're going to focus on the servermodule, which is non-GUI [17:07] ok, it's a whole new world for me [17:07] bub_: for a gui you will need a few more things [17:07]