[07:03] <fgimenez> good morning
[08:11] <elopio> hey fgimenez, one review please :)
[08:11] <elopio> https://github.com/elopio/subunit/pull/5
[08:12] <fgimenez> hi elopio! sure, on it
[08:18] <Chipaca> mo'in
[08:19] <Chipaca> elopio: what're you doing up?!?
[08:19] <elopio> Chipaca: hackin'
[08:19] <elopio> going to bed now.
[08:19] <elopio> _o/
[08:19] <Chipaca> elopio: that last one sounds like an eminently sane idea
[08:42] <mvo> ogra_: hi, so  - silly question. if I mount /writable in the inird read-only and then put it into the generated /etc/fstab as "LABEL=writable /writable ext4 remount,rw 0 0", should this work?
[08:42] <ogra_> work for what exactly ?
[08:43] <ogra_> (why do you want it in fstab ?)
[08:43] <mvo> ogra_: work in the sense that it will remount it
[08:43] <ogra_> sure
[08:43] <mvo> ogra_: how to debug if it does not work :) ?
[08:43] <ogra_> sudo touch /writable/foo ... after boot ?
[08:44] <mvo> ogra_: readonly fs, I see it in mount as mounted ro, but fstab conains the remount,rw line and systemd tells me the writable.mount was run
[08:44] <ogra_> (i guess your boot log and console  would be full of errors already by stuff that tries to write to it via a bind mount)
[08:44] <mvo> ogra_: yeah, there are some errors, fortunately it keeps booting
[08:45] <ogra_> i'm not sure if you can force an order of mounts
[08:45] <ogra_> you definitely want it rw beofre anything tries to access one of the bind mounts
[08:45] <mvo> pitti: is the fstab generated mounts ordered or will systemd try to mount it all at once? (context is my question above)
[08:45] <mvo> ogra_: aha, that might be a issue indeed
[08:46] <ogra_> well, you can influence how we generate the fstab (thats done in initrd)
[08:46] <mvo> ogra_: hrm, hrm, I was hoping I could get back to read-only only in initramfs :/
[08:46] <ogra_> so you could put /writable first in there
[08:46] <mvo> ogra_: right, I did that
[08:46] <ogra_> the question is if systemd will process it in the order it is in fstab or not
[08:46] <ogra_> i still dont understand why you want this
[08:47] <pitti> mvo: partially ordered, subdirs auto-depend on mounts of their parent dirs
[08:47] <ogra_> (you could as well just remount it froma  local-bottom script instead)
[08:48] <mvo> pitti: thanks
[08:48] <pitti> mvo:$ systemctl show -p RequiresMountsFor proc-sys-fs-binfmt_misc.mount
[08:48] <pitti> RequiresMountsFor=/proc/sys/fs
[08:48] <pitti> mvo: ^ for example
[08:48] <ogra_> pitti, heh, and for cross device bind mounts ?
[08:48] <mvo> ogra_: right, I could just leave it as it is (rw), I had hoped to move all the rw logic out of initrd so that systemd can do the fsck, provide a better emergency etc
[08:48] <pitti> mvo: and RequiresMountsFor= translates into something like Requrires/After=proc-sys-fs.mount for any parent mount
[08:49] <mvo> pitti: aha, nice. let me see
[08:49] <pitti> ogra_: shouldn't matter - a mount is a mount?
[08:49] <ogra_> pitti, well, /writable/system-data/foobar might come from /readonly/foobar
[08:50] <mvo> pitti: could it be that systemd paritial ordering does not work for bind mounts, i.e. it only looks at the second column of the bind mounts?
[08:50] <pitti> mvo: could be; haven't read scrollback here yet (still talking to doko/fighting with puppet); can you pastebin systemctl show of that .mount?
[08:50] <ogra_> right, the question is if it looks for /writable or for /readonly in the above case
[08:51] <ogra_> if the latter then it wont consider it depending on having /writable mounted first
[08:52] <pitti> mvo: ah, the case is "remount"?
[08:52] <pitti> mvo: could very well be that it stumbles over that -- /writable is already mounted, after all
[08:52] <pitti> (just not with the changed options)
[08:52] <ogra_> yeah
[08:53] <ogra_> i'D really keep that bit in initrd
[08:53] <mvo> pitti: its hard for me to pastebin, this is a very hacked snappy VM, the dependencies look ok of my writable.mount
[08:53] <ogra_> the whole basic assembly of the underlying setup at least (/writable plus system-a/b)
[08:53] <mvo> pitti: is there a way to figure out if it actually ran anything
[08:55] <mvo> ogra_: hm, so the initrd will mount /writable and /boot sure, but I wonder if it would make sense to mount it RO and do the RW later
[08:55] <ogra_> mvo, yeah, from a local-bottom script
[08:55] <mvo> ogra_: I'm not a initrd guy, so I may be totally off, but what I keep hearing is that this whole fsck in the initrd is bad
[08:55] <ogra_> thats runs right before run-init
[08:58] <ogra_> well, do we still need the fsck for vfat after the changes we made ?
[08:58] <ogra_> i think we shoudl be fine without it nowadays
[08:59] <pitti> mvo: there should be someting like "Mounting /writable..." ... "Mounted /writable" in the journal?
[08:59] <ogra_> (snappy update should perhaps run it when/after writing instead, normally nothing writes to the vfat in a way that fs content changes otherwise)
[09:00] <mvo> ogra_: we mount /writable RW in the initrd, part of that is that its is fscked before and I would like to avoid that (same for /boot fwiw). mount both RO and let the normal system startup do the RW and possible fsck dance
[09:00] <mvo> ogra_: but keep in mind I may be totally wrong about that this is a worthwhile goal to persue :)
[09:00] <pitti> mvo: I tested with a bind mount of /media -> /home/media, and I get RequiresMountsFor=/home /media
[09:00] <ogra_> yippie ! my new alix board just arrived ... will be my first snappy server !
[09:01] <pitti> mvo: i. e. at first sight it seems to take the "first column" into account as well for bind mounts -- I suppose it's rather because /writalbe is already mounted, so that the RequiresMountsFor= is satisfied?
[09:01] <pitti> ogra_: new toys!
[09:01] <ogra_> mvo, well, we might need to write to it from initrd
[09:01] <mvo> pitti: yeah, the dependencies look ok
[09:01] <pitti> mvo: so check the journal, I suppose it gets remounted too late?
[09:02] <mvo> ogra_: maybe, but I don't see any writes currently (at least in the version that uses squashfs)
[09:02] <ogra_> http://www.amazon.de/gp/product/B00JR6X0ZK
[09:02] <mvo> pitti: I don't see anything about /writable in the journal from systemd
[09:02] <pitti> mvo: there are ways around it, like adding a drop-in for systemd-remount-fs.service to also make /writable r/w instead of remounting it in the fstab; just a bit strange
[09:02] <ogra_> mvo, yea, thats why i said "might" :)
[09:03] <ogra_> we currently dont but that couold change
[09:03] <mvo> ogra_: heh :) ok
[09:03] <mvo> ogra_: well, we could simply reenable all of it once it changes?
[09:03] <ogra_> imagine we'd move away from livecd-rootfs and put the /etc/timezone or /etc/hostname stuff in place during boot
[09:04] <mvo> pitti: journalctl -u writable.mount says no entries
[09:04] <mvo> pitti: systemctl status writable.mount tells me its active (mounted)
[09:04] <ogra_> i guess we could have our own systemd unit that does the remount without using fstab
[09:05] <ogra_> would be the same as a local-bottom script though
[09:05] <mvo> ogra_: yeah
[09:05] <mvo> ogra_: right, then we can just leave it as it is I guess
[09:05] <mvo> I'm mostly curious at this point if I do something wrong or if there is a bug
[09:06] <pitti> ogra_: then I'd just append it to systemd-remount-fs.service and get the ordering for free?
[09:06] <ogra_> as long as we are ext4 fsck wont be a biggie anyway for /writable
[09:06] <ogra_> it is rather cosmetic
[09:12] <JamesTait> Good morning all; happy Friday, and happy No News is Good News Day! 😃
[09:31] <mvo> pitti: ok, so I think systemd simply not supports remount in fstab, it has systemd-remount-fs.service and it looks like this only looks for /, /usr
[09:32] <pitti> mvo: right, what I suspected; so this could be come a systemd-remount-fs.service.d/writable.conf with an extra "ExecStartPost=/bin/mount -o remount" if you want that, then it'll inherit the same dependencies (i. e. it will be done before any other fstab entry)
[09:32] <mvo> pitti: hrm, I think I will just leave it in the initramfs then
[09:33] <ogra_> well, we should keep that possibility in mind in case we ever actually *need* to move it out
[09:34] <ogra_> given that writable might be encrypted we'll likely need to keep it in initrd though
[09:34] <ogra_> (hwo do we handle fsck with encrypted root on server/desktop today btw ? that should have a similar issue)
[09:39] <pitti> ogra_: it hasn't really changed in ages -- the initramfs sets that up
[09:39] <Chipaca> let's hear it for tests! wooo!
[09:39]  * Chipaca just found a nasty bug before committing code :)
[09:39] <ogra_> pitti, yes, but who does the fsck ?
[09:39] <ogra_> is it mountall/systemd or the initrd
[09:39] <pitti> ogra_: back in the days, the OS; with recent initramfs-tools it now fscks / (and /usr) by itself
[09:40] <pitti> ogra_: "OS" -> mountall or systemd-fsck
[09:40] <ogra_> ah
[09:40] <pitti> I think the initramfs-tools maintainer's argument was that it's generally a bad idea to fsck the root partition with tools from the root partitions
[09:40] <ogra_> so the decryption happens in readonly ?
[09:40] <pitti> ogra_: yes AFAIUI
[09:40] <ogra_> ah
[09:41] <pitti> while that argument makes sense, it makes nice plymouth integration much harder, though
[09:41] <pitti> i. e. we lost plymouthy fsck feedback for the root partition
[09:41] <pitti> so, I'm not sure I actually like that change :)
[09:41] <ogra_> heh, yeah
[09:42] <pitti> pretty vs. robust, tough :)
[09:46] <ogra_> wheee !
[09:46] <ogra_> and my new snappy server is assembled, installed and running :D
[09:46] <ogra_> that was exactly 20min of work :D
[09:47] <ogra_> (including HW assembly)
[09:51] <ogra_> hmmm
[09:51] <ogra_> but the resizing didnt work
[09:51] <ogra_> (partition is resized, the fs isnt :/ )
[09:54] <ogra_> weird, worked on the second boot
[10:00] <asac> ogra_: already have your mail stuff snapped?
[10:01] <ogra_> asac, nope, thats weekend work ...
[10:01] <asac> ogra_: if you make a nice bundle that i can easily configure i could also replace my mailserver
[10:01] <ogra_> i also want the user setup to be a bit different
[10:01] <asac> remember to include TLS for the MTA
[10:01] <asac> then i am in
[10:01] <asac> one snap delivering a great integrated solution
[10:01] <asac> MTA, mail filtering, imap
[10:01] <ogra_> (and i'm still waiting for the actual SSD, that will only come on monday)
[10:01] <asac> in one bundle
[10:01] <Chipaca> mvo: have you seen thomi's talk on connascence?
[10:01] <asac> easy to configure :) ... done.
[10:02] <ogra_> a 32G SDD as bundled doesnt really cut it ;)
[10:02] <asac> ogra_: you can start with SD to hack on it :)
[10:02] <mvo> Chipaca: not sure, what was the link again?
[10:02] <asac> ogra_: 32G would be enough for my mail needs
[10:02] <asac> send it my way :P
[10:02] <ogra_> yeah, i have a kingston 32G SSD ... and an USB mSATA adapter here
[10:02] <ogra_> you can have it when the new one is here :)
[10:02] <asac> cool
[10:03] <ogra_> it is enought for experimenting on the weekend though
[10:03] <asac> with snappy home-mail product preinstalled... i am your first customer :P
[10:03] <Chipaca> mvo: https://www.youtube.com/watch?v=iwADIlIgDNA
[10:03] <asac> just plug and boot
[10:03] <ogra_> haha
[10:03] <ogra_> well, you dont want an ogra user preinstalled with my ssh key i guess ;)
[10:03] <asac> snappy-mail-geek-ready
[10:04] <Chipaca> a year from now I'm going to own a snappy-powered AI that will have the keys to my snappy-powered attack drone^W^Wspider bot
[10:04] <Chipaca> I feel like i'm in the future already
[10:05] <ogra_> Chipaca, lame ... you just install the AI snap on the drone directly :P
[10:05] <Chipaca> ogra_: batteries will still be a problem a year from now
[10:05] <Chipaca> ogra_: we won't solve that one for a bit yet :)
[10:05] <ogra_> there are always solar panels you can stick onto it
[10:06] <Chipaca> ogra_: and give whatever it chooses to attack an easy way to disable it?
[10:07] <ogra_> ah, well ... you got a point there
[10:32] <ogra_> Chipaca, did we change anything wrt snappy config ... nothing in bug 1472788 seems to work anymore for me
[10:32] <ogra_> all variants just generate a go backtrace
[10:32] <ogra_> (i'm on 15.04 edge here though)
[10:32] <Chipaca> ogra_: can you show me the session?
[10:33] <ogra_> http://paste.ubuntu.com/12334856/
[10:33] <ogra_> that line used to work for me in the past
[10:35] <Chipaca> ogra_: and if you add -- before the - ?
[10:35] <ogra_> hangs
[10:40] <Chipaca> mmm
[10:40] <ogra_> why the heck to we even need to pass yaml into the command instead of having set/get for variable/value pairs
[10:40]  * ogra_ still doesnt get whats the benefit of it 
[10:41] <Chipaca> ogra_: what's "15.04 edge" ?
[10:41] <Chipaca> ogra_: because that code doesn't seem to be what i have here
[10:41] <ogra_> Chipaca, the daily 15.04 build
[10:41] <ogra_> http://system-image.ubuntu.com/ubuntu-core/15.04/
[10:42] <ogra_> ubuntu-snappy	1.0.1-1+472~ubuntu15.04.1
[10:42] <ogra_> ubuntu-snappy-cli	1.0.1-1+472~ubuntu15.04.1
[10:42] <ogra_> is what the manifest for that image says
[10:47] <sergiusens> Chipaca, care to quickly look at https://code.launchpad.net/~sergiusens/snapcraft/filesets/+merge/270455 (the last commit only if you want)
[10:47]  * sergiusens fought with raw strings in python sometimes not being  raw strings
[10:47] <sergiusens> oh, and to keep the human touch going, good morning to all (applied retroactively as well)
[10:48] <ogra_> moin moin
[10:48] <asac> good morning sergiusens :)
[10:49] <ogra_> hmm, if i use --enable-ssh will there still be an ubuntu user ? and will password auth be on ?
[10:49] <Chipaca> umm
[10:49] <Chipaca> ogra_: your yaml is bad and you should feel bad
[10:49]  * ogra_ feels bad
[10:49] <Chipaca> ogra_: add an extra space before timezone
[10:49] <ogra_> same thing
[10:50] <Chipaca> ogra_: python3 -c 'import sys,yaml; print(yaml.load(sys.stdin))'
[10:50] <Chipaca> ogra_: and feed it your yaml
[10:52] <ogra_> with the same redirect ?
[10:52] <sergiusens> ogra_, add two spaces instead of one after config:\n
[10:52] <sergiusens> and shift the inner ones accordingly
[10:52] <ogra_> sergiusens, already tried
[10:52] <Chipaca> ogra_: yes, with the same redirect
[10:52] <ogra_> Chipaca, hangs
[10:53] <ogra_> (amd64)ubuntu@localhost:~$ python3 -c 'import sys,yaml; print(yaml.load(sys.stdin))' <(echo 'config:\n ubuntu-core:\n  timezone: Europe/Berlin\n')
[10:53] <sergiusens> ogra_, SIGABRT to see where :-)
[10:53] <Chipaca> dude
[10:53] <Chipaca> duude
[10:53] <ogra_> (even with corrected space it hangs)
[10:53] <Chipaca> ogra_:  < <(...)
[10:54] <Chipaca> so many things wrong
[10:54] <ogra_> geez
[10:54] <Chipaca> for example, echo -e
[10:54] <ogra_> how else would you force the backslash interpretation in non bash echo ?
[10:55] <Chipaca> ah, if it's non-bash, then i think you don't need -e
[10:55] <Chipaca> that is
[10:55] <Chipaca> dash builtin echo does not need -e
[10:55] <Chipaca> but /bin/echo does
[10:55] <Chipaca> but
[10:56] <Chipaca> on the other hand
[10:56] <Chipaca> dash does not have <(), or does it?
[10:56] <ogra_> -e is a no-op for all the others
[10:56] <ogra_> POSIX knows <() i think
[10:56] <Chipaca> nope
[10:57] <ogra_> anyway ... not working ... (no error either though)
[10:57] <sergiusens> am I seeing this right? ogra_ writing bashisms?
[10:57] <ogra_> :P
[10:57]  * Chipaca refers ogra_ to http://mywiki.wooledge.org/Bashism
[10:57] <ogra_> i just want to set my timezone
[10:57] <Chipaca> ogra_: show me again what you're doing please
[10:57] <ogra_> this is really hard :(
[10:58] <ogra_> snappy config ubuntu-core < <(echo 'config:\n  ubuntu-core:\n    timezone: Europe/Berlin\n')
[10:58] <ogra_> the nicely prints the config ... using Etc/timezone
[10:58] <Chipaca> ogra_: that should do nothing
[10:58] <Chipaca> ogra_: right, that's "get"
[10:58] <Chipaca> ogra_: "set" is with an argument
[10:58] <Chipaca> ogra_: go with -- -
[10:58] <ogra_> tried, same go traceback
[10:59] <Chipaca> ogra_: yes, because -e
[10:59] <Chipaca> ogra_: you can't use <() and not -e a the same time
[10:59] <ogra_> doesnt matter if i add or remove -e
[10:59] <ogra_> same error
[11:00] <Chipaca> you're going to make me *try* this stuff
[11:00] <ogra_> same behavior in all cases
[11:00]  * Chipaca boots something that may or may not be 15.04 edge
[11:00] <ogra_> oooh
[11:00] <ogra_> new error !
[11:01] <Chipaca> no, this is 15.04 stable. still, should be the same
[11:01] <ogra_> (amd64)ubuntu@localhost:~$ sudo snappy config ubuntu-core -- <(echo -e 'config:\n  ubuntu-core:\n    timezone: Europe/Berlin\n')
[11:01] <ogra_> open /dev/fd/63: no such file or directory
[11:01] <Chipaca> ogra_: -- -
[11:01] <Chipaca> and <
[11:01] <ogra_> hanngs hard
[11:01] <Chipaca> dammit
[11:01] <ogra_> ha
[11:01] <ogra_> < did it
[11:01] <ogra_> seriously ... who came up with that insanity
[11:02] <ogra_> can we please have proper set/get syntax alongside ?
[11:02] <Chipaca> ogra_: http://pastebin.ubuntu.com/12335797/
[11:03] <ogra_> Chipaca, right, thats what worked here too now
[11:03] <Chipaca> ah
[11:03] <Chipaca> missed that
[11:04] <ogra_> still, how is an admin supposed to ever decypher that line ?
[11:04] <Chipaca> ogra_: http://i.imgur.com/YsbKHg1.gifv
[11:04] <ogra_> LOL
[11:04] <ogra_> right
[11:05] <ogra_> also setting the hostname should tell you that you need to reboot to make it take effect
[11:05] <ogra_> (or at least to re-login)
[11:06] <ogra_> (not sure, perhaps the timezone setting needs that too)
[11:15] <Chipaca> ogra_: config can't communicate that kind of thing out :-/
[11:15] <Chipaca> maybe it should be able to, but right now it can't
[11:16] <ogra_> well, perhaps a generic message like "you might have changed config options that require a reboot"
[11:17] <Chipaca> ogra_: i'd rather let config hooks tell you things
[11:17] <ogra_> yeah, or that
[11:17] <Chipaca> like "you can't tell me to only use three of the four propellers when i'm a fridge"
[11:18] <Chipaca> or "this config is dangerous, ask for it again for it to take effect"
[11:18] <Chipaca> or something, dunno
[11:18] <Chipaca> just info/error messages
[11:19] <ogra_> yeah
[11:20] <Chipaca> if you want to go crazy, debug messages (logged, not shown), info messages (logged, shown), error messages (logged, shown, config fails)
[11:21] <ogra_> yup
[11:24] <ogra_> hmm
[11:24] <ogra_> why does /var/lib/extrausers/subuid not exist on that image
[11:24] <ogra_> i added that in livecd-rootfs
[11:26] <ogra_> weird, not there
[11:30]  * ogra_ uploads a fix 
[11:37] <sergiusens> ogra_, Chipaca the config spec is not completely implemented, configs are supposed to return success or failure with reason
[11:38] <Chipaca> sergiusens: also probably not panic on bad input
[11:38] <Chipaca> :)
[11:38] <ogra_> well, i think making the interface actually usable is more important than messages and feedback in the end
[11:38] <ogra_> its a nice to have thing :)
[11:38] <sergiusens> Chipaca, that is up to each hook
[11:39] <Chipaca> sergiusens: yes, the ubuntu-core hook panics and brings snappy down with it, which shouldn't happen
[12:07] <Chipaca> ok, lunch break for me
[12:25] <stgraber> mvo: anyhing I can do to get your branch merged? I'd rather not have LXD use a private, temporary bzr branch if I can help it :)
[12:37] <mvo> stgraber: absolutely agreed, I poked the gettext-go upstream again, no reaction though. to get it merge into trunk someone needs to review it, I need either sergiusens or Chipaca to look at https://code.launchpad.net/~mvo/snappy/snappy-gettext-fixes/+merge/270620. alternatively you (or someone from your team) can of course review it as well :)
[12:38] <Chipaca> whoa, \" -> \\" ftw
[12:41] <stgraber> mvo: looks like it's been reviewed now, thanks :)
[12:48] <Chipaca> daemon/task.go:29:2: struct field Id should be ID
[12:48] <Chipaca> whoever wrote golint did not know id was a word, not an acronym
[12:53] <Chipaca> https://github.com/golang/lint/issues/89
[12:54] <mvo> thanks Chipaca
[12:55] <mvo> Chipaca: meh, the comment in this upstream bug is unhelpful, there should be at least a --ignore=E101 or something
[12:56] <Chipaca> i'm coming to expect that kind of response from go upstream
[12:56] <Chipaca> mvo: in other news, https://code.launchpad.net/~chipaca/snappy/tasks/+merge/270813 \o/
[12:58] <Chipaca> hm, that diff is borked, 1 sec
[12:58] <mvo> Chipaca: yay, I go and review now
[12:58] <Chipaca> fixed now :)
[13:36] <ogra_> ppisati, hmm, do you plan non snappy RPi images ?
[13:36]  * ogra_ just saw bug 1494719
[13:36] <ppisati> ogra_: i already vanilla ubuntu rpi2 images
[13:36] <ppisati> *have
[13:44] <ogra_> ppisati, well, i was just wondering if you plan actual isos/imgs
[13:45] <tedg> mvo: Did you have a chance to look at the python-apt stuff? Seems like it's having trouble kicking the local system habit.
[13:45] <mvo> tedg: ups, once sec
[13:45] <tedg> np
[13:46] <Chipaca> https://code.launchpad.net/~chipaca/snappy/daemon-daemon-please-add-a-task---no-by-the-chin-of-my-chinny-chin-chin/+merge/270821
[13:46] <Chipaca> and school run for me
[13:46] <tedg> Chipaca: Make sure to listen to the teachers and do your homework!
[13:47] <sergiusens> tedg, btw, how is that pip plugin looking?
[13:47] <tedg> sergiusens: Okay, I wanted to confirm with zyga that it works for checkbox before doing the MR.
[13:47] <sergiusens> Chipaca, buffer overflow, branch name too long
[13:47] <tedg> sergiusens: I think they may need an array of requirements text files.
[13:48] <sergiusens> tedg, ah, so it is on the same branch as before and updated?
[13:48]  * sergiusens checks
[13:48] <tedg> sergiusens: Yup
[13:48]  * tedg checks a push to make sure it's all up
[13:52] <mvo> tedg: is "ros-jade-ros-core" a good example pkg? I will poke at the code
[13:54] <tedg> mvo: Yeah, that's supposed to be a meta package for all the base stuff.
[13:55] <tedg> mvo: It pulls in a lot though, lots and lots of boost.
[13:56] <mvo> ta
[14:06] <mvo> tedg: aha, fun, I blame sergiusens :P for the issue, python-apt is fine
[14:06] <sergiusens> mvo, what did I do? :-)
[14:07] <mvo> tedg, sergiusens: so the issue is that python-argparse is a virtual package but the depedency resolver in the ubuntu plugin will not deal with that
[14:07] <mvo> tedg, sergiusens: give me some more minutes to poke at it and maybe there is a easy way out
[14:07] <sergiusens> mvo, the ubuntu plugin replacement you mn?
[14:07] <mvo> sergiusens: what replacement is that?
[14:07] <sergiusens> in any case, that is all original code :-)
[14:08] <tedg> sergiusens: Yes, I was adding arbitrary sources lists
[14:08] <sergiusens> mvo, there is no more ubuntu plugin
[14:08] <mvo> sergiusens: oh, then I blame the original code ;)
[14:08] <mvo> the "class Ubuntu"
[14:08] <sergiusens> mvo, yeah, that is mine, mine it is not a plugin ;-)
[14:08] <mvo> ok, sorry, in any case, I blame $someone_else_that_is_not_me :P
[14:08]  * mvo still looks into a fix
[14:08] <sergiusens> mvo, but the dependency logic is all from the original plugin, I just used fetch_binares instead of dget
[14:09]  * mvo nods
[14:29] <mvo> tedg: you have a MP
[14:30] <sergiusens> asac, rickspencer3 ricmm tedg mvo any all or some mind looking at https://code.launchpad.net/~sergiusens/snapcraft/docs/+merge/270830 ?
[14:30] <tedg> Woot! /me looks
[14:30] <sergiusens> I think I want rickspencer3 to go through it first as he's the outsider :-)
[14:31] <mvo> sergiusens, tedg: the MP uses the python-apt resolver now and it will also skip priority (essential, important). that is a bit arbitrary, but it will prevent libc, passwd from getting pulled in. adjust as needed using whitelist/blacklist for pkgs or whatever if priority is not the best fit for this
[14:32] <sergiusens> mvo, where is that MP?
[14:32]  * sergiusens checks his queue
[14:32] <mvo> sergiusens: https://code.launchpad.net/~mvo/snapcraft/more-python-apt/+merge/270831 <- this one probably not in your queue
[14:33] <sergiusens> mvo, right, seems so from the target
[14:33] <sergiusens> :-)
[14:40] <sergiusens> mvo, commented with open questions :-)
[14:41] <mvo> sergiusens: thanks, excellent point. why single quoes?
[14:41] <elopio> fgimenez: try +	{TestID: "test-with-timestamp", Status: "success", Timestamp: time.Now().UTC().Round(time.Microsecond)},
[14:41] <elopio> (adding the UTC call)
[14:42] <mvo> sergiusens: it seems the python world has not really made up their mind when to use which
[14:43] <sergiusens> mvo, because elopio said so; that we should use one and single dominated the code bases these days
[14:43] <sergiusens> :-)
[14:45] <mvo> sergiusens: fair enough, branch updated, thanks
[14:49] <sergiusens> mvo, looks good, still missing an either or action on manifest.txt (remove or elif to skip too)
[14:51] <mvo> sergiusens: aha, shows my ignorance with the code, yeah, let me look at this
[14:52] <asac> sergiusens: i would love to look at it after merge
[14:52] <asac> quick glance looks good, but want to go tipp to tail to feel how complete etc
[14:53] <asac> sergiusens: i suggest to use example.tld
[14:53] <asac> not com :)
[14:54] <asac> j.k.
[14:54] <ogra_> .onion is in fashin currently i heard
[14:54] <ogra_> *fashion
[14:54] <asac> hehe
[14:55] <sergiusens> :-)
[14:56] <BjornT> do i have to poke someone to get MPs reviewed for snapcraft, or will someone review it in a timely manner anyway? https://code.launchpad.net/~bjornt/snapcraft/setuptools/+merge/270733
[14:57] <sergiusens> BjornT, I did not comment on that one since it had merge issues; I saw you based it out of mine or rebased yours out of that as well; might want to wait a bit for tedg's pip integration
[14:57] <sergiusens> BjornT, but, to answer your question, tedg or myself ;-)
[14:58] <mvo> sergiusens: I'm actually not quite sure what to do, I would love to just kill manifest.txt and see if that works, it only lists essential/important packages but then I don't know the rational for the list (debootstrap output maybe?)
[14:59] <BjornT> sergiusens: ok :) fwiw, the merge issues should be fixed already.
[15:00] <sergiusens> BjornT, ah, launchpad never notifies about those :-/
[15:01] <sergiusens> BjornT, I'll look, but I'll lock on tedg as he is doing some pip work on that same plugin
[15:02] <BjornT> sergiusens: thanks!
[15:04] <elopio> fgimenez: so all green on subunit? should I merge?
[15:05] <fgimenez> elopio, yup, go ahead!
[15:05] <elopio> thanks.
[15:21] <sergiusens> mvo, did you just add needs fixing to your own branch?
[15:22] <ogra_> he's just honest :)
[15:22] <mvo> sergiusens: yes, but tedg has merged it already (without merging it, not sure what he did)
[15:23] <tedg> Ah, yeah. I merged it to my branch. I can do another merge with updates before things get into the main branch.
[15:23] <tedg> I wouldn't want to have double quoted strings or something crazy like that.
[15:24] <sergiusens> tedg, there is one minor fix wrt to explicitly installing package_names even if they are in essential or important
[15:24] <sergiusens> which is what the original implementation already had
[15:47] <elopio> ogra_: using xz seems to work on beagle, canonistack and kvm tests.
[15:47] <elopio> do we care about somethinig else?
[15:48] <ogra_> yes, Rpi
[15:48] <ogra_> but then i guess i need to make sure it is xz there too
[15:49] <elopio> let me flash it and try.
[15:50] <ogra_> are you doing the repacking on the snappy system ?
[15:50] <elopio> I would prefer to always use xz, because we would need a tool to unpack and a tool to repack. That becomes scary bash for me.
[15:51] <elopio> but well, you can help me :)
[15:51] <elopio> ogra_: yes, everything happens on local-premount on snappy.
[15:51] <ogra_> well, the question is if we will ever provide the test tool to others
[15:51] <elopio> oh wait, not everything.
[15:51] <elopio> the unpack repack is when it's booted, of course.
[15:52] <ogra_> if we give the suite to third parties they could use whatever compression they like for their initrd
[15:52] <ogra_> for that it would be nice if the tool could cope with it
[15:52] <ogra_> if it is only for use we can just make sure it is always xz everywhere
[15:52] <ogra_> s/use/us/
[15:53] <elopio> it would be nice indeed.
[15:54] <elopio> but maybe we don't care here about how it is compressed. Linux takes care of that and we can assume it works well.
[15:55] <elopio> we just want the option to add spy scripts. We could generate with mkinitramfs, and compress with whatever we like.
[15:58] <ogra_> no, we couldnt ...
[15:58] <ogra_> not withut making bits of the ro fs writable
[15:58] <ogra_> (and i also plan to rip all initrd rebuild tools out of the rootfs since we dont support it on snappy anyway)
[15:59] <elopio> I tried that way a couple of days ago, making it writable. But something went wrong, I now don't remember what.
[15:59] <ogra_> your unxz and cpio is the best you can do ...
[15:59] <ogra_> just keep that
[15:59] <elopio> ogra_: ok, that makes sense.
[15:59] <elopio> (stripping the init tools, I mean)
[16:00] <ogra_> if we eveer give the tests to third parties we can adapt
[16:01] <elopio> ogra_: I agree. Shouldn't be that hard. The script will get uglier with two cases and we might need to add file to the image, but let's worry about it later.
[16:01] <ogra_> right
[16:01] <elopio> ogra_: I can't merge this yet, because there's a bug in the test helpers on beagle. Will fix that now.
[16:01] <ogra_> k
[16:25] <mvo> sergiusens: thanks for your reviews, I think I have fixed them all, will get dinner now and check that the branches are merged after that
[17:18] <sergiusens> mvo, k, was having lunch myself
[18:06] <kyrofa> ogra_, did you see the "installing apps on snappy personal" email that just came across snappy-devel?
[18:09] <sergiusens> kyrofa, I guess that email is probably thinking from a UI
[18:10] <kyrofa> sergiusens, right. Is he talking about an image generated from the personal channel?
[18:10] <kyrofa> I didn't know one was uploaded anywhere
[18:10] <sergiusens> kyrofa, I think he is; notice it might not be ogra_ bu olli
[18:11] <olli> nah, it must be ogra_ as olli is not building images
[18:11] <rickspencer3> hehe
[18:11] <rickspencer3> olli, I assumed it was in reference to one your blog posts or something
[18:30] <olli> ogra_, is there such a thing like a personal image
[18:30]  * olli thinks he should know
[19:02] <kgunn> ogra_: can confirm, but afaik there's not a snappy personal image per se in a channel, it's just that you can use u-d-f to create one off the rolling edge