[00:13] I can't seem to set up a bridge for my snappy img running in qemu-kvm [00:14] any ideas? === wolfeidau_ is now known as wolfeidau === chihchun_afk is now known as chihchun [05:56] sergiusens: hmmmm, right, native is not ideal indeed, sorry for overlookng this [06:53] good morning [06:57] hey dholbach & snappy world [06:58] salut seb128 [06:58] how are things in snappy land [06:58] ? [06:58] good, still working on getting personal to work ;-) [06:59] yeah, I saw some uploads of yours - looks like it's a bit more work enabling everything [06:59] yeah, let's see how things look like today === vmayoral|pc is now known as vmayoral [07:05] good morning [07:25] morning! [07:49] mvo_, bah, you broke ubuntu-core/desktop-next builds :p [07:50] * seb128 fixes [07:51] or not [07:51] mvo_, let me know when you are around to discuss the issue :-) [07:51] seb128: whats the issue? clickpkg -> snappypkg ? [07:51] yes [07:51] https://launchpadlibrarian.net/210397648/buildlog_ubuntu_wily_i386_ubuntu-core-system-image_BUILDING.txt.gz [07:52] seb128: sure, let me look [07:52] seb128: sorry, but that the only way to know if it works, upload and hope for the best. no local testing :( [07:52] mvo_, btw you had your changes commited as if they were uploaded, but they were not [07:52] so I changed back to unreleased, batched some desktop-next tweaks and uploaded [07:52] hope that was ok ;-) [07:53] mvo_, you can do a local build, it just takes a while [07:53] seb128: sure, I though I did upload, I guess may I should go to bed [07:53] mvo_, https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html has "howto build locally" [07:54] need to adapt the PROJECT/SUBPROJECT env variables [07:54] but that works (or at least enough to check the groups thingy) [07:54] seb128: I'm not sure that works in the age of LP builders [07:55] seb128: oh, you checked it works? nice [07:55] yeah, I did the user/group config for desktop-next using that [07:55] mvo_, [07:55] "Setting up ubuntu-snappy-cli (1.2-1+524~ubuntu15.10.1) ... [07:55] Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory [07:55] Adding system user `clickpkg' (UID 109) ..." [07:55] seb128: the build failure is due to a out-of-sync issue of snappy and livefs rootfs [07:55] seems like ubuntu-snappy-cli creates this group [07:56] if Chipaca can review https://code.launchpad.net/~mvo/snappy/snappy-gettext-fix and https://code.launchpad.net/~mvo/snappy/snappy-gettext-fix2 we should have a working image again [07:56] seb128: yeah, it does create the snappypkg user in trunk but trunk failed to build for unreleated reasons so they got out of sync [07:57] seb128: but all my faul, once the fixes above land we should be good again [07:57] mvo_, any estimate of when you can land those fixes? [07:57] I'm sort of waiting on a new image build to continue my personal work [07:58] seb128: once someone reviews them, you can do that too if you want, should all be pretty small/obvious, I just need a ACK on the MP :) [07:58] * seb128 looks [07:59] * conyoo error parsing serv.dat [08:03] mvo_, those look good to me, I comment approved but can't approve the mp, not in the right team [08:04] seb128: sure, thats fine [08:04] seb128: thanks [08:04] yw! [08:07] seb128: great, I top-approved, once they are merged (every 10min) I will trigger a build and once that is available we can do new images [08:10] mvo_, do you plan to upload to wily as well? [08:11] seb128: oh, you don't use our ppa, sure, I will do a upload [08:12] mvo_, thanks [08:12] and no, we don't use the ppa [08:12] we are good citizens ;-) [08:13] mvo_, tarmac doesn't like my +1 [08:13] "Voting does not meet specified criteria. Required: Approve >= 1, Disapprove == 0. Got: 1 Pending." [08:14] seb128: silly thing, I approved now as well to make it happy. we can't block oyu [08:14] you [08:27] Good morning all; happy Mailman^WPostal Worker Day! 😃 === chihchun is now known as chihchun_afk [08:48] mvo_, thanks for the snappy upload ;-) [08:53] mvo_: aw, for a moment i thought you were fixing the apparmor thing for arm :) [08:53] mvo_: (ubuntu-core-launcher seems to need an additional .so on arm than on intel, at least last night) [09:03] seb128, mvo_, i dont think the fix that was uploaded will work [09:04] you only fixed the fallout ... the reason for the failure is the switch from clickpkg to snappypkg [09:04] ogra_, ? [09:05] ogra_, snappy changed its group from clickpkg to snappypkg [09:05] ogra_, mvo updated the groups in livecd-rootfs to reflect the change [09:05] but that was uploaded before ubuntu-snappy [09:06] with the new version there is no clickpkg user anymore [09:06] why would it fail? [09:06] because there is a snappypkg user now [09:06] or snappkg [09:06] (not sure how exactly it is called) [09:07] the user was just renamed ... but your livecd-rootfs change doesnt have that rename [09:07] ? [09:07] http://launchpadlibrarian.net/210413322/livecd-rootfs_2.320_2.322.diff.gz [09:07] ogra_, https://launchpadlibrarian.net/210356511/livecd-rootfs_2.319_2.320.diff.gz [09:07] oh, i missed that [09:08] ignore me then [09:08] ogra_, my upload from today was to fix the ":ubuntu" missing after I tweaked the groups yesterday [09:08] :-) [09:23] Chipaca: uh, arm failing? meh, no I did not look at this [09:23] mvo_: ok, i'm looking :) [09:25] ooh, maybe it's the 32bit-ness, not the arm-ness [09:25] * Chipaca tries with x86 [09:29] tyhicks: do you know of any reason we shouldn't include libgcc_s.so in the apparmor profile for ubuntu-core-launcher even on amd64 where it's not needed? it's needed on 32bit platforms and i'd rather not have a different profile for different bittiness [09:30] * Chipaca makes a branch prediction [09:30] lol [09:42] tyhicks: added you to https://code.launchpad.net/~chipaca/ubuntu-core-launcher/libgcc_s/+merge/263489 but probably should've added your team instead (which team should that be?) [09:43] sergiusens: elopio: fixes https://bugs.launchpad.net/snappy/+bug/1470210 for you [09:43] Ubuntu bug 1470210 in Snappy "integration tests fail with: error while loading shared libraries: libgcc_s.so.1" [Undecided,New] [09:43] i should move that to the launcher, shouldn't i [09:43] there === fgimenez_ is now known as fgimenez === chihchun_afk is now known as chihchun [10:42] mvo_, Chipaca hi, i'm getting this http://paste.ubuntu.com/11803910/ on bbb, is it a known bug? [10:42] the dates look weird [10:43] how can 87 be newer than 88 ? [10:43] haha, indeed [10:44] ogra_, yep :, i got [10:45] ogra_, the image with: [10:45] sudo ubuntu-device-flash --revision -2 --verbose core rolling --output bbb-edge-2.img --channel edge --developer-mode --oem beagleblack [10:47] hmm, so is that timestamp created by u-d-f ? [10:47] i thought it comes from the server [11:03] morning [11:04] Chipaca: I'll defer on that one [11:04] sergiusens: sure, wasn't asking you to review C code :) was just heads-up'ing you wrt it being fixed there [11:07] seems seb128 cant have his system-a/b partitions mounted by label on amd64 === chihchun is now known as chihchun_afk [11:07] dont we use labels on grub installs ? [11:07] Chipaca: it's a one liner :-P [11:08] sergiusens: cee coooode [11:08] sergiusens: scaaary [11:08] looks like neither root=/dev/disk/by-label/system-a nor root=LABEL=system-a works [11:08] sergiusens: * not even code, let alone C :) [11:08] ogra_: yes, we use labels [11:08] do we act special in any way on grub based installs ? [11:08] wird [11:08] *weird [11:09] ogra_: and that works as far as i've been able to test it [11:09] k [11:09] does it require some initramfs support we might be missing? [11:09] seb128: efi? [11:09] the partitions have label according to blkid [11:09] ooohhh [11:09] no, that's in virt-manager, I think standard grub [11:09] well, and udev should at least create the /dev/disk/by-label/ symlinks [11:09] ah, no, then it should work [11:09] but seems they are not there either [11:10] seb128: can you go to the grub console? [11:10] Chipaca, http://people.canonical.com/~seb128/shot0001.png [11:10] Chipaca, how would the grub console help ? [11:10] seb128: plz to grub console [11:10] Chipaca, I need to go for lunch, people are waiting, but I'm going to have a look to that once back [11:11] Chipaca, please give hints and I can read the backlog then ;-) [11:11] ogra_: i'll do a search from there [11:11] ogra_: as i know what i expect there === chihchun_afk is now known as chihchun [11:11] Chipaca, but the mounting happens from initrd, way later when the kernel took over already ... [11:11] * ogra_ <- confused [11:12] ogra_: but it's not finding root [11:12] ogra_: which is specified by grub [11:12] ogra_: so that's wrong, somehow [11:13] its not finding the labeled partition ... even with manually specifying root=/dev/disk/by-label/system-a or root=LABEL=system-a [11:18] Chipaca, echo $root gives hd0,gpt2 [11:18] Chipaca, unsure what info you want/need [11:18] shouldn't the LABEL thing be independant of that? it wouldn't boot at all if the boot was not correct [11:19] yes [11:19] thats what i mean [11:19] grub should only find the boot partition, load kernel and initrd and switch over [11:19] mounting happens from the initrd [11:19] seb128: search --no-floppy --label system-a [11:21] hd0,gpt3 [11:21] system-b on gpt4 [11:21] (which is the one I want/which has the /) [11:22] seb128: echo $snappy_ab [11:22] a [11:22] ok, so now [11:22] why is root gpt2? [11:23] no idea, it's the snappy personal image [11:24] Chipaca, the grub config is http://paste.ubuntu.com/11757708/ [11:24] ah, i don't know how that's partitioned [11:24] shouldnt differ from core [11:24] augh. when is the new grub.cfg going to land already :) [11:24] same as core [11:24] seb128: ok, so your root should be system-a or system-b, not some other partition [11:24] seb128: do this: [11:25] set label="system-$snappy_ab" [11:25] set cmdline="root=LABEL=$label ro init=/lib/systemd/systemd console=tty1 console=ttyS0 panic=-1" [11:25] search --no-floppy --set --label "$label" [11:25] linux /vmlinuz $cmdline [11:25] initrd /initrd.img [11:25] boot [11:26] is that going to teach us anything? [11:26] (you probably dont want console=ttyS0 on a desktop system :) so you can see the messages on screen) [11:26] I can boot fine using root=/dev/vda4 [11:26] gpt2 is a "system-boot" vfat partition [11:26] seb128: vda4? [11:26] k, really need to go for lunch [11:26] what's vda4? [11:26] sda4 [11:26] in a virt-manager vm [11:26] seb128, do you get a busybox after the mount error ? [11:27] no, back to grub [11:27] bbiab [11:27] i dont see a prompt in your pic [11:27] ah [11:28] ogra_: console=tty1 console=ttyS0 puts it on both, afaik [11:28] no [11:28] the first one applies to kernel messages [11:28] the second one to userspace [11:29] so as soon as the kernel hands over to initrd the messages go to serial [11:29] oh, that's not what we want [11:29] if you only set console= once it will apply to both [11:30] so you just want to drop console=ttyS0 [11:31] You can specify multiple console= options on the kernel command line. [11:31] Output will appear on all of them. The last device will be used when [11:31] you open /dev/console. [11:31] right [11:31] the last sentence is key :) [11:32] (having /dev imples userspace ;) ) [11:32] Chipaca, in any case u-d-f makes a system-boot vfat partition on personal, unsure why the $root points to that [11:32] cyphermox or slangasek might know [11:33] well, the commandline is created durin livecd-rootfs if i'm not wrong [11:33] system-boot is where grub lives, system-a or system-b is where the kernels and initrds live [11:33] (in the current scheme, that is going to change rsn) [11:35] ah, no, livecd-rootfs doesnt set any root= arg ... it only sed's /etc/default/grub for systemd stuff etc [11:37] seb128: you asked me whether we'd learn anything from entering all the above; the answer is that we'd learn whether the future grub.cfg would be able to boot this, whatever it is :) [11:37] ogra_: so, console=ttyS0 console=tty1 is what we'd want, right? to have serial for kernel/early boot but everything else on tty1 as expected? [11:38] yeah, sounds right [11:38] i still dont get where grub is involved with the rootfs mounting (beyond handing the cmdline over to the kernel) [11:39] the actual work happens inside the initrd ... and the initrd doesnt seem to have any knowledge of the labels [11:41] ogra_: this might be the old grub config confusing me; reading the grub manual, there's nothing special about the root env var [11:41] ogra_: afaict, just setting “root=$root” in the linux commandline is what's expected [11:42] well, it works if seb128 sets root=/dev/vda1 [11:42] ogra_: the variable, or the commandline? [11:42] whatever is in /proc/cmdline [11:42] the initrd parses that [11:43] and then calls: [11:43] # convert UUID/LABEL to a device name [11:43] path=$(findfs "$root" 2>/dev/null || :) [11:43] so findfs doesnt return any usable thing [11:44] seb128: is this reproducible? how? === chihchun is now known as chihchun_afk [11:44] parsing the cmdline happens very early in /usr/share/initramfs-tools/init ... mounting in /usr/share/initramfs-tools/scripts/ubuntu-core-rootfs [11:51] * Chipaca -> grubby lunch [12:12] Chipaca: mvo_ https://code.launchpad.net/~sergiusens/snappy/returnErrIfErr/+merge/263510 [12:13] sergiusens: ETOOMUCHERR [12:13] Chipaca: we probably want to backport this one too [12:13] sergiusens: i've got a couple of changes to that grub.cfg, when you're looking at that again [12:14] sergiusens: can we have a test case? [12:15] because i thought i'd fixed this before now :) [12:15] Chipaca: sure [12:15] sergiusens: if you're in the middle of somehting [12:15] sergiusens: i can do the test case :) === alex-abreu is now known as alex-abreu|off [12:31] Chipaca: I am, but I can do it ;-) [12:33] how can I ignore certain files for snappy build [12:33] I don't want it to zip up verything in . [12:34] * ogra_ hasnt found a way beyond moving the files out of the way [12:35] sigh [12:35] is there a bug on this? [12:35] * zyga goes to file one [12:35] yeah [12:37] https://bugs.launchpad.net/snappy/+bug/1470491 [12:37] Ubuntu bug 1470491 in Snappy "snappy build should not zip everything in ., add an option to ignore certain paths" [Undecided,New] [12:37] ogra_: have you seen snappy-device-agents? [12:37] ogra_: https://code.launchpad.net/snappy-device-agents [12:38] do they wear black suits and sunglasses ? [12:38] * ogra_ thinks he saw one on the street [12:38] :P [12:39] (no, havent heard if it yet :) ) [12:39] ogra_: it's a set of tools for deploying snappy images to devices automatically for the CI stuff we're working on [12:39] ogra_: currently just BBB and _very_ hacky/underdocumented [12:39] ogra_: but it's something you may want to look at [12:39] ogra_: it's basically one day old now ;-) [12:40] ogra_: merge requests and bug are much welcome [12:40] https://code.launchpad.net/~zyga/snappy-device-agents/+git/snappy-device-agents/+ref/pex [12:40] this branch as a way to create a snap out of that [12:40] snappy deploying snappy [12:40] so thats the equivalent to phablet-tools ? [12:41] ogra_: apart from deployment it can run adt tests [12:41] ogra_: maybe, maybe not, it will be tailored to each device we have to support [12:41] ogra_: p-t is far more consistent because it can rely on adb [12:41] ogra_: here we may need magic voodoo :-( [12:41] ogra_: depending real devices [12:41] well, you can kind of rely on serial for arm boards [12:41] ogra_: we try to encourage the a/b/c method [12:42] ogra_: yes, I know, I'm trying to convince plars to use it :) [12:42] ogra_: we'll support many methods [12:42] ogra_: exposing one interface/api/tools [12:42] ogra_: depending on what kind of stuff you have you may pick [12:42] zyga: we don't zip everything, fwiw [12:42] * ogra_ isnt so thrilled by python though ... [12:42] ogra_: but in the end you can deploy any image to a bard [12:42] Chipaca: oh? so what does snappy build do, --help is not saying anything useful and there is no manual page [12:42] but thats just personal preference [12:43] ogra_: would you write this in go? [12:43] shell ;) [12:43] ogra_: oh, shell is terrible ;-) [12:43] ogra_: error handling [12:43] shell is lovely if done right ;) [12:43] ogra_: I love shell but... [12:43] ogra_: right, show me one script that handles errors and cleanup right [12:43] zyga: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/snappy/build.go#L54 [12:43] zyga, you know about the trap function, right ? [12:44] Chipaca: wow CVS and darcs [12:44] ogra_: sure [12:44] ogra_: it's possible [12:44] ogra_: just _hard_ [12:44] nah [12:44] not hard :) [12:44] zyga: it's like a list of past mistakes [12:44] anyway, you picked py ... i'll get along [12:45] Chipaca: I think the bug stands, it's not possible to tweak this and the defaults are not optimal (or can be in general) [12:45] ogra_: we picked CLI for now, the implementation may be totally different for each tool [12:45] zyga: i wasn't disagreeing with the bug :) [12:45] Chipaca: ah, thanks, I misunderstood [12:45] ogra_: we just want to get started, deploy this and let it be used via the CI message queue [12:46] right [12:46] ogra_: we'll see what kind of API we can provide at this level [12:46] ogra_: but the external api for this will be the message queue [12:46] ogra_: later on I'll probably build something more like lava where you have a http API for sending test jobs [12:47] Chipaca: what is DEADJOE? [12:47] Chipaca: that list is pretty full of magic [12:47] lol [12:47] zyga: as the comment says, it's inherited from other places [12:47] or ,, [12:48] DEADJOE i believe is no longer used, but used to be joe's tmpfiles [12:48] anyone here using the joe editor ? [12:48] ogra_: ahh [12:48] * ogra_ thought that was dead since a decade or so :P [12:48] ogra_: it seems this list predates that :) [12:49] i wonder if people using joe for editing also use elm for mail :) [12:50] ogra_: yeah, both of them do ;-) [12:51] hah! it still creates 'em [12:53] and ,, is from baz, apparently [12:55] ah, i thought it was cunieform [12:55] wow [12:55] sine we seem to want backwards compatibility to the beginnings of mankind [12:55] but no tla support [12:56] I'm dissapointed ;-) [13:11] * ogra_ is off to the dentist === tbr_ is now known as tbr [13:14] ogra_: good luck :-) [13:32] fgimenez: you did not get a reply to your question about http://paste.ubuntu.com/11803910/, did you? if not, I look now [13:34] mvo_, ok thanks :) [13:34] seb128: is this failure something new? the boot issue? iirc you mentioned that it was working before(?) [13:37] seb128: i just built a personal image and it boots fine, so please fill us in on what you're doing :) [13:38] it doesn't do much *more* than booting, but that's probably not snappy :) [13:50] Chipaca, what grub entry do you boot? and on uefi? [13:50] mvo_, which issue? [13:50] seb128: you boot uefi using virt manager? [13:50] Chipaca, no, but maybe you use uefi and that works? ;-) [13:51] just checking [13:51] seb128: no, kvm, i don't touch grub and it just works [13:51] shrug [13:51] seb128: that it does not boot [13:51] how did you build the image? [13:51] Chipaca, "u-d-f personal rolling --channel edge --output img.img"? [13:52] mvo_, the cloud-init hang or the invalid grub config? [13:52] seb128: no --oem? i'll try without an oem and see [13:52] seb128: invalid grub config [13:52] Chipaca, no oem no [13:52] mvo_, since ever, but there is an "ubuntu" entry in the grub menu which does work [13:54] ok [13:55] ok, gotta fly, but will continue with this after [13:55] Chipaca, thanks, I'm going to try with a new image in a bit, but nothing changed this week so I doubt that got magically resolved [13:57] mvo_, you didn't do the seed update needed for the ubuntu-snappy migration? [13:57] seb128: I did, not uploaded yet though, sorry [13:57] seb128: I do that now [13:57] mvo_: on s-i updates I get system-image-cli: error: unrecognized arguments: --progress json [13:57] mvo_, thanks [13:57] mvo_: almost therewith update grub [13:59] sergiusens: hrm, is system-image-cli installed on the system? or is it still using system-image-snappy-cli ? [14:00] mvo_: in what image was it removed? [14:00] or swapped [14:01] sergiusens: in the same that switched to the new way of calling it - at least in theory [14:01] mvo_: which one is the new way? --machine-readable or --progress json ? [14:02] sergiusens: the new one is progress json [14:03] sergiusens: so if that arg is used the image should have s-i-cli instead of s-i-snappy-cli [14:03] mvo_: hard to tell with no dpkg info ;-) [14:04] sergiusens: :-D [14:05] fgimenez: thanks again for the crashreport, there will be a branch shortly [14:09] mvo_, np, thank you, elopio found it yesterday running the integration tests on the bbb (he is really brave :) [14:10] mvo_, at first we thought it may be related to the tests [14:21] Chipaca: ubuntu-security would be the team [14:25] tedg, hey, nitpick but can you look at https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1470531 ? [14:25] Ubuntu bug 1470531 in url-dispatcher (Ubuntu) "update-directory errors out on missing directory" [Undecided,New] [14:26] Chipaca: approved - thanks :) [14:28] mvo_: fgimenez oh, I fixed that bug in the update-grub work just now, was driving me nuts [14:28] seb128, Sure, do you have a session systemd running? [14:28] tedg, probably not since I don't have a session open [14:29] it's a boot to the greeter and a systemctl --failed on vt9 from systemd.debug-shell [14:29] seb128, ? Then how did that get run? It should be a session job. [14:29] mvo_: fwiw, it crashes for grub as well ;-) [14:29] tedg, hum, let me check, I might have logged into a vt on that boot [14:29] mvo_: I think my fix is a lot simpler even if a bit more hacky [14:30] tedg, but no desktop session for sure, just vt login [14:30] seb128, To be clear, I think it can still be fixed, more curious. === kickinz1 is now known as kickinz1|afk [14:35] sergiusens: :) I tried to make it less ugly but I don't mind as long as we fix it soon [14:37] mvo_: I don't want to delay update-grub work more though [14:37] hello. [14:37] fgimenez: I followed your advice and moved the meeting 30 minutes. [14:38] starting from tomorrow :) [14:38] seb128, Looking through the code it seems that it should handle that case. Do you have a log file? [14:39] elopio, ok :) i'm already there [14:40] elopio, i've pushed the fixes you suggested to the build-test branch [14:40] mvo_: so, latest image still has machine readable and latest snappy has --format json ... [14:41] tedg, http://paste.ubuntu.com/11804973/ [14:42] mvo_: and client.ini looks really weird now [14:43] sergiusens: it does? [14:43] mvo_: there's a client.inie now as well [14:43] sergiusens: *ick* [14:43] sergiusens: let me try to find out why we got the old one === stgraber_ is now known as stgraber [14:46] hmpf [14:46] seb128, can you boot with break=premount (and also make sure to have no serial console on the cmdline) ? [14:46] so we can take a look why findfs doesnt find a label or why udev doesnt set the links [14:46] the break= should give a you shell in the initrd ... (if we didnt hack that out for snappy) === ogra_` is now known as ogra_ [14:47] ogra_`, let me try [14:47] ogra_, "no serial console on the cmdline"? [14:48] yeah ... no "console=ttyS0" === andyrock_ is now known as andyrock [14:48] why not? (just curious) [14:48] because that would spawn the shell on serial [14:48] (and also print all output there) === alecu_ is now known as alecu [14:49] at least in the constellation Chipaca showed before [14:49] mvo_: http://bazaar.launchpad.net/~sergiusens/snappy/noUpdateGrub/revision/492 === Ursinha_ is now known as Ursinha [14:49] mvo_: just missing some tests if the approach is good [14:50] mvo_: so far the files get sync'ed, but I'm stuck on other broken things (and the fact about bootlader dir being nil took away most of my morning) [14:50] ogra_, that reboots back to grub ... [14:50] mvo_: lesson learned should be to panic instead of returning nil if you are going to panic anyways ;-) [14:50] damn === psftw_ is now known as psftw [14:51] mvo_, sergiusens, is there a way to switch off the auto-reboot ? === Abhishek__ is now known as Abhishek_ [14:51] in grub based systems [14:51]