IRC logs for #baserock for Friday, 2015-05-22

*** zoli__ has joined #baserock07:09
*** edcragg has joined #baserock07:13
*** a1exhughe5 has joined #baserock07:15
*** Albert has joined #baserock07:29
*** paulw has joined #baserock07:32
*** mariaderidder has joined #baserock07:55
*** jonathanmaw has joined #baserock08:01
*** bashrc has joined #baserock08:04
*** gary_perkins has joined #baserock08:10
pedroalvarez<SotK> I'm seeing an error from Babel when I try to get a list of the running jobs from Zuul:
pedroalvarezI hit the same error yesterday08:23
pedroalvarezSotK: do you have any plan?08:23
SotKI didn't formulate a plan, and I no longer have time to do so for a while I'm afraid :(08:24
SotKI was probably just going to commit the zip file or something08:25
straycat        if['upgrade']:08:27
straycat            raise cliapp.AppException(08:27
straycat                'Running `morph upgrade --upgrade` does not make sense.')08:27
* straycat doesn't really see the harm in accepting upgrade --upgrade08:27
* SotK thinks we should get rid of one of the two paths, but I don't mind which08:28
straycatyeah it's a ui thing that i don't really have an opinion on, personally i use deploy --upgrade08:29
SotKme too08:29
SotKbecause in my head I'm "deploying an upgrade"08:30
pedroalvarezthe few times I try an upgrade I always do `morph deploy`08:56
*** ssam2 has joined #baserock09:00
*** ChanServ sets mode: +v ssam209:00
straycatssam2, - short paste of discussion you just missed, which you might have an opinion on09:06
ssam2thanks for that09:07
ssam2I don't really have a strong opinion, some people seem to prefer one and some the other09:08
ssam2accepting `morph upgrade --upgrade` may be harmless, catching stuff like that can be helpful though because it may be a sign of a user mis-paste or something09:09
* straycat isn't against keeping both deploy --upgrade and upgrade09:10
richard_mawmerry systemd release everyone09:11
richard_mawwe can actually use a released version in our OpenStack now09:11
* richard_maw is just a bit annoyed that he couldn't get any patches to sort out the nspawn command-line parsing in in time09:12
* richard_maw is saddened that it can't handle file paths with : in for bind mounts or overlayfs mounts, and overlayfs mounts can't handle anything with a , in09:13
ssam2SotK: is how to use `morph deploy --partial` documented anywhere ?09:13
SotKssam2: I thought I'd documented it in `morph help deploy`, but I may well be mistaken09:14
SotKI didn't, because I'm an idiot :)09:16
SotKI think then that the only documentation is the brief instructions in the commit message (
ssam2a section at would be really useful!09:17
SotKsure thing09:18
*** lachlanmackenzie has joined #baserock09:19
*** Krin has joined #baserock09:38
pedroalvarezOk, Babel needs Unicode CLDR to be built, and they suggest to run `python import_cldr` wich downloads a zip, uncompress it and then imports the files needed09:47
pedroalvarezI was going to just commit the zip file, but it looked ugly09:47
pedroalvarezI think I can make CLDR a submodule, so that I don't need to put a zip in the repo, would that be ok?09:48
SotKthat sounds sensible to me09:48
ssam2Sotk: thank you!!09:48
franredpedroalvarez, sounds ok to me09:51
* richard_maw submitted and to deal with some interesting corner cases in subsystem deployment09:51
pedroalvarezSotK, franred: Although the CLDR svn repo is going to be too big just to solve this case :/09:59
pedroalvarez150M so far, and it's still lorrying 200510:02
pedroalvarezshould I go and lorry the CLDR tarball? or should I just commit the files needed into babel?10:03
pedroalvarezor just lorry the babel tarball?10:03
ssam2do you have any idea how often the tarball changes?10:04
ssam2one of the main issues with tarballs is we have to manually update them10:04
ssam2but if it changes rarely, that's no issue10:05
pedroalvarezevery 3 months10:06
ssam2ok. seems reasonable to have a tarball of it then10:07
pedroalvarezI'm starting to dislike my CLDR as submodule idea10:07
*** Krin has quit IRC10:12
*** Blacksnow has joined #baserock10:13
pedroalvarezgrrr.. lorry tarball import doesn't have 'zip' support10:40
Kinnisonzips are not streamable10:42
pedroalvarez-pPrint to stdout10:43
Kinnisonthe converter is a stream converter from tarball to git-fast-import stream10:43
* pedroalvarez sighs10:43
Kinnisonif you have a tool which converts a zip to a tar stream, we could add support10:43
Kinnison(without unpacking)10:43
franredpedroalvarez, ....svn.... :/10:44
pedroalvarez250M to get cldr data to fix babel build, doesn't sound too nice to me10:44
pedroalvarezcommiting a zip file into babel repo neither10:44
straycatDavePage, rjek, others, I'm planning to lorry in a bunch of cpan modules from gitpan so we get their history, couldn't find an obvious upstream repo for most of them, does this seem reasonable?10:45
pedroalvareztarball import of babel?10:45
franredummm, we are importing a lot of tarballs lately when one of our aims are building from source...10:46
franredand not rely in other people builds, AFAIK10:46
*** fay__ has quit IRC10:47
pedroalvarezfranred: then, what do you reckon is the best solution?10:47
pedroalvareznote that with a tarball import we still build from source10:47
*** fay_ has joined #baserock10:48
DavePageThe solution is to get all upstreams to use publically-accessible git with proper tags ;)10:48
straycatthat doesn't really seem to happen with cpan stuff, from what i've seen?10:48
franredpedroalvarez, I don't see the problem with the 250 M of svn repo, tbf10:49
straycatalright, lorrying from GitPan unless someone suggests something better10:50
pedroalvarezfranred: the problem with tath solution is that I still need to tweak babel.git to have the cldr repo as a submodule10:51
pedroalvarezs/tath/that/ :)10:51
Kinnisonpedroalvarez: Sadly, right now, there's not much of a better option10:51
pedroalvarezKinnison: I take that you think that lorrying the svn repo, and tweaking babel to get cldr from there is a better option than commiting the files needed into babel10:52
KinnisonUnless cldr rarely moves, yes10:53
pedroalvarezcldr releases every 3 months10:54
pedroalvarezcldr version used in babel hasn't changed ever10:54
pedroalvarezlie, it changed 2 years ago10:55
Kinnisonhow often does babel change?10:55
pedroalvarezlatest release 22 months ago10:56
pedroalvarezlatest change in master 12 months ago10:57
KinnisonThat's on the boundary10:57
KinnisonI can't recommend the lorrying approach becauase it's not changing a lot, nor can I recommend the 'add the files' approach because it clearly does change10:57
KinnisonGo with your gut10:57
* Kinnison <- least useful helper today10:58
pedroalvarezKinnison: it was useful :)10:58
* Kinnison shall have to try less hard10:58
*** bfletcher has left #baserock11:12
*** bfletcher has joined #baserock11:12
*** pacon has joined #baserock11:17
*** zoli___ has joined #baserock11:32
*** zoli__ has quit IRC11:32
pedroalvarezOk, i think this is the easiest approach:
ssam2seems reasonable11:55
*** Blacksnow has quit IRC12:15
*** Blacksnow has joined #baserock12:19
jonathanmawis there any way to make `morph deploy` more verbose? It seems to be hanging for me.12:32
SotKjonathanmaw: Does --debug or --verbose help?12:32
SotKIf it's hanging during an extension being run I don't think they will help though.12:33
jonathanmawhrm, --debug hasn't helped much, not seeing anything new when it gets to 'Populating "orig" subvolume', which is where it hangs12:34
SotKthat step can sometimes take a while, how long was it stuck for?12:35
jonathanmawI left it running over lunch at one stage, though the target may have been too small tha ttime12:35
jonathanmawdeployment has been running for at least 12 minutes, with no signs of activity on the target12:46
jonathanmawi.e. no sign of increased disk usage12:46
SotKwhat deployment type is it?12:46
jonathanmawssh-rsync upgrade12:46
jonathanmaw`ps -ef` indicates that it's in the middle of an rsync command-line12:53
straycatssam2, good spot, sorry about that (ssh_runcmd)13:10
franredpedroalvarez, it is not ideal, but meh13:10
franredpedroalvarez, go ahead with it13:11
pedroalvarezfranred: svn lorry is taking 1h and 30m already13:11
franredo.O no comments (and they are only xml files as far as I saw)13:12
tiagogomes_pedroalvarez what are you snv'ing? Are you using trunk?13:12
* pedroalvarez is tempted to maintain some git mirrors of some projects13:13
pedroalvareztiagogomes_: unicode cldr, trunk, branches, and tags13:13
pedroalvareztiagogomes_: note, I'm converting it to git, using lorry13:14
tiagogomes_pedroalvarez have you tried to lorry only trunk and the branch/tag that you need?13:15
pedroalvareztiagogomes_: I haven't, because when I think of lorrying svn repos, I think that we should lorry everything13:16
tiagogomes_If they occupy 400Mb and still haven't finished, maybe that's not a good idea13:18
*** pacon has quit IRC13:19
*** a1exhughe5 has quit IRC13:24
*** a1exhughe5 has joined #baserock13:29
*** zoli___ has quit IRC13:34
*** franred has quit IRC13:42
*** franred has joined #baserock13:57
straycatssam2, biff13:59
*** zoli__ has joined #baserock13:59
*** mariaderidder has quit IRC14:02
*** a1exhughe5 has quit IRC14:04
radiofreewhat happens when your patch has two +1's on gerrit?14:06
richard_mawit hsa two +1s on gerrit, not a lot else14:07
richard_mawthe plan is for Zuul to then test and if that passes +2 and merge14:07
richard_mawcurrently the set of mergers need to review patches that have two +1s and decide whether to +2 and merge14:07
radiofreeah ok14:08
edcraggis it OK to use URLs for repositories used in definitions where not available on g.b.o, or are they supposed to all be lorried?14:09
KinnisonIf it's for definitions aimed at g.b.o's baserock:definitions then we prefer everything be lorried14:09
KinnisonIf it's for something else, there's no need to pre-lorry14:10
edcraggKinnison: but aren't all definitions going to end up on baserock:definitions?14:12
KinnisonNot necessarily -- e.g. the baserock infra definitions don't14:13
edcraggah, ok14:13
*** mariaderidder has joined #baserock14:17
*** a1exhughe5 has joined #baserock14:18
straycatradiofree, take it is tested?14:25
Zarabit confused-- I made a system that was just 'build-essential-minimal' on x86 and on an armv5 chroot (cross bootstrap system on jetson). on x86, can deploy with a size of 16M (btrfs doesn't let me go smaller). on armv5, need at least 80M.14:43
pedroalvarezis this minimal system identical?14:44
ZaraI'll pastebin, the names are different but I doubt that'd make a difference :P14:45
Zara vs
Zaraso different arch, but otherwise seem identical at the system level14:46
pedroalvarezZara: hmm no idea14:47
pedroalvarezyou can take a look at the rootfs artifact of both and see what's inside14:47
Zaraokay, how would I do that? (I also checked the build-essential strata; they look the same)14:52
pedroalvarezif you build the system, morph will tell you the where its rootfs artifact is14:55
pedroalvarezyou can uncompress that, and look inside14:55
pedroalvarez(I don'k know a better way for getting the artifact name of the rootfs)14:56
SotK`morph list-artifacts . HEAD $system | grep *.system.*` in your definitions checkout14:56
Zaraokay, I'll have a look around, thanks :)14:57
SotKlist-artifacts may print the rootfs name last anyway actually, not sure though14:57
*** Albert has quit IRC15:00
Zarahehe, already I can see that one compressed rootfs is 71.0M, the other is 6.6M15:00
straycatssam2, biff, again (reworks)15:07
*** fay_ has quit IRC15:07
Zarahow do I uncompress the rootfs artifact?15:08
*** Albert has joined #baserock15:08
SotKZara: `tar -C $uncompressed_location -xf $artifact_path`15:09
Zaraah, I was trying tar -xzvf without success15:09
Zarait told me 'invalid magic' which wasn't helpful15:09
flatmush"magic" is the identifier at the beginning of a file15:10
flatmushwhich means the tar file is either corrupt or not a tar file15:10
DavePageOr in this case, not a zipped file?15:10
SotKZara: you don't need the z, I don't think we use gzip on them15:10
DavePageI think invalid magic means you need more of richard_maw's hat15:11
richard_mawDavePage: you say that like I only have 1 wizard hat15:11
Zaraah, tar -xf worked (I'd already cd'd to the directory I wanted it). Thanks for the explanations!15:12
Zarausr is the culprit! :0 will pastebin output of du -h because this might  warrant further investigation15:18
*** a1exhughe5 has quit IRC15:18
DavePagerichard_maw: Maybe you could lend one to Zara15:19
Zarax86: armv5:
pedroalvarezshe is doing pretty well without any hat :)15:20
pedroalvarezZara: I'd like to see what's inside /usr/bin and /usr/lib15:21
pedroalvarez(and their size)15:22
pedroalvarez`ls -alh /usr/bin`15:22
Zaraokay, these are both off the bigger system since that seems to be the weird one: usr/bin:    and usr/lib:
richard_mawZara: which two morphologies are you using?15:28
richard_mawbecause your usr/bin contains parts of gcc15:29
Zararichard_maw: if you mean which strata, it should just be build-essential, but I'm not sure which morphologies you mean15:31
richard_mawI mean the system morphologies, it's the minimal.*armv5l vs x86 right?15:31
Zararichard_maw: no, this is a customised system that should *only* build build-essential (so I don't expect the end product to work or anything)15:32
richard_mawwell, for minimal, you also need to list `artifacts:\n-build-essential-minimal` in your system morphology15:33
richard_mawotherwise it includes gcc15:33
Zara15:46 < Zara> vs15:33
Zarathere they are :)15:33
richard_mawbut you're doing that15:33
Zarayeah, I was wondering if this could be some cross-bootstrap weirdness which is making it ignore artifacts being specified, since the size of the bigger one looked like the size of the smaller one before I remembered to list artifacts.15:35
*** Albert has quit IRC15:35
richard_mawcross-bootstrap is not expected to produce a minimal system15:35
richard_mawok, your libs are understandable if unfortunately large, but your bins includes stuff from binutils15:35
richard_mawI can only assume that it's cross-bootstrap not handling artifact splitting that's causing your result to contain binutils15:37
*** petefoth_ has joined #baserock15:40
Zarayeah, I'm building in a devel system that was originally created via cross-bootstrap so that sounds probable15:41
*** petefoth has quit IRC15:41
*** petefoth_ is now known as petefoth15:41
paulsherwoodException Exception AttributeError: "'NoneType' object hasAttributeError no: " at'NtronibeTutype e''p oatbjh'ec" in t h<function _remove at 0x7f2997cec758> ignored15:52
Zararichard_maw: why would the libs be so big, ooi? on the x86 system those are also much smaller, so I'm guessing those are where the armv5 arch makes things bigger15:52
paulsherwoodi assume that means i've recursed out of memory someohw?15:52
rjekpaulsherwood: It looks like a threading race condition!15:52
rjekOr perhaps part of the error is in Klingon?15:53
Zararichard_maw: (output for x86:
*** CTtpollard has quit IRC15:54
richard_mawZara: you can have bigger libs on arm because x86 has more support in the cpu for those operations15:56
richard_mawe.g. division15:56
ZaraI see-- though they just seem so *much* bigger I'm suspicious (120K vs 15M)15:59
*** jonathanmaw has quit IRC15:59
pedroalvareztiagogomes_: biff
tiagogomes_pedroalvarez that happens when you copy from one with wrong indentation as well16:01
pedroalvarez:) yes, the same has happened to me when copying from others16:01
pedroalvarezwow, straycat fixed it, thanks!16:04
*** mariaderidder has quit IRC16:28
*** franred has quit IRC16:30
*** Blacksnow has quit IRC16:47
ZaraI don't know enough about what libs should be in here, but I'm wondering if there are some extra things here, too. will look into it some more on Tues16:57
Zara(biggest ones: )16:58
Zarasome of these look suspicious to me. :P17:00
*** bashrc has quit IRC17:00
*** tiagogomes_ has quit IRC17:23
*** ssam2 has quit IRC17:43
*** gary_perkins has quit IRC18:03
*** edcragg has quit IRC18:08
*** lachlanmackenzie has quit IRC18:26
*** pacon has joined #baserock23:58

Generated by 2.15.3 by Marius Gedminas - find it at!