[05:01] morning [05:20] mvo: hi, back to your morning schedule? [05:21] hey mborzecki - yeah [05:21] mborzecki: this should be my usual time again [05:22] mvo: poor kids back to school in august :( [05:23] mborzecki: yeah, in the worst heat since forever [05:23] mborzecki: not fun [05:23] mborzecki: and I see a lot of unhappy tests, its a bit flaky again, right? [05:23] interfaces-accounts-service [05:23] it seems is the culprit a lot of time? [05:23] times [05:24] mvo: that would be double guid in eds? [05:30] mborzecki: I see InvalidArgs errors here [05:30] mborzecki: but I only looked at one of the failures so far, haven't payed much attention to this before [05:30] mvo: which pr is this? [05:32] mborzecki: that was 5600 [05:34] hm maybe gnome online accounts has changed it's dbus iface? [05:35] mvo: i'll look into this [05:35] mborzecki: yeah, its very strange it shouldn't do that in the middle of the stable 16.04 release though. I wonder what is going on [05:36] mborzecki: I have a look, I see it also in travis on master once [05:36] mborzecki: and its not happening all the time (fun!) [05:48] mvo: well, (sssa{sv}a{ss})' matches the current stable org.gnome.OnlineAccounts.Manager.AddAccount iface [05:51] mvo: and 3.18.x release (supposedly in xenial) was the same [05:55] mborzecki: yeah, it should not have changed [05:56] mvo: i don't like how we don't pass the typespec to gdbus, it's guessed instead? [05:58] mvo: we pass "imap_smtp" "test@example.com" "Display Name" "{}" "{'actual': 'data'}", the error is that it's expecting (sssa{sv}a{ss}) but got '(ssssa{ss})' as if "{}" was interpreted as 's'? [06:00] mborzecki: yes, I think thats the issue but only sometimes which makes it strange [06:01] mborzecki: I wonder if there is a way to add debug to the call to see what it actually sends on the wire [06:01] or we could run dbus-monitor in to gather debug data [06:01] mvo: let me see if it honors G_MESSAGES_DEBUG or alike [06:04] Good morning [06:04] Long time no see [06:04] zyga: hey [06:04] zyga: hey, good morning! how are you? well rested? [06:06] Yes :-) [06:07] It feels like a month has passed [06:07] How are you all? [06:08] How is the project? === chihchun_afk is now known as chihchun [06:12] zyga: all going well so far [06:14] How is core18? [06:17] mvo: https://gitlab.gnome.org/GNOME/glib/issues/598 [06:18] mvo: wonder why it's using that particular error as an example [06:21] zyga: core18 is looking good, an image for amd64 is released, we are looking at arm now [06:21] mborzecki: heh, yeah [06:25] mborzecki: I added a PR that adds some debug, lets see if that gives us some clues [06:46] mvo: is the image stable or still in beta/candidate phase [06:55] zyga: very much beta still [06:55] zyga: but looking good overall [07:04] mvo: i looked into gdbus source code, it introspects the called method before repacking command line arguments to dbus types, so at least this part should try to do the right thing [07:06] mvo: we could just merge https://github.com/snapcore/snapd/pull/5602 and inspect it further when the problem is reproduced again [07:08] mborzecki: yeah, lets do this [07:08] mborzecki: thank you === pstolowski|off is now known as pstolowski [07:11] heyas [07:11] pstolowski: hey [07:11] pstolowski: back from vacation? [07:12] hey pstolowski [07:12] are you back just now? [07:14] hey pstolowski, welcome back! [07:21] mborzecki, mborzecki i got back home a few days ago [07:22] and temperatures here are not much different from greece, easy accomodation ;) [07:24] pstolowski: sound like you had a great time [07:32] mborzecki: indeed, corfu is really beautiful [07:59] we're down to 33 reviews [08:06] mvo: today I will focus on preparing for Flock tomorrow [08:06] but let me know if I can help with short or urgent tasks please [08:15] zyga: wb! [08:15] thank you :) [08:26] zyga: https://flock2018.sched.com/event/Fjde/fedora-and-snaps-a-two-year-retrospective-and-an-exciting-future this one right? [08:40] mborzecki: that's right [08:40] zyga: wonder if there'll be a live stream or sth === bads is now known as Guest73517 [09:42] xnox: hey, anything I can do to help with bug 1778936 (readding support for read-only-etc for hostnamed? should I just sru this change in isolation or is there a bigger systemd sru planned? [09:56] popey: hey, do you think something like https://bazaar.launchpad.net/~snappy-dev/snappy-hub/test-snapd-curl/revision/1 is worth pushing to the curl upstream? or to snapcrafters? we need a snap for curl for our internal testing but it seems like it would be generally useful [10:00] zyga: did you find any problem with slot remapping wrt the issue i had 2 weeks ago? [10:03] pstolowski: hey, no I didn't find anything at the time [10:06] mvo: certainly worth trying to submit upstream before putting in snapcrafters. [10:09] mvo: worth looking into whether upstream actually support distributing binary builds or not. [10:09] popey: what the best approach? I can do a PR that juts contains snapcraft.yaml for git master? [10:09] popey: aha, good point, they have a winbuild dir but I have not investigated that at all [10:10] mvo: typically we add some boilerplate to explain what it is, and why you're adding it. They also need to know how to register the name in the store etc. [10:11] mvo: for example. https://github.com/rust-lang-nursery/rustup.rs/pull/1441 [10:12] popey: thank you [10:12] np :) [10:13] mvo: xnox is on leave [10:14] mwhudson: thanks, who the best person to talk about systemd while he is away? [10:14] mvo: errrr i guess there is always slangasek [10:15] mwhudson: :) ok [10:17] but i suspect the implication is that there is no systemd sru planned in the near term [10:17] * mvo nods [10:21] there are no tests for snap-device-helper? [10:25] mborzecki: I don't think there are any individual tests [10:25] there are indirect tests via spread [10:25] but that piece of code is ... very old [10:25] heh, needs to be taught new tricks now, such as parallel installs [10:26] beware of dragons [10:26] zyga: i can hack some tests with gtest probably [10:26] why gtest? [10:27] I mean, we use glib for tests [10:27] zyga: we use that in s-c already, i'd add it to already existing unit tests [10:27] ah [10:27] so, in order to keep up with the latest in security, today I'll be pushing 23 new PRs, all of them bug-ridden. https://arxiv.org/pdf/1808.00659.pdf [10:27] I assumed you meant google's test [10:28] zyga: nah, just plain glib test framework [10:28] mborzecki: +1 then :) [10:28] sorry for being silly === vila_ is now known as vila [11:17] work on fixing godd on armhf (missing libs, rathole because x/sys/unix needs later go than xenial has) [11:17] eh, sorry, there is a bit of context missing here [11:18] I am in a bit of a rathole right now, I want to (re)build godd but x/sys/unix changed and needs a newer go to build. the godd snap uses xenial (which I would like to keep for now). so I experimented with using the go snap as a build-snap but LP will always use the system go. anyone have tried to override this? I have no luck so far [11:19] oh man, that's nested [11:20] mvo: That shouldn't be anything to do with LP as such - surely it's entirely in control of your snapcraft.yaml? Or maybe of the relevant snapcraft plugin I guess [11:20] cjwatson: I think its simply a PATH bug [11:20] cjwatson: i.e. /usr/bin is before /snap/bin and LP happen to have go installed as well, just an older version [11:21] cjwatson: at least that is my guess - I guess the easiest might be to try to just override-{pull,build} and set PATH manually(?) [11:21] * mvo tries that [11:21] I'm quite surprised that go would be in the chroots [11:22] cjwatson: oh, then its the go plugin pulling it in [11:22] cjwatson: I have a look at this next [11:22] Not in the xenial amd64 chroot at least (I don't have the armhf one locally) [11:22] Installing build dependencies: golang-1.6-go golang-1.6-src golang-go golang-src [11:22] from your build log [11:23] self.build_packages.append('golang-go') [11:24] /etc/profile.d/apps-bin-path.sh seems to put /snap/bin after everything else too ... [11:25] Maybe snapcraft's Go plugin just needs to have a more built-in way to use the snap [11:26] mvo: can't you use golang-golang-x-sys-dev ? [11:31] Chipaca: its pulled in via "pb" - I was considering to replace it with our own progress stuff [11:33] cjwatson: yeah, looking into this now === chihchun is now known as chihchun_afk [11:40] when maj:min is not passed to snap-device-helper the exit code is 0, while if other parameters are skipped we exit with 1 [11:45] Is it possible to rebuild that image but with a later kernel http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-amd64.img.xz ? [11:45] mvo: ah :-) ok [11:48] we will be using https://software.intel.com/en-us/openvino-toolkit/documentation/system-requirements and believe a somewhat fresh kernel will be better. [11:48] that brings me to the question: How far along is UbuntuCore18 ? [11:49] mvo, hey [11:51] cachio: hey, good morning [11:58] hmm standups disappeared from my calendar [12:00] plars, https://forum.snapcraft.io/t/stellarium-plars-not-working-on-nvidia-cards/6685/2 mind merging the PR ? (fix tested on both, intel and nvidia) [12:00] mvo: do we have standups as usual? [12:01] plars, (happy to drop the depth=1 if needed . (but it is painful for local builds if the git checkout is multiple gigs) === pstolowski is now known as pstolowski|lunch [12:14] mvo: I tried to use the new core18 in a vm on friday, but had trouble. it wanted to resize but I didn't know how big it was going to get. I couldn't figure out how to use qemu-img to resize before running without breaking the image [12:16] ogra: can we rebuild Ubuntu Core 16 amd64 image with latest kernel ? [12:17] we need Ubuntu Core but minimum kernel requirement is 4.14 for Intel' OpenVINO [12:17] ref: https://software.intel.com/en-us/articles/OpenVINO-Install-Linux [12:19] om26er, you can surely build your own kernel snap but for core 16 only 4.4 is officially supported ... you will have to wait for core18 to come out (perhaps you can then combine core 16 with the 4.15 core18 kernel, not sure, thats a question for mvo and if kernel tracks will also be supported in core 16 later) [12:20] I was thinking if there is way to rebuild the image but not compile the kernel ourselves and pick kernel snaps (pc-kernel) from 18/beta etc [12:20] jdstrand, it resizes to the pre-defined device size at build time ... u-image should dtrt and you shouldnt need to do anything [12:20] I guess recompiling won't be a problem, if that's really the only way [12:21] jdstrand, s/resizes/auto-resizes/ [12:21] om26er, well, mvo released his first experimental core18 image on friday ... you might want to play with that instead [12:23] jdstrand, if you want to resize yourself, technically just dd'ing zeros to the end of the img should be enough to have core's auto-resize trigger on next boot and resize /writable to full disk size [12:24] iirc our img's are raw so no qemu-img should be needed, dd should be enough [12:24] mvo: where can I find that "experimental" Ubunut Core 18 image ? [12:24] perhaps, I can help test it. [12:25] om26er, http://people.canonical.com/~mvo/core18/ [12:26] ogra: thanks, do you know of a tentative timeline for core18 release ? [12:26] before EOY :) [12:26] we have to do a prototype for a customer and want to make sure we pick the "right" target [12:27] i guess first stable beta quality images will show up within a few weeks [12:27] s/stable/usable/ [12:32] mvo: fyi, core16 is all approved (I just re-ran the tools-- they've since been updated to allow core16), but you'll have to publish them [12:33] ogra: re u-image: I tried to use the image that mvo created. I then tried to use u-image but couldn't figure out how to make it build a core18 image [12:33] Interesting, I believe our timeline is tighter, so I will ask on forums how we can compile and bundle linux 4.15 with UbuntuCore 16, before we fallback to ubuntu server image. [12:33] jdstrand, well, dd (on the uncompressed image) is your friend ... [12:34] ogra: I know they are raw. what I wanted to do is start it in a vm. it said it was autoresizing and I was afraid it was going to resize the raw image to fill my laptop's drive since I'm familiar with the resizing process [12:35] ogra: so, you are saying dd to some other filename? [12:35] jdstrand, it only resizes the filesystem to full img size [12:35] ogra: yes, which I mentioned I didn't know what it was [12:35] no, use dd with skip to append to the image [12:35] whatever you see with ls after unxz ;) [12:36] ogra: it says 3G [12:36] u-image just zero-pads the img file as well ... if you unxz you'll likely have a 3G img full of zeros [12:36] right [12:36] ogra: so you're saying it would only resize to that? [12:36] ok [12:37] so the resize script will resize writable to occupy the "physical" free space of these 3G [12:37] it was taking so long I was worried it was going to be longer [12:37] nah ... the vm only sees a 3G device [12:37] alright, well I'll try again then [12:37] and a filesystem thats smaller ... [12:37] so it just adjusts [12:38] hey jdstrand, ogra [12:38] hey zyga [12:38] * zyga waves and returns to Flock prep [12:38] hey zyga ... recovered ? [12:38] ogra: from holidays? :D [12:38] ogra: you know, I may have let it run and saw another issue [12:38] :) [12:38] * jdstrand tries again [12:38] ogra: I wish I had some more but I'm very happy I took the week off [12:38] so you didnt have to move ? :) [12:39] I eventually want this in a qcow2, but I'll let the resize happen in the raw before converting (the qemu-img convert seemed to mess up the label on the disk) [12:41] cjwatson: yes unfortunately; we had a fixed that ended escalating into a larger design discussion. To make the behavioral change not so surprising, we might just tie this to the use of bases (even adding the build snap still install the build package which is also what we want to solve). [12:41] google:arch-linux-64:tests/main/degraded just failed with https://pastebin.ubuntu.com/p/MX7WqN7xPr/ -- is this something I should just retry? [12:44] pstolowski|lunch: yeah, standups as usual (in +15min) [12:44] mvo: yep, thanks, just got all the details from mborzecki [12:45] jdstrand: re core18> the test image is ~3G iirc but it needs much less space. how big do you want it to be? [12:46] om26er: you could try to set in your model-assertion: "kernel: pc-kernel=18" which will pull in 4.15. as an experiment thats fine, if you want to support this we should talk :) [12:48] jdstrand: it takes forever because *drumroll* entropy :( [12:48] jdstrand: just hit a few keys [12:48] mvo (cc ogra): ah that was it. it drops to an initramfs: "cannot find 'writable' partition [12:48] jdstrand: uh, thats not good [12:48] all I did was unxz and then tried to launch it under kvm [12:48] after you used qemu-img on it you men ? [12:48] jdstrand: ok, let me try that, that should not happen [12:48] no [12:49] oh [12:49] jdstrand: anything unusal about your qemu/kvm setup? maybe the kernel has not the right virtio modules or something like this [12:49] let me get you the domain xml [12:50] jdstrand: fwiw, I ran it with "kvm -m 1500 -snapshot -redir tcp:10022::22 core18.img" and it worked, but let me re-run to double check [12:50] mvo: I did a virsh dumpxml on a bionic vm. then I adjusted to remove the mac, uuid and change the name and image [12:51] I have a whole process surrounding using libvirt, etc, and this is what I typically do for Core 16 [12:51] (though with a xenial dumpxml) [12:51] well, image wise 18 shouldnt differ [12:51] sergiusens: I sent a small go plugin PR your way, would be great if you could have a look (its tiny) [12:51] it uses the same u-image tocreate it so the result should be identical [12:52] mvo: https://paste.ubuntu.com/p/3BH6ZxScz2/ [12:52] * ogra also never uses libvurt/virsh or whatnot ... i also only use plain kvm [12:52] *libvirt [12:53] yeah, like I said, at a future step I convert to a qcow2 and add a snapshot. but I didn't do any of that yet [12:53] actually, there is something about that domain xml. let me try something [12:53] jdstrand: fwiw https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1783810 is the entropy bug [12:54] mvo, well, findfs has a 120 sec timeout ... if he runs into "writable not found" thsi is likely before entropy is even used === pstolowski|lunch is now known as pstolowski [12:57] mvo, ogra: I was dropped into the initramfs. that is *very* early boot. is it affected by that bug? [12:59] jdstrand: trying to reproduce right now by setting the drive to virtio [12:59] jdstrand: I also see a hang now and unable to resolve LABEL=writable [13:00] mvo: interesting. I was able to get it to resize using the regular kvm options, but then I was concerned about how big it would get. i'm no longer worried about that [13:00] (that was last friday) [13:02] mvo: fyi, I tried with defining the domain xml based off of my snappy-16-amd64 domain xml, it it has the same issue (but seems like you identified an issue with virtio) [13:03] mvo: btw, how are you creating this? I tried with ubuntu-image and didn't know how to setup the model assertion [13:03] jdstrand: I'm in a meeting now but I can reproduce the issue by setting the drive to virtio [13:03] it didn't know about 18, etc [13:03] ok [13:04] mvo: did you see that you need to still publish core16? [13:10] mvo: fyi, I changed it to ide and it is working. I'm unblocked it seems, so please prioritize however you want [13:11] mvo: that does not work, says "error: cannot download snap "pc-kernel=18": snap not found" [13:11] I then tapped shift a bunch of times to get past crng [13:11] mvo: here is my model assertion https://paste.ubuntu.com/p/R5YFR4GG8s/ [13:11] and I'm off and running [13:11] mvo: thanks! [13:11] intentionally removed authority-id etc. [13:12] I bet I can configure to qcow2 right off the bat... [13:12] I ran this command `sudo ubuntu-image -o pc.img -c beta pc.model` [13:12] mvo: commented, but good [13:17] jdstrand, no, not affected by the entropy bug then ... entropy will only be used later once we switched to the real root... what you were hitting was really the 120sec findfs timeout i think [13:18] ogra: yes, see above. once I used ide, then I hit the entropy bug. I tap shift until it moves along and I'm good [13:18] yeah [13:19] entropy issues will be interesting once we have full disk encryption upstzream ;) [13:19] well ... at that level of the boot that is [13:24] mvo: fyi, 'vi: command not found'. that's pretty stripped down! [13:24] :) [13:24] no nano either [13:24] * jdstrand wonders what to use [13:24] sed [13:24] ;) [13:25] (we dont have a classic snap for core18 either ... to trash your possible hopes in that direction) [13:25] jeez, echo isn't there either [13:25] this is quite the change [13:25] snap install extract-deb ... [13:26] extract-deb.download vim-tiny [13:26] try that ... and then call vim via the direc extraction path [13:26] well, if you're stripping stuff, you may as well get rid of sensible-editor, cause there is nothing sensible on the system [13:27] om26er: you need the "edge" core [13:27] om26er: on the machine you build the image, only the latest core has support for the kernel=track syntax [13:34] pstolowski: if you feel like doing some reviews https://github.com/snapcore/snapd/pull/5561 :) [13:34] jdstrand: core18 is very minimal, we need a vim snap [13:34] I'm surprised the images are so stripped down. I thought they were supposed to be roughly equivalent to cloud [13:34] jdstrand: I mean, we really needs snaps for the basic functionality [13:34] and lxd [13:34] jdstrand: we can add stuff still, not sure how tiny vim-tiny is but if it is actually tiny I think its not too bad to add it [13:35] mvo: we can't have vim witht he current interfaces since can't use classic and they need writes everywhere [13:35] around 1MB i think [13:35] it is very small [13:36] Installed-Size: 1071 [13:37] jdstrand: aha, vim is classic - hm, hm [13:37] I think installing a small editor makes a lot of sense [13:37] yeah [13:37] and vim-tiny is a quasi standard on all ubuntus [13:37] I would prefer vim-tiny, but really anything other than sed is good :) [13:38] jdstrand: nano [13:38] use nano [13:38] ogra: jdstrand: mvo: clearly it should be mg [13:38] it's small and useful OOTB [13:38] zyga: it isn't there either [13:38] nano has deps ... [13:38] but again, surprised at the new direction. last I heard, it was supposed to be similar to the cloud/lxd images [13:39] (nano uses ncurses ... ) [13:40] vim-tiny is really the way to go here ... also to stay in sync with all the other minimal ubuntu images IMHO [13:40] +1 (fwiw) [13:41] ed? [13:42] jdstrand: can a store assertion allow connecting snapd-control without it being autoconnected? [13:42] snap install extract-deb && snap connect extract-deb:home && extract-deb.download --arch amd64 vim-tiny && unpack/usr/bin/vim.tiny [13:42] jdstrand, ^^^ that works here [13:42] mborzecki: ? [13:42] (though only tested on core 16) [13:46] Chipaca: s/vim-tiny/ed, i mean there are legends that people used it [13:46] mborzecki: ? [13:47] Chipaca: sure [13:47] Chipaca: small editor for core18 snap [13:48] i have used sed as defaulkt editor in the past ... but you need echo too [13:48] mborzecki: ? [13:50] ogra: thanks. noted [13:50] * Chipaca quits ed so he can talk like regular people again [13:51] ppisati, hmm ... are there any known issues with the xenial kernel (beyond the two patches you added that i have already in use locally) https://paste.ubuntu.com/p/Jmg7d43J3h/ [13:51] mvo: is there a small non-desktop snap that uses 'base: core18' and listens on the network that you know of? eg, xkcd-webserver for core18? [13:51] jdstrand: would that be a reasonable suggestion to somebody trying to build a store app thing? [13:52] mvo, 2.34.3 is ready to go to stable [13:52] Chipaca: maybe? we are in the area of clear direction from Gustavo [13:52] mvo, if you are ok, I could sync with the store team to make it during the afternoon [13:53] Chipaca: and noise. I think the topic should be raised when Gustavo is back [13:53] jdstrand: agreed - i'd like to find a solution for that, but it's delicate [13:53] I'd like to at least stop this person from even trying to use classic to work around it [13:53] cachio: we should be fine just about anytime as long as we are not in the middle of a deploy or somehting [13:54] yeah [13:54] Chipaca: yeah, that doesn't seem like a helpful direction [13:54] noise][, nice, tx [13:54] Chipaca: well, classic will be denied for the same reason [13:55] ogra: i'm building one on LP ATM, i'll let you know how it ends [13:55] I mean, classic is there because of a lack of interfaces or ability to change something [13:55] you can't just use classic because you were denied use of an interface [13:55] ok, replied as much [13:55] in a short sentence [13:55] ppisati, seems to be the initrd step at the end of the build ... [13:55] cachio: +1 from me for this [13:56] hey folks, is it possible to restrict the amount of bandwidth snapd uses for e.g. automatic refreshes? since it might start refreshing whenever, I'd like to at least ensure it doesn't slow the home network down to a crawl :) [13:57] roadmr: not without a shaping proxy, but you can control when it refreshes [13:57] roadmr: e.g. "once a day between 3 and 5 am", that kinda thing [13:57] Chipaca: might be a nice feature to add download limiting, wdyt? [13:58] +1 [13:58] right... thanks Chipaca [13:58] mvo: (a) can of worms, (b) i mean one of those 200l oil drums (c) spice-eating worms [13:58] rate limiting would be best for me because even if I can timeframe the upgrades, destroying the network is always inconvenient [13:58] yummy ! [13:58] i mean, sure, nice [13:58] (and I also don't leave the computer on at times when it's not inconvenient; e.g. 3-5 am I'm fast asleep and the computer is off :) [13:59] Chipaca: heh, ok [13:59] sleep slower and leave it on ;) [13:59] mvo: i mean, yes, but it's usually full of little hard corner cases [13:59] ah, the "buy a new computer" argument :P no. [13:59] hehe ogra j/k, I understand these arguments... just wanted to check if it was something that existed [14:00] yeah, it doesnt because Chipaca is worm-phobic ;) [14:00] leaving this concern out of snapd and relying on e.g. QoS set on the home router makes good sense I think [14:00] mvo: roadmr: one thing we looked at back in u1 days, that was actually easier than bw limiting, was to just not saturate [14:00] Chipaca: yeah, I understand. it looks like the good people from juju implemented something already, might be worth a look [14:00] that is, look at the number of … packets? frames? i forget the details; something low-level in /proc/something [14:01] ahh interesting [14:01] plars, did you see my ping before ? https://forum.snapcraft.io/t/stellarium-plars-not-working-on-nvidia-cards/6685 ... i'd appreciate a merge of the PR [14:01] roadmr: saying "fix it with QoS" is always the easy answer that users hate [14:02] iptables could also do it (https://github.com/snapcore/snapd/blob/master/tests/main/econnreset/task.yaml#L7) [14:02] roadmr: (it's also right :-) ) [14:02] Chipaca: hehe except in this case I'm the user mostly [14:02] but I think it might be worthwhile to look at integrating the juju/ratelimit thing [14:03] anyway, after I looked at this core18 "synced" dir stuff :/ [14:06] - google:arch-linux-64:tests/main/degraded [14:06] grrrrr [14:07] ogra: yes, I said I'd take a look. I got slammed with several urgent things as soon as I started this morning. I'll take a look after the meeting I'm in right now [14:07] plars, ah,m i didnt see any reply (probably because all the freenode blocking due to the spam atm) [14:07] plars, thanks ! [14:08] ogra: heh, yeah it was a spammy weekend for sure. I'm still unburying myself from it. thanks for testing it, I don't have an nvidia system so I was just happy to hear someone else was using it even if it needs a fix :) [14:08] mvo: mborzecki: what can we do about google:arch-linux-64:tests/main/degraded failing all the time? (systemctl status says degraded on arch) [14:09] plars, well, the fix is tested and all and i have another user in the ubuntu-users ML that can test once it is in edge [14:10] plars, the only thing i cant test is amd graphics cards but i think they are nowadays just covered by the same setup as intel [14:10] mvo: fyi: [14:10] $ passwd [14:10] passwd: Authentication token manipulation error [14:10] passwd: password unchanged [14:10] mvo: same under sudo [14:11] sudo passwd -u $USER [14:12] ogra: yeah, that doesn't work [14:12] passwd: password expiry information changed. [14:12] (not the same thing as before, I forgot the -u) [14:12] but still not working [14:13] Chipaca: hm it's reproducible then? it used to happen occasionally [14:13] Chipaca: got a log? [14:13] mborzecki: https://api.travis-ci.org/v3/job/412606238/log.txt [14:15] jdstrand: looking, I think sergio reported this issue too [14:15] jdstrand, well, not sure if mvo forgot to use the patched shadow in core 18 ... we have some special packages in the image PPA that we use oin 16 and not all patches were forwarded yet [14:15] that's fine. just fyi [14:16] if shadow comes from the archive it will try to modify /etc/passwd by default [14:16] ogra: I think thats it, we are currently not pulling from the ppa [14:16] yeah [14:17] there were also some pam hacks to point to extrausers in live-build hooks ... you'll need to carry these over as well [14:18] Chipaca: mvo: looks like gce services failed [14:18] ogra: yeah, those should be in [14:18] great [14:20] ogra: hm, the shadow patch was also pushed to the deb, strange [14:20] * mvo looks deeper [14:20] oh, wait ... the command order above is wrong ... [14:20] jdstrand, sudo -u $USER passwd [14:20] try that one [14:21] sil2100: did you find out anything about the issue running consle-conf on the pis btw? === chihchun_afk is now known as chihchun [14:30] Chipaca: mvo: yeah, so multi-user.target depends on gce services https://pastebin.com/raw/8DBcXJCq, and those fail https://pastebin.com/raw/5strYP8L cachio maybe the image needs an update? [14:32] cachio: you probably need to rebuild gce-compute-image-packages and push an updated image [14:41] ogra: https://launchpadlibrarian.net/382085652/buildlog_snap_ubuntu_xenial_armhf_piso-xenial-raspi2-dummy_BUILDING.txt.gz [14:41] mvo: still investigating, I have some leads as I saw the 'match' rules being removed by console-conf, but I still didn't dig deeper into why the pi actually even does 'set-name', since it's completely unnecessary - anyway, in progress [14:41] ogra: built fine on LP [14:41] Chipaca: mvo: maybe we could blacklist arch in the test for now, wdyt? [14:42] ogra: i assume you were building xenial/raspi2, right? [14:42] ogra: i mean, it built fine after i applied one more patch on top of it [14:42] mvo: just to confirm, you mentioned this is only on the pi3 right now, right? SInce on my amd64 kvm there is no set-name and networking is set up correctly [14:42] mborzecki: how would we not forget to fix it? [14:42] ogra: but my build failure was different than what you got [14:42] sil2100: yeah, on the amd64 this works, let me check what the config looks like [14:43] sil2100: correct, no set-name there [14:46] sil2100: I pushed a fix for the pam config that should fix "passwd" on core18 (cc jdstrand and cachio) [14:46] mvo, great [14:46] cachio: you add trouble beside passwd on core18? or just that you couldn't set the passwd? [14:46] mvo, the issue with the resize is stopping the test now [14:46] it was not happening on friday as frequent as today [14:47] mvo, by the way, 2.34.3 is stable now [14:47] cachio: thanks for the stable update [14:47] cachio: the tests are hanging using the extrnal: mode in spread for core18? or for qemu? [14:47]