IRC logs for #baserock for Tuesday, 2015-03-31

*** zoli__ has quit IRC04:32
*** zoli__ has joined #baserock04:32
*** zoli__ has quit IRC05:52
*** zoli__ has joined #baserock05:52
*** zoli__ has quit IRC05:55
*** zoli__ has joined #baserock05:55
*** zoli__ has quit IRC05:57
*** zoli__ has joined #baserock05:57
*** zoli__ has quit IRC05:58
*** zoli__ has joined #baserock05:59
*** zoli__ has quit IRC06:25
*** zoli__ has joined #baserock06:34
*** zoli__ has quit IRC06:41
*** zoli__ has joined #baserock06:41
*** zoli__ has quit IRC06:44
*** mike has joined #baserock07:00
*** mike is now known as Guest3538407:00
*** Albert_ has joined #baserock07:07
*** Albert_ has joined #baserock07:08
*** rdale has joined #baserock07:54
*** mdunford has joined #baserock07:55
*** mdizzle has joined #baserock07:56
*** bashrc has joined #baserock07:58
*** a1exhughe5 has joined #baserock07:59
*** jonathanmaw has joined #baserock08:07
*** tiagogomes_ has joined #baserock08:29
*** ssam2 has joined #baserock08:33
*** ChanServ sets mode: +v ssam208:33
*** gary_perkins has joined #baserock08:45
*** CTtpollard has joined #baserock08:49
*** edcragg has joined #baserock08:55
edcraggrichard_maw, pedroalvarez, franred, jmacs, Kinnison, fay_,  a1exhughe5:
edcraggpaulsherwood: 15:58:12 [Build 21/411] [gcc] Elapsed time 00:08:4109:04
radiofree8 minutes! Nice09:05
SotKjjardon: I had a bit more of a look this morning whilst eating breakfast/waiting for my landlord's phones to open, and discovered that mesa-common and wayland-generic needed to be added to the system morphology. When I left I had an unusable desktop displaying!09:06
*** wschaller has joined #baserock09:07
richard_mawedcragg:  #    error "No LG_QUANTUM definition for architecture; specify via CPPFLAGS"09:07
SotKIts unusable because fonts are either missing or not rendering properly, so that't my job for tonight.09:08
richard_mawno architecture support09:08
ssam2SotK: do all the fonts show as squares? might need to run fc-cache09:08
bashrcwhen making a system is there any way to know which strata are mutually incompatible?09:08
persiabashrc: Only be trying a build.  The overlay rules probably keep it unclear until testing the built system.09:09
SotKssam2: thats what happens09:09
SotKI'll try that tonight09:09
bashrcdoesn't that limit the user's options?09:10
jjardonSotK: pang of query modules > /use/etc/pango.modules09:10
persiabashrc: No, rather expands them, as the only limitations are those experienced in testing, rather than there being some imposed by metadata.09:10
bashrcwell to make some remix the user would need to laboriously test build the combinations09:11
persiaThis is also true for package-based systems, where the metadata implies conflicts.  Worse, the metadata may be wrong, which is a huge source of irritation for system builders.  Especially when it is wrong for convenient pragmatic reasons related to a distribution.09:12
SotKAnyone got time to see whats wrong with Mason?09:24
ssam2SotK: at a guess,'s /home disk is full again. thanks for raising it09:30
ssam2i'll look at it in a bit09:30
pedroalvarezssam2: yes, you are right. I've removed some artifacts09:32
pedroalvarezfree diskspace info is actually public09:34
*** zoli__ has joined #baserock09:44
pedroalvarezedcragg: what are you going to do with redis then?09:47
pedroalvarezI don't think we need it09:47
*** zoli__ has quit IRC09:49
straycatperryl, seems i wrote the section for build-request that uses a randomly generated id10:00
straycatI don't think it's a good method10:00
straycatit would surely be better to use the IdentifierGenerator?10:00
perrylif IdentifierGenerator is meant to be a unique process, or at least moreso than random_id i think it would be a better option10:01
ssam2straycat: thinking about this, the IdentifierGenerator might not be a great idea because every ID will be 'Initiator-1'10:01
straycatoh this is in the initiator10:02
ssam2if I remember right, IdentifierGenerator increments each time its used, but for list-jobs and build-request it'll be only ever be used once in a process10:02
straycatthat will be why i didn't use it10:02
*** wschaller_ has joined #baserock10:06
straycatwe could possibly maybe just use the repo,ref,morphology triplet or a hash of it as the request id, might involve more code changes. or we could write something so that initiators make requests for build request ids from the controller10:07
perryli think the latter may be best, it has to be something unique to each build10:09
*** wschaller has quit IRC10:10
persiaCan we reuse the cacheid for this?10:10
ssam2persia: seems logical, as there would be no point the controller running multiple builds of an identical thing10:11
straycatperryl, the latter obviously assumes you can route a message to the controller and have it reply to the correct initiator without already having a unique id10:11
straycatssam2, but people might make requests for the same thing10:11
perrylthere needs to be some handling for multiple of the same build i think10:12
ssam2straycat: the InitiatorConnection creates a unique (within the controller) ID for the incoming request and creates a route map10:12
ssam2perryl: why might we want to build the same thing multiple times?10:12
perrylssam2: we may not want to but is there any handling that, for instance stops a build from running if the same build is already running on the network?10:13
straycatssam2, it's not that we do, it's that there's possibly overlapping build requests from different initiators10:13
persiaPerhaps initiator+cacheid to generate a unique ID, and then we can parse that to determine if we have a build already scheduled for the cacheid?10:13
ssam2straycat: ah, that's a good point. It's still valid to have multiple requests for the same thing, and we need to route output to everyone who requested that thing10:14
straycatperryl, yes distbuild has some very basic build scheduling, so that if a build of foo is already running the second request for foo just "joins" the first request, so foo only gets built once10:14
perrylthat's fine then10:14
straycatpersia, that should work10:15
ssam2persia: I think parsing the message ID isn't necessary here. but having build-1234567880-1 might be a good idea10:15
ssam2since there's no requirement for these IDs to be unique, it might be handier to use the first 8 chars of the cache ID10:15
ssam2users will need to use these IDs to identify their job if they detached from it and later want to cancel it, so if they are 70 characters long it will be annoying10:16
straycathrm? the build-request ids do need to be unique?10:16
persiassam2: My concern is that hashing algorithms may cause unexpected collisions with truncated hashes.10:16
persiassam2: Also, I'd prefer unique and parsing, as it makes it easier to drop duplicate requests from multiple initiators.10:16
ssam2straycat, persia: if they do need to be unique, surely generating a random number is the best we can do?10:17
straycatno i think it's awful10:17
ssam21000 people could request a build of the same thing, and each needs to generate a unique ID10:17
straycatthere's no guarantee that will be unique10:17
ssam2straycat: unless all initiators communiate with each other in advance, it's impossible for them to send a unique ID10:18
straycatinitiatorid+cacheid should be unique?10:18
straycatoh, no i guess not10:18
ssam2what is initiatorid ?10:18
ssam2the other alternative is that the ID sent to the server is not the ID the user uses to identify the build10:19
ssam2the server can send back an ID that it knows is unique10:19
straycatyes that's what i suggested earlier10:20
ssam2ah, cool10:21
rdalewhere is the code for configuration-extensions, such as busybox-init - is it part of the morph repo as I can't find it?10:22
richard_mawrdale: some are in morphlib/exts, others are in definitions.git10:23
rdaleah ok, thanks10:24
persiassam2: For unique, I actually really don't like random.  True RNGs generate duplicates.  Lots of work as been done on UUID generation based on non-random data to guarantee uniqueness.10:24
persiaThe advantage of using cacheid is that we can prune requests early, and discard requests to build the same thing twice.10:24
persiaUsing initiator should avoid collisions in the ID.  We may need more than just initiator, if we never want to collide, but we should choose things we know provide useful differentiation, rather than random output.10:26
ssam2persia: I think in that case we could just remove the 'id' field altogether10:26
ssam2for messages send *from* the initiator10:26
straycatcould we use python's uuid module?10:26
ssam2I think the existance of the field is purely to handle a possible future situation where one Morph process could initiate more than one build10:26
persiaI don't understand the implemetation enough to have an opinion on that, but I wonder if it also works for the case of multiple initiators.10:26
persiaI consider the limitation that morph only does one build at a time a buge bug that massively increases system build times.10:27
ssam2define 'morph' :)10:27
ssam2a morph distbuild network does more than one build at a time10:27
persiaThen I'm confusing one implementation with the entire model.  One process to one build makes more sense if one can have multiple processes.10:28
persiaAnd perhaps this bug only exists for local builds, and the solution is to use distbuild.10:29
SotKpersia: is this the "concurrent builds don't work" bug?10:29
persiaSotK: I think that is the bug that is being solved with the discussion of buildids.10:29
persiaMy bug was that when I run morph locally it seems to only do one thing at a time, regardless of the number of cores or amount of RAM I have.  I don't believe my bug is important today.10:30
* straycat thinks uuid() might be okay10:30
straycatseems simpler than asking the controller for an id10:30
persiauuid() is guaranteed unique, which is better than random, but that doesn't protect against parallell builds of the same cacheid.10:30
straycatdistbuild already handles that10:31
straycatanyhow, the moral of this story is straycat is a moron and should have used uuid() instead of generating a random number10:31
paulsherwoodstraycat: don't beat yourself up. i wrote a significant amount of ybd without discovering the .get command for dicts :)10:33
*** mdizzle is now known as mariaderidder11:06
ssam2Public service announcement: if you want to put preformatted text in a Gerrit comment, start each line with 1 or more spaces11:09
ssam2seems bullet points can be done if you use - or * at the start of each line, as well11:10
tlsaah, thanks11:11
tlsaany way to edit comments, btw?11:12
ssam2don't think so11:12
*** ssam2 has quit IRC11:21
*** ssam2 has joined #baserock11:34
*** ChanServ sets mode: +v ssam211:34
jjardontlsa: in new versions of gerrit you can even edit commits inside the gerrit interface11:35
*** ssam2 has quit IRC11:40
*** zoli__ has joined #baserock11:41
jmacsArgh, was nano dropped from the build system?11:47
radiofreei remember seeing a patch to move it to a different stratum, don't know if it was merged11:50
jmacsCan't see anything specific in the git log11:50
jmacsBut I don't have an editor11:50
radiofreeit's still in core11:51
radiofreeshould be there11:51
pedroalvarezoh, the problem was that nano wasn't being installed11:52
radiofreeon my devel system i have /baserock/nano-* but nano isn't there11:52
pedroalvarezThis patch fixes it, but also moves it to devtools11:52
radiofreejmacs: you probably have busybox vi11:52
jmacsradiofree: Like I said, no editor.11:52
pedroalvarezradiofree: yeajh, the chunk only had pre-configure-commands, nothing else11:52
*** ssam2 has joined #baserock11:53
*** ChanServ sets mode: +v ssam211:53
jmacspedroalvarez: When you say 'this patch', is that something up for review?11:53
pedroalvarezit was merged, using gerrit, but something failed.11:54
pedroalvarezI'll recover it and merge it11:54
jmacsEither it was merged or it wasn't, surely?11:55
radiofreei don't think it was merged11:55
pedroalvarezmerged on gerrit, the gerrit db thinks that it was merged, but it failed to do it11:55
jmacsGah. I'm annoyed that I've lost visiblity of this because we've moved to gerrit.11:56
radiofree at least doesn't have nano11:56
radiofreebtw, how do you use the search on gerrit?11:57
radiofreei tried searching for "nano" and i get "Unsupported query:nano"11:57
radiofreei guess there's some syntax i need to learn11:57
richard_mawit's a google product, surely they of all people know how to do a search engine properly!11:58
jmacsSo is gerrit out of step with reality?11:58
radiofreethat would appear to be the case, at least with this nano patch11:59
pedroalvarezhas happened twice since we moved to gerrit12:01
pedroalvarezwe need to investigate why this is happening12:01
pedroalvarezNano patch has been merged now12:01
* richard_maw suspects it's people pushing to git.baserock.org12:01
radiofreehmm yes, the patch landed 1 minute ago12:02
radiofreewas that done manually?12:02
straycatcan't you just try owner:jmac or something?12:03
straycator topic:nano12:03
straycatif it has a topic12:03
jmacsI don't own any patch sets12:04
radiofreetopic:nano didn't display anyting12:04
straycatwho does own it?12:05
jmacsnor does topic:nano find anything. topic:fix-nano works, but how would you know that?12:05
radiofreeyeah it's not that useful as a search function like that12:05
* straycat disappears12:05
jmacsHang on, email doesn't work from gerrit, does it?12:07
* richard_maw has been getting e-mails from gerrit, though he wouldn't consider that "working" given the low signal to noise ratio12:07
jmacsAh, ok then12:07
pedroalvarezradiofree: yes, merged manually12:13
jjardonrichard_maw: jmacs FYI, you can select what project to watch and what kind of emails you want to receive in you user settings:
jmacs13:01  * richard_maw suspects it's people pushing to git.baserock.org12:14
jmacsjjardon: Yeah, I just set that up - I was worried that emails weren't working, but apparently they are12:15
jjardonyeah, sam fix this the other day12:16
richard_mawjjardon: it doesn't give me the option of not doing so without removing my e-mail address though12:19
jmacs"ERROR: Stratum ruby has no build dependencies for chunk ruby-1.8 in strata/ruby.morph"12:24
*** wschaller_ has quit IRC12:24
*** Albert_ has quit IRC12:26
*** Albert_ has joined #baserock12:26
jmacsDid we change something so build-depends: [] is no longer required?12:26
jjardonDoes anyone know if cliapp catch KeyboardInterrupt exceptions? Seems morph doesn't exit cleanly when I CTRL-C12:26
jjardonjmacs: yeah, build-depends: [] is not longer required, morph will build definitions with or without it12:27
jmacsSo why when I manually add build-depends: [] am I no longer getting that ruby-1.8 error? ^12:29
Kinnisonolder morph?12:29
*** fay_ has quit IRC12:30
jmacsI downloaded the raw build image one hour ago.12:30
SotKwhat is the output of morph --version?12:31
jmacsIf I need to upgrade morph before I can build a devel system then I think that needs to be in the quick-start instructions12:32
rjekI find that quite regularly if you're trying to build the HEAD of definitions.git, you need the HEAD of morph.git12:32
rjek(And historically the error message has been unhelpful or late)12:32
rjekI agree that this should probably be mentioned in the quick start guide.12:33
rjek(It does cover how to use the latest/HEAD morph, it just doesn't say how likely it will be that you'll need to.)12:33
SotKjmacs: yeah, thats from before the build depends changes got merged12:33
jjardonjmacs: you should be able to build without build-depends: [] with that version of morph12:33
jmacsrjek: Where?12:33
jjardonSotK: ops, maybe I see the git history incorrectly12:34
rjekjmacs: Under "Configure Morph" on
SotKjjardon: it looks to me like jmacs SHA is from March 5th, and the build_depends change was merged on March 6th12:34
rjekThere's a link to how to use the latest morph12:34
jmacsrjek: That says "If you want to use 'bleeding edge morph' see <link>."12:34
jmacsrjek: Why would I assume I did want bleeding edge morph?12:35
rjekjmacs: That is precisely my point: 13:33 < rjek> (It does cover how to use the latest/HEAD morph, it just doesn't say how likely it will be that you'll need to.)12:35
pedroalvarezsuggestions about how to improve that page, welcome12:35
jjardonSotK: yeah, you are rigth12:36
pedroalvarezeven patches to fix that12:36
jmacspedroalvarez: I know, I'll be editing if I can get something to work12:36
pedroalvarezthanks jmacs :)12:36
pedroalvarezI think we are failing to comunicate that to build master of definitions you may need master of morph12:37
jmacsIndeed - but master of definitions is the default in the instructions.12:37
jjardonI already said this but I I think we should do another release for 2 reasons: 1.current definitions can not be build with the latest image 2. Current version of morh will inform the user if it cant build a future definitions format12:37
jmacsSo we should say "you need master of morph" as default.12:37
rjek(both jmacs and jjardon)12:38
SotK+1 for another release12:38
pedroalvarezI'd be ok with a release everytime we change definitions version12:38
SotKthat is what I would like to happen12:38
jjardonjmacs: I think stratuctions by default says definitions as in the baserock-15.10 release12:39
KinnisonSo do we now have a definitions versioning system in place, with migrations?12:39
jjardon(morph checkout baserock:baserock/definitions baserock-15.10)12:39
pedroalvarezKinnison: that's another discussion I believe12:39
tlsanew release will fix nano too :)12:39
Kinnisonpedroalvarez: Hmm12:39
pedroalvarezKinnison: not saying that I disagree12:39
pedroalvarezwe need that12:39
pedroalvarezgit diff12:39
pedroalvarezgit diff == what was I doing?12:40
jmacsjjardon: Quick start doesn't say anything about 15.10, it just says "morph branch baserock:baserock/definitions your-branch"12:40
pedroalvarezwhich defaults to master12:41
jjardonKinnison: we have, since a while ago. No migrations at the moment but we can add it at any point as we are not breaking compatibility12:41
Zara(using-latest-morph also discussed here: )12:41
jjardonjmacs: sorry, I was looking at
*** fay_ has joined #baserock12:42
jjardonjmacs: I guess you are reading in  "Upgrade your baserock VM to a devel VM" ?12:43
Kinnisonjjardon: IMO no update to the version processing should be permitted without a migration script12:43
jmacsjjardon: Yes12:43
jjardonyeah, that needs improvement: we should suggest to use the definitions shipped with the release there or use latest morph. Unfortunatelly I never done that process (I always use chroot), so others should have a better idea about that12:46
jmacsI've updated the Quick-start wiki page12:48
*** zoli__ has quit IRC12:51
*** wschaller has joined #baserock12:56
*** zoli__ has joined #baserock12:57
ssam2jjardon: about CTRL+C: it's handled by Python, but if Morph is running a subprocess at the time you press CTRL+c it might get ignored by the subprocess13:06
ssam2jjardon: also if the Python code is inside a 'try: except: ' block (catching BaseException instead of a specific Exception class) then KeyboardInterrupt might be eaten by the 'except:' statement13:06
straycatthe RFC branch morph never really got settled, i don't know what to do with the series13:08
jjardonssam2: ah, I asked because I was wondering why the terminal tittle was not cleaned when I exit morph (context:
jjardoncliapp seems to catch KeyboardExpections as well, but it returns error 255, not sure why13:09
straycati think that rfc should be resolved before the next release13:09
ssam2yes, I still don't have a clear idea how to handle version increments13:10
ssam2I was wondering about having to 'propose' the changes over the course of one release. So if we are removing a feature, we warn but support it in definitions N, then remove it in N+113:10
ssam2doing a release for each value of N13:10
ssam2if adding a feature, we add support for it to Morph in N, then make use of it in N+113:11
persiaI think we need to decouple "definitions version changes", "morph releases", and "baserock image releases".13:11
jjardonthe main thing is how to handle breakage with old definitions when we stop supporting them: should we branch morph at that point, as straycat suggested, or not?13:12
persiaWe've all agreed to version definitions, and that means we need morph to deal with this, for which multiple branches/releases seems the easiest way to define subsets of the set of definitions versions supported.  Image release timing still needs thought, but I think that is mostly an infrastruture thing.13:13
persiaIn my ideal world, the CI builds images that are downloadable, so we don't have to do anything special to grab a recent image.13:13
jjardonmaybe we should tag when current definitions start to be v1?13:13
persiatag where?13:14
jjardondefinitions repo13:14
persiaThat makes sense to me: makes it easier to see where the boundaries happen than watching the content of a file.13:15
ssam2I'd like to have Morph decoupled from definitions, but I'm not confident we have the capacity to do the extra leg work13:16
jjardonThis is the commit when definitions start to be v1: 9fa6cb41f584670cf5ca43b963d47ee62a8f6e6113:17
persiassam2: What extra legwork?13:18
jjardoncurrent status is: current morph builds version 0 and 1 of definitions, current morph trying to build a future definitions format (incompatible) -> fail13:19
ssam2persia: I don't know cleraly, all I know is our current release process13:20
ssam2would need to think through what the new process would look like13:20
radiofreeok searing "message" seems to be the best13:21
persiassam2: Ah.  I think our current process is too hard, which is my main motivation for decoupling morph.  My thought is that we should do morph releases when we add significant things, and only point devel at released morph.13:21
persiaAnd then we can have automation generate download images with some confidence that this doesn't result in something that cannot be used to build anything.13:21
persiaAnd we can validate morph trunk with firehose (as much as I dislike the name)13:21
radiofreee.g "message:nano"13:22
jjardonin the releases, we only need to be sure that the morph we include is able to build the definitions included in the release. If the use try to upgrade to definitions master, its possible that morph can not build definitions anymore13:22
jjardonpersia: still, if any user try to build definitions master, and the format has changed, morph will fail to build13:23
persiajjardon: True.  We need to sort the upgrade path.13:23
jjardon(and I think is ok, we should suggest to the user to upgrade morph at that point)13:23
ssam2persia: Since changes to definitions version will normally require changes to Morph and to definitions.git, decoupling the two seems like it would add extra work13:23
persiaI think we should suggest the user upgrade to a system with a newer morph (which is not quite the same).13:24
persiaI think having morph not be defined in definitions is dangerous.13:24
ssam2when I say 'decoupling', I mean decoupling their release processes13:24
* SotK agrees with persia on upgrades13:24
persiassam2: For developers, I understand that viewpoint.  As a user, that they are coupled makes them very hard to consume.13:24
jjardonpersia: unfortunately I and other use chroot and can not upgrade my system13:24
persiajjardon: That you can't upgrade a chroot is a bug.13:25
persiaFor that matter, that we need a chroot is a bug: it's mostly because nobody has bothered to identify the dependencies of morph.13:25
jmacsCan I just put a morph-version-required field into definitions? Or is it bad to assign a version number to morph?13:25
jjardonpersia: dont think the use of a chroot is because (only) the dependencies, but I can be wrong13:26
persiajmacs: morph doesn't currently have a version.  I'd prefer morph to understand which definitions can be processed vs. definitions understanding which morph to use, but we could change the direction.13:28
persiajjardon: That was my memory of why chroot was done: specifically because morph was not expected to run under Debian.13:28
*** ssam2 has quit IRC13:30
jmacspersia: That sounds possible.13:30
jjardonoh, didn't know that, can anyone confirm this? Dont really understand the "morph was not expected to run under Debian": because morph dependencies or other reason?13:32
SotKI think Kinnison did the chroot work, maybe he knows13:33
persiaNobody was able to explain to me in any detail when I asked, but when I asked to be able to run in Debian, the chroot solution was suggested as easier than any other option.13:33
Kinnisonmorph is written to expect a baserock build system's facilities13:35
Kinnisonit's *possible* to put together debs to achieve that under Debian13:35
jmacsAha, I see jjardon added a VERSION when he removed build-depends: [] - that's handy13:35
Kinnisonbut a chroot of Baserock seemed (a) vastly simpler to achieve and (b) vastly more likely to be reliable13:35
jjardonjmacs: :) Removal of build-depends was version 1, previously version 0 already exist13:39
jjardonKinnison: can you explain what baserock build system's facilities need a chroot so its simpler to implement and also more reliable?13:41
Kinnisonjjardon: it's things like specific versions of linux-user-chroot and the tooling required for subsequent deployment13:41
Kinnisonjjardon: Trying to manage those from an external packaged distro is hard work, or duplicative or worse13:42
jjardonKinnison: so, morph needs to run in a chroot/VM because its dependencies are maybe too new?13:43
*** ssam2 has joined #baserock13:43
*** ChanServ sets mode: +v ssam213:43
jonathanmawSotK: I don't suppose you can remember why gtk2 and enlightenment are in the genivi-demo-platform stratum?13:44
Kinnisonjjardon: Or not available, or too old, or too strange, or built differently, etc.13:44
SotKjonathanmaw: no idea... at a guess I found I needed them when trying to get fuel-stop-advisor to build13:45
rdalejonathanmaw: i added enlightenment as it was the smallest desktop environment that would work with qt4/qt5 and qt creator13:46
SotK(I was building a system with that stratum then deploying it and trying to build fuel-stop-advisor in the deployed system by hand13:47
jjardonKinnison: so, to be clear; in case I have all those dependencies in my distro, there is not any other reason to use morph in a chroot?13:49
KinnisonIn theory, no13:50
ssam2there's the fact that you have to run builds as root, too13:50
ssam2we need to fix that, but it doesn't seem to be on anyone's list of priorities13:50
Kinnisonssam2: even in a non-baserock environment that's just a sudo away13:51
ssam2if you trust the developers of Morph13:51
ssam2in a chroot it's more likely that it can only destroy its own chroot13:52
KinnisonThere's that too13:52
ssam2given that configure and write extensions also run as root and have full access to the host system, I really don't trust Morph builds to not break things13:53
tlsais zookeeper used for anything?13:54
pedroalvareznot sure if being used currently, why?13:55
persiatlsa: I don't think it is part of any reference systems.  Lots of people use it for various things.  Midonet is my current favorite system using it.13:55
tlsathere are several issues with those systems:
tlsaI'm wondering if those systems should be removed of fixed13:56
tlsa(although they were useful fro testing teh reproducibility certification tool)13:57
tlsa*for *the13:58
tlsatyping :(13:58
ssam2mason-x86-64.baserock seems to have crashed and burned14:02 even14:02
ssam2long backtrace from btrfs on its console14:02
ssam267G of 80G used on its root disk, so not a disk full catastrophe14:04
tlsaThat used to happen every few days when mason was running on a local openstack host, if its the same thing14:04
ssam2seems the procps-ng chunk is installing files into /14:09
ssam2today is turning into an easter egg hunt except with bugs14:09
*** zoli__ has quit IRC14:11
ssam2franred: seems this is your fault !
ssam2do you remember why that chunk has 'prefix: /' ?14:11
richard_mawssam2: I do14:12
ssam2maybe it's to override the busybox tools. .. but it means that I have /include, /share  etc14:12
richard_mawotherwise you'd end up with it not replacing the versions of the tools provided by busybox14:12
ssam2right. I guess we need to do that in a different way14:12
richard_mawI see, it would be better to either set --bindir (or equivalent), or fix the split /bin, /sbin, /usr/sbin and /usr/bin mess14:13
ssam2I know which one I can do in 10 minutes :)14:13
richard_maw(we also need to fix /var/run not being a symlink to /run)14:13
jjardonssam2: --bindir is what I used the last time14:15
jjardondoes morph depend on cliapp upstream or the one in g.b.o?14:18
SotKthe one in g.b.o I think14:19
jonathanmawhrm, gtk+ doesn't like the currently-installed version of automake (1.5), it wants 1.7, or 1.0 to 1.414:20
SotKthere is a branch on g.b.o with a patch to fix that I think (I needed it last night)14:21
radiofreejonathanmaw: do you need gtk+?14:21
paulsherwoodin other news, thanks to Kinnison ybd has apparently built base-system-x86_64-generic14:22
ssam2jjardon: yes it depends on baserock/morph branch in, which is a bit different to upstream14:22
SotKin the gtk+ repo jonathanmaw14:22
jjardonjonathanmaw: using latest gtk2.24 release will solve that14:23
*** zoli__ has joined #baserock14:23
franredssam2, that was long time ago, and yes, it was to replace the busybox process utilities tools by the procps-ng ones - why this is causing mason to fail?14:23
pedroalvarezfranred: my guess is that is not related to mason14:28
pedroalvarezssam2: want me to reinstantiate mason-x86-64?14:29
ssam2I have done that14:30
ssam2I was investigating why it has 67GB of root disk used14:30
ssam2and in the process, wondered why it had /include and /share directories14:30
ssam2which led me to procps-ng14:30
ssam2oh, /srv/distbuild will be taking all the space, it's not on a volume or anything14:31
pedroalvarezyes in a voulume we will have less btrfs problems I guess14:34
pedroalvarezbut then instantiating a node will be a bit more complex given that nova cant attach volumes at instantiaton time, before the distbuild-setup scripts run14:35
pedroalvarezit doesn't matter if they run twice actually14:36
ssam2seems to be working fine mostly, but is slowly filling up14:38
ssam2partly with 100MB Morph log files of course14:38
radiofreedoes mason populate an artefact cache server as they are built14:40
radiofreeor only after the whole thing is successful?14:40
ssam2depends on how it's deployed14:41 and use as their artifact cache server while building, so things go in there as soon as they are built14:41
ssam2you can also deploy a Mason to use one artifact cache server while building, then copy all the artifacts across to a different server on success14:42
radiofreeah, there's an internal arm server i'm trying to use, seems like it's not working then14:43
radiofreeafter upgrading morph 2015-03-31 14:44:07 [Build 3/268] [stage2-linux-api-headers] Building chunk stage2-linux-api-headers14:44
radiofreeERROR: Directory /src/cache/gits/git___git_baserock_org_delta_linux_stable is not a Git repository.14:44
* radiofree just deletes the folder14:45
jmacsIs OK? Disk issue this morning noted14:49
*** zoli__ has quit IRC14:49
*** zoli__ has joined #baserock14:49
*** zoli__ has quit IRC14:55
*** zoli__ has joined #baserock14:55
*** zoli__ has quit IRC15:00
*** zoli__ has joined #baserock15:01 should be fine, otoh mason might not have populated it yet15:05
jmacsThat may be the problem; it looks pretty empty15:06
jonathanmawgrumble grumble efl master doesn't work with the latest systemd.15:10
paulsherwoodjonathanmaw: is efl needed for something?15:11
jonathanmawits expects libsystemd-daemon, libsystemd-journal and libsystemd-login. iirc, they were all merged into libsystemd.15:11
paulsherwood(here, i mean)15:11
jonathanmawpaulsherwood: enlightenment, which SotK had in his genivi-demo-platform definitions.15:11
paulsherwoodi don't think it's required by genivi?15:11
jonathanmawpaulsherwood: I don't think so. I think SotK used it when trying to build the fuel stop advisor.15:14
radiofreeoh god, i think it is15:16
radiofreethey use (or at least used) some enlightenment libs there15:16
SotKyeah, I think it was efl I needed15:16
jjardonjonathanmaw: modern versions of systemd only ship libsystemd.pc, you can enable the old pc files with the --enable-compat-libs option in systemd15:16
* radiofree wonders why that isn't enabled by default in baserock15:17
jonathanmawno sign of enlightenment or efl in meta-genivi-demo15:20
jonathanmawbut that doesn't mean it's not added in a lower layer15:20
rdalei think it's only there because i added it, not because of genivi15:21
tiagogomes_Hi, I can't push to gerrit: I have done a rebase before pushing15:23
ssam2tiagogomes_: could you paste the output of `git log --oneline | head -n 10` somewhere ?15:25
tiagogomes_it is gerrit that doesn't like me15:26
*** Krin has quit IRC15:26
tiagogomes_I assume that I don't have to add my SSH key per repo15:27
ssam2yeah, that error seems wrong15:27
ssam2maybe Gerrit has got confused about something15:27
tiagogomes_I don't have this
ssam2hmmm! that's interesting15:28
tiagogomes_on my local repo, but git pull doesn't retrieve that commit15:28
ssam2that commit isn't present in 'master' in Gerrit, even in /srv/gerrit/gits on the server15:29
ssam2this seems like another instance of Gerrit screwing up a merge15:29
radiofreejonathanmaw: ahh, i think it's dbus-c++ that needs efl15:29
ssam2the only error I can see is that 'master' of initramfs-scripts.git has got out of sync ....15:29
radiofree--disable-ecore should work15:30
jonathanmawalso noted that yocto does have a meta-efl layer, but it does not appear to be required.15:30
ssam2I wonder if *lorry* is force-pushing and deleting commits right after Gerrit merges them, but before gerrit-replication pushes them to
ssam2argh, yes, lorry is able to force-push15:35
ssam2which is fine for branches that aren't master, but not at all fine for 'master'.15:36
* ssam2 tries to work out a refspec for 'force push to anything that isn't master'15:36
jjardonmaybe of interest here:
* straycat notes that there seems to be no obvious reason to call swift rings rings15:43
straycat(we are not alone)15:43
ssam2tiagogomes_: I just noticed is for the initramfs-scripts repo, not definitions15:45
ssam2so that isn't the problem15:45
ssam2I've temporarily disabled incoming mirroring on while I try to unpick this mess. So anything merged to will not appear in gerrit for the time being15:46
jjardonssam2: maybe it would help if you disable push to baserock/* repos in g.b.o ? and use the gerrit ones instead15:48
ssam2that would help, but I still want to track down the cause of this 'merges not happening' bug15:53
ssam2I realise can just prevent the 'Mirroring Tools' group from force-pushing to master, that should be enough to see if it's breaking anything15:54
*** a1exhughe5 has quit IRC16:00
ssam2I've made it so lorry can't force push to master any more, and restarted mirroring on Hopefully this will fix the 'merges getting lost' issue we've been seeing16:23
ssam2I'd like to write a quick script to check that everything in 'merged' state is indeed merged. But I don't think I'll get time for at least a few days16:24
jonathanmawargh! boost failed to build because it couldn't find uintptr_t. apparently this is fixed in boost 1.55. The currently known working boost is a tarball, boost from git is arranged into 123 submodules16:35
jonathanmawooh, boost-tarball has a version 1_5716:35
*** mariaderidder has quit IRC16:35
* pedroalvarez checks16:36
pedroalvarezindeed, 123 modules16:36
*** ssam2 has quit IRC16:36
pedroalvarezI understand now why we lorried the tarball16:36
paulsherwoodybd base system build, from scratch, no pre-caches... 2015-03-30 12:10:39 [base-system-x86_64-generic] Elapsed time 01:15:1016:56
* paulsherwood now lets rip with morph16:57
*** Guest35384 has quit IRC17:00
*** bashrc has quit IRC17:02
*** mdunford has quit IRC17:04
jjardonpaulsherwood: is it needed to run ybd inside a chroot?17:09
*** jonathanmaw has quit IRC17:13
paulsherwoodit should work on a linux system, jjardon17:16
pedroalvarezpaulsherwood: does ybd have support for system-integration commands?17:20
pedroalvarezalso, 1 hour 15 min?17:23
pedroalvarezIf you are going to do the same test with morph, it wouldn't be fair if you run ybd on your host, and morph in a VM17:24
* jjardon cloning ybd17:24
jjardonpaulsherwood: yeah, if you can use a chroot to test morph it would be better :)17:25
paulsherwoodpedroalvarez: i'm running ybd on baserock17:27
paulsherwoodno support for deploy or system integration commands so far17:28
paulsherwoodand still some recursion bugs17:29
paulsherwoodjjardon: note it uses baserock repos if they are cloned in /src/cache/gits17:31
straycatheh, okay i think i prefer doing reviews in gerrit >.>17:37
straycatas long as they're not huge dependency chains17:37
paulsherwoodstraycat: wow, what happened? :-)17:38
*** wschaller has quit IRC17:38
jjardonpaulsherwood: seems some thing are still hardcoded: "OSError: [Errno 2] No such file or directory: '/src/cache/ccache'" I will try later with a baserock system with python317:39
jjardon(disabling ccache doesnt seem to work)17:40
straycati reviewed perryl's distbuild changes and the side-by-side view actually made it really easy, it's also smart about leaving the right spacing between blocks of related code and omits common line by default (but also allows you to easily incremently show common code) you can also compare between patch set n and any other earlier set really easily.17:41
paulsherwoodoops... i'll raise an issue jjardon. nb i'm still running it with python217:41
straycatmaybe i should go now >.>17:42
straycati also like that comments by default are drafts, allowing you to get through the whole series and refine your comments if needed before posting the actual review17:45
straycatthat's the kind of thing i needed to track myself with mail17:45
* straycat disappears17:46
straycati do think using gerrit obviously encourages you to put more into a single commit, but maybe that's okay17:48
*** rdale has quit IRC17:48
persiaA commit should contain a single logical change, no more.  SImilarly a logical change should be in a single commit, no more.17:53
edcraggpaulsherwood, fay_, richard_maw, franred, pedroalvarez, Kinnison: seems it's not a problem building the openstack-server system on armv8l64, a couple of packages need small fixes, but otherwise it's just finished building18:02
persiaedcragg: Unless you really need the attention of a specific person, I'll recommend speaking to the entire channel.  You may find that by highlighting specific folk, you are narrowing your message so that fewer folk respond.18:03
jjardonpaulsherwood: you should stick with python3 :) Im sure Im missing something but what are the advantages of ybd against, for example, jhbuild? (apart from understand the definitions syntax) (morph has the advantage that the builds are isolated in a chroot)18:07
*** edcragg has quit IRC18:09
*** zoli__ has quit IRC18:42
*** zoli___ has joined #baserock18:42
*** gary_perkins has quit IRC18:53
* SotK tries doing pango-querymodules > /usr/etc/pango.modules and fc-cache but still doesn't have working fonts :(18:54
paulsherwood2015-03-30 12:12:30 Collecting morphologies involved in building systems/base-system-x86_64-generic.morph from reference19:14
paulsherwood2015-03-30 13:42:04 [Build 129/129] [base-system-x86_64-generic] system base-system-x86_64-generic-rootfs is cached at /src/cache/artifacts/4ca4c516c3036a98d7ece4b62459e479aea168eecd80560d492ffd5c00343bef.system.base-system-x86_64-generic-rootfs19:14
paulsherwoodso 1 hour 30 ish19:15
persiaSo ybd is 1:15:10 and morph is 1:29:34.19:15
persia14 minutes doesn't seem entirely outlandish for sandboxing.19:15
paulsherwoodagreed :)19:16
radiofreeIts still better19:29
persiaDepends what you are doing.  I've been burnt with unsandboxed builds more times than I can count.19:31
* radiofree thinks about the number of cups of coffee he could drink in 14 minutes19:32
pedroalvarezedcragg: good! Now time to deploy that and test kvm ;)20:18
*** Albert_ has quit IRC21:20
*** zoli___ has quit IRC21:48
*** zoli__ has joined #baserock22:05
*** zoli__ has quit IRC22:11

Generated by 2.14.0 by Marius Gedminas - find it at!