=== ogasawara is now known as Guest14527
=== c74d is now known as Guest58751
=== wgrant is now known as Guest27601
=== kgunn is now known as Guest52384
=== Guest27601 is now known as wgrant
=== bigcat_ is now known as bicgat[afk]
[06:50] <dholbach> good morning
[07:09] <fgimenez> good morning
[07:20] <dholbach> ogra_, ogra2: do you know who could help figuring out https://bugs.launchpad.net/snappy/+bug/1506480 (link to "Kernel requirements for Snappy" is broken and I'm not sure what else to link to)?
[07:20] <ubottu> Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New]
[08:26] <Chipaca> asac: beuno: http://jimbenton.tumblr.com/image/131162934224
[08:29] <tasdomas> morning
[08:30] <Chipaca> mo'in!
[08:30] <tasdomas> the wiki specification for snappy confinement mentions an assign.yaml file that can be used instead of running the hw-assign command
[08:30] <tasdomas> however, I couldn't find any more information about it (format, etc.)
[08:30] <tasdomas> is it supported?
[08:33] <Chipaca> tasdomas: where does it mention that?
[08:34] <tasdomas> Chipaca, https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
[08:35] <Chipaca> tasdomas: there's no assign.yaml in that doc
[08:35] <Chipaca> tasdomas: it says "assign yaml"
[08:35] <Chipaca> tasdomas: no dot
[08:35] <Chipaca> tasdomas: it's not a file; it's part of the oem config
[08:35] <tasdomas> Chipaca, ah, sorry - misread that
[08:36] <Chipaca> tasdomas: so, yes it's supported, for oem snaps
[08:37] <tasdomas> Chipaca, so for my own snap the only thing to do is use hw-assign, right?
[08:37] <Chipaca> tasdomas: right
[08:38] <Chipaca> tasdomas: what're you wanting to do?
[08:38] <tasdomas> Chipaca, I was writing a simple snappy app to control the piglow device on my orange matchbox
[08:38] <tasdomas> Chipaca, http://domas.monkus.lt/posts/2015-10-15-writing-a-snappy-application/
[08:39] <tasdomas> Chipaca, my main problem was that I need to restart the service after assigning the i2c device to it
[08:39] <Chipaca> really?
[08:39] <Chipaca> that's surprising to me -- but then i know little about i2c and the rpi2
[08:40] <Chipaca> tasdomas: are you sure it's not that you need to restart the service that uses it?
[08:40] <Chipaca> (that'd be bug 1484645 fwiw)
[08:40] <ubottu> bug 1484645 in Snappy "Snappy hw-assign doesn't restart affected services" [High,Triaged] https://launchpad.net/bugs/1484645
[08:40] <tasdomas> Chipaca, sorry - maybe I wasn't clear - my problem was that I needed to restart the service (exposed by my snappy app) that uses the i2c device
[08:41] <Chipaca> wow, it's going to be a long day
[08:41] <Chipaca> because you said exactly that
[08:41] <Chipaca> sorry :-(
[08:42] <Chipaca> tasdomas: that's a bug, we know about it, should get fixed (on rolling/edge) soonish
[08:42] <tasdomas> Chipaca, ah, cool!
[08:42] <tasdomas> Chipaca, can I bother you with one more question?
[08:42] <Chipaca> tasdomas: i dount you can bother me with a question, but you're welcome to try
[08:42] <Chipaca> doubt*
[08:42] <tasdomas> there's an mqtt snappy app available in the store - but I can't find the source for it
[08:43] <tasdomas> I want to modify it to make it mdns discoverable
[08:44] <Chipaca> tasdomas: have you tried asking the snap publisher?
[08:45] <Chipaca> or gone to the snap support url?
[08:45] <Chipaca> tasdomas: this one, i presume https://search.apps.ubuntu.com/api/v1/package/mosquitto.kartben
[08:46] <tasdomas> Chipaca, ah, will do
[08:48] <dpm> davidcalle, dholbach, looking at askubuntu, there seems to be quite a lot of questions around snappy already
[08:48] <dpm> might be worth for us looking at them in the upcoming weeks
[08:49] <dholbach> maybe we can talk about it in our next docs hour call?
[08:50] <dholbach> dpm, ^
[08:50] <dpm> it could be a good topic, yes
[08:50] <dholbach> cool
[08:50] <davidcalle> dholbach, dpm, +1
[08:54] <tasdomas> by the way, is it possible to use snapcraft to build a snappy package for a different architecture? e.g. build a RPi2 compatible package on my amd64 laptop?
[08:55] <dpm> davidcalle, dholbach, it might be worth creating a snapcraft tag as well. Right now we've got 'snappy' already, which redirects to 'ubuntu-core'
[08:56] <dholbach> yep, that makes sense
[08:58] <dholbach> ciao ppisati, do you know how we could fix https://bugs.launchpad.net/bugs/1506480? (which information should we link to in the article there?)
[08:58] <ubottu> Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New]
[09:00] <JamesTait> Good morning all; happy Friday, and happy World Food Day! 😃
[09:22] <ogra_> dholbach, ppisati should be able to help with the link
[09:22] <dholbach> cool
=== soee_ is now known as soee
[09:30] <dpm> dholbach, davidcalle, do we have any document that specifies the format of the snapcraft.yaml file?
[09:32] <dholbach> dpm, no spec-like doc in our docs yet, but there's 1) https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/ and 2) ./examples in lp:snapcraft and 3) https://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/snapcraft-advanced-features.md which will land as soon as the md importer is working
[09:32] <davidcalle> dpm, closest thing we have to a spec for it in the the App dev manual
[09:32] <dholbach> ah yes, and that
[09:32] <davidcalle> It's actually quite detailed
[09:33] <dpm> davidcalle, yeah, I've gone through 1) and 2), but I've been missing a doc that is specific to snapcraft.yaml
[09:33] <davidcalle> dpm, https://docs.google.com/document/d/1Rj9nVBttx62BvGlbnkmKOzAlAIEWuLNr1QaSGe3gQDA/edit#heading=h.8o7w1g30gucy
[09:34] <dpm> ahaha
[09:35] <dpm> I had actually seen this, but couldn't figure out where, glad I wasn't going mad
[09:35] <davidcalle> dpm, not sure the link is world-readable though, hopefully next week in some form on duc...
[09:35] <dpm> yeah
[09:52] <dpm> davidcalle, dholbach, http://askubuntu.com/questions/686167/what-is-snapcraft, this might help with AskUbuntu/Stackoverflow searches to give a 5 min intro and direct folks to the site
[09:53] <Chipaca> mvo: ping
[09:54] <davidcalle> dpm, this is excellent
[09:54] <davidcalle> dpm, love it :)
[09:54] <mvo> Chipaca: pong
[09:54] <dpm> glad it if it's useful :)
[09:54] <Chipaca> mvo: this race condition with the automount unit
[09:55] <Chipaca> mvo: tell me about it
[09:56] <mvo> Chipaca: its not that much that I know - so the code will activate and start the automount unit, right after that it runs the click stuff
[09:56] <dholbach> dpm, nice one!
[09:56] <dholbach> dpm, now we can't change the URLs anymore! :-)
[09:56] <mvo> Chipaca: when I do not unpack the meta,.click dirs it will fail to generate the apparmor profiles
[09:57] <mvo> Chipaca: however ls a bit later is fine
[09:58] <dpm> dholbach, oh, I can update the link after we've done the IA rearrangement. Or just make it point to https://developer.ubuntu.com/snappy
[09:58] <mvo> Chipaca: hm, maybe its something else, need to look deeper
[09:58] <dholbach> dpm, or we add redirects - in any case, no problem :)
[09:58] <Chipaca> mvo: aiui, systemctl should not return until automount has actually started
[09:59] <Chipaca> mvo: maybe we're creating the units but not starting the .automount until later?
[09:59]  * Chipaca looks
[09:59] <mvo> Chipaca: adding a sleep did not solve it, so its something else
[10:00] <mvo> Chipaca: here we go, its a missing .click/manifest in the snap :/
[10:00] <mvo> Chipaca: sorry
[10:00] <mvo> Chipaca: let me fix that
[10:01] <Chipaca> hue hue hue, to quote a brazilian
[10:01] <mvo> Chipaca: we also may want to keep the .meta for now because of "snappy list -v"
[10:01] <mvo> unless we go husks
[10:01] <Chipaca> mvo: that one i don't follow
[10:01] <Chipaca> mvo: once automount is started, any access under it will trigger the mount
[10:01] <Chipaca> mvo: even if you're accessing things that are there
[10:02] <mvo> Chipaca: so only the active snap has a automount unit
[10:02] <Chipaca> ohhhh
[10:02] <mvo> Chipaca: so snappy list -v (old snap) will not have a meta/packages.yaml
[10:02] <Chipaca> yep yep
[10:02] <Chipaca> so, yeah, leave it for now, flag it for removal when we switch to lightweights
[10:02] <Chipaca> ok
[10:03] <mvo> yeah, will do
[10:03] <Chipaca> mvo: have you checked it for speed?
[10:04] <mvo> Chipaca: not yet, no
[10:04] <Chipaca> k
[10:04] <Chipaca> mvo: the lightweight thing of looking at remote manifests does not work for sideloaded stuff though
[10:04] <mvo> Chipaca: one more complication - the hooks expect .click/$name.$origin.manifest - and the $origin is not known at build time. so we can not ship that in the snap and need to generate it
[10:05] <mvo> Chipaca: once hooks are gone this is no longer a issue of course
[10:05] <Chipaca> hooks were going to be gone "soon" since i joined
[10:05] <Chipaca> not lookin' good
[10:05] <mvo> yeah
[10:05] <mvo> there is only one left
[10:05] <mvo> but that one is pretty sticky :P
[10:57] <mvo> Chipaca: do you want me to split the branch for the snapfs-mount up more?
[10:58] <Chipaca> mvo: how would you split it?
[10:58] <Chipaca> unless you moved all the systemd stuff to .. ahem .. systemd :-p
[10:59] <Chipaca> mvo: anyway, you don't have to, but my review is slower :)
[10:59] <mvo> Chipaca: I can do that I think if it helps (I will do that in any case in this MP, your suggestion makes sense)
[10:59] <mvo> but lunch first
[10:59] <Chipaca> mvo: i'm not sure the total time would be less, so i'd say nah
[12:18] <beuno> Chipaca, lol
[12:44] <longsleep> yaml question, how can i have a binary with a _ in the name?
[13:07] <tedg> sergiusens: So I think I may need to copy the options locally to stay under the 79 character limit :-)
[13:30] <sergiusens> tedg, harr harr :-)
[13:30]  * sergiusens notices that today is not talk like a pirate day
[13:30] <tedg> sergiusens: It can be here!
[13:30] <tedg> matey
[13:31] <sergiusens> tedg, I couldn't sleep last night thingking about the override of setup_stage_packages; maybe it is best to use repo.Ubuntu directly instead
[13:31] <tedg> Since we can't have casual Friday's working from home, we should have talk like a pirate Fridays.
[13:31] <sergiusens> tedg, right on
[13:31] <tedg> sergiusens: Heh, I never meant for you to lose sleep over it :-)
[13:31] <sergiusens> although my vocabulary is rather scarce
[13:31] <sergiusens> tedg, it is one of those things
[13:32] <sergiusens> I also stayed up late as I went to a docker meetup to see a bunch of old friends
[13:32] <sergiusens> learned a lot about docker and why developer like it so much
[13:32] <tedg> I'm feeling like we might need to detach the plugin lifecycle from the overall one. Like have more phases for plugins.
[13:33] <tedg> I think it is nice. I just haven't see the overlays actually work well. Seems like they always get confused for me.
[13:33] <ogra_> because you talk like a pirate to them ?
[13:38] <tedg> Stupid overlays are no fun, they never talk like pirates.
[14:01] <dholbach> sergiusens, tedg: snappy clinic planning?
[14:07] <jdstrand> mvo: hey, curious if you had a chance to review my email re snappy-debug. I know we were both pretty busy yesterday
[14:18] <mvo> jdstrand: I saw it but have not acted on it yet, sorry
[14:20] <jdstrand> mvo: ack
[15:03] <dholbach> sergiusens, I found an interesting one: http://pastebin.ubuntu.com/12799579/
[15:03] <dholbach> not sure if we support this
[15:03] <dholbach> tedg, ^
[15:04] <dholbach> I just used: apt-get source bamtools
[15:04] <sergiusens> dholbach, thanks, perfect example for custom plugin
[15:04] <dholbach> I'll leave that one for you then :)
[15:22] <dholbach> tedg, sergiusens: I added two more examples to the pad
[15:23] <Chipaca> sergiusens: i should probably have pointed you at that talk earlier
[15:23] <Chipaca> sergiusens: 's good stuff
[15:23] <elopio> mvo: Chipaca: yes! with this last test I saw the moment when the last cloud init message appeared and the moment when the mode switched to regular. It's just twice as slow as the last time I tried.
[15:23] <elopio> fgimenez: ^
[15:23] <elopio> Chipaca: tell me more about waiting for a systemd service.
[15:24] <Chipaca> elopio: it's just a for loop with a sleep and a check
[15:24] <Chipaca> elopio: give me a sec
[15:25] <elopio> Chipaca: ah, we have that.
[15:25] <Chipaca> elopio: ah! show me the code :)
[15:25] <elopio> I thought you were talking about subscribing a listener to the service or something like that.
[15:25] <Chipaca> elopio: well, you could, but why bother
[15:26] <elopio> Chipaca: https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/testutils/wait/wait.go
[15:26] <elopio> to work around the workaround I will just have to increase the maxWaitRetries.
[15:27] <Chipaca> elopio: and you're waiting for bootok?
[15:27] <elopio> Chipaca: I'm waiting for snappy_mode=regular
[15:28] <Chipaca> elopio: and is that better, or worse than waiting for boot ok?
[15:28]  * sergiusens wonders if it is beer o clock already
[15:28] <Chipaca> sergiusens: it is!
[15:29] <elopio> Chipaca: better, I think. Instead of checking the service, we check it's effect.
[15:29] <Chipaca> sergiusens: you should come visit. can't have beer on my own (and ellie doesn't do beers)
[15:29] <elopio> *its
[15:29] <elopio> it's beer-on-hangout o'clock.
[15:30] <Chipaca> elopio: so, yeah, looks like you're already doing the right thing and all :)
[15:30] <Chipaca> elopio: wrt increasing maxWaitRetries, maybe instead have an arch-dependent base?
[15:30] <Chipaca> elopio: ie scale checkInterval by some bogomips factor
=== kickinz1 is now known as kickinz1|away
[15:31] <elopio> Chipaca: that would be nice.
[15:31] <Chipaca> var bogomips = map[string]int{"arm": 100, "amd64": 1, etc}
[15:31] <Chipaca> and index it on GOARCH
[15:31] <elopio> I'll make a card to be able to configure the wait, with a delay factor.
[15:32] <elopio> but anyway, this is a bug :) Instead of working it around, somebody should fix it.
[15:32]  * elopio looks at somebody.
[15:32] <Chipaca> elopio: which is the bug, exactly?
[15:32] <Chipaca> elopio: that you can ssh in before you can log in?
[15:33] <elopio> Chipaca: you can sign in before boot-ok. both ssh and normal log in through serial. And if you are fast with a rollback, that makes the boot crazy.
[15:33] <elopio> https://bugs.launchpad.net/snappy/+bug/1498293
[15:33] <ubottu> Launchpad bug 1498293 in Snappy "after a successful update and reboot, the bootloader snappy_mode is set to 'try'" [Critical,Triaged]
[15:33] <elopio> on bbb you don't have to be super fast. I actually can reproduce this manually.
[15:35] <Chipaca> elopio: so that's the bug
[15:35] <Chipaca> elopio: not that "try" thing :)
[15:36] <Chipaca> so, we want the boot-ok to be done *before* ssh and getty lets people in
[15:37] <Chipaca> pitti: do you remember offhand whether there's a target that would let us do that easily?
[15:37] <elopio> Chipaca: I think so. You could fix the rollback so it waits for boot-ok, but then it might affect something else.
[15:38] <elopio> Chipaca: and if you just move the log in after boot-ok, the reboot will take twice the time to let you access the board.
[15:39] <Chipaca> elopio: well, but it's letting you in before things are ready
[15:39] <sergiusens> Chipaca, I don't mind visiting; when are we having a sprint in London?
[15:40] <Chipaca> sergiusens: i have space for two for half a week every week
[15:40] <Chipaca> as long as they're not super tall :)
[15:40] <elopio> Chipaca: well, before cloud-init has finished. Most of the things are ready.
[15:41] <dholbach> tedg, sergiusens: is the announce text roughly what you expected?
[15:42] <sergiusens> dholbach, where is it?
[15:42] <dholbach> sergiusens, ah sorry - on the pad :)
[15:43] <sergiusens> dholbach, looks good, just added on clarification just in case
[15:43] <dholbach> thanks sergiusens
[15:43] <sergiusens> dholbach, btw, how hard would it be to patch clog?
[15:43] <dholbach> rock and roll
[15:43] <dholbach> let me check
[15:44] <sergiusens> dholbach, so ideally, patch CMakeLists.txt to take an arg to provide an alternate ~/.clogrc path
[15:44] <tedg> If sergiusens is happy I'm good.
[15:45]  * tedg didn't keep a link to the pad :-)
[15:45] <dholbach> tedg,
[15:45] <dholbach> http://snappy.asac.ws:9001/p/snapcraft-clinics
[15:45] <sergiusens> -DLOGRC_PATH=$SNAP_APP_DATA_PATH or something like that, and then the code would need to expand the var
[15:46] <tedg> dholbach: +1
[15:53] <dholbach> sergiusens, I guess it's not too hard to do - maybe something to look into some other time?
[16:05] <dholbach> tedg, sergiusens: thibautr suggested next time we ask for proposals on what people would like to see snappified :)
[16:05] <fgimenez> have a nice weekend o/
[16:10] <sergiusens> dholbach, sounds like a good idea
[16:10] <sergiusens> dholbach, maybe at the end of the clinic we ask that question too
[16:10] <dholbach> for next time we can maybe leave it a bit more time in advance, so we can collect suggestions beforehand
[17:04] <sergiusens> elopio, very simple MP https://code.launchpad.net/~sergiusens/snapcraft/tested_or_not/+merge/274741
[17:06] <elopio>  sergiusens: why is that needed? I find it good to see if all your test code is being run.
[17:06] <elopio> if it isn't, you can probably remove it. Or you have a condition that has to be faked.
=== willcooke_ is now known as willcooke
[17:21] <sergiusens> Chipaca, can we get the release from the rest api already or not?
[17:22] <Chipaca> sergiusens: i don't think that's in stable yet
[17:24] <Chipaca> sergiusens: why?
[17:24] <sergiusens> Chipaca, to be able to ask it to be able to ask the store if you know what I mean.
[17:29] <Chipaca> sergiusens: updating to latest edge to see if it's there yet
[17:31] <sergiusens> elopio, ok, it just bothers me to be honest :-)
[17:36] <Chipaca> sergiusens: wait, the release?
[17:36] <Chipaca> sergiusens: you could always get the release!
[17:37] <sergiusens> Chipaca, as in 15.04-core .. btw, I'm not saying you can't, I'm asking if you can! :-D
[17:37] <Chipaca> sergiusens: the store id is what was missing, and is there now
[17:37] <Chipaca> sergiusens: http://pastebin.ubuntu.com/12801235/
[17:38] <Chipaca> sergiusens: ^ that's the output in rolling/edge :)
[17:38] <sergiusens> Chipaca, yup, nice
[17:39] <Chipaca> sergiusens: http://pastebin.ubuntu.com/12801274/
[17:39] <Chipaca> sergiusens: that's 15.04, now
[17:40] <Chipaca> sergiusens: note the socket name has changed
[17:42] <sergiusens> Chipaca, life is good!
[17:43] <sergiusens> Chipaca, mind looking at this https://code.launchpad.net/~sergiusens/snapcraft/build-deps-request-something-missing/+merge/274749 among other complicated things in your life?
[17:44] <Chipaca> sergiusens: i don't *mind*, but it's friday afternoon and the malbec has already confessed its crimes
[17:44] <sergiusens> Chipaca, look at it and then decide ;-)
[17:44]  * Chipaca obeys
[17:45] <Chipaca> sergiusens: no, that's too many lines of code for this hour
[17:45] <Chipaca> sergiusens: also, the complexity is astounding
[17:45] <Chipaca> sergiusens: flabbergasting
[17:45] <Chipaca> sergiusens: maybe split it in two or three and have a team work on it on monday
[17:46] <sergiusens> Chipaca, btw https://github.com/docopt/docopt.go
[17:46] <Chipaca> !
[17:49] <Chipaca> sergiusens: also, in that branch, i think you're using the Schwarzschild metric wrong; you need to use Kruskal–Szekeres coordinates to express it like that
[17:52] <pitti> Chipaca: Before=systemd-user-sessions.service? That's "before people can log in" (I didn't read the full backscroll)
[17:52] <Chipaca> pitti: that includes ssh and getty (both tty and serial)?
[17:53] <pitti> yes
[17:53] <Chipaca> elopio: could you try that?
[17:53] <Chipaca> pitti: thanks!
[17:55] <Chipaca> pitti: can something be after: multi-user.service *and* before: systemd-user-sessions.service?
[17:55] <Chipaca> that seems to be a no-no
[17:55] <pitti> no
[17:55]  * Chipaca could test, but me has already checked out
[17:55] <pitti> as multi-user is after user-sessions
[17:55] <Chipaca> suspected as much
[17:56] <Chipaca> we need to check on monday, then, whether sessions is enough
[17:56] <pitti> it has multi-user in it, after all :)
[17:56] <pitti> right; I'm just on a drive-by, need to leave again
[18:34] <sergiusens> Chipaca, let me fix!
[18:34] <sergiusens> :-)
[18:56] <sergiusens> Chipaca, I like the docopts thing, but I can't easily add help to commands
[20:00] <sergiusens> tedg, final comment wrt setup_stage_packages
[20:01] <sergiusens> and there's a merge conflict (very minor)
[20:01] <tedg> Heh
[20:01]  * tedg isn't sure if he wants to look
[20:02] <tedg> sergiusens: I don't think we can use pull with the current configuration of the command. Because the superclass is just empty.
[20:04] <sergiusens> tedg, right, I mean, pull() -> handle_source_options;
[20:05] <sergiusens> tedg, then have your private implementation of setup_stage_packages keeping self.stage_packages empty (or reuse if you want)
[20:05] <tedg> Oh, I see.
[20:05] <tedg> That seems a little scarier to me...
[20:05] <sergiusens> tedg, in other words, setup_stage_packages should have always been _setup_stage_packages
[20:05] <tedg> Because then we have two overrides
[20:06] <sergiusens> tedg, 2?
[20:07] <tedg> sergiusens: We'd have to override setup_stage_packages to be null, then have pull get sources, setup deps, and then call it.
[20:08] <sergiusens> tedg, let me try and propose something
[20:13] <sergiusens> tedg, meh, I'll do this in another proposal (I'll fix the priv/pub thing first)
[20:13] <tedg> sergiusens: I think restructuring pull() also would help.
[20:14] <sergiusens> tedg, indeed, that's why :-)
[20:14] <sergiusens> well another reason why
[20:14] <tedg> I think there may need to be a "get_deps_from_source()"
[20:14] <tedg> Or something for plugins.
[20:16] <tedg> sergiusens: I'm getting an odd error with trying to copy system libs. Basically the -dev packages are bringing in symlinks and that seems to be confusing snapcraft.
[20:16] <tedg> sergiusens: Does that sound like something you've seen?
[20:19] <tedg> http://paste.ubuntu.com/12804340/
[20:20] <tedg> http://pastebin.ubuntu.com/12804368/
[20:20] <tedg> The first results in the second :-)
[20:31] <sergiusens> tedg, that is weird, the path exists but can't be copied to
[20:31] <sergiusens> tedg, does /home/ubuntu/readlinetest/parts/ginac/install/lib/x86_64-linux-gnu/ exist?
[20:32] <tedg> sergiusens: No
[20:32] <sergiusens> tedg, that is the darn problem then :-/
[20:32] <tedg> sergiusens: I'll get an MR here in a sec.
[20:33] <sergiusens> tedg, its just a mnissing os.makedirs(os.path.basename(real_path, exist_ok=True)
[20:33] <sergiusens> before the copy
[20:35] <sergiusens> tedg, what I don't get is that that lib should of been relinked to the internal one
[20:40] <tedg> sergiusens: There is no internal one because it's on the list of blocked packages.
[20:40] <tedg> sergiusens: I'm not sure that readline should be on that list though.
[20:41] <sergiusens> tedg, ah, then the makedirs missing is the correct thing to do or if it is one of those that is always on the system, add it to the skip list
[20:41] <sergiusens> tedg, right, maybe not; the only real problematic one is libc
[20:42] <sergiusens> tedg, all others come inherited from deb2snap
[20:43] <tedg> sergiusens: So, I think it found a bug, but perhaps it isn't a bad bug once we get everything more refined.
[21:04] <sergiusens> tedg, what bug?
[21:07] <tedg> sergiusens: Not making the directory
[21:11] <sergiusens> tedg, right, that is indeed a bug