#snappy 2015-07-01 <h00sier> I can't seem to set up a bridge for my snappy img running in qemu-kvm <h00sier> any ideas? <mvo_> sergiusens: hmmmm, right, native is not ideal indeed, sorry for overlookng this <dholbach> good morning <seb128> hey dholbach & snappy world <dholbach> salut seb128 <dholbach> how are things in snappy land <dholbach> ? <seb128> good, still working on getting personal to work ;-) <dholbach> yeah, I saw some uploads of yours - looks like it's a bit more work enabling everything <seb128> yeah, let's see how things look like today <fgimenez> good morning <vmayoral> morning! <seb128> mvo_, bah, you broke ubuntu-core/desktop-next builds :p * seb128 fixes <seb128> or not <seb128> mvo_, let me know when you are around to discuss the issue :-) <mvo_> seb128: whats the issue? clickpkg -> snappypkg ? <seb128> yes <seb128> https://launchpadlibrarian.net/210397648/buildlog_ubuntu_wily_i386_ubuntu-core-system-image_BUILDING.txt.gz <mvo_> seb128: sure, let me look <mvo_> seb128: sorry, but that the only way to know if it works, upload and hope for the best. no local testing :( <seb128> mvo_, btw you had your changes commited as if they were uploaded, but they were not <seb128> so I changed back to unreleased, batched some desktop-next tweaks and uploaded <seb128> hope that was ok ;-) <seb128> mvo_, you can do a local build, it just takes a while <mvo_> seb128: sure, I though I did upload, I guess may I should go to bed <seb128> mvo_, https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html has "howto build locally" <seb128> need to adapt the PROJECT/SUBPROJECT env variables <seb128> but that works (or at least enough to check the groups thingy) <mvo_> seb128: I'm not sure that works in the age of LP builders <mvo_> seb128: oh, you checked it works? nice <seb128> yeah, I did the user/group config for desktop-next using that <seb128> mvo_, <seb128> "Setting up ubuntu-snappy-cli (1.2-1+524~ubuntu15.10.1) ... <seb128> Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory <seb128> Adding system user `clickpkg' (UID 109) ..." <mvo_> seb128: the build failure is due to a out-of-sync issue of snappy and livefs rootfs <seb128> seems like ubuntu-snappy-cli creates this group <mvo_> 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 <mvo_> seb128: yeah, it does create the snappypkg user in trunk but trunk failed to build for unreleated reasons so they got out of sync <mvo_> seb128: but all my faul, once the fixes above land we should be good again <seb128> mvo_, any estimate of when you can land those fixes? <seb128> I'm sort of waiting on a new image build to continue my personal work <mvo_> 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 :) * seb128 looks * conyoo error parsing serv.dat <seb128> mvo_, those look good to me, I comment approved but can't approve the mp, not in the right team <mvo_> seb128: sure, thats fine <mvo_> seb128: thanks <seb128> yw! <mvo_> 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 <seb128> mvo_, do you plan to upload to wily as well? <mvo_> seb128: oh, you don't use our ppa, sure, I will do a upload <seb128> mvo_, thanks <seb128> and no, we don't use the ppa <seb128> we are good citizens ;-) <seb128> mvo_, tarmac doesn't like my +1 <seb128> "Voting does not meet specified criteria. Required: Approve >= 1, Disapprove == 0. Got: 1 Pending." <mvo_> seb128: silly thing, I approved now as well to make it happy. we can't block oyu <mvo_> you <JamesTait> Good morning all; happy Mailman^WPostal Worker Day! ð <seb128> mvo_, thanks for the snappy upload ;-) <Chipaca> mvo_: aw, for a moment i thought you were fixing the apparmor thing for arm :) <Chipaca> mvo_: (ubuntu-core-launcher seems to need an additional .so on arm than on intel, at least last night) <ogra_> seb128, mvo_, i dont think the fix that was uploaded will work <ogra_> you only fixed the fallout ... the reason for the failure is the switch from clickpkg to snappypkg <seb128> ogra_, ? <seb128> ogra_, snappy changed its group from clickpkg to snappypkg <seb128> ogra_, mvo updated the groups in livecd-rootfs to reflect the change <seb128> but that was uploaded before ubuntu-snappy <seb128> with the new version there is no clickpkg user anymore <seb128> why would it fail? <ogra_> because there is a snappypkg user now <ogra_> or snappkg <ogra_> (not sure how exactly it is called) <ogra_> the user was just renamed ... but your livecd-rootfs change doesnt have that rename <seb128> ? <ogra_> http://launchpadlibrarian.net/210413322/livecd-rootfs_2.320_2.322.diff.gz <seb128> ogra_, https://launchpadlibrarian.net/210356511/livecd-rootfs_2.319_2.320.diff.gz <ogra_> oh, i missed that <ogra_> ignore me then <seb128> ogra_, my upload from today was to fix the ":ubuntu" missing after I tweaked the groups yesterday <seb128> :-) <mvo_> Chipaca: uh, arm failing? meh, no I did not look at this <Chipaca> mvo_: ok, i'm looking :) <Chipaca> ooh, maybe it's the 32bit-ness, not the arm-ness * Chipaca tries with x86 <Chipaca> 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 * Chipaca makes a branch prediction <mvo_> lol <Chipaca> 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?) <Chipaca> sergiusens: elopio: fixes https://bugs.launchpad.net/snappy/+bug/1470210 for you <ubottu> Ubuntu bug 1470210 in Snappy "integration tests fail with: error while loading shared libraries: libgcc_s.so.1" [Undecided,New] <Chipaca> i should move that to the launcher, shouldn't i <Chipaca> there <fgimenez> mvo_, Chipaca hi, i'm getting this http://paste.ubuntu.com/11803910/ on bbb, is it a known bug? <ogra_> the dates look weird <ogra_> how can 87 be newer than 88 ? <rsalveti> haha, indeed <fgimenez> ogra_, yep :, i got <fgimenez> ogra_, the image with: <fgimenez> sudo ubuntu-device-flash --revision -2 --verbose core rolling --output bbb-edge-2.img --channel edge --developer-mode --oem beagleblack <ogra_> hmm, so is that timestamp created by u-d-f ? <ogra_> i thought it comes from the server <sergiusens> morning <sergiusens> Chipaca: I'll defer on that one <Chipaca> sergiusens: sure, wasn't asking you to review C code :) was just heads-up'ing you wrt it being fixed there <ogra_> seems seb128 cant have his system-a/b partitions mounted by label on amd64 <ogra_> dont we use labels on grub installs ? <sergiusens> Chipaca: it's a one liner :-P <Chipaca> sergiusens: cee coooode <Chipaca> sergiusens: scaaary <ogra_> looks like neither root=/dev/disk/by-label/system-a nor root=LABEL=system-a works <Chipaca> sergiusens: * not even code, let alone C :) <Chipaca> ogra_: yes, we use labels <ogra_> do we act special in any way on grub based installs ? <ogra_> wird <ogra_> *weird <Chipaca> ogra_: and that works as far as i've been able to test it <ogra_> k <seb128> does it require some initramfs support we might be missing? <Chipaca> seb128: efi? <seb128> the partitions have label according to blkid <Chipaca> ooohhh <seb128> no, that's in virt-manager, I think standard grub <ogra_> well, and udev should at least create the /dev/disk/by-label/ symlinks <Chipaca> ah, no, then it should work <ogra_> but seems they are not there either <Chipaca> seb128: can you go to the grub console? <seb128> Chipaca, http://people.canonical.com/~seb128/shot0001.png <ogra_> Chipaca, how would the grub console help ? <Chipaca> seb128: plz to grub console <seb128> Chipaca, I need to go for lunch, people are waiting, but I'm going to have a look to that once back <seb128> Chipaca, please give hints and I can read the backlog then ;-) <Chipaca> ogra_: i'll do a search from there <Chipaca> ogra_: as i know what i expect there <ogra_> Chipaca, but the mounting happens from initrd, way later when the kernel took over already ... * ogra_ <- confused <Chipaca> ogra_: but it's not finding root <Chipaca> ogra_: which is specified by grub <Chipaca> ogra_: so that's wrong, somehow <ogra_> its not finding the labeled partition ... even with manually specifying root=/dev/disk/by-label/system-a or root=LABEL=system-a <seb128> Chipaca, echo $root gives hd0,gpt2 <seb128> Chipaca, unsure what info you want/need <seb128> shouldn't the LABEL thing be independant of that? it wouldn't boot at all if the boot was not correct <ogra_> yes <ogra_> thats what i mean <ogra_> grub should only find the boot partition, load kernel and initrd and switch over <ogra_> mounting happens from the initrd <Chipaca> seb128: search --no-floppy --label system-a <seb128> hd0,gpt3 <seb128> system-b on gpt4 <seb128> (which is the one I want/which has the /) <Chipaca> seb128: echo $snappy_ab <seb128> a <Chipaca> ok, so now <Chipaca> why is root gpt2? <seb128> no idea, it's the snappy personal image <seb128> Chipaca, the grub config is http://paste.ubuntu.com/11757708/ <Chipaca> ah, i don't know how that's partitioned <ogra_> shouldnt differ from core <Chipaca> augh. when is the new grub.cfg going to land already :) <seb128> same as core <Chipaca> seb128: ok, so your root should be system-a or system-b, not some other partition <Chipaca> seb128: do this: <Chipaca> set label="system-$snappy_ab" <Chipaca> set cmdline="root=LABEL=$label ro init=/lib/systemd/systemd console=tty1 console=ttyS0 panic=-1" <Chipaca> search --no-floppy --set --label "$label" <Chipaca> linux /vmlinuz $cmdline <Chipaca> initrd /initrd.img <Chipaca> boot <seb128> is that going to teach us anything? <ogra_> (you probably dont want console=ttyS0 on a desktop system :) so you can see the messages on screen) <seb128> I can boot fine using root=/dev/vda4 <seb128> gpt2 is a "system-boot" vfat partition <Chipaca> seb128: vda4? <seb128> k, really need to go for lunch <Chipaca> what's vda4? <seb128> sda4 <seb128> in a virt-manager vm <ogra_> seb128, do you get a busybox after the mount error ? <seb128> no, back to grub <seb128> bbiab <ogra_> i dont see a prompt in your pic <ogra_> ah <Chipaca> ogra_: console=tty1 console=ttyS0 puts it on both, afaik <ogra_> no <ogra_> the first one applies to kernel messages <ogra_> the second one to userspace <ogra_> so as soon as the kernel hands over to initrd the messages go to serial <Chipaca> oh, that's not what we want <ogra_> if you only set console= once it will apply to both <ogra_> so you just want to drop console=ttyS0 <Chipaca> You can specify multiple console= options on the kernel command line. <Chipaca> Output will appear on all of them. The last device will be used when <Chipaca> you open /dev/console. <ogra_> right <ogra_> the last sentence is key :) <ogra_> (having /dev imples userspace ;) ) <seb128> Chipaca, in any case u-d-f makes a system-boot vfat partition on personal, unsure why the $root points to that <seb128> cyphermox or slangasek might know <ogra_> well, the commandline is created durin livecd-rootfs if i'm not wrong <Chipaca> system-boot is where grub lives, system-a or system-b is where the kernels and initrds live <Chipaca> (in the current scheme, that is going to change rsn) <ogra_> ah, no, livecd-rootfs doesnt set any root= arg ... it only sed's /etc/default/grub for systemd stuff etc <Chipaca> 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 :) <Chipaca> 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? <ogra_> yeah, sounds right <ogra_> i still dont get where grub is involved with the rootfs mounting (beyond handing the cmdline over to the kernel) <ogra_> the actual work happens inside the initrd ... and the initrd doesnt seem to have any knowledge of the labels <Chipaca> ogra_: this might be the old grub config confusing me; reading the grub manual, there's nothing special about the root env var <Chipaca> ogra_: afaict, just setting âroot=$rootâ in the linux commandline is what's expected <ogra_> well, it works if seb128 sets root=/dev/vda1 <Chipaca> ogra_: the variable, or the commandline? <ogra_> whatever is in /proc/cmdline <ogra_> the initrd parses that <ogra_> and then calls: <ogra_> # convert UUID/LABEL to a device name <ogra_> path=$(findfs "$root" 2>/dev/null || :) <ogra_> so findfs doesnt return any usable thing <Chipaca> seb128: is this reproducible? how? <ogra_> parsing the cmdline happens very early in /usr/share/initramfs-tools/init ... mounting in /usr/share/initramfs-tools/scripts/ubuntu-core-rootfs * Chipaca -> grubby lunch <sergiusens> Chipaca: mvo_ https://code.launchpad.net/~sergiusens/snappy/returnErrIfErr/+merge/263510 <Chipaca> sergiusens: ETOOMUCHERR <sergiusens> Chipaca: we probably want to backport this one too <Chipaca> sergiusens: i've got a couple of changes to that grub.cfg, when you're looking at that again <Chipaca> sergiusens: can we have a test case? <Chipaca> because i thought i'd fixed this before now :) <sergiusens> Chipaca: sure <Chipaca> sergiusens: if you're in the middle of somehting <Chipaca> sergiusens: i can do the test case :) <sergiusens> Chipaca: I am, but I can do it ;-) <zyga> how can I ignore certain files for snappy build <zyga> I don't want it to zip up verything in . * ogra_ hasnt found a way beyond moving the files out of the way <zyga> sigh <zyga> is there a bug on this? * zyga goes to file one <ogra_> yeah <zyga> https://bugs.launchpad.net/snappy/+bug/1470491 <ubottu> Ubuntu bug 1470491 in Snappy "snappy build should not zip everything in ., add an option to ignore certain paths" [Undecided,New] <zyga> ogra_: have you seen snappy-device-agents? <zyga> ogra_: https://code.launchpad.net/snappy-device-agents <ogra_> do they wear black suits and sunglasses ? * ogra_ thinks he saw one on the street <ogra_> :P <ogra_> (no, havent heard if it yet :) ) <zyga> ogra_: it's a set of tools for deploying snappy images to devices automatically for the CI stuff we're working on <zyga> ogra_: currently just BBB and _very_ hacky/underdocumented <zyga> ogra_: but it's something you may want to look at <zyga> ogra_: it's basically one day old now ;-) <zyga> ogra_: merge requests and bug are much welcome <zyga> https://code.launchpad.net/~zyga/snappy-device-agents/+git/snappy-device-agents/+ref/pex <zyga> this branch as a way to create a snap out of that <zyga> snappy deploying snappy <ogra_> so thats the equivalent to phablet-tools ? <zyga> ogra_: apart from deployment it can run adt tests <zyga> ogra_: maybe, maybe not, it will be tailored to each device we have to support <zyga> ogra_: p-t is far more consistent because it can rely on adb <zyga> ogra_: here we may need magic voodoo :-( <zyga> ogra_: depending real devices <ogra_> well, you can kind of rely on serial for arm boards <zyga> ogra_: we try to encourage the a/b/c method <zyga> ogra_: yes, I know, I'm trying to convince plars to use it :) <zyga> ogra_: we'll support many methods <zyga> ogra_: exposing one interface/api/tools <zyga> ogra_: depending on what kind of stuff you have you may pick <Chipaca> zyga: we don't zip everything, fwiw * ogra_ isnt so thrilled by python though ... <zyga> ogra_: but in the end you can deploy any image to a bard <zyga> Chipaca: oh? so what does snappy build do, --help is not saying anything useful and there is no manual page <ogra_> but thats just personal preference <zyga> ogra_: would you write this in go? <ogra_> shell ;) <zyga> ogra_: oh, shell is terrible ;-) <zyga> ogra_: error handling <ogra_> shell is lovely if done right ;) <zyga> ogra_: I love shell but... <zyga> ogra_: right, show me one script that handles errors and cleanup right <Chipaca> zyga: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/snappy/build.go#L54 <ogra_> zyga, you know about the trap function, right ? <zyga> Chipaca: wow CVS and darcs <zyga> ogra_: sure <zyga> ogra_: it's possible <zyga> ogra_: just _hard_ <ogra_> nah <ogra_> not hard :) <Chipaca> zyga: it's like a list of past mistakes <ogra_> anyway, you picked py ... i'll get along <zyga> Chipaca: I think the bug stands, it's not possible to tweak this and the defaults are not optimal (or can be in general) <zyga> ogra_: we picked CLI for now, the implementation may be totally different for each tool <Chipaca> zyga: i wasn't disagreeing with the bug :) <zyga> Chipaca: ah, thanks, I misunderstood <zyga> ogra_: we just want to get started, deploy this and let it be used via the CI message queue <ogra_> right <zyga> ogra_: we'll see what kind of API we can provide at this level <zyga> ogra_: but the external api for this will be the message queue <zyga> ogra_: later on I'll probably build something more like lava where you have a http API for sending test jobs <zyga> Chipaca: what is DEADJOE? <zyga> Chipaca: that list is pretty full of magic <ogra_> lol <Chipaca> zyga: as the comment says, it's inherited from other places <zyga> or ,, <Chipaca> DEADJOE i believe is no longer used, but used to be joe's tmpfiles <ogra_> anyone here using the joe editor ? <zyga> ogra_: ahh * ogra_ thought that was dead since a decade or so :P <zyga> ogra_: it seems this list predates that :) <ogra_> i wonder if people using joe for editing also use elm for mail :) <zyga> ogra_: yeah, both of them do ;-) <Chipaca> hah! it still creates 'em <Chipaca> and ,, is from baz, apparently <ogra_> ah, i thought it was cunieform <zyga> wow <ogra_> sine we seem to want backwards compatibility to the beginnings of mankind <zyga> but no tla support <zyga> I'm dissapointed ;-) * ogra_ is off to the dentist <rsalveti> ogra_: good luck :-) <mvo_> fgimenez: you did not get a reply to your question about http://paste.ubuntu.com/11803910/, did you? if not, I look now <fgimenez> mvo_, ok thanks :) <mvo_> seb128: is this failure something new? the boot issue? iirc you mentioned that it was working before(?) <Chipaca> seb128: i just built a personal image and it boots fine, so please fill us in on what you're doing :) <Chipaca> it doesn't do much *more* than booting, but that's probably not snappy :) <seb128> Chipaca, what grub entry do you boot? and on uefi? <seb128> mvo_, which issue? <Chipaca> seb128: you boot uefi using virt manager? <seb128> Chipaca, no, but maybe you use uefi and that works? ;-) <seb128> just checking <Chipaca> seb128: no, kvm, i don't touch grub and it just works <seb128> shrug <mvo_> seb128: that it does not boot <seb128> how did you build the image? <seb128> Chipaca, "u-d-f personal rolling --channel edge --output img.img"? <seb128> mvo_, the cloud-init hang or the invalid grub config? <Chipaca> seb128: no --oem? i'll try without an oem and see <mvo_> seb128: invalid grub config <seb128> Chipaca, no oem no <seb128> mvo_, since ever, but there is an "ubuntu" entry in the grub menu which does work <mvo_> ok <Chipaca> ok, gotta fly, but will continue with this after <seb128> 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 <seb128> mvo_, you didn't do the seed update needed for the ubuntu-snappy migration? <mvo_> seb128: I did, not uploaded yet though, sorry <mvo_> seb128: I do that now <sergiusens> mvo_: on s-i updates I get system-image-cli: error: unrecognized arguments: --progress json <seb128> mvo_, thanks <sergiusens> mvo_: almost therewith update grub <mvo_> sergiusens: hrm, is system-image-cli installed on the system? or is it still using system-image-snappy-cli ? <sergiusens> mvo_: in what image was it removed? <sergiusens> or swapped <mvo_> sergiusens: in the same that switched to the new way of calling it - at least in theory <sergiusens> mvo_: which one is the new way? --machine-readable or --progress json ? <mvo_> sergiusens: the new one is progress json <mvo_> sergiusens: so if that arg is used the image should have s-i-cli instead of s-i-snappy-cli <sergiusens> mvo_: hard to tell with no dpkg info ;-) <mvo_> sergiusens: :-D <mvo_> fgimenez: thanks again for the crashreport, there will be a branch shortly <fgimenez> mvo_, np, thank you, elopio found it yesterday running the integration tests on the bbb (he is really brave :) <fgimenez> mvo_, at first we thought it may be related to the tests <tyhicks> Chipaca: ubuntu-security would be the team <seb128> tedg, hey, nitpick but can you look at https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1470531 ? <ubottu> Ubuntu bug 1470531 in url-dispatcher (Ubuntu) "update-directory errors out on missing directory" [Undecided,New] <tyhicks> Chipaca: approved - thanks :) <sergiusens> mvo_: fgimenez oh, I fixed that bug in the update-grub work just now, was driving me nuts <tedg> seb128, Sure, do you have a session systemd running? <seb128> tedg, probably not since I don't have a session open <seb128> it's a boot to the greeter and a systemctl --failed on vt9 from systemd.debug-shell <tedg> seb128, ? Then how did that get run? It should be a session job. <sergiusens> mvo_: fwiw, it crashes for grub as well ;-) <seb128> tedg, hum, let me check, I might have logged into a vt on that boot <sergiusens> mvo_: I think my fix is a lot simpler even if a bit more hacky <seb128> tedg, but no desktop session for sure, just vt login <tedg> seb128, To be clear, I think it can still be fixed, more curious. <mvo_> sergiusens: :) I tried to make it less ugly but I don't mind as long as we fix it soon <sergiusens> mvo_: I don't want to delay update-grub work more though <elopio> hello. <elopio> fgimenez: I followed your advice and moved the meeting 30 minutes. <elopio> starting from tomorrow :) <tedg> seb128, Looking through the code it seems that it should handle that case. Do you have a log file? <fgimenez> elopio, ok :) i'm already there <fgimenez> elopio, i've pushed the fixes you suggested to the build-test branch <sergiusens> mvo_: so, latest image still has machine readable and latest snappy has --format json ... <seb128> tedg, http://paste.ubuntu.com/11804973/ <sergiusens> mvo_: and client.ini looks really weird now <mvo_> sergiusens: it does? <sergiusens> mvo_: there's a client.inie now as well <mvo_> sergiusens: *ick* <mvo_> sergiusens: let me try to find out why we got the old one <ogra_`> hmpf <ogra_`> <ogra_> seb128, can you boot with break=premount (and also make sure to have no serial console on the cmdline) ? <ogra_`> <ogra_> so we can take a look why findfs doesnt find a label or why udev doesnt set the links <ogra_`> <ogra_> the break= should give a you shell in the initrd ... (if we didnt hack that out for snappy) <seb128> ogra_`, let me try <seb128> ogra_, "no serial console on the cmdline"? <ogra_> yeah ... no "console=ttyS0" <seb128> why not? (just curious) <ogra_> because that would spawn the shell on serial <ogra_> (and also print all output there) <ogra_> at least in the constellation Chipaca showed before <sergiusens> mvo_: http://bazaar.launchpad.net/~sergiusens/snappy/noUpdateGrub/revision/492 <sergiusens> mvo_: just missing some tests if the approach is good <sergiusens> 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) <seb128> ogra_, that reboots back to grub ... <sergiusens> mvo_: lesson learned should be to panic instead of returning nil if you are going to panic anyways ;-) <ogra_> damn <ogra_> mvo_, sergiusens, is there a way to switch off the auto-reboot ? <ogra_> in grub based systems <sergiusens> ogra_: yeah, snappy config ubuntu-core <sergiusens> autopilot: off <ogra_> sergiusens, well, from outside the image <ogra_> we need to debug the initrd <sergiusens> ogra_: yes, create an oem package with autopilot off in the config <ogra_> oh man <ogra_> we need a cmdline option for such stuff :) <sergiusens> ogra_: but the reboot on panic, you need to edit manually yourself <sergiusens> ogra_: like, mount .img/system-boot, edit grub.cfg, boot <ogra_> ah, itrs in the grub.cfg ... <ogra_> seb128, can you turn it off there ? <ogra_> sergiusens, does that generally prevent the shell (does it replace the std. panic() finction of initramfs ? ) <ogra_> *function <tedg> seb128, I'm not sure what to do with that error, we're making directories and opening the database all before it happens. Normally I'd say we can access it, but it would seem that we already did. <sergiusens> ogra_: we don't do any customization wrt panic <ogra_> ok <tedg> seb128, Here's the function, perhaps a second set of eyes will see something: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.15.10/view/head:/service/url-db.c#L26 <sergiusens> ogra_: it's just a cmdline -> panic=-1 <ogra_> right <ogra_> seb128, drop that too, i think that disables the shell (so even if it wouldnt reboot it wouldnt spawn a shell with that option set) <seb128> ogra_, "that"? <ogra_> panic=-1 <ogra_> from the kernel cmdline <dholbach> fgimenez, elopio: sorry for the mail spam - balloons and I just ended up in another meeting tomorrow, so we thought we'd shrink our open house meeting to just 30 mins - I think that should be fine <seb128> ogra_, without that it boots to a kernel error <ogra_> what does the error say ? <seb128> let me try again in a vb <seb128> bit <seb128> I booted the vm to change the grub config <ogra_> og, you do all that in a vm ? <ogra_> then i could do it myself i suppose <elopio> dholbach: sounds good. <dholbach> thanks a bunch! <fgimenez> dholbach, ok np for me <dholbach> <3 <seb128> tedg, it's snappy and /root is ro it seems <seb128> tedg, you don't handle mkdir failing <tedg> seb128, ? I think we do: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.15.10/view/head:/service/url-db.c#L39 <tedg> Though it probably doesn't make sense to run the click hooks for root <seb128> ups, rather the sqlite3_open() <seb128> tedg, I think ^ fails <seb128> right <seb128> I was going to say <seb128> tedg, I think the "Unable to create tables" is from sqlite3_open(), that function creates the filename if it doesn't exists <seb128> also I'm unsure why is /root should be ro of it that's another snappy issue to be resolved <tedg> seb128, I guess what is confusing is that mkdir() in theory isn't failing, but making the file is? <seb128> tedg, it's possible that the directory got created when I had a rw mount I guess <seb128> so maybe local issue... <seb128> or it's part of the image for some reason <seb128> need to check <tedg> Well, we'd still return an error if we couldn't make the directory. <tedg> :-) It would just be an error that made more sense. <seb128> right <seb128> ogra_, unsure how to edit grub.cfg ... wouldn't it be easier if you/whoever wants to debug build a personal issue and kvm boot it? ;-) <Chipaca> yeah, got it here <seb128> Chipaca, you did? what did you change? <Chipaca> sudo ubuntu-device-flash --revision=-1 personal rolling --channel edge -o personal_x86.img --developer-mode <seb128> compared to what? <seb128> e.g what option did you use that gave a working grub earlier? <seb128> it was the oem one? <ogra_> seb128, yeah, is that possible with the std u-d-f yet ? <seb128> ogra_, yes, using the wily version <ogra_> ok <seb128> ogra_, see the command Chipaca just gave <Saviq> ogra_, hey, mzanetti mentioned there's a problem with the Pi GPIO on snappy, anywhere I can read more on that? <ogra_> yep <Chipaca> seb128: previously i'd used --oem generic-i386 <Chipaca> seb128: and that works <ogra_> Saviq, no, the issue is with using custom or overlay dtbs to actually enable GPIO on the Pi <Chipaca> seb128: at least as much as the ubuntu grub entry works without it <seb128> Chipaca, hum, k <seb128> unsure what's the difference <ogra_> Saviq, we simply dont have proper support for that yet ... and specifically for the Pi it is tricky since the binary blob owns the actual dtb * Saviq looks suspicious at the choice of the Pi for the Matchbox then... <ogra_> well, thats one of the reasons the Pi isnt officially supported <Saviq> ogra_, one issue I have with an add-on 433MHz transceiver board from openenergymonitor is that the bootloader goes apeshit when it's connected, might that be related? <ogra_> yes <ogra_> you likely need the right dtb overlay to enable it <Saviq> ogra_, so I'd need a custom device tarball? <Saviq> == a custom image <ogra_> you need a custom oem snap ... <Saviq> right <ogra_> but even then, no guarantees that the kernel works with that dtb <ogra_> (i.e your dtb might define the right device but the module/driver might be missing) <Saviq> and in that case I'd need to build a custom kernel <ogra_> yes <Saviq> ohkay, /me has his work cut out for him (/hethinks) <Saviq> now who can tell me how to fix security_yaml_click_ security_yaml_ errors :/ <ogra_> Saviq, i'm working with ppisati to get that to work, it just isnt there yet <Saviq> ogra_, maybe I can help? * Saviq hopes he could, instead of !helping <ogra_> Saviq, sure, if i got something to try i'll let you know <Saviq> thanks <ogra_> seb128, Chipaca, found the issue i think ... /dev/vd* devices are indeed handled specially in the shipped udev rule in the initrd <ogra_> KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}" <ogra_> KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n" <seb128> ogra_, oh, nice, where did he say that? <ogra_> seb128, i pulled the device tarball and unpacked the initrd <ogra_> lib/udev/rules.d/60-persistent-storage.rules in there <seb128> k <seb128> but that's only adding symlinks <seb128> is that supposed to create issues? <ogra_> no, but i think it makes it skip creating the by-label symlinks <seb128> or is that taking over the normal by-label <seb128> k <ogra_> not 100% sure yet ... i'll have to dig a bit <seb128> thanks for investigating this one <ogra_> the set of rules we ship by default is definitely limeted though <seb128> but make sure to not dup work with Chipaca there <ogra_> might be a fallout from -touch <Chipaca> waaait <Chipaca> there is no initrd line <ogra_> he is looking at the grub side of things :) <Chipaca> in grub <ogra_> oh ! <Chipaca> that might explain things <ogra_> well, not why it boots with UUID ... <Chipaca> the UUID entry does specify initrd <seb128> or with root=/dev/vda3 <ogra_> at least then there wouldnt be a readonly and writable mount etc <ogra_> it would boot rw directly into the root without initrd <seb128> Chipaca, no, take the system-a entry, do "e", change the LABEL=... by /dev/vda3 and ctrl-X <seb128> that boots without issue <Chipaca> seb128: can you confirm there isn't an initrd entry in that entry? <seb128> Chipaca, yes, I can <Chipaca> seb128: pleasae do :) <seb128> I just did <seb128> you can probably on your image as well <seb128> no? <Chipaca> seb128: i saw it on mine, wanted you to confirm whether it was the same over there <Chipaca> and yes, specifying root=/dev/sda3 for me makes it boot too <seb128> my system-a boot option has no initrd <Chipaca> but i'm assumign this just sidesteps the initrd entirely <seb128> and changing the LABEL to a /dev makes it boot <Chipaca> seb128: can you also check whether the system-a entry asks for a efi kernel and the otehr one doesn't? <seb128> yes, I noticed that some days ago as well <Chipaca> ok <Chipaca> i'm now out of my depth wrt where the grub.cfg is coming form, but i'm going to blame sergiusens because he'll be able to blame the right person <seb128> likely cyphermox / slangasek <Chipaca> seb, if you specified an initrd it'd probably work <seb128> cyphermox was looking at some of the grub issues <seb128> k <seb128> well unsure why we have those different entries <seb128> and why the system-a/b ones don't have a initrd <seb128> let's see in any of the grub knowing people can help though ;-) <sergiusens> seb128: Chipaca maybe something is missing from our "overlay" <Chipaca> seb128: the whole thing is changing for the better anyway :) <ogra_> by throwing away 80% of it :=) <Chipaca> YEAH! * Chipaca wipes the spittle off his screen <mvo_> sergiusens: I just remember -it seems like go-flags makes description translations impossible, because its in the ` ` style struct options. maybe we need something else :/ <sergiusens> mvo_: oh fancy that <sergiusens> mvo_: we will need a struct based thing then type Opt struct { Name, longDescription, shortDescription string, target [type] } <Chipaca> mvo_: is that another bullet in go-flags' utility? <Chipaca> feels like we're fighting it more than it's helping us <sergiusens> Chipaca: we will drop it <mvo_> Chipaca: yeah, I have the same feeling right now <slangasek> seb128, Chipaca: the grub.cfg system-a/b entries come from a snappy-specific grub config file; I don't remember offhand which package it's from or the name of it, but it's in /etc/grub.d and should be obvious <sergiusens> slangasek: ubuntu-core-config <slangasek> right, that thing :) <Chipaca> slangasek: i'm still blaming sergiusens for it <slangasek> ok ;) <sergiusens> Chipaca: did you look at the branch I gave you already? <mvo_> its 09_snappy from ubuntu-snappy in grub.d <mvo_> oh, yeah, that too * sergiusens points out that he hasn't been breaking the image these past days ;-) <ogra_> just because nobody filed bugs et doesnt mean it isnt broken <ogra_> *yet <ogra_> :P <sergiusens> ogra_: oh, we know it's broken ;-) <Chipaca> sergiusens: noUpdateGrub? <sergiusens> Chipaca: yes <Chipaca> sergiusens: yes <sergiusens> Chipaca: need to get n ack on the approach to get tests for that approach <sergiusens> ogra_: btw, why is livecd-rootfs arch any? <ogra_> sergiusens, is it ? * ogra_ never noticed <sergiusens> ogra_: yeah, I noticed as I'm waiting on an arm64 builder :P <sergiusens> ogra_: but it doesn't make sense, does it? * sergiusens wonders if slangasek has the answer <slangasek> I don't know; it may be legacy <slangasek> there used to not be a live-build, only livecd-rootfs - at that point a lot more of the logic was in the livecd-rootfs package <sergiusens> slangasek: any idea how to make this go faster https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7596423 ? <slangasek> sergiusens: well apparently I have access to bump build scores, which is interesting <ogra_> for images ? <slangasek> for packages <ogra_> thats likely controlled via ubuntu-cdimage membership <ogra_> ah <slangasek> sergiusens: I don't know what the arm64 builders are doing right now, but every time I bump the build score the time goes up :P <mvo_> lol@slangasek <slangasek> and I'm not going to bump it higher than -security, because it's not higher than -security ;) <sergiusens> slangasek: wow, it was 5 first, then 25 and now 1hour :-/ <slangasek> yep! <slangasek> you're welcome <sergiusens> ogra_: I'm in ubuntu-cdimage and I don't see that... <ogra_> sergiusens, yeah, me neither <ogra_> was just wishful thinking :) <sergiusens> I don't like that there's no queueing system based on payloads either <ogra_> (it woudl make a lot of sense for cdimage members to be able to bump image build scores for sure) <seb128> mvo_, shrug, that ubuntu-snappy grub config generator is 440 lines of code! <ogra_> tiny <sergiusens> seb128: we got rid of that though ;-) <seb128> sergiusens, where? I'm looking at today's wily update <sergiusens> seb128: but the image needs sorting for e2e testing <ogra_> the kernel has 20mio lines ... whats 440 in that light :P <sergiusens> seb128: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381 <sergiusens> seb128: those two <seb128> sergiusens, ah, s/got ride/are getting ride ;-) <seb128> rid <sergiusens> seb128: it's all relative to where :P <seb128> sergiusens, k, I guess we should better wait for that work to land to look at/debug grub config issues... <seb128> Chipaca, ogra_, slangasek, mvo_, ^ <ogra_> seb128, yeah <ogra_> sergiusens, but you really want to drop that serial console for personal ... is there a way we can make it conditional ? <Chipaca> ogra_: we want to switch the order for non-personal too, no? <Chipaca> for intel at least <sergiusens> ogra_: just propose a branch for it <ogra_> well, not sure ... will you always have an actual tty on intel ? <sergiusens> ogra_: hurry before it moves to git <sergiusens> :-P <ogra_> yeah <seb128> ogra_, is that creating issues? the image boots fine on an usb stick or in a vm with that config <ogra_> seb128, it will be an issue for plymouth and if you acxtually want to see userspace boot messages on screen <ogra_> (not sure we'll go on using plymouth on snappy or with Mir though) * Chipaca 'll propose a branch with these changes <ogra_> well, do we have a way to conditionally decide what to put there ? <ogra_> (do we know if it will be a vm vs real HW image) <sergiusens> Chipaca: ogra_ the console stuff can go into a separate oem package too and personal can default to it <ogra_> i think serial console is actualy only interesting for VM images <ogra_> and perhaps for some exotic HW <ogra_> but yeah, oem makes sense <Chipaca> ogra_: sergiusens: https://code.launchpad.net/~chipaca/snappy-hub/grub-tweaks/+merge/263544 <ogra_> Chipaca, but then all kernel messages will go to serial (black screen on PC til the initrd kicks in) is that what we want ? <ogra_> ( i definitely agree it is better than the former though :) ) <ogra_> i think we should resort to one console= entry to not hop around ... but that would need to be conditional based on the image type (in a VM you might want a getty on ttyS0 and all ... while on PC you wont) <elopio> sergiusens: we can enable now launchpad translations, right? <sergiusens> elopio: I think so <sergiusens> mvo_: any update on system-image-cli? <sergiusens> Chipaca: agreed ping about https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381 <rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-core-config/0.6.25 <sergiusens> meh, arm64 blocks image builds too... <Saviq> ogra_, ah, it looks like it's the serial port (ttyAMA0) that's the culprit in my case, is the console enabled on it on purpose? <Saviq> or could it be dropped from the rpi snap? <sergiusens> Chipaca: CopyFile doesn't overwrite though <sergiusens> Chipaca: and I thought of it too, just forgot, now I see it failing :-P <Chipaca> sergiusens: sigh <Chipaca> sergiusens: if you can hold off half an hour, i'll ad a copyflag :) <sergiusens> Chipaca: I can os.Remove or Rename, or what you say :-) <sergiusens> Chipaca: I'll wait <sergiusens> well, I'll walk the dogs and it would be 30' or so ;-) <Chipaca> sergiusens: sounds fair to me :) <Chipaca> sergiusens: https://code.launchpad.net/~chipaca/snappy/overwrite/+merge/263584 <Chipaca> darn, 10 minutes instead of 30 <Chipaca> now i need to go have a beer or something to spend the excess <Chipaca> life is pain <sergiusens> Chipaca: how about a test where it fails the copy if the flag is not set? <Chipaca> sergiusens: sounds fair to me <Chipaca> sergiusens: pushed <sergiusens> Chipaca: branch updated <sergiusens> Chipaca: no we need the correct system-image-cli <Nissyen> Why does "sudo aa-clickhook -f" have to be run on a core update sometimes? <Chipaca> Nissyen: wha? <Chipaca> Nissyen: manually, you mean? <Nissyen> yeah. <Nissyen> I had to run it to fix permissions on an update from 15.04/stable core-2 to core-3 update. <Chipaca> Nissyen: shouldn't happen; it's a bug <Chipaca> Nissyen: sorry :( <Nissyen> OK, I filed a bug report on it: bug #1466682 . <nothal> Bug #1466682: Docker unix socket permission issue on ubuntu-core update <Snappy:New> <apparmor (Ubuntu):New> <docker (Ubuntu):New> <http://launchpad.net/bugs/1466682> <ubottu> bug 1466682 in docker (Ubuntu) "Docker unix socket permission issue on ubuntu-core update" [Undecided,New] https://launchpad.net/bugs/1466682 <Chipaca> Nissyen: thanks <Chipaca> Nissyen: i removed docker and apparmor because this one is all ours :-/ <Chipaca> Nissyen: i'll take a poke at it in the morning <Nissyen> Thank you very much. I have been experimenting with running containers on AWS and provisioning machines using cloudformation and the stable snappy AMI. <Nissyen> Although I have used ubuntu for some time, snappy is a different learning curve, and I am not always familiar with what is going on. <Chipaca> Nissyen: good on you for figuring out aa-clickhook fixed it, then :) <Saviq> jdstrand, hey, can you see why http://pastebin.ubuntu.com/11807012/ would cause review errors for security_yaml_click_emonhub and security_yaml_services? <Saviq> do I need to write the .snappy-systemd file myself? <Saviq> oh... or do I not have the snappy-dev ppa enabled... <Saviq> hmm I do :| <Chipaca> Saviq: jdstrand is on vacation <Saviq> *gasp* slacker <Chipaca> inorite <Chipaca> Saviq: what are the errors? <Saviq> Chipaca, originally "ERROR: Could not find 'emonhub.snappy-systemd'" <Chipaca> Saviq: where? <Chipaca> i mean, doing what? <Saviq> Chipaca, in the store auto-review (or using click-review locally) <Chipaca> Saviq: which ppa do you have? <Saviq> ppa:snappy-dev/tools <Chipaca> correct <Saviq> ubuntu-snappy-cli 1.1.1-0ubuntu1 <Saviq> not sure why it even mentions click... it's a snap <Saviq> grr ^W <Chipaca> heh <Chipaca> Saviq: i don't know this part as much as i'd need to help you easily, but i fyou could share the whole snap i could take a poke at it <Saviq> Chipaca, sure, https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d/download?path=%2F&files=emonhub-pi_1.0-2_multi.snap * Saviq wonders where to file a bug about ~ being allowed in version numbers but then breaking the systemd unit <Saviq> i.e. systemd hates ~ <Chipaca> sergiusens: you around? * Saviq files in snappy <Chipaca> Saviq: in snappy <Saviq> bug #1470661 <nothal> Bug #1470661: Tilde allowed in version but systemd hates it <Snappy:New> <http://launchpad.net/bugs/1470661> <ubottu> bug 1470661 in Snappy "Tilde allowed in version but systemd hates it" [Undecided,New] https://launchpad.net/bugs/1470661 <Saviq> oh yay, two bots :) #snappy 2015-07-02 <sergiusens> Chipaca: I am now <elopio> Hey mvo, I enabled the translations for snappy in launchpad. <mvo> elopio: excellent, thanks a bunch! <elopio> mvo: I wasn't quite sure about the configs to set, so maybe you'll like to take a look. <elopio> I set autoimport and autoexport in trunk. <mvo> elopio: nice, I have a look. we need to change the image seed too, right now iirc we don't have all the packages needed to get translations :) <elopio> mvo: do you mean, to start snappy in a different language? <mvo> elopio: yes, on a snappy system, I think we lack some of the required libraries/packages <elopio> I see. I was wondering how to do that. <elopio> but for now I'm happy. It will be good for the open house to encourage people to contribute translations. <mvo> elopio: absolutely! <dholbach> good morning <seb128> hey dholbach & snappy crew <dholbach> salut <mvo> hey good morning seb128 and dholbach and fgimenez <dholbach> hey mvo <fgimenez> good morning mvo and all <seb128> hey mvo <Saviq> mo'ing <seb128> hey Saviq <Saviq> oi * ogra_ sihs about the size of personal <ogra_> *sighs <ogra_> one day we'll produce desktop images that dont take a lifetime to download :P <Saviq> it's not the size of the image that's the problem, it's your crappy internets, ogra_! ;) <ogra_> yeah+ <ogra_> still, it would be good if ubuntu-device-flash and the system-image server could talk rsync <Saviq> or delta, at least <ogra_> re-downloading the whole thing every time is just so wasteful <Saviq> ogra_, is console=ttyACM0 on Pi meant to stay? that seems to actually be my problem as the emon add-on uses serial to communicate <Saviq> so the bootloader gets scared by all that happens on ttyACM0 <ogra_> yes, i think it is meant to stay for the default image <ogra_> embedded boards = serial console <Saviq> ok then, /me rolls a custom snap then, ogra_ do you guys have a branch for your main pi snap? <ogra_> we might have a "gui oem snap" for it or some such though <ogra_> in that i would drop it <ogra_> no branch yet, you can just unpack it and modify as needed <Saviq> kk * ogra_ puts "make branch" on his TODO <ogra_> i have a half baked one for the overlay dtb support (needs also a spoecific device tarball with the last kernel), i'll upload that if this personal download ever finishes <dholbach> hey rsalveti, did you get my open house mail? <JamesTait> Good morning all; happy "I Forgot" Day! ð <Chipaca> JamesTait: i don't even remember what i forgot! <JamesTait> Chipaca, have you been drinking again? <Chipaca> JamesTait: not today (yet), and only twice ever enough to forget <JamesTait> Chipaca, so, success? <mvo> Chipaca: hey, goooood morning! do you happen to know if there is anything blocking the noUpdateGrub branch from landing? if everything is ready I can land it today <Chipaca> mvo: god morning! <mvo> sergiusens: hi, for later - could you pass me the links for the passwd and adduser diff so that I can upload your fix? <mvo> Chipaca: I hope that was a typo ;) <Chipaca> ooh, my beuno script has a bug! <Chipaca> mvo: god morning! <Chipaca> indeed <Chipaca> /exec -o beuno mvo <Chipaca> ^^ failing <mvo> lol <Chipaca> mvo: goooooooooooooooooooooooooooooooooooooooooooooood morning! <mvo> loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooool <Chipaca> it's âecho -n "${1:-beuno}: g";eval printf "o%.0s" {2..$((RANDOM/512))}; echo 'd morning!'â <ogra_> mvo, i think this was the final one for shadow http://paste.ubuntu.com/11778897/ ... the adduser stuff should be in an MP <Chipaca> but /bin/sh doesn't have a RANDOM? guess i havne't used it in a while <ogra_> Chipaca, shuf -i 1-100 -n 1 <ogra_> Chipaca, also ... https://wiki.ubuntu.com/DashAsBinSh the page every ubuntu dev should know by heart :) <ogra_> (there is a more complex example for $RANDOM in a POSIX compliant way) <Chipaca> ogra_: i was using dash (or ash?) as sh before the official switch <Chipaca> ogra_: but i guess i never tested this thing after the last time i tweaked it? dunno <ogra_> :) <Chipaca> i was using some small sh back in debian, which was before warty <mvo> ogra_: nice, thanks. I wasn't sure if there was a real branch for passwd or just the pastebin <Chipaca> anyway <Chipaca> mvo: in answer to your question <Chipaca> mvo: i don't know what's missing, but sergio should be around soon <ogra_> mvo, just the pastebin i think, but sergiusens might have made changes since so better have him confirm that paste as final <mvo> ok <mvo> thanks Chipaca and ogra_ <Chipaca> there's still some question around console <ogra_> more than one ... see Saviq above about the RPi :) <Chipaca> ogra_: where? <ogra_> i think console shoul dprehaps become an option to u-d-f or some such <ogra_> Chipaca, in the backlog ... his RPi runs sime peripherial HW attached to the serial console ... our default image uses that device as console device and crashes his HW ... <ogra_> we need to find a more flexible way to set console altogether i think <ogra_> on all images <ogra_> and grub shouldnt use two console entries, IMHO all output from the boot should go to the same console device <ogra_> (preferably the one where also your getty will start once finished) <Chipaca> the default image also runs a getty on serial afaik <Chipaca> or is that a freebie from it being console? <rsalveti> morning snapers <ogra_> snaaapers :) <rsalveti> ogra_: I think we'd just need another oem for rpi2 that would not use the serial port by default <rsalveti> since unless hardcoded in the kernel, that's just a cmdline option, right? <ogra_> rsalveti, i think we need a gerneral solution for console= <ogra_> rsalveti, grub has similar probs <rsalveti> ogra_: what are the problems with grub? <ogra_> (not actually killing hardware ... but cloud definitely wants serial while desktop will definitely want tty) <ogra_> we need a more flexible way to define it at image creation time IMHO <rsalveti> problem with options at the image creation time can make the same image behave differently <rsalveti> which is why having another oem is so cheap <ogra_> i dont want "options" i want one option ;) <rsalveti> oem/gadget <rsalveti> for now, yeah :P <ogra_> --console=serial|native <ogra_> something like that <rsalveti> right <rsalveti> sergiusens: ^^ <ogra_> nothing you can freely define ... <ogra_> just a switch <ogra_> (it is ugly to mangle the cmdline during build, i know that, but i dont see a better way) <ogra_> (unless we want to have a ton of duplicate oem snaps for each device just for one option changed) <Chipaca> --console=serial|network|native ;) <ogra_> hah, even a third option :) * ogra_ didnt think about network :) * ogra_ laughs about balloons' open house mail ... switching folders in my mailer is like zapping on TV and always seeing the same ad on all channels <Chipaca> asac: rsalveti: mvo: sergiusens: should i re-enable click-review on build? <Chipaca> asac: rsalveti: mvo: sergiusens: i ask because bug #1470265 <nothal> Bug #1470265: Binary with an underscore fails to produce an apparmor profile <Snappy:New> <http://launchpad.net/bugs/1470265> <ubottu> bug 1470265 in Snappy "Binary with an underscore fails to produce an apparmor profile" [Undecided,New] https://launchpad.net/bugs/1470265 <asac> Chipaca: did the error messages get cleaned up yet? <Chipaca> asac: if by that you mean has it caught up with current snappy, yes <Chipaca> asac: there might be things still improperly reported as broken, because not enough testing, because we're not using it :) <asac> Chipaca: no, i mean are the errors it spits out now readable and complains only about things that are really issues? <Chipaca> in particular there's at least something about systemd units that seems off <Chipaca> asac: the majority of things it complains about are actual issues; the (mostly hypothetical) remaining things are bugs we need to address <Chipaca> asac: but either we start using it, or we start reimplementing it in 'snappy build' <Chipaca> asac: snappy assumes you've used it, and does not do deep checks <Chipaca> asac: so things break in strange ways <Chipaca> asac: (as in the linked bug) <asac> Chipaca: so is the bug that a snap install fails ? <Chipaca> asac: also in the linked bug: the full output from the review tool for a modified 'hello-world' that reproduces the issue <asac> e.g. bails out ...? <asac> e.g. you build and you install, and then a) it does not install or b) does not work right? <Chipaca> asac: no, the bug is that snap install does not bail, but fails to do all the things it should, afaik <Chipaca> (b) <Chipaca> mostly (b) <Chipaca> things we catch and fail on, we mostly catch at build
{'channel': 'snappy', 'month': 7}