IRC logs for #baserock for Friday, 2014-11-28

radiofreeIt should work paulsher1ood00:23
radiofreeI know that place and I know they have guest wifi00:23
radiofreeBut yes deploy is broke. I'll submit a bug report tomorrow00:23
radiofreeBuild with no git update works fine. It is just deploy00:24
radiofreeBinutils every time00:24
* persia is reading backscroll and fails to understand how copying scripts from a wiki page could possibly be easier than `git clone ${MAGIC_REPO}; cd baserock_vagrant; vagrant up`08:37
petefothpersia: if you are in a browser, viewing the script, you can press a single down;oad button. No need to swithc to a terminal, and git cline. And why would siomebidy who wants to run a creipt to setup VirtualBox or KVM want to use Vagreant?08:39
*** locallycompact [] has joined #baserock08:40
persiapetefoth: I generally only want to read scripts when either I expect I can't trust them or something has gone wrong.08:40
persiaAlso, I don't think most new users *care* whether they are using one or another virtualisation technique: they haven't been using Baserock enough to develop a preference.08:40
petefothpersia: then don’t bother reading it - just clone (or download) it and run it :)08:41
persiaHowever, my estimation of people can be wrong, and my attitude towards scripts may be different (plus, my opinions about the low quality of cut&paste on the linux desktop may not be shared)08:41
persiaBut if it is a script on a wiki page, I *can't* clone/download and run it!08:42
*** mariaderidder [] has joined #baserock08:43
*** mariaderidder [] has quit []08:43
persiapetefoth: As I read backscroll more, I discover you've already made this point :)08:43
petefothI don’t have neartly enough data to make judgements on what “most” people want, need or care about. If we knew *most* people wanted to work with e.g VBox (perhaps because they already use it) then we needn’t bother with explingin how to set up KVM. So we make some educate guess, act according to those guesse and. if we have the time, try to establish alter on which guesse were correct08:44
petefothpersia: ‘Read first, ask questions later”? Where’s the fun in that ;)08:45
persiaOh, yes, I agree that documenting both is useful.  I just had instinctive horror at someone's claim that "scripts would be simpler [than vagrant]"08:46
petefothpersia: That wasn’t me (I think / hope)08:47
persiapetefoth: Indeed, it was not :)08:48
*** bashrc [] has joined #baserock08:59
pedroalvarezso, when deploying we need network to figure out what artifact we are going to deploy... I was wondering if it would be still needed  now that we have in definitions: a) all the chunk morphologies  and b) the sha1s and repos of all the chunks. Is anything else needed to construct the cachekey of a system artifact?09:11
*** jonathanmaw [] has joined #baserock09:17
persiaFor optimisation reasons, we need the tree SHA for the chunk refs, which may not be local09:21
paulsher1oodbuild has already done the mappings. it could trivially leave that work in place for potential deploys09:23
radiofreeeverything else seems to be fine, without the network09:23
persiaI'm not sure it's trivial, but yes, caching the cache-key mappings should address this09:24
radiofreeit always seems to halt at binutils though09:24
pedroalvarezradiofree: isn't binutils the first thing we build?09:24
radiofreepaulsher1ood: you can do the demo, just connect to a phone for the deploy09:26
*** ssam2 [] has joined #baserock09:27
Mode #baserock +v ssam2 by ChanServ09:27
paulsher1oodradiofree: yup thanks09:28
*** tiagogomes [] has joined #baserock09:30
*** Krin [] has joined #baserock09:57
ssam2hooray for write extension documentation! thanks petefoth!09:57
petefothssam2: we aim to please ;)09:58
ssam2a lot of patch series in my email catchup that have already been reviewed and merged, in fact! which is a nice start to the day!10:01
straycatmy build failed10:02
* straycat restores balance10:02
straycatand not in the way i expected :(10:02
radiofreepedroalvarez: have you seen [PATCH 0/2] V2: Add generic weston systems (x86 and ARM) to ci server?10:29
pedroalvarezradiofree: looks ok, but do we want it to make it a  first class system? Shouldn't we add other systems we care more about (like the genivi one) first?10:31
radiofreepedroalvarez: would it mean would have cache for mesa etc?10:33
radiofreepedroalvarez: i think the weston system is fundamentally the same as a genivi system10:33
radiofreeweston/wayland-ivi-extension only takes a few minutes to build10:33
radiofreelol "I'm aware of 2 features that we will lose:10:36
radiofree- swrast on Wayland - I'm not sure about this. Perhaps kms-swrast has10:36
radiofreeaddressed this already."10:36
pedroalvarezradiofree: I'm just saying that if we are going to increase the feedback time by adding more systems to the CI, I'd like those system to be systems that we really care about. I'm not saying "-1, don't merge it", I'm just waiting others opinion. 10:38
radiofreepersonally i care more about upstream weston then i do ivi-shell10:39
pedroalvarezbut you have to understand that I care more about ivi-shell one since is the one we  have to do  releases10:39
pedroalvarezand as you said, weston only takes a few minutes to build :P10:40
radiofreeyeah, i also build ivi-extension/weston-ivi-shell constantly, i can be the human CI for that ;)10:41
persiapedroalvarez: I think the interesting part of "systems we care more about" is the definition of "we".  Personally, I'd rather see mesa tested than GENIVI, but that's just me :)10:45
persia(and no reason you can't add GENIVI in a patch as well, if you want CI for it, to ease your release efforts)10:46
pedroalvarezpersia: you can +1 it if you want10:50
pedroalvarezcertainly I'm starting to think that is a good idea, and also this way  we can see how mason behaves when building more than one system10:50
persiaI don't know the infrastructure implications, or I would have done so already :)10:50
persiaI'm not saying you should +1 it, only that I don't know that it is safe to assert a "we" that cares more about one thing than another.10:51
persiaOr at least, without specifying the "we".  For "we" meaning "the release team", I'm sure your statement is accurate :)10:51
pedroalvarezI'm saying "we" because I want a consensus about what we care more about10:52
pedroalvarezI'm not asserting that we care more about the genivi system than the stock-weston one10:52
radiofreethe weston system is actually the genivi system10:54
radiofreeonly difference is the version of weston, so it will build the genivi system as well10:54
radiofreeit's also, IMO, more appealing to outsiders not interested in cars10:54
radiofreewe're stuck at... 1.4.9x of weston with ivi-shell10:54
radiofreealthough patches have just landed to merge for 1.7.010:55
pedroalvarezall right, let's add it to the CI and see how it goes.10:56
radiofreeyay :D10:57
pedroalvarezI think I'm the only one who cares about genivi :)10:57
persiaI thought there were other folk on the release team: at least other folk *used* to do releases once in a while.11:00
* persia doesn't really understand the release team organisation very well, but is happy in ignorance, as this leaves less emotional attachment to the release concept11:00
petefothYesterday straycat reminded me that ‘any of the env vars can be passed on the command line to morph deploy’. I just want to double check that this is true for the OPENSTACK_* parameters in the OpenStack write extension11:03
*** zoli_ [] has joined #baserock11:03
*** zoli_ [] has quit [Changing host]11:03
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock11:03
petefothpedroalvarez: SotK: jmacs: ^^11:03
jmacsI know nothing about Openstack11:03
SotKit is true11:03
petefothjmacs: sorry to have bothered you then :) SotK: thanks11:04
SotKwe advise passing OPENSTACK_PASSWORD on the command line iirc11:04
franredpetefoth, you can do it11:04
persiaI remember having some discussion about this on the mailing list.  There is apparently a partial conversion between some entries on the command line and differing values for reasons I never understood.11:04
*** wdutch [] has quit [Ping timeout: 265 seconds]11:04
petefothfranred: thanks11:04
persiaSo `OS_PASSWORD=mypass morph deploy ....` has a similar meaning to `morph deploy ... OPENSTACK_PASSWORD=mypass`, and it isn't permissible to swap the all-caps entries (despite differing names).11:05
persiaI believe the one *after* `morph` overrides the one before, but with the abovementioned name mangling.11:06
persiaThat all said, one probably should not use OPENSTACK_PASSWORD as a parameter11:06
persiaRather, one should exchange a password with Keystone to get a token, and then pass the token as a parameter11:06
petefothpersia: eeeeeew! That’s not very nice :) 11:07
franredpersia, that remains to the user who do the cluster morphology11:07
petefothpersia: maybe, but unless that’s how it currently works I’m not going to document it that way11:07
persia(using the password on the command line is a fallback, because when there is no token, e.g. glance client will query keystone to get one)11:07
persiapetefoth: That is how it currently works11:07
petefothpersia: OK, then I can add some words to the docs - thanks11:08
persiafranred: Yes, but we should probably document the best practice, rather than the known insecure one11:08
petefothpersia: I think we should provide full and accurate documentation, with appopriate recmmendations11:09
franredpersia, I though you need user-password for keystone give you the token, so all the other services/clients will know that you are logged11:09
franredso you also do not need the token (not sure, but I think adding the token to the parameters is getting deprecated as far as I can see in the messages from keystone.middleware) but I can be wrong11:11
SotKhas someone made sure that `OS_PASSWORD=foo morph deploy...` works before we document doing it that way?11:12
persiapetefoth: I can agree with that.  Note that 99% of OpenStack users just copy the rcfile from Horizon into their environment, so are entirely unaware of the authentication model (and would not use any of these in either the command line or the cluster morphology)11:12
* SotK would expect morph to complain about OPENSTACK_PASSWORD not being provided11:12
persiafranred: All services *except* Keystone require a token for authentication11:13
pedroalvarezSotK: true!11:13
persiaSotK: I think we quelled that spurious error.  If not, we ought.11:13
SotKyes, openstack.check still raises cliapp.AppException if any of the OPENSTACK_* variables are not present11:14
petefothI think the approach we should take is that I will documnent what currentlky happens (and hopefully works). IF we then decide we need to change, we can work on a patch which moodifies the impelmentation *and* the docs at the same time11:14
SotKpetefoth: +111:14
pedroalvarezmakes sense to me11:15
franredpersia, I will have a look at it once again11:15
persiapetefoth: Heh.  OK.  If our practices happen to be so deviant from normal, then I agree you should document baserock practices, rather than typical OpenStack practices (but this probably represents a bug)11:18
SotKa simple fix would be to call the variables OS_* rather than OPENSTACK_*?11:18
SotKthat way both workflows will allow a successful deployment11:19
*** straycat [] has quit []11:19
* SotK wonders why they weren't called that in the first place11:19
petefothI like the idea of ‘moodifying’ our SW - turning it into a teenager prone to sulks and sullen unco-operativeness :)11:20
persiaIn the thread where this was discussed a while back, it was to distinguish the morph configuration variable names from the environment variable names, which was intended to reduce confusion.11:20
SotKit doesn't seem like confusion has been particularly reduced by this11:23
*** wdutch [] has joined #baserock11:23
jjardonpedroalvarez: radiofree \o/ thanks, this is a HUGE improvement!!11:26
petefothIf anyone is happier reviewing juts the text of rather than the full patch set, it can be found at
richard_mawpetefoth: biff11:30
radiofreejjardon: pedroalvarez reviewed it :\11:31
jjardonradiofree: yeah, both you and him11:32
radiofreeyou put richard in the merge though11:33
jjardonabout the NETWORK_CONFIG problem: Any opinions about what I suggested yesterday: to pass the configuration directly in the native format, so no script is needed, similar how coreos does:
jjardonoops, sorry pedroalvarez, richard_maw It will not going to fix it but I will make clear by email who review it11:36
radiofreehow come the arm mason stays red for so long?
radiofreebecause the changes haven't reached the trove it's using yet?11:37
SotKI think that is the reason11:37
radiofreeyes, ERROR: Ref 778f4b6a95dc3510d9d2d70866d5142691da1a78 is an invalid reference for repo git://
persiaWhy does it use a different trove again?11:37
radiofreehow come the x86 mason doesn't have that problem?11:38
radiofree is a flawless sea of green11:38
radiofreepersia: distbuild i think11:39
radiofreeneeds to push temporary build branches11:39
persiaOh, right.11:39
SotKthe arm mason uses the jetson cloud distbuild network, which is using a different trove to the distbuilds that are deployed with the x86 masons AIUI11:39
persiaCan that be fixed, or does it break something if fixed?11:39
SotKpedroalvarez knows about this maybe?11:39
radiofreeah, so x86 mason is not a distbuild and uses gbo directly?11:39
persiaWait, right, the x86 distbuilds also do the same thing, so why can't ARM use the same trove?11:39
radiofreepersia: might not be distbuilding on x86?11:40
radiofreein which case it can use gbo directly11:40
radiofreemaybe mason can force the trove mirror when it sees there's an update to gbo definitions?11:41
radiofreebefore building11:41
pedroalvarezI'm going to try to explain this11:41
*** CTtpollard [] has joined #baserock11:42
radiofreeit took 43 minutes between definitions being updated an it working last time!11:42
pedroalvarezx86 mason is also a distbuild network. This distbuild network is using g.b.o directly, because we know that it's always building branches (master) that are already in g.b.o, so this distbuild doesn't need to push temporary branches ever.11:43
pedroalvarezwith the jetsons we are using a different trove for the sources, so we can use it to build things that require a temporary build branches, i. e., things that haven't been pushed11:44
pedroalvarezI'll be ok with using g.b.o directly, but I don't know all the implications11:45
pedroalvarezradiofree: yeah, it can take 2 hours11:46
*** petefoth [] has quit []11:46
*** petefoth [] has joined #baserock11:46
radiofreewe need two jetson distbuild networks then!12:07
radiofreeone for mason (uses gbo) and another one for doing test builds!12:07
pedroalvareznote that I'm of the opinion that we could use g.b.o also for test builds12:08
persiaI'd rather not clutter those repos, because the build commits make my visualisation tools unhappy.12:09
persiaIs there a way to cause distbuild not to push temporaries, if it is only building known commits?12:10
persia(and to force folk to only distbuild things available from a public git server)?12:10
pedroalvareziirc it doesn't push anything that is already in the trove12:10
pedroalvarezah, you mean to not push temporary branches ever? I don't know :/12:11
persiaOr is it possible to have the target configurable on a per-run basis, so that random people distbuilding on the internet get sent to one place, and those who pass some magic authentication token can (avoid) pushing to g.b.o?12:11
persiaI'd be very happy with "never push any temporary branches", but it means that folk always have to push stuff before distbuilding, which breaks some workflows.12:12
persia(or it requires a new and different distbuild)12:12
radiofreecould you not just push the branches to the controller?12:13
pedroalvarezradiofree: all the workers need the branches, not just the controller12:14
persiaThat requires modifications to distbuild12:14
radiofreepedroalvarez: yeah12:14
radiofreerather then git clone TROVE_HOST/my-temp-build-branch it'd be git clone CONTROLLER/my-temp-build-branch12:14
persiaPerhaps we could just not give any of the workers or the controller keys that have write access to g.b.o?12:14
persiaSo if they try to write, it fails, and it all falls down, but if the commit is already present, everything works?12:14
radiofreepeople would get mad12:15
pedroalvarezhm.. I think that the initiator would be the one that pushes to  g.b.o, not the controller12:15
radiofreealthough if you made the error message clear (would be novel for distbuild) it might be ok12:16
persiaSadly, the configuration is such that the value of SOMEWHERE happens to be defined in the distbuild network configuration, rather than the caller configuration.12:19
persiaAs a result, one ends up telling users "NO PONY FOR YOU", rather than "GO DO THIS SENSIBLE THING"12:20
* radiofree hopes paulsher1ood didn't forget the psu for his jetson12:24
radiofreewould that work though, having the controller act as the temporary git server?12:27
radiofreeobviously need some changes, but would be equivalent right?12:27
pedroalvarezradiofree: then you have to have push access to the controller git server12:28
radiofreedon't the workers already have that?12:29
radiofreeoh right i see what you mean12:29
pedroalvarezI don't know all the implementation details of distbuild though12:29
radiofreewell it's the controller that pushes the temp build branches right?12:29
pedroalvarezI think that is the initiator12:30
persiaI think that someone should dit down and draw up the architecture, and we should debate it again.12:32
pedroalvarezI agree12:32
persiaThis many confused folk means that something is conceptually wrong12:32
pedroalvarezhere we go! A greener than green feedback!
radiofreeand maybe look at distcc again?12:34
*** locallycompact [] has quit [Ping timeout: 256 seconds]12:34
persiaradiofree: distcc doesn't solve the same class of problem, but perhaps can be part of a solution.12:35
radiofreecertainly for things like Qt it would be really nice12:35
radiofree"we're not using any other workers because we're waiting for this to be built first... distcc it"12:37
*** straycat [] has joined #baserock12:49
straycatfranred, I think your build will be fine12:49
Kinnisonradiofree: distcc is difficult unless you can build into the definitions an understanding of when it becomes available12:49
petefoththe file morph/morphlib/plugins mentions 5  values for type: tar, rawdisk, virtualbox-ssh, kvm and nfsboot. I suspect we need to add ‘openstack’ as a type. Can anyone offer some words to complete the following sentence ‘* `openstack` where Morph…’?12:49
Kinnisonradiofree: and of course, the distributed build stuff then needs to be able to construct appropriate system roots12:50
franredstraycat, you mean with the change on setup_tools?12:50
* petefoth know sqrt(very_little) about OpenStacck12:50
pedroalvarezpetefoth: there are even more values now12:50
straycatfranred, yesh the problem seems to be that for whatever reasons pbr with setuptools fails to obtain the dependencies it needs: it doesn't have pbr so it can't process itself.12:51
radiofreeKinnison: could you recreate the same build root on each worker, then run the distcc server in the chroot?12:51
straycatIf I install keystone's dependencies myself (using pip install) then the problem goes away.12:51
petefothpedroalvarez: why doesn’t that surprise me? :) 12:51
straycatThis also explains why the morph build I ran didn't fail, because the morph build already has all the dependencies12:51
Kinnisonradiofree: You could, but it'd need to be a conscious effort to donate that worker's time to that particular build, because building up/tearing down those would be more expensive than you'd like if you wanted to do it more than once during a build cycle12:51
petefoth‘Documentation out of step with the code: shock!’12:52
franredstraycat, that also explain why I can not remove pip or pbr from my strata12:52
petefothpedroalvarez: so ssh-rsync and initramfs are the oither missing types?12:53
robtaylorKinnison: ah, turns out is by the same guy as sprunge.us12:53
radiofreeKinnison: good point, for most things the current setup is fine, maybe there could be something in the chunk to say "distcc" this12:53
petefothAny others?12:53
radiofreeit would have a massive benefit for the really big stuff, like qtbase12:54
pedroalvarezimage-package.write pxeboot.write  sdk.write12:54
pedroalvarezthey are in definitions.git. not sure if we should document them as well12:54
petefothpedroalvarez: they don’t have their own write extennsions in morph though?12:56
pedroalvarezthis is because morph deploy can  use write extensions from morph.git and from definitions.git (or in whatever repo your definitons are)12:57
petefothpedroalvarez: OK. I may neeed to split my ‘Documentation for write extensions’ task up a bit further then13:00
petefothActually, there’s a good help file for pxeboot.write which could maybe do with formatting to match the others, but I guess that is low priorrity. And image-package.write has lots of help in comments which I can easily move to a write.help13:04
petefothI could still dop with some words about openstack deployment type though, as in my original question: “Can anyone offer some words to complete the following sentence ‘* `openstack` where Morph…’?”13:05
pedroalvarezpetefoth: can you give me an example with kvm and I'll try to make the openstack one?13:08
petefothpedroalvarez: vbssh is ‘“`virtualbox-ssh` where Morph creates a VirtualBox disk image, and creates a new virtual machine on a remote host, accessed over ssh.” and kvm is “’`kvm`, which is similar to `virtualbox-ssh`, but uses libvirt          and KVM instead of VirtualBox. “13:10
pedroalvarezopenstack: where Morph creates a raw disk image and deploys it to an OpenStack host using Glance13:12
petefothpedroalvarez: perfect - thanks. 13:14
petefothsimilar words for image-package pxeboot sdk initramfs would be very welcome from anyone who knows anything aboput them13:14
petefothand ssh-rsync13:16
*** zoli_ [~zoli_@linaro/zoli] has quit []13:31
*** zoli_ [] has joined #baserock13:33
*** zoli_ [] has quit [Changing host]13:33
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock13:33
Kinnisonradiofree: Mmm if a chunk could say "I'm very compile-intensive, it's worth dedicating extra workers to me" that oculd be useful13:59
richard_mawit's be better if we could have a heuristic to determine which builds are likely to be slow, so we should use distcc to parallelise further, rather than using those other nodes for building other chunks in parallel14:03
franredhow can I check what I have inside of my system before deploy it? I know that we have a system cache artifact which I can zcat and look for what I want to check if it is inside... but which artifact is my system?14:04
pedroalvarezI normally use tar -tvf ...14:05
richard_mawfranred: after you do a build it should list the path to the file14:05
richard_mawif it doesn't, you can try passing --verbose14:05
franredpedroalvarez, richard_maw, cheers14:17
straycatssam2, hey, would you prefer me to send my import branch for review when i'm ready?14:25
*** franred [] has quit [Quit: Leaving]14:26
*** franred [] has joined #baserock14:27
*** tiagogomes [] has quit [Ping timeout: 258 seconds]14:29
ssam2straycat: It'd be helpful to send for review, I think14:30
ssam2straycat: although are you on holiday from next week ? if so I guess any comments I have will need to also be fixed up by me as well ;)14:31
straycatyeah i might not be around for a month or so, and i'll be working on other stuff probably14:34
ssam2ok. not a problem14:38
straycatokay i'll send for review once i've done a bit more testing14:49
straycatif first reviews are quick then i can probably get the fix ups done 14:50
radiofreeKinnison: richard_maw: sorry was out at lunch14:52
radiofreesome heuristic would be nice, but that sounds scary and complicated compared to a simple marker in the chunk :\14:52
*** tiagogomes [] has joined #baserock14:53
franredwhere do live the logs for the built chunks?14:53
persiafranred: Locally, they are stored in the same cache directory as the artifacts14:55
persia(with a similar name, so if you know the name of the artifact, you can deduce the name of the log)14:55
persiaFor non-local builds, I have no idea14:55
straycatfor non-local builds you get the build logs put in your workspace14:56
persiaIn the workspace directly?  At what location?14:57
straycatyour cwd iirc14:57
straycatOr maybe ssam2 changed it to something else, not sure.14:58
pedroalvarezI believe that still is the current behavior14:59
ssam2I didn't change that15:21
straycatahh, so the cache is on port 8080 >.> i probably should have realised that sooner <.<15:39
straycatdo we have anything on the wiki about that?15:40
pedroalvarezstraycat: I believe so15:40
straycatok cool15:40
pedroalvarezstraycat: found it on:
pedroalvarezrichard_maw: following your suggestion of using a context manager I've implemented this:
pedroalvarezdoes the latter make more sense than the former?15:45
straycatahh that's so good15:46
richard_mawhow does create_raw_disk_image get the location?15:46
pedroalvarezIt opens a file using `with open...` and then writes `'\0's15:47
richard_mawyes, but how does it know where to write it? raw_disk is undefined15:48
pedroalvarezoh yeah, raw_disk should be location15:48
richard_mawbtw, the former is better than the latter, since if the former raises an exception too early, location might not be a disk image, so the unlink can fail and trample the useful exception message15:48
richard_mawalso, you're supposed to name your context managers so it reads like `with a_created_disk_image(location):`, though we don't usually bother with the a_15:50
pedroalvarezthat is a good tip15:51
richard_maw`with create_diskimage(location):` doesn't read as nicely15:51
richard_mawthere's a lot of exceptions to this trend in the python standard library, since a lot of functions have had context managers added afterwards15:52
richard_mawpedroalvarez: those sound like they should return a boolean, but I lack sufficient understanding of the english language to describe why15:53
* richard_maw goes to look up the PEP15:54
straycatbecause disk image created has a subject and a verb, it's not just an object15:56
richard_maw    The tense used in the names of the example contexts is not15:58
richard_maw    arbitrary. Past tense ("-ed") is used when the name refers to an15:58
richard_maw    action which is done in the __enter__ method and undone in the15:58
richard_maw    __exit__ method. Progressive tense ("-ing") is used when the name15:58
richard_maw    refers to an action which is to be done in the __exit__ method.15:58
richard_maw for the interested15:59
pedroalvarezok, this is done in the __enter__ but not undone in the __exit__16:00
richard_maw@contextlib.contextmanager makes everything after the yield part of the __exit__16:01
richard_mawcreated_cleaning_up_on_error_disk_image is a bit of a mouthful though, so I'd just stick with created_disk_image16:02
*** fay_ [] has quit [Remote host closed the connection]16:03
richard_mawfor the tempfile stuff they have a parameter to specify whether to cleanup on exit, but this is because it serves as both a temporary file, and a file that you are working on, and will move into place later16:06
*** genii [~quassel@ubuntu/member/genii] has joined #baserock16:30
*** mauricemoss_ [] has quit [Quit: Leaving]16:39
*** CTtpollard [] has quit [Ping timeout: 255 seconds]16:57
*** wdutch [] has quit [Ping timeout: 272 seconds]16:58
* straycat finds one more package that fails to import17:07
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]17:09
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock17:10
*** wdutch [] has joined #baserock17:11
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer]17:18
*** zoli_ [] has joined #baserock17:19
*** zoli_ [] has quit [Changing host]17:19
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock17:19
straycatOkay well this particular package is using disribute a deprecated setuptools fork, so I guess we shouldn't worry about failing to import packages that are using deprecated stuff17:22
straycatOh wow, finding dependencies here involves compilation, yay17:31
straycatand now instead of a list of dependencies I just have some zombie python processes :/17:40
*** Krin [] has quit [Remote host closed the connection]18:03
*** bashrc [] has quit [Quit: Lost terminal]18:08
*** jonathanmaw [] has quit [Quit: Leaving]18:16
*** tiagogomes [] has quit [Ping timeout: 240 seconds]18:18
*** wdutch [] has quit [Quit: Quit]18:22
*** ssam2 [] has quit [Remote host closed the connection]18:25
*** cosm [] has quit [Ping timeout: 245 seconds]20:48
*** cosm [] has joined #baserock21:03
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]21:33
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock21:56
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]21:58
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer]22:00
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock22:02
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]22:02
*** zoli_ [] has joined #baserock22:06
*** zoli_ [] has quit [Changing host]22:06
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock22:06
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]22:09
*** zoli_ [] has joined #baserock22:18
*** zoli_ [] has quit [Changing host]22:18
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock22:18
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection]23:31
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock23:31

Generated by 2.15.3 by Marius Gedminas - find it at!