| *** zoli__ has quit IRC | 04:32 | |
| *** zoli__ has joined #baserock | 04:32 | |
| *** zoli__ has quit IRC | 05:52 | |
| *** zoli__ has joined #baserock | 05:52 | |
| *** zoli__ has quit IRC | 05:55 | |
| *** zoli__ has joined #baserock | 05:55 | |
| *** zoli__ has quit IRC | 05:57 | |
| *** zoli__ has joined #baserock | 05:57 | |
| *** zoli__ has quit IRC | 05:58 | |
| *** zoli__ has joined #baserock | 05:59 | |
| *** zoli__ has quit IRC | 06:25 | |
| *** zoli__ has joined #baserock | 06:34 | |
| *** zoli__ has quit IRC | 06:41 | |
| *** zoli__ has joined #baserock | 06:41 | |
| *** zoli__ has quit IRC | 06:44 | |
| *** mike has joined #baserock | 07:00 | |
| *** mike is now known as Guest35384 | 07:00 | |
| *** Albert_ has joined #baserock | 07:07 | |
| *** Albert_ has joined #baserock | 07:08 | |
| *** rdale has joined #baserock | 07:54 | |
| *** mdunford has joined #baserock | 07:55 | |
| *** mdizzle has joined #baserock | 07:56 | |
| *** bashrc has joined #baserock | 07:58 | |
| *** a1exhughe5 has joined #baserock | 07:59 | |
| *** jonathanmaw has joined #baserock | 08:07 | |
| *** tiagogomes_ has joined #baserock | 08:29 | |
| *** ssam2 has joined #baserock | 08:33 | |
| *** ChanServ sets mode: +v ssam2 | 08:33 | |
| *** gary_perkins has joined #baserock | 08:45 | |
| *** CTtpollard has joined #baserock | 08:49 | |
| *** edcragg has joined #baserock | 08:55 | |
| edcragg | richard_maw, pedroalvarez, franred, jmacs, Kinnison, fay_, a1exhughe5: http://paste.baserock.org/inacunucok | 09:03 |
|---|---|---|
| edcragg | paulsherwood: 15:58:12 [Build 21/411] [gcc] Elapsed time 00:08:41 | 09:04 |
| radiofree | 8 minutes! Nice | 09:05 |
| SotK | jjardon: 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 #baserock | 09:07 | |
| richard_maw | edcragg: # error "No LG_QUANTUM definition for architecture; specify via CPPFLAGS" | 09:07 |
| SotK | Its unusable because fonts are either missing or not rendering properly, so that't my job for tonight. | 09:08 |
| richard_maw | no architecture support | 09:08 |
| ssam2 | SotK: do all the fonts show as squares? might need to run fc-cache | 09:08 |
| bashrc | when making a system is there any way to know which strata are mutually incompatible? | 09:08 |
| persia | bashrc: Only be trying a build. The overlay rules probably keep it unclear until testing the built system. | 09:09 |
| persia | s/be/by | 09:09 |
| SotK | ssam2: thats what happens | 09:09 |
| SotK | I'll try that tonight | 09:09 |
| bashrc | doesn't that limit the user's options? | 09:10 |
| jjardon | SotK: pang of query modules > /use/etc/pango.modules | 09:10 |
| persia | bashrc: No, rather expands them, as the only limitations are those experienced in testing, rather than there being some imposed by metadata. | 09:10 |
| jjardon | pango-querymodules* | 09:11 |
| bashrc | well to make some remix the user would need to laboriously test build the combinations | 09:11 |
| persia | This 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 |
| SotK | Anyone got time to see whats wrong with Mason? | 09:24 |
| ssam2 | SotK: at a guess, cache.baserock.org's /home disk is full again. thanks for raising it | 09:30 |
| ssam2 | i'll look at it in a bit | 09:30 |
| pedroalvarez | ssam2: yes, you are right. I've removed some artifacts | 09:32 |
| ssam2 | ta! | 09:33 |
| pedroalvarez | free diskspace info is actually public | 09:34 |
| pedroalvarez | http://cache.baserock.org/lc-status.html | 09:34 |
| *** zoli__ has joined #baserock | 09:44 | |
| paulsherwood | Kinnison: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/ps/some-dependencies | 09:45 |
| Kinnison | ta | 09:45 |
| pedroalvarez | edcragg: what are you going to do with redis then? | 09:47 |
| pedroalvarez | I don't think we need it | 09:47 |
| *** zoli__ has quit IRC | 09:49 | |
| straycat | perryl, seems i wrote the section for build-request that uses a randomly generated id | 10:00 |
| straycat | I don't think it's a good method | 10:00 |
| straycat | it would surely be better to use the IdentifierGenerator? | 10:00 |
| perryl | if IdentifierGenerator is meant to be a unique process, or at least moreso than random_id i think it would be a better option | 10:01 |
| ssam2 | straycat: thinking about this, the IdentifierGenerator might not be a great idea because every ID will be 'Initiator-1' | 10:01 |
| straycat | oh this is in the initiator | 10:02 |
| ssam2 | if 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 process | 10:02 |
| straycat | ahh | 10:02 |
| straycat | that will be why i didn't use it | 10:02 |
| *** wschaller_ has joined #baserock | 10:06 | |
| straycat | we 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 controller | 10:07 |
| perryl | i think the latter may be best, it has to be something unique to each build | 10:09 |
| *** wschaller has quit IRC | 10:10 | |
| persia | Can we reuse the cacheid for this? | 10:10 |
| ssam2 | persia: seems logical, as there would be no point the controller running multiple builds of an identical thing | 10:11 |
| straycat | perryl, 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 id | 10:11 |
| straycat | ssam2, but people might make requests for the same thing | 10:11 |
| perryl | there needs to be some handling for multiple of the same build i think | 10:12 |
| ssam2 | straycat: the InitiatorConnection creates a unique (within the controller) ID for the incoming request and creates a route map | 10:12 |
| ssam2 | perryl: why might we want to build the same thing multiple times? | 10:12 |
| perryl | ssam2: 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 |
| straycat | ssam2, it's not that we do, it's that there's possibly overlapping build requests from different initiators | 10:13 |
| persia | Perhaps 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 |
| ssam2 | straycat: 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 thing | 10:14 |
| straycat | perryl, 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 once | 10:14 |
| perryl | that's fine then | 10:14 |
| straycat | persia, that should work | 10:15 |
| ssam2 | persia: I think parsing the message ID isn't necessary here. but having build-1234567880-1 might be a good idea | 10:15 |
| ssam2 | since there's no requirement for these IDs to be unique, it might be handier to use the first 8 chars of the cache ID | 10:15 |
| ssam2 | users 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 annoying | 10:16 |
| straycat | hrm? the build-request ids do need to be unique? | 10:16 |
| persia | ssam2: My concern is that hashing algorithms may cause unexpected collisions with truncated hashes. | 10:16 |
| persia | ssam2: Also, I'd prefer unique and parsing, as it makes it easier to drop duplicate requests from multiple initiators. | 10:16 |
| ssam2 | straycat, persia: if they do need to be unique, surely generating a random number is the best we can do? | 10:17 |
| straycat | no i think it's awful | 10:17 |
| ssam2 | 1000 people could request a build of the same thing, and each needs to generate a unique ID | 10:17 |
| straycat | there's no guarantee that will be unique | 10:17 |
| ssam2 | straycat: unless all initiators communiate with each other in advance, it's impossible for them to send a unique ID | 10:18 |
| straycat | initiatorid+cacheid should be unique? | 10:18 |
| straycat | oh, no i guess not | 10:18 |
| ssam2 | what is initiatorid ? | 10:18 |
| ssam2 | the other alternative is that the ID sent to the server is not the ID the user uses to identify the build | 10:19 |
| ssam2 | the server can send back an ID that it knows is unique | 10:19 |
| straycat | yes that's what i suggested earlier | 10:20 |
| ssam2 | ah, cool | 10:21 |
| rdale | where 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_maw | rdale: some are in morphlib/exts, others are in definitions.git | 10:23 |
| rdale | ah ok, thanks | 10:24 |
| persia | ssam2: 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 |
| persia | The advantage of using cacheid is that we can prune requests early, and discard requests to build the same thing twice. | 10:24 |
| persia | Using 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 |
| ssam2 | persia: I think in that case we could just remove the 'id' field altogether | 10:26 |
| ssam2 | for messages send *from* the initiator | 10:26 |
| straycat | could we use python's uuid module? | 10:26 |
| ssam2 | I think the existance of the field is purely to handle a possible future situation where one Morph process could initiate more than one build | 10:26 |
| persia | I 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 |
| persia | I consider the limitation that morph only does one build at a time a buge bug that massively increases system build times. | 10:27 |
| persia | s/buge/huge/ | 10:27 |
| ssam2 | define 'morph' :) | 10:27 |
| ssam2 | a morph distbuild network does more than one build at a time | 10:27 |
| persia | Then 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 |
| persia | And perhaps this bug only exists for local builds, and the solution is to use distbuild. | 10:29 |
| SotK | persia: is this the "concurrent builds don't work" bug? | 10:29 |
| persia | SotK: I think that is the bug that is being solved with the discussion of buildids. | 10:29 |
| persia | My 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 okay | 10:30 | |
| straycat | seems simpler than asking the controller for an id | 10:30 |
| persia | uuid() is guaranteed unique, which is better than random, but that doesn't protect against parallell builds of the same cacheid. | 10:30 |
| straycat | hrm? | 10:31 |
| straycat | distbuild already handles that | 10:31 |
| straycat | anyhow, the moral of this story is straycat is a moron and should have used uuid() instead of generating a random number | 10:31 |
| paulsherwood | straycat: don't beat yourself up. i wrote a significant amount of ybd without discovering the .get command for dicts :) | 10:33 |
| straycat | :) | 10:36 |
| *** mdizzle is now known as mariaderidder | 11:06 | |
| ssam2 | Public service announcement: if you want to put preformatted text in a Gerrit comment, start each line with 1 or more spaces | 11:09 |
| ssam2 | seems bullet points can be done if you use - or * at the start of each line, as well | 11:10 |
| tlsa | ah, thanks | 11:11 |
| tlsa | any way to edit comments, btw? | 11:12 |
| ssam2 | don't think so | 11:12 |
| tlsa | ok | 11:12 |
| *** ssam2 has quit IRC | 11:21 | |
| *** ssam2 has joined #baserock | 11:34 | |
| *** ChanServ sets mode: +v ssam2 | 11:34 | |
| jjardon | tlsa: in new versions of gerrit you can even edit commits inside the gerrit interface | 11:35 |
| *** ssam2 has quit IRC | 11:40 | |
| *** zoli__ has joined #baserock | 11:41 | |
| jmacs | Argh, was nano dropped from the build system? | 11:47 |
| radiofree | i remember seeing a patch to move it to a different stratum, don't know if it was merged | 11:50 |
| jmacs | Can't see anything specific in the git log | 11:50 |
| jmacs | But I don't have an editor | 11:50 |
| radiofree | it's still in core | 11:51 |
| radiofree | should be there | 11:51 |
| jmacs | Odd. | 11:51 |
| pedroalvarez | oh, the problem was that nano wasn't being installed | 11:52 |
| radiofree | on my devel system i have /baserock/nano-* but nano isn't there | 11:52 |
| pedroalvarez | This patch fixes it, but also moves it to devtools | 11:52 |
| radiofree | jmacs: you probably have busybox vi | 11:52 |
| jmacs | radiofree: Like I said, no editor. | 11:52 |
| pedroalvarez | radiofree: yeajh, the chunk only had pre-configure-commands, nothing else | 11:52 |
| radiofree | :) | 11:52 |
| *** ssam2 has joined #baserock | 11:53 | |
| *** ChanServ sets mode: +v ssam2 | 11:53 | |
| jmacs | pedroalvarez: When you say 'this patch', is that something up for review? | 11:53 |
| pedroalvarez | it was merged, using gerrit, but something failed. | 11:54 |
| pedroalvarez | I'll recover it and merge it | 11:54 |
| jmacs | Either it was merged or it wasn't, surely? | 11:55 |
| radiofree | https://gerrit.baserock.org/#/c/101/ | 11:55 |
| radiofree | i don't think it was merged | 11:55 |
| pedroalvarez | merged on gerrit, the gerrit db thinks that it was merged, but it failed to do it | 11:55 |
| jmacs | Gah. I'm annoyed that I've lost visiblity of this because we've moved to gerrit. | 11:56 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/devtools.morph at least doesn't have nano | 11:56 |
| radiofree | btw, how do you use the search on gerrit? | 11:57 |
| radiofree | i tried searching for "nano" and i get "Unsupported query:nano" | 11:57 |
| radiofree | i guess there's some syntax i need to learn | 11:57 |
| richard_maw | it's a google product, surely they of all people know how to do a search engine properly! | 11:58 |
| jmacs | So is gerrit out of step with reality? | 11:58 |
| radiofree | that would appear to be the case, at least with this nano patch | 11:59 |
| pedroalvarez | has happened twice since we moved to gerrit | 12:01 |
| pedroalvarez | we need to investigate why this is happening | 12:01 |
| pedroalvarez | Nano patch has been merged now | 12:01 |
| * richard_maw suspects it's people pushing to git.baserock.org | 12:01 | |
| radiofree | hmm yes, the patch landed 1 minute ago | 12:02 |
| radiofree | was that done manually? | 12:02 |
| straycat | can't you just try owner:jmac or something? | 12:03 |
| straycat | or topic:nano | 12:03 |
| straycat | if it has a topic | 12:03 |
| jmacs | I don't own any patch sets | 12:04 |
| radiofree | topic:nano didn't display anyting | 12:04 |
| straycat | who does own it? | 12:05 |
| jmacs | nor does topic:nano find anything. topic:fix-nano works, but how would you know that? | 12:05 |
| radiofree | topic:fix-nano | 12:05 |
| radiofree | yeah it's not that useful as a search function like that | 12:05 |
| * straycat disappears | 12:05 | |
| jmacs | Hang 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 ratio | 12:07 | |
| jmacs | Ah, ok then | 12:07 |
| pedroalvarez | radiofree: yes, merged manually | 12:13 |
| jjardon | richard_maw: jmacs FYI, you can select what project to watch and what kind of emails you want to receive in you user settings: https://gerrit.baserock.org/#/settings/projects | 12:14 |
| jmacs | 13:01 * richard_maw suspects it's people pushing to git.baserock.org | 12:14 |
| jmacs | jjardon: Yeah, I just set that up - I was worried that emails weren't working, but apparently they are | 12:15 |
| jjardon | yeah, sam fix this the other day | 12:16 |
| richard_maw | jjardon: it doesn't give me the option of not doing so without removing my e-mail address though | 12:19 |
| jmacs | "ERROR: Stratum ruby has no build dependencies for chunk ruby-1.8 in strata/ruby.morph" | 12:24 |
| *** wschaller_ has quit IRC | 12:24 | |
| *** Albert_ has quit IRC | 12:26 | |
| *** Albert_ has joined #baserock | 12:26 | |
| jmacs | Did we change something so build-depends: [] is no longer required? | 12:26 |
| jjardon | Does anyone know if cliapp catch KeyboardInterrupt exceptions? Seems morph doesn't exit cleanly when I CTRL-C | 12:26 |
| jjardon | jmacs: yeah, build-depends: [] is not longer required, morph will build definitions with or without it | 12:27 |
| jmacs | So why when I manually add build-depends: [] am I no longer getting that ruby-1.8 error? ^ | 12:29 |
| Kinnison | older morph? | 12:29 |
| *** fay_ has quit IRC | 12:30 | |
| jmacs | I downloaded the raw build image one hour ago. | 12:30 |
| SotK | what is the output of morph --version? | 12:31 |
| jmacs | 9e105fccb12de23551c93aac6cb2b1056b858700 | 12:31 |
| jmacs | If I need to upgrade morph before I can build a devel system then I think that needs to be in the quick-start instructions | 12:32 |
| rjek | I find that quite regularly if you're trying to build the HEAD of definitions.git, you need the HEAD of morph.git | 12:32 |
| rjek | (And historically the error message has been unhelpful or late) | 12:32 |
| rjek | I 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 |
| SotK | jmacs: yeah, thats from before the build depends changes got merged | 12:33 |
| jjardon | jmacs: you should be able to build without build-depends: [] with that version of morph | 12:33 |
| jmacs | rjek: Where? | 12:33 |
| jjardon | SotK: ops, maybe I see the git history incorrectly | 12:34 |
| rjek | jmacs: Under "Configure Morph" on http://wiki.baserock.org/quick-start/ | 12:34 |
| SotK | jjardon: it looks to me like jmacs SHA is from March 5th, and the build_depends change was merged on March 6th | 12:34 |
| rjek | There's a link to how to use the latest morph | 12:34 |
| jmacs | rjek: That says "If you want to use 'bleeding edge morph' see <link>." | 12:34 |
| jmacs | rjek: Why would I assume I did want bleeding edge morph? | 12:35 |
| rjek | jmacs: 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 |
| pedroalvarez | suggestions about how to improve that page, welcome | 12:35 |
| jjardon | SotK: yeah, you are rigth | 12:36 |
| pedroalvarez | even patches to fix that | 12:36 |
| jmacs | pedroalvarez: I know, I'll be editing if I can get something to work | 12:36 |
| pedroalvarez | thanks jmacs :) | 12:36 |
| pedroalvarez | I think we are failing to comunicate that to build master of definitions you may need master of morph | 12:37 |
| jmacs | Indeed - but master of definitions is the default in the instructions. | 12:37 |
| jjardon | I 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 format | 12:37 |
| jmacs | So we should say "you need master of morph" as default. | 12:37 |
| rjek | +1 | 12:38 |
| rjek | (both jmacs and jjardon) | 12:38 |
| SotK | +1 for another release | 12:38 |
| pedroalvarez | I'd be ok with a release everytime we change definitions version | 12:38 |
| SotK | that is what I would like to happen | 12:38 |
| jjardon | jmacs: I think stratuctions by default says definitions as in the baserock-15.10 release | 12:39 |
| Kinnison | So 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 |
| pedroalvarez | Kinnison: that's another discussion I believe | 12:39 |
| tlsa | new release will fix nano too :) | 12:39 |
| Kinnison | pedroalvarez: Hmm | 12:39 |
| pedroalvarez | Kinnison: not saying that I disagree | 12:39 |
| pedroalvarez | we need that | 12:39 |
| pedroalvarez | git diff | 12:39 |
| pedroalvarez | ouch | 12:40 |
| pedroalvarez | git diff == what was I doing? | 12:40 |
| jmacs | jjardon: Quick start doesn't say anything about 15.10, it just says "morph branch baserock:baserock/definitions your-branch" | 12:40 |
| pedroalvarez | which defaults to master | 12:41 |
| jjardon | Kinnison: we have, since a while ago. No migrations at the moment but we can add it at any point as we are not breaking compatibility | 12:41 |
| Zara | (using-latest-morph also discussed here: https://irclogs.baserock.org/%23baserock.2015-03-03.log.html ) | 12:41 |
| jjardon | jmacs: sorry, I was looking at http://wiki.baserock.org/devel-with/ | 12:42 |
| *** fay_ has joined #baserock | 12:42 | |
| jjardon | jmacs: I guess you are reading in "Upgrade your baserock VM to a devel VM" ? | 12:43 |
| Kinnison | jjardon: IMO no update to the version processing should be permitted without a migration script | 12:43 |
| jmacs | jjardon: Yes | 12:43 |
| jjardon | yeah, 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 that | 12:46 |
| jmacs | I've updated the Quick-start wiki page | 12:48 |
| *** zoli__ has quit IRC | 12:51 | |
| *** wschaller has joined #baserock | 12:56 | |
| *** zoli__ has joined #baserock | 12:57 | |
| ssam2 | jjardon: 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 subprocess | 13:06 |
| ssam2 | jjardon: 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:' statement | 13:06 |
| straycat | the RFC branch morph never really got settled, i don't know what to do with the series | 13:08 |
| jjardon | ssam2: ah, I asked because I was wondering why the terminal tittle was not cleaned when I exit morph (context: https://gerrit.baserock.org/#/c/166/) | 13:08 |
| jjardon | cliapp seems to catch KeyboardExpections as well, but it returns error 255, not sure why | 13:09 |
| straycat | i think that rfc should be resolved before the next release | 13:09 |
| persia | +1 | 13:09 |
| ssam2 | yes, I still don't have a clear idea how to handle version increments | 13:10 |
| ssam2 | I 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+1 | 13:10 |
| ssam2 | doing a release for each value of N | 13:10 |
| ssam2 | if adding a feature, we add support for it to Morph in N, then make use of it in N+1 | 13:11 |
| persia | I think we need to decouple "definitions version changes", "morph releases", and "baserock image releases". | 13:11 |
| jjardon | the 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 |
| persia | We'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 |
| persia | In 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 |
| jjardon | maybe we should tag when current definitions start to be v1? | 13:13 |
| persia | tag where? | 13:14 |
| jjardon | definitions repo | 13:14 |
| persia | That makes sense to me: makes it easier to see where the boundaries happen than watching the content of a file. | 13:15 |
| ssam2 | I'd like to have Morph decoupled from definitions, but I'm not confident we have the capacity to do the extra leg work | 13:16 |
| jjardon | This is the commit when definitions start to be v1: 9fa6cb41f584670cf5ca43b963d47ee62a8f6e61 | 13:17 |
| persia | ssam2: What extra legwork? | 13:18 |
| jjardon | current status is: current morph builds version 0 and 1 of definitions, current morph trying to build a future definitions format (incompatible) -> fail | 13:19 |
| ssam2 | persia: I don't know cleraly, all I know is our current release process | 13:20 |
| ssam2 | *clearly | 13:20 |
| ssam2 | would need to think through what the new process would look like | 13:20 |
| radiofree | ok searing "message" seems to be the best | 13:21 |
| persia | ssam2: 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 |
| persia | And 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 |
| persia | And we can validate morph trunk with firehose (as much as I dislike the name) | 13:21 |
| radiofree | e.g "message:nano" | 13:22 |
| jjardon | in 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 anymore | 13:22 |
| jjardon | persia: still, if any user try to build definitions master, and the format has changed, morph will fail to build | 13:23 |
| persia | jjardon: 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 |
| ssam2 | persia: Since changes to definitions version will normally require changes to Morph and to definitions.git, decoupling the two seems like it would add extra work | 13:23 |
| persia | I think we should suggest the user upgrade to a system with a newer morph (which is not quite the same). | 13:24 |
| persia | I think having morph not be defined in definitions is dangerous. | 13:24 |
| ssam2 | when I say 'decoupling', I mean decoupling their release processes | 13:24 |
| * SotK agrees with persia on upgrades | 13:24 | |
| persia | ssam2: For developers, I understand that viewpoint. As a user, that they are coupled makes them very hard to consume. | 13:24 |
| jjardon | persia: unfortunately I and other use chroot and can not upgrade my system | 13:24 |
| persia | jjardon: That you can't upgrade a chroot is a bug. | 13:25 |
| persia | For 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 |
| jmacs | Can I just put a morph-version-required field into definitions? Or is it bad to assign a version number to morph? | 13:25 |
| jjardon | persia: dont think the use of a chroot is because (only) the dependencies, but I can be wrong | 13:26 |
| persia | jmacs: 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 |
| persia | jjardon: That was my memory of why chroot was done: specifically because morph was not expected to run under Debian. | 13:28 |
| *** ssam2 has quit IRC | 13:30 | |
| jmacs | persia: That sounds possible. | 13:30 |
| jjardon | oh, 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 |
| SotK | I think Kinnison did the chroot work, maybe he knows | 13:33 |
| persia | Nobody 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 |
| Kinnison | morph is written to expect a baserock build system's facilities | 13:35 |
| Kinnison | it's *possible* to put together debs to achieve that under Debian | 13:35 |
| jmacs | Aha, I see jjardon added a VERSION when he removed build-depends: [] - that's handy | 13:35 |
| Kinnison | but a chroot of Baserock seemed (a) vastly simpler to achieve and (b) vastly more likely to be reliable | 13:35 |
| jjardon | jmacs: :) Removal of build-depends was version 1, previously version 0 already exist | 13:39 |
| jjardon | Kinnison: can you explain what baserock build system's facilities need a chroot so its simpler to implement and also more reliable? | 13:41 |
| Kinnison | jjardon: it's things like specific versions of linux-user-chroot and the tooling required for subsequent deployment | 13:41 |
| Kinnison | jjardon: Trying to manage those from an external packaged distro is hard work, or duplicative or worse | 13:42 |
| jjardon | Kinnison: so, morph needs to run in a chroot/VM because its dependencies are maybe too new? | 13:43 |
| *** ssam2 has joined #baserock | 13:43 | |
| *** ChanServ sets mode: +v ssam2 | 13:43 | |
| jonathanmaw | SotK: I don't suppose you can remember why gtk2 and enlightenment are in the genivi-demo-platform stratum? | 13:44 |
| Kinnison | jjardon: Or not available, or too old, or too strange, or built differently, etc. | 13:44 |
| SotK | jonathanmaw: no idea... at a guess I found I needed them when trying to get fuel-stop-advisor to build | 13:45 |
| rdale | jonathanmaw: i added enlightenment as it was the smallest desktop environment that would work with qt4/qt5 and qt creator | 13: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 hand | 13:47 |
| SotK | ) | 13:47 |
| jjardon | Kinnison: 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 |
| Kinnison | In theory, no | 13:50 |
| ssam2 | there's the fact that you have to run builds as root, too | 13:50 |
| ssam2 | we need to fix that, but it doesn't seem to be on anyone's list of priorities | 13:50 |
| Kinnison | ssam2: even in a non-baserock environment that's just a sudo away | 13:51 |
| ssam2 | if you trust the developers of Morph | 13:51 |
| Kinnison | heh | 13:52 |
| ssam2 | in a chroot it's more likely that it can only destroy its own chroot | 13:52 |
| Kinnison | There's that too | 13:52 |
| ssam2 | given 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 things | 13:53 |
| tlsa | is zookeeper used for anything? | 13:54 |
| pedroalvarez | not sure if being used currently, why? | 13:55 |
| persia | tlsa: 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 |
| tlsa | there are several issues with those systems: http://paste.baserock.org/atagijimiz | 13:55 |
| tlsa | I'm wondering if those systems should be removed of fixed | 13:56 |
| tlsa | *or | 13:56 |
| tlsa | (although they were useful fro testing teh reproducibility certification tool) | 13:57 |
| tlsa | *for *the | 13:58 |
| tlsa | typing :( | 13:58 |
| franred | :) | 13:58 |
| ssam2 | mason-x86-64.baserock seems to have crashed and burned | 14:02 |
| ssam2 | mason-x86-64.baserock.org even | 14:02 |
| ssam2 | long backtrace from btrfs on its console | 14:02 |
| ssam2 | 67G of 80G used on its root disk, so not a disk full catastrophe | 14:04 |
| tlsa | That used to happen every few days when mason was running on a local openstack host, if its the same thing | 14:04 |
| ssam2 | seems the procps-ng chunk is installing files into / | 14:09 |
| ssam2 | today is turning into an easter egg hunt except with bugs | 14:09 |
| *** zoli__ has quit IRC | 14:11 | |
| ssam2 | franred: seems this is your fault ! http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=68e2d0bcddcb6cab8a5d378bbf2e5e42f7cad42a | 14:11 |
| ssam2 | do you remember why that chunk has 'prefix: /' ? | 14:11 |
| richard_maw | ssam2: I do | 14:12 |
| ssam2 | maybe it's to override the busybox tools. .. but it means that I have /include, /share etc | 14:12 |
| richard_maw | otherwise you'd end up with it not replacing the versions of the tools provided by busybox | 14:12 |
| ssam2 | right. I guess we need to do that in a different way | 14:12 |
| richard_maw | I see, it would be better to either set --bindir (or equivalent), or fix the split /bin, /sbin, /usr/sbin and /usr/bin mess | 14:13 |
| ssam2 | I 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 |
| jjardon | ssam2: --bindir is what I used the last time | 14:15 |
| jjardon | does morph depend on cliapp upstream or the one in g.b.o? | 14:18 |
| SotK | the one in g.b.o I think | 14:19 |
| jonathanmaw | hrm, gtk+ doesn't like the currently-installed version of automake (1.5), it wants 1.7, or 1.0 to 1.4 | 14:20 |
| SotK | there is a branch on g.b.o with a patch to fix that I think (I needed it last night) | 14:21 |
| radiofree | jonathanmaw: do you need gtk+? | 14:21 |
| paulsherwood | in other news, thanks to Kinnison ybd has apparently built base-system-x86_64-generic | 14:22 |
| SotK | baserock/tlsa/2.24.25+automake115_fix | 14:22 |
| ssam2 | jjardon: yes it depends on baserock/morph branch in git.baserock.org, which is a bit different to upstream | 14:22 |
| SotK | in the gtk+ repo jonathanmaw | 14:22 |
| jjardon | jonathanmaw: using latest gtk2.24 release will solve that | 14:23 |
| *** zoli__ has joined #baserock | 14:23 | |
| franred | ssam2, 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 |
| pedroalvarez | franred: my guess is that is not related to mason | 14:28 |
| pedroalvarez | ssam2: want me to reinstantiate mason-x86-64? | 14:29 |
| ssam2 | I have done that | 14:30 |
| ssam2 | I was investigating why it has 67GB of root disk used | 14:30 |
| ssam2 | and in the process, wondered why it had /include and /share directories | 14:30 |
| ssam2 | which led me to procps-ng | 14:30 |
| ssam2 | oh, /srv/distbuild will be taking all the space, it's not on a volume or anything | 14:31 |
| pedroalvarez | hm... | 14:34 |
| pedroalvarez | yes in a voulume we will have less btrfs problems I guess | 14:34 |
| pedroalvarez | but then instantiating a node will be a bit more complex given that nova cant attach volumes at instantiaton time, before the distbuild-setup scripts run | 14:35 |
| pedroalvarez | it doesn't matter if they run twice actually | 14:36 |
| ssam2 | seems to be working fine mostly, but is slowly filling up | 14:38 |
| ssam2 | partly with 100MB Morph log files of course | 14:38 |
| radiofree | does mason populate an artefact cache server as they are built | 14:40 |
| radiofree | or only after the whole thing is successful? | 14:40 |
| ssam2 | depends on how it's deployed | 14:41 |
| ssam2 | mason-x86-64.baserock.org and mason-x86-32.baserock.org use cache.baserock.org as their artifact cache server while building, so things go in there as soon as they are built | 14:41 |
| ssam2 | you can also deploy a Mason to use one artifact cache server while building, then copy all the artifacts across to a different server on success | 14:42 |
| radiofree | ah, there's an internal arm server i'm trying to use, seems like it's not working then | 14:43 |
| radiofree | after upgrading morph 2015-03-31 14:44:07 [Build 3/268] [stage2-linux-api-headers] Building chunk stage2-linux-api-headers | 14:44 |
| radiofree | ERROR: Directory /src/cache/gits/git___git_baserock_org_delta_linux_stable is not a Git repository. | 14:44 |
| * radiofree just deletes the folder | 14:45 | |
| jmacs | Is cache.baserock.org OK? Disk issue this morning noted | 14:49 |
| *** zoli__ has quit IRC | 14:49 | |
| *** zoli__ has joined #baserock | 14:49 | |
| *** zoli__ has quit IRC | 14:55 | |
| *** zoli__ has joined #baserock | 14:55 | |
| *** zoli__ has quit IRC | 15:00 | |
| *** zoli__ has joined #baserock | 15:01 | |
| pedroalvarez | cache.baserock.org should be fine, otoh mason might not have populated it yet | 15:05 |
| jmacs | That may be the problem; it looks pretty empty | 15:06 |
| jonathanmaw | grumble grumble efl master doesn't work with the latest systemd. | 15:10 |
| paulsherwood | jonathanmaw: is efl needed for something? | 15:11 |
| jonathanmaw | its configure.ac expects libsystemd-daemon, libsystemd-journal and libsystemd-login. iirc, they were all merged into libsystemd. | 15:11 |
| paulsherwood | (here, i mean) | 15:11 |
| jonathanmaw | paulsherwood: enlightenment, which SotK had in his genivi-demo-platform definitions. | 15:11 |
| paulsherwood | i don't think it's required by genivi? | 15:11 |
| jonathanmaw | paulsherwood: I don't think so. I think SotK used it when trying to build the fuel stop advisor. | 15:14 |
| radiofree | oh god, i think it is | 15:16 |
| radiofree | they use (or at least used) some enlightenment libs there | 15:16 |
| SotK | yeah, I think it was efl I needed | 15:16 |
| jjardon | jonathanmaw: modern versions of systemd only ship libsystemd.pc, you can enable the old pc files with the --enable-compat-libs option in systemd | 15:16 |
| * radiofree wonders why that isn't enabled by default in baserock | 15:17 | |
| jonathanmaw | no sign of enlightenment or efl in meta-genivi-demo | 15:20 |
| jonathanmaw | but that doesn't mean it's not added in a lower layer | 15:20 |
| rdale | i think it's only there because i added it, not because of genivi | 15:21 |
| tiagogomes_ | Hi, I can't push to gerrit: http://paste.baserock.org/osebahatuf. I have done a rebase before pushing | 15:23 |
| ssam2 | tiagogomes_: could you paste the output of `git log --oneline | head -n 10` somewhere ? | 15:25 |
| tiagogomes_ | http://paste.baserock.org/ubibifahal | 15:26 |
| tiagogomes_ | it is gerrit that doesn't like me | 15:26 |
| *** Krin has quit IRC | 15:26 | |
| tiagogomes_ | I assume that I don't have to add my SSH key per repo | 15:27 |
| ssam2 | yeah, that error seems wrong | 15:27 |
| ssam2 | maybe Gerrit has got confused about something | 15:27 |
| tiagogomes_ | I don't have this https://gerrit.baserock.org/#/c/104/ | 15:28 |
| ssam2 | hmmm! that's interesting | 15:28 |
| tiagogomes_ | on my local repo, but git pull doesn't retrieve that commit | 15:28 |
| ssam2 | that commit isn't present in 'master' in Gerrit, even in /srv/gerrit/gits on the server | 15:29 |
| ssam2 | this seems like another instance of Gerrit screwing up a merge | 15:29 |
| radiofree | jonathanmaw: ahh, i think it's dbus-c++ that needs efl | 15:29 |
| radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/james/genivi-demo-platform&id=dc712f1da5b61a9078f543d4df568ca873a90f70 | 15:29 |
| ssam2 | the only error I can see is that 'master' of initramfs-scripts.git has got out of sync .... | 15:29 |
| radiofree | --disable-ecore should work | 15:30 |
| jonathanmaw | also noted that yocto does have a meta-efl layer, but it does not appear to be required. | 15:30 |
| ssam2 | I wonder if *lorry* is force-pushing and deleting commits right after Gerrit merges them, but before gerrit-replication pushes them to git.baserock.org... | 15:31 |
| ssam2 | argh, yes, lorry is able to force-push | 15:35 |
| ssam2 | which 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 | |
| jjardon | maybe of interest here: https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-are-out/ | 15:43 |
| * straycat notes that there seems to be no obvious reason to call swift rings rings | 15:43 | |
| straycat | (we are not alone) | 15:43 |
| ssam2 | tiagogomes_: I just noticed https://gerrit.baserock.org/#/c/104/ is for the initramfs-scripts repo, not definitions | 15:45 |
| ssam2 | so that isn't the problem | 15:45 |
| tiagogomes_ | oh | 15:46 |
| ssam2 | I've temporarily disabled incoming mirroring on gerrit.baserock.org while I try to unpick this mess. So anything merged to git.baserock.org will not appear in gerrit for the time being | 15:46 |
| jjardon | ssam2: maybe it would help if you disable push to baserock/* repos in g.b.o ? and use the gerrit ones instead | 15:48 |
| ssam2 | that would help, but I still want to track down the cause of this 'merges not happening' bug | 15:53 |
| ssam2 | I realise can just prevent the 'Mirroring Tools' group from force-pushing to master, that should be enough to see if it's breaking anything | 15:54 |
| *** a1exhughe5 has quit IRC | 16:00 | |
| ssam2 | I've made it so lorry can't force push to master any more, and restarted mirroring on gerrit.baserock.org. Hopefully this will fix the 'merges getting lost' issue we've been seeing | 16:23 |
| ssam2 | I'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 days | 16:24 |
| jonathanmaw | argh! 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 submodules | 16:35 |
| jonathanmaw | ooh, boost-tarball has a version 1_57 | 16:35 |
| *** mariaderidder has quit IRC | 16:35 | |
| * pedroalvarez checks | 16:36 | |
| pedroalvarez | indeed, 123 modules | 16:36 |
| *** ssam2 has quit IRC | 16:36 | |
| pedroalvarez | I understand now why we lorried the tarball | 16:36 |
| paulsherwood | ybd base system build, from scratch, no pre-caches... 2015-03-30 12:10:39 [base-system-x86_64-generic] Elapsed time 01:15:10 | 16:56 |
| * paulsherwood now lets rip with morph | 16:57 | |
| *** Guest35384 has quit IRC | 17:00 | |
| *** bashrc has quit IRC | 17:02 | |
| *** mdunford has quit IRC | 17:04 | |
| jjardon | paulsherwood: is it needed to run ybd inside a chroot? | 17:09 |
| *** jonathanmaw has quit IRC | 17:13 | |
| paulsherwood | it should work on a linux system, jjardon | 17:16 |
| pedroalvarez | paulsherwood: does ybd have support for system-integration commands? | 17:20 |
| pedroalvarez | also, 1 hour 15 min? | 17:23 |
| pedroalvarez | :) | 17:23 |
| pedroalvarez | If 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 VM | 17:24 |
| * jjardon cloning ybd | 17:24 | |
| jjardon | paulsherwood: yeah, if you can use a chroot to test morph it would be better :) | 17:25 |
| paulsherwood | pedroalvarez: i'm running ybd on baserock | 17:27 |
| paulsherwood | no support for deploy or system integration commands so far | 17:28 |
| paulsherwood | and still some recursion bugs | 17:29 |
| paulsherwood | jjardon: note it uses baserock repos if they are cloned in /src/cache/gits | 17:31 |
| straycat | heh, okay i think i prefer doing reviews in gerrit >.> | 17:37 |
| straycat | as long as they're not huge dependency chains | 17:37 |
| paulsherwood | straycat: wow, what happened? :-) | 17:38 |
| *** wschaller has quit IRC | 17:38 | |
| jjardon | paulsherwood: 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 python3 | 17:39 |
| jjardon | (disabling ccache doesnt seem to work) | 17:40 |
| straycat | i 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 |
| straycat | *lines | 17:41 |
| paulsherwood | oops... i'll raise an issue jjardon. nb i'm still running it with python2 | 17:41 |
| straycat | *incrementally | 17:42 |
| straycat | maybe i should go now >.> | 17:42 |
| paulsherwood | :-) | 17:43 |
| straycat | i 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 review | 17:45 |
| straycat | that's the kind of thing i needed to track myself with mail | 17:45 |
| * straycat disappears | 17:46 | |
| straycat | i do think using gerrit obviously encourages you to put more into a single commit, but maybe that's okay | 17:48 |
| *** rdale has quit IRC | 17:48 | |
| persia | A commit should contain a single logical change, no more. SImilarly a logical change should be in a single commit, no more. | 17:53 |
| edcragg | paulsherwood, 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 building | 18:02 |
| persia | edcragg: 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 |
| jjardon | paulsherwood: 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 IRC | 18:09 | |
| *** zoli__ has quit IRC | 18:42 | |
| *** zoli___ has joined #baserock | 18:42 | |
| *** gary_perkins has quit IRC | 18:53 | |
| * SotK tries doing pango-querymodules > /usr/etc/pango.modules and fc-cache but still doesn't have working fonts :( | 18:54 | |
| paulsherwood | 2015-03-30 12:12:30 Collecting morphologies involved in building systems/base-system-x86_64-generic.morph from reference | 19:14 |
| paulsherwood | 2015-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-rootfs | 19:14 |
| paulsherwood | so 1 hour 30 ish | 19:15 |
| persia | So ybd is 1:15:10 and morph is 1:29:34. | 19:15 |
| persia | 14 minutes doesn't seem entirely outlandish for sandboxing. | 19:15 |
| paulsherwood | agreed :) | 19:16 |
| radiofree | Its still better | 19:29 |
| persia | Depends 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 minutes | 19:32 | |
| pedroalvarez | edcragg: good! Now time to deploy that and test kvm ;) | 20:18 |
| *** Albert_ has quit IRC | 21:20 | |
| *** zoli___ has quit IRC | 21:48 | |
| *** zoli__ has joined #baserock | 22:05 | |
| *** zoli__ has quit IRC | 22:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!