| *** bwh_ has joined #baserock | 00:47 | |
| *** bwh has quit IRC | 00:48 | |
| *** bwh_ is now known as bwh | 00:49 | |
| *** edcragg has quit IRC | 01:16 | |
| *** gtristan has quit IRC | 04:25 | |
| *** gtristan has joined #baserock | 04:42 | |
| *** CTtpollard has joined #baserock | 07:58 | |
| *** paulw has joined #baserock | 08:29 | |
| *** perryl has joined #baserock | 08:46 | |
| *** tiagogomes_ has joined #baserock | 08:55 | |
| *** edcragg has joined #baserock | 08:57 | |
| *** ctbruce has joined #baserock | 09:04 | |
| *** edcragg has quit IRC | 09:18 | |
| *** edcragg has joined #baserock | 09:35 | |
| *** jonathanmaw has joined #baserock | 09:47 | |
| *** toscalix has joined #baserock | 09:51 | |
| *** rdale has joined #baserock | 09:52 | |
| mwilliams_ct | Hey! I mentioned yesterday I couldnt convince trove to deploy to openstack and pasted http://paste.baserock.org/ufihokeqof . ybd is also giving the same issue | 09:57 |
|---|---|---|
| mwilliams_ct | ssam2 suggested deploying to a rawdisk which worked fine | 09:57 |
| pedroalvarez | that's weird... | 09:58 |
| pedroalvarez | I mean, when deploying to openstack, openstack.write extension creates a rawdisk image | 09:58 |
| pedroalvarez | so if the latter worked, former should | 09:59 |
| * pedroalvarez goes to see the log | 09:59 | |
| paulsherwood | pedroalvarez: while you're on, any thoughts on https://github.com/devcurmudgeon/ybd/issues/167 ? | 10:00 |
| pedroalvarez | "set_extlinux_root_to_virtio" | 10:00 |
| paulsherwood | does that script now depend on specific content/format in metafiles? | 10:00 |
| *** benbrown_ has joined #baserock | 10:02 | |
| *** ssam2 has joined #baserock | 10:03 | |
| *** ChanServ sets mode: +v ssam2 | 10:03 | |
| pedroalvarez | paulsherwood: yeah, it depends on metafiles being json files | 10:03 |
| *** benbrown_ has quit IRC | 10:03 | |
| *** benbrown_ has joined #baserock | 10:04 | |
| paulsherwood | rdale: aren't ybd's metafiles json, now? | 10:04 |
| pedroalvarez | and it needs the files of the artifact listed in the metafile too, in some way | 10:05 |
| rdale | no, they're yaml | 10:05 |
| pedroalvarez | regarding "does that script now depend on.. ", nope, that has been the case since it was created I believe | 10:06 |
| paulsherwood | pedroalvarez: json is a subset of yaml, iiuc. would it make sense to adapt it to deal with yaml? | 10:06 |
| paulsherwood | it may be that ybd has never been able to run that script, then :) | 10:07 |
| pedroalvarez | paulsherwood: that would make sense | 10:07 |
| paulsherwood | ok, i'll take a look, thanks | 10:07 |
| pedroalvarez | I'd like them to have a similar structure though | 10:07 |
| paulsherwood | we can all dream :) | 10:08 |
| rdale | there is a lot of stuff in the morph meta files that looks like dumps of internal data structures, and so it is difficult to standardize on that format | 10:09 |
| paulsherwood | i'm not going to try, sorry. | 10:09 |
| paulsherwood | (standardising) | 10:10 |
| rdale | i agree there isn't much point | 10:11 |
| rdale | except inter operating with spdx perhaps | 10:11 |
| paulsherwood | that would be cool | 10:12 |
| paulsherwood | and may ultimately be a requirement | 10:12 |
| pedroalvarez | mwilliams_ct: I think I may know where your problem is. I'll try to help you in a moment :) | 10:21 |
| mwilliams_ct | thanks pedroalvarez :D | 10:22 |
| *** gtristan has quit IRC | 10:26 | |
| *** Lachlan1975 has joined #baserock | 10:27 | |
| *** Lachlan1975 has quit IRC | 10:33 | |
| *** franred has joined #baserock | 10:38 | |
| *** locallycompact has joined #baserock | 10:40 | |
| *** Lachlan1975 has joined #baserock | 10:47 | |
| *** gtristan has joined #baserock | 11:05 | |
| *** tiagogomes_ has quit IRC | 11:07 | |
| *** tiagogomes_ has joined #baserock | 11:19 | |
| paulsherwood | is there any way (in python) to stop tar generating a flood of errors on ENOSPACE? | 11:21 |
| richard_maw | paulsherwood: is this with the tarfile module, or running tar in a subprocess? | 11:22 |
| paulsherwood | with tarfile | 11:23 |
| richard_maw | paulsherwood: got a log snippet I can look at? | 11:24 |
| paulsherwood | richard_maw: http://paste.baserock.org/ucapayolem | 11:26 |
| paulsherwood | the code is at https://github.com/devcurmudgeon/ybd/blob/master/ybd/utils.py#L246 | 11:26 |
| ssam2 | I upgraded a devel system to master of definitions (plus glibc patch) and my prompt is no longer colourful :-( | 11:27 |
| paulsherwood | ssam2: think yourself lucky. i upgraded my laptop a few months ago, and all of my baserock vms no longer work :/ | 11:28 |
| paulsherwood | iirc Kinnison described my problem as 'interesting' | 11:28 |
| ssam2 | :( | 11:31 |
| ssam2 | GLIBC update seems to work, anyone fancy giving https://gerrit.baserock.org/#/c/1839/ another +1 ? | 11:31 |
| franred | ssam2, done | 11:32 |
| ssam2 | thanks | 11:32 |
| locallycompact | here's a new whatsit whats less badder https://github.com/locallycompact/definitions/commits/lc/defsv8 | 11:33 |
| locallycompact | that migration library is very good thanks | 11:34 |
| pedroalvarez | locallycompact: just spotted a "+ submodules: {}" | 11:36 |
| locallycompact | yeah that's because kafka-python has an empty .gitmodules file | 11:36 |
| locallycompact | I'm tempted to just leave it | 11:37 |
| pedroalvarez | also, I wonder if the migration handles recursive submodules | 11:37 |
| pedroalvarez | (dunno if "recursive" is the right word here) | 11:38 |
| locallycompact | migration doesn't handle nested submodules because we don't have any, but the schema supports and ybd supports building them | 11:38 |
| paulsherwood | locallycompact: on your branch. '0 16-02-18 00:00:37 [0/41/574] [polkit] ERROR: No definition found for polkit' | 11:41 |
| paulsherwood | with master ybd, building ci.morph? | 11:41 |
| * paulsherwood needs to get the schema validation integrated into ybd... that error is not very helpful | 11:42 | |
| *** cosm has quit IRC | 11:42 | |
| paulsherwood | locallycompact: presumably you tested different build targets? | 11:42 |
| paulsherwood | actually, maybe this is a hold-over from jjardon's recent work | 11:43 |
| locallycompact | I'll test as fast as my cpu can go | 11:45 |
| locallycompact | But if anything is failing because submodules then everything should be | 11:45 |
| paulsherwood | locallycompact: yup, this issue is not with your changes | 11:45 |
| locallycompact | paulsherwood, is ybd rebuilding everything because I changed the VERSION file? | 11:45 |
| paulsherwood | pls could you re-run your migration against master? | 11:45 |
| locallycompact | this was against master | 11:46 |
| locallycompact | as of 5pm yesterday | 11:46 |
| paulsherwood | pls hold | 11:46 |
| paulsherwood | master now is not the same as master then | 11:47 |
| locallycompact | will rerun | 11:47 |
| paulsherwood | shouldn't be different, but hey :) | 11:48 |
| paulsherwood | s/different/a different result/ | 11:48 |
| locallycompact | stunningly, that rebases. https://github.com/locallycompact/definitions/commits/lc/defsv8-rebase | 11:49 |
| jjardon | Hi, ok to lorry this stuff https://gerrit.baserock.org/#/c/1849/ https://gerrit.baserock.org/#/c/1840/ https://gerrit.baserock.org/#/c/1838/ and https://gerrit.baserock.org/#/c/1834/ ? | 11:50 |
| jjardon | paulsherwood: that's fixed in master | 11:50 |
| paulsherwood | locallycompact: rebase is not the same operation as re-running your migration | 11:50 |
| paulsherwood | locallycompact: it *might* have the same result, but it's not the same thing | 11:51 |
| paulsherwood | jjardon: don't we already have lua? | 11:51 |
| locallycompact | if it weren't the same result it would have conflicted | 11:51 |
| jjardon | paulsherwood: we have, but from and old repo thats is not being updated anymore | 11:52 |
| paulsherwood | locallycompact: i don't know what you mean, sorry | 11:52 |
| paulsherwood | jjardon: ok, do we need to move it to -disabled ? | 11:52 |
| ssam2 | Artifacts should now be available on cache.baserock.org for a devel system built against patched GLIBC | 11:52 |
| paulsherwood | ssam2: when did you start that process, fwiw? | 11:52 |
| paulsherwood | (ie how long did it take to do) | 11:53 |
| ssam2 | yesterday morning | 11:53 |
| jjardon | paulsherwood: Id like to, but the repo is being used by some strata/systems | 11:53 |
| ssam2 | but it probably finished a few hours after I went home | 11:53 |
| jjardon | we could when we migrate all of them | 11:53 |
| paulsherwood | jjardon: ah, ok | 11:54 |
| locallycompact | paulsherwood, the result of the migration script is equivalent to a patch operation, the only reason to rerun it would be a merge conflict. | 11:55 |
| locallycompact | Still I'm rerunning it anyway | 11:55 |
| paulsherwood | locallycompact: small possibility that there's something in master that breaks your migration? hence the result (although correct) might not actually be achievable by anyone else on thier definitions? | 11:57 |
| locallycompact | we'll see in a bit | 11:57 |
| paulsherwood | ack | 11:57 |
| paulsherwood | jjardon: is that navit's official git resting place? we have 2 navit repos already | 11:58 |
| jjardon | thanks ssam2 ! | 11:58 |
| jjardon | paulsherwood: thats the current one, yes; they moved to github around june 2015 | 11:58 |
| *** ctbruce has quit IRC | 11:58 | |
| *** ctbruce has joined #baserock | 11:59 | |
| jjardon | paulsherwood: I didnt disable the other for the same reason: its being used in some system | 11:59 |
| paulsherwood | ack | 12:00 |
| paulsherwood | is lorry struggling on gcc, by any chance? | 12:10 |
| pedroalvarez | paulsherwood: I can have a look. Why are you asking? | 12:11 |
| paulsherwood | well upstream seems to keep moving, but it seems ours is 3 days old? | 12:12 |
| pedroalvarez | oh yes, it is struggling yes | 12:13 |
| pedroalvarez | seen this error before, never fixed it | 12:13 |
| pedroalvarez | http://paste.baserock.org/revutuleto | 12:13 |
| paulsherwood | hmmm | 12:14 |
| pedroalvarez | seems like `git remote update` runs `git gc` in background, making the latter `git gc` fail | 12:15 |
| pedroalvarez | we can disable that it seems | 12:16 |
| pedroalvarez | `git config --global gc.auto 0` | 12:16 |
| pedroalvarez | testing that solution now, if that works I'll send a patch | 12:18 |
| paulsherwood | +1, if you know what you're doing. i'm unable to comment competently on this | 12:18 |
| pedroalvarez | :) | 12:18 |
| richard_maw | wouldn't it be better to have some proper locking on the repo, so the parallel git processes don't all try to gc/update the same repo? | 12:25 |
| pedroalvarez | richard_maw: hm.. I don't know how to achieve that | 12:26 |
| richard_maw | there's some locking on the artifact cache in ybd | 12:27 |
| richard_maw | might be worth looking at that code | 12:27 |
| richard_maw | I also wrote http://yakking.branchable.com/posts/flocking/ | 12:28 |
| richard_maw | and I also wrote https://github.com/fishface60/python-flock after that article, to package up what I was doing | 12:29 |
| ssam2 | does Git not already do that? | 12:29 |
| ssam2 | seems like quite an oversight | 12:29 |
| richard_maw | ssam2: git uses locking to know when two processes could interfere | 12:30 |
| richard_maw | but it doesn't appear to have a mode to block until the other process has done the operation | 12:30 |
| richard_maw | to effectively coalesce the operation | 12:30 |
| ssam2 | right | 12:30 |
| ssam2 | I'm still not sure how Lorry could run a 'git gc' at the same time it's running 'git remote update' though | 12:31 |
| ssam2 | surely random Git processes doesn't fork in the background to GC ? | 12:31 |
| ssam2 | *don't | 12:31 |
| pedroalvarez | no no, it says that gc will run in the background | 12:32 |
| benbrown_ | "Auto packing the repository in background for optimum performance. | 12:32 |
| pedroalvarez | and then we run gc again, causing the failure | 12:32 |
| richard_maw | oh, damn, I had misinterpreted it as ybd's git cache or something | 12:32 |
| * benbrown_ wonders whether setting gc.autodetach to 0 would help? | 12:32 | |
| pedroalvarez | phew... | 12:33 |
| pedroalvarez | I didn't want to start doing sometihng complex right now | 12:33 |
| richard_maw | oh wow, I've never heard of gc.autodetach before | 12:33 |
| richard_maw | eww, why is that a feature‽ | 12:33 |
| paulsherwood | pedroalvarez: everything is complicated, here in the trenches :) | 12:33 |
| richard_maw | and why did they make that on by default‽ | 12:34 |
| richard_maw | eww | 12:34 |
| richard_maw | eww | 12:34 |
| richard_maw | eww | 12:34 |
| pedroalvarez | paulsherwood: I agree :) | 12:34 |
| pedroalvarez | indeed, eww | 12:34 |
| pedroalvarez | so, is `git config gc.auto 0` a good idea for you? | 12:35 |
| richard_maw | not exactly | 12:35 |
| pedroalvarez | I can also try/catch | 12:35 |
| richard_maw | since I prefer whenever possible, to avoid modifying state | 12:35 |
| ssam2 | gc.autodetach=0 seems like a winner to me | 12:35 |
| richard_maw | you probably want autogc | 12:35 |
| richard_maw | but not autodetach | 12:35 |
| richard_maw | git -c gc.autodetach=false remote update | 12:36 |
| richard_maw | gc.autodetach makes me want to swear | 12:36 |
| richard_maw | it's an ABI break FFS! | 12:36 |
| * richard_maw adds it to his mental list of tweaks to the git command that should be run in batch mode | 12:37 | |
| richard_maw | along with turning off git-replace | 12:37 |
| paulsherwood | well, i believe baserock has broken things from time to time too, so maybe we need to be tolerant :) | 12:37 |
| pedroalvarez | richard_maw: so, your suggestion is to: http://paste.baserock.org/itatituyec.diff | 12:40 |
| richard_maw | aye | 12:40 |
| pedroalvarez | good, thanks! | 12:41 |
| * richard_maw is angry at git now | 12:41 | |
| pedroalvarez | move to svn :P | 12:41 |
| richard_maw | pedroalvarez: I thought the goal was to become less angry | 12:41 |
| pedroalvarez | now you are less angry at git :) | 12:42 |
| jjardon | paulsherwood: how up-to-date is the ybd cache? | 12:45 |
| paulsherwood | it's populating now | 12:46 |
| paulsherwood | it was uptodate prior to the gcc change | 12:46 |
| paulsherwood | sorry glibc | 12:46 |
| paulsherwood | (take master ybd) | 12:46 |
| paulsherwood | 1 16-02-18 00:53:50 [295/963/969] [libpcap] Uploaded libpcap.23b0e91e96e886dbfd4e0abfa40438f6308ac7f6597d6eb870b9a0238b60019d to http://artifacts1.baserock.org:8000/upload | 12:47 |
| paulsherwood | will be uptodate with the glibc stuff in an hour or so, i think | 12:48 |
| richard_maw | paulsherwood: your tar problem is not with the python tarfile module, python is incapable of producing those messages, it's definitely the tar binary | 12:48 |
| jjardon | paulsherwood: all ci.morph? nice | 12:48 |
| paulsherwood | yup | 12:48 |
| paulsherwood | richard_maw: does the tarfile module use the tar binary? | 12:49 |
| richard_maw | no | 12:49 |
| richard_maw | but you use tar as part of extract | 12:49 |
| pedroalvarez | Patch for lorry sent. https://gerrit.baserock.org/#/c/1851 | 12:52 |
| paulsherwood | any thoughts on how to fix, richard_maw ? | 12:52 |
| richard_maw | converting your logic to extract with the tarfile module rather than the tar command would do it | 12:52 |
| richard_maw | there might be an option you can pass to tar to make it stop at the first write fail, but I haven't seen it | 12:53 |
| paulsherwood | it's not my logic :) | 12:54 |
| locallycompact | script finished https://github.com/locallycompact/definitions/commits/lc/defsv8nu | 12:54 |
| richard_maw | 7fa1b047 cache.py (Paul Sherwood 2015-08-30 19:30:41 +0000 133) if call(['tar', 'xf', tmpfile, '--directory', unpackdir]): | 12:55 |
| paulsherwood | ah, that's definitely mine! sorry, i was looking in the wrong place | 12:56 |
| paulsherwood | thanks! | 12:56 |
| paulsherwood | locallycompact: i'll kick off a build of that as soon as my curent one finishes | 13:15 |
| richard_maw | paulsherwood: oh, and I did a bit of digging, it's apparently desired behaviour for the version of tar you're using, that it does that | 13:29 |
| richard_maw | and no way to tell it not to | 13:30 |
| paulsherwood | well, it certainly catches the eye :) | 13:30 |
| *** gtristan has quit IRC | 13:32 | |
| *** gtristan has joined #baserock | 13:38 | |
| paulsherwood | eek 1 16-02-18 01:43:19 [859/963/969] [gnome-getting-started-docs] ERROR: git clone failed for e50ec428ee080513f059a5cab0a41174f99f0413 | 13:39 |
| paulsherwood | ah, ENOSPACE | 13:41 |
| paulsherwood | 20GB is no longer enough to build ci.morph | 13:42 |
| pedroalvarez | mwilliams_ct: I've created a story for the error you found. I hope I can get to it soon https://storyboard.baserock.org/#!/story/76 | 13:43 |
| mwilliams_ct | pedroalvarez: thanks :) | 13:44 |
| *** ctbruce has quit IRC | 14:04 | |
| benbrown_ | ooi, does gnome-system-x86_64 build from master of definitions? | 14:13 |
| paulsherwood | benbrown_: i'm testing that now | 14:17 |
| paulsherwood | do you believe it should not? | 14:17 |
| benbrown_ | paulsherwood: Just something in the morphology that I'd expect parsing to trip over | 14:17 |
| benbrown_ | "- name: strata/privileges-management" the name doesn't match up to what's in strata/privileges-management.morph | 14:18 |
| paulsherwood | ack. please send a patch? | 14:18 |
| *** ctbruce has joined #baserock | 14:19 | |
| benbrown_ | paulsherwood: done: https://gerrit.baserock.org/#/c/1855/ | 14:24 |
| jjardon | benbrown_: is that with morph or ybd? | 14:25 |
| paulsherwood | i think ybd managed to build it somehow, but still istm benbrown_'s patch is correct | 14:26 |
| jjardon | agree, trying to know if its a bug or not that morph manages to build that without any warnings | 14:27 |
| paulsherwood | we need to have the schema checking, lax first. then ratchet it up | 14:30 |
| locallycompact | words | 14:32 |
| pedroalvarez | jjardon: I think this patch will help preventing possible errors because of that | 14:37 |
| pedroalvarez | https://gerrit.baserock.org/#/c/1805/ | 14:37 |
| jjardon | ah, nice | 14:39 |
| jjardon | I wonder, could we remove the name: parameter from the list of strata in system morphologies (and only use the location of the morph file for all the strata?) | 14:40 |
| paulsherwood | ybd should support that our-of-the-box i think | 14:41 |
| paulsherwood | but it's a schema change | 14:42 |
| paulsherwood | which leads to a big topic... | 14:43 |
| jjardon | ok, what is the reason to be like it is now? compatibility with morph or another technical problem? | 14:43 |
| * tiagogomes_ notes that he attempted to that once but it broke morph | 14:43 | |
| paulsherwood | i want to do *LOADS* of changes to definitions schema, and i'd be happy to keep ybd uptodate with them, but i have no bandwidth/capability for fixing morph | 14:44 |
| paulsherwood | jjardon: backwards compatibility i think | 14:44 |
| jjardon | paulsherwood: include ybd in a baserock release, so we have a fallback? | 14:46 |
| paulsherwood | i'd be happy to. it's already lorried. not sure how others feel about it | 14:47 |
| ssam2 | jjardon: i still don't like the idea of removing 'name' field, it's useful in cases where the data is stored without a filename | 14:47 |
| ssam2 | paulsherwood: what it boils down to is: do you care about the Baserock definitions format being a shared standard (like the ANSI C standard, for example), or do you want a format that is an implementation detail of a specific tool (YBD) | 14:48 |
| paulsherwood | ssam2: i didn't like the idea either, originally - i hated the path soln. however based on actual definitions history, path is unavoidably the only way to key/index definitions | 14:48 |
| paulsherwood | ssam2: false dichotomy | 14:49 |
| ssam2 | why? | 14:49 |
| ssam2 | what other options are there? | 14:49 |
| paulsherwood | there already other tools parsing definitions | 14:49 |
| ssam2 | i'm not trying to imply that this means you should have to fix Morph, by the way | 14:49 |
| paulsherwood | afaik there are only two tools *building* from definitions so far | 14:50 |
| ssam2 | right, there are other tools parsing definitions, so do you have bandwidth to update the Import tool every time you change the format? do you have bandwidth to update the script that does syntax highlighting in cgit each time it changes? | 14:50 |
| paulsherwood | but ack | 14:50 |
| paulsherwood | oops. | 14:50 |
| paulsherwood | ack. | 14:50 |
| paulsherwood | i believe the preferable solution would be a library, that n tools can use | 14:50 |
| ssam2 | that would help a lot | 14:51 |
| paulsherwood | so, if such a library existed, how would it present definitions to consuming programs? | 14:51 |
| locallycompact | a library that converts what to what | 14:51 |
| ssam2 | i can't answer that usefully as an IRC message | 14:52 |
| paulsherwood | locallycompact: parses definitions (maybe validates them too), hands over an object that (say) build tools can use | 14:52 |
| paulsherwood | ssam2: fair enough :) | 14:52 |
| * paulsherwood previously wondered if the 'library' should be (say) some python code in the definitions repo itself | 14:54 | |
| paulsherwood | (since we already have scripts, and migrations) | 14:54 |
| ssam2 | would you want that library to be the canonical definition of what Baserock definitions are, or would you still be in favour of maintaining a spec (again, comparable to ANSI C standard or something) | 14:55 |
| ssam2 | (not comparable in complexity, obviously :-) | 14:55 |
| paulsherwood | i think the spec, and the library, should be colocated, to avoid breakage between moving parts | 14:56 |
| ssam2 | i would prefer the latter. and if that means we sometimes get to a situation where only some tools can understand definitions version 19, and others can only understand version 16, then so be it | 14:56 |
| paulsherwood | i prefer that there's a spec, too | 14:56 |
| ssam2 | as long as there is a spec, and it's possible to use an implementation other than the 'reference' implementation, then fine | 14:57 |
| ssam2 | otherwise, we risk the format becoming an implementation detail of that implementation, again | 14:57 |
| paulsherwood | agreed | 14:57 |
| paulsherwood | are you ok with the json-schema approach as spec? | 14:57 |
| ssam2 | that can form part of a spec | 14:57 |
| paulsherwood | what else is needed? | 14:57 |
| ssam2 | imagine trying to write a program that built Baserock definitions, given only a json-schema file | 14:58 |
| ssam2 | what other info would you need to write that program ? | 14:58 |
| ssam2 | mainly, a description of what each of the fields in the YAML files actually *mean* | 14:58 |
| edcragg | +1 a spec is a document, usually | 14:58 |
| ssam2 | it's all very well saying "the kind field can have values 'foo', 'bar', or 'baz'", but that doesn't help you understand what the 'kind' field actually means | 14:59 |
| paulsherwood | well, ok. so the documentation should be in the repo too :) | 15:00 |
| paulsherwood | (along with the examples, which already exist) | 15:00 |
| ssam2 | yes, that would be fine | 15:00 |
| paulsherwood | cool :) | 15:00 |
| paulsherwood | now to work out how to make it so :) | 15:01 |
| perryl | so i've been looking into reproducible builds again, and using the diffoscope tool on artifacts from build-essential, and i've found that gcc:x86_64-unknown-linux-gnu/4.9.2/cc1 has a diff file that's 110507 lines long \o/ and libstdc++.a diff is a whopping 261957 lines \o/ | 15:05 |
| ssam2 | do those files have debug info included ? | 15:06 |
| paulsherwood | locallycompact: i've tested your branch, i'll be +1 once you put it in gerrit | 15:06 |
| ssam2 | debug info usually includes the full path to each source file that was built | 15:06 |
| perryl | ssam2: cc1 doesn't afaict, it seems to just be miniscule filesize changes in headers and minor address changes | 15:06 |
| ssam2 | although that should be consistent in Baserock, since we built in a chroot.. | 15:06 |
| ssam2 | right | 15:06 |
| perryl | ssam2: i've got a bit of cc1 diff output here if you want to check it out http://paste.baserock.org/uxesitohal | 15:07 |
| perryl | libstdc++ may; it seems to be including file lists and permissions, and hardcoding build-dates that way | 15:08 |
| jjardon | ok, storage-management is next | 15:12 |
| perryl | the worst thing about these files is they're so huge it's hard to assume what the full contents are...7704 lines into libstdc++.a's diffoscope output looks to mostly be header size/address data, but then that's only 2% of the whole file checked :( | 15:13 |
| ssam2 | also the information is total gibberish | 15:15 |
| ssam2 | well, almost total | 15:15 |
| ssam2 | maybe there are toolchain patches that would fix this? i'm sure debian-reproducible must have solved this already | 15:15 |
| perryl | i would assume so; or that there are certain file extensions they don't bother to examine? | 15:17 |
| ssam2 | i very much doubt that | 15:18 |
| ssam2 | certainly they will be examining the toolchain itself | 15:18 |
| * perryl pops over to #debian-reproducible to investigate | 15:19 | |
| perryl | also an output of over a quarter of a million lines seems ludicrous | 15:19 |
| ssam2 | https://tests.reproducible-builds.org/rb-pkg/unstable/amd64/gcc-4.9.html | 15:19 |
| ssam2 | seems their gcc is not quite reproducible, but the differences are in the hundreds, not tens of thousands | 15:19 |
| paulsherwood | what does 'cannot merge' mean in gerrit? | 15:20 |
| perryl | seems to be 4.9.3 so slightly ahead of what i've been building | 15:20 |
| ssam2 | paulsherwood: it means gerrit is dumb. it might been you need to rebase | 15:20 |
| ssam2 | or it might mean that you are trying to merge a patch that depends on something unmerged | 15:21 |
| paulsherwood | ok, thanks ssam2 | 15:21 |
| mwilliams_ct | probably silly question time: I managed to find a generic trove image from last July and have deployed on Openstack manually until pedroalvarez can fix the problems I saw earlier. now though, I've made some lorry config files. lorry is creating delta/reponame.git for the repos in question, but they are both empty | 15:27 |
| mwilliams_ct | is there something I need to set elsewhere to make sure lorry clones? | 15:27 |
| pedroalvarez | hm.. it should work as it is | 15:29 |
| pedroalvarez | mwilliams_ct: you can try to access to the lorry controller control panel (I just made that name up) | 15:29 |
| mwilliams_ct | lc-status.html? | 15:29 |
| pedroalvarez | if you do `ssh -L 12765:localhost:12765 root@<IP>` | 15:30 |
| pedroalvarez | and you leave that connection open | 15:31 |
| pedroalvarez | you will be able to open a browser and go to localhost:12765/1.0/status-html | 15:31 |
| locallycompact | The sign in/signup whatever doesn't work on gerrit.baserock | 15:36 |
| mwilliams_ct | for anyone playing along at home (ie me googling this in six months), the problem was that /home/lorry/working-area was owned by root. thanks benbrown_ and pedroalvarez for the help! | 15:36 |
| mwilliams_ct | anyway chowning, chgrping fixed everythin | 15:37 |
| mwilliams_ct | which means I have earned a nice cup of tea | 15:37 |
| pedroalvarez | mwilliams_ct: btw, to force it to lorry agan `curl -X POST -d path=delta/gcc http://localhost:12765/1.0/move-to-top` in the trove | 15:37 |
| pedroalvarez | locallycompact: do you get any errors? | 15:38 |
| locallycompact | Server Error (500) | 15:38 |
| locallycompact | @ https://openid.baserock.org/openid/ | 15:38 |
| pedroalvarez | that's weird | 15:39 |
| pedroalvarez | that's broken | 15:40 |
| locallycompact | I'll use the list | 15:40 |
| pedroalvarez | thanks for trying though :) | 15:40 |
| pedroalvarez | I'll let you know whenever we are ready for your next try | 15:41 |
| *** ssam2 has quit IRC | 15:44 | |
| *** ssam2 has joined #baserock | 15:55 | |
| *** ChanServ sets mode: +v ssam2 | 15:55 | |
| ratmice | perryl: beyond the debian patches, also noticed https://gcc.gnu.org/wiki/Randomization | 16:03 |
| perryl | ratmice: oh, that could explain some of the differences, yeah...if it's expecting one line which is somewhere completely different, that could probably be fixed by modifying gcc.morph? | 16:05 |
| jjardon | is there any reason why trove builds lua instead depend on the lua stratum? | 16:08 |
| paulsherwood | jjardon: its use of lua may pre-date the lua stratum | 16:09 |
| ratmice | maybe, not sure if it can be fixed from the morph file or requires some coordination with the build tool depends on shell spawning semantics i don't know off hand | 16:09 |
| ssam2 | jjardon: no reason I know of | 16:09 |
| ssam2 | Sorry for the openid.baserock.org breakage, it should be fixed now | 16:09 |
| ssam2 | the problem is that the django-openid-provider module is more or less abandoned, so there are some fixups needed now we have upgraded to django 1.9 | 16:10 |
| paulsherwood | ssam2: abandoned, in favour of something else? | 16:10 |
| ssam2 | i don't think so, no, just not maintained | 16:12 |
| ssam2 | if I had infinite time I'd set up a fork and push all our local fixes to it | 16:12 |
| ssam2 | but I still have about 9 other machines to upgrade | 16:12 |
| paulsherwood | :) | 16:13 |
| paulsherwood | ssam2: maybe i need to find you an underling? :) | 16:13 |
| mwilliams_ct | would that be ssam3 or ssam2junior (or ssam2nior)? | 16:13 |
| locallycompact | paulsherwood, what's this doing https://github.com/devcurmudgeon/ybd/blob/master/ybd/definitions.py#L33-L38 | 16:14 |
| paulsherwood | ssamling | 16:14 |
| pedroalvarez | mwilliams_ct: that was a good one :) | 16:14 |
| mwilliams_ct | :) | 16:14 |
| mwilliams_ct | I must tell you my switzerland joke sometime... | 16:14 |
| paulsherwood | locallycompact: when i originally proposed a schema, that code worked with it | 16:15 |
| *** ssam2 has quit IRC | 16:16 | |
| locallycompact | that was a single schema file? | 16:17 |
| paulsherwood | locallycompact: https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-May/013051.html | 16:17 |
| paulsherwood | yes | 16:17 |
| paulsherwood | iiuc the actual schema content in definitions was originated by ssam, not sure if he considered my stuff | 16:18 |
| *** ssam2 has joined #baserock | 16:19 | |
| *** ChanServ sets mode: +v ssam2 | 16:19 | |
| paulsherwood | anyone have netsurf running on a reasonably powerful machine? | 16:35 |
| ssam2 | tlsa seems absent from this channel | 16:38 |
| paulsherwood | never mind... seems concourse doesn't play nice in netsurf | 16:38 |
| paulsherwood | ssam2: i assume you saw my previous comment 16:18 < paulsherwood> iiuc the actual schema content in definitions was originated by ssam, not sure if he considered my stuff | 16:39 |
| ssam2 | i didn't see that | 16:39 |
| ssam2 | what was the context? | 16:39 |
| locallycompact | <locallycompact> paulsherwood, what's this doing https://github.com/devcurmudgeon/ybd/blob/master/ybd/definitions.py#L33-L38 | 16:40 |
| locallycompact | + https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-May/013051.html | 16:40 |
| paulsherwood | 16:15 < paulsherwood> locallycompact: when i originally proposed a schema, that code worked with it | 16:40 |
| ssam2 | i see. I just added json-schema schemas, I didn't update any build tools to make use of them | 16:40 |
| paulsherwood | ack. i wonder if there's any possibility to re-open this and go for one schema file instead of several? | 16:41 |
| locallycompact | I'm not sure that's clearer | 16:41 |
| paulsherwood | ok | 16:41 |
| ssam2 | the reason there's 4 schema files instead of one is that if we merged the 4 schema files into one, json-schema would give totally useless error messages | 16:41 |
| paulsherwood | alright, i demur to wiser folks | 16:42 |
| paulsherwood | thanks | 16:42 |
| ssam2 | unless we produced one schema files that was the minimal combination of all four, but that seems a bit pointless as it would catch way fewer errors | 16:42 |
| ssam2 | *file | 16:42 |
| paulsherwood | locallycompact: any chance you could submit your submodules stuff to gerrit? | 16:44 |
| ssam2 | ANNOUNCMENT: Baserock infrastructure will be a bit broken for the next 15 minutes or so, I need to upgrade the database | 16:44 |
| locallycompact | paulsherwood, after that ^ :) | 16:44 |
| paulsherwood | ack | 16:44 |
| ssam2 | another 15 minutes or so, mail relay is done but not yet database | 17:06 |
| paulsherwood | ack | 17:06 |
| paulsherwood | win 43 | 17:07 |
| paulsherwood | bah | 17:07 |
| *** ctbruce has quit IRC | 17:18 | |
| *** tiagogomes_ has quit IRC | 17:23 | |
| *** jmacs has joined #baserock | 17:31 | |
| ssam2 | Everything should be working again | 17:33 |
| ssam2 | Still more stuff to upgrade, but shouldn't be as disruptive | 17:34 |
| paulsherwood | w00t :) | 17:34 |
| jjardon | thanks ssam2 ! | 17:34 |
| paulsherwood | rjek: are lua versions not backwards compatible? jjardon is proposing a lua51 stratum | 17:40 |
| locallycompact | Why does gerrit feel the need to fill my commit message with shit? | 17:44 |
| pedroalvarez | it needs that shit to make some magic happen | 17:45 |
| pedroalvarez | :) | 17:45 |
| pedroalvarez | is not too annoying though.. I hope | 17:45 |
| locallycompact | well it didn't work anyway | 17:46 |
| locallycompact | https://paste.fedoraproject.org/324948/14558175/ | 17:46 |
| paulsherwood | locallycompact: get the uncommitted files, and create new commits, i think | 17:47 |
| locallycompact | are you joking | 17:47 |
| paulsherwood | (assuming you've got the change-id hook magic) | 17:47 |
| franred | or rebase | 17:47 |
| paulsherwood | i'm not joking, it's worked for me :) | 17:48 |
| SotK | doesn't git commit --amend work? | 17:48 |
| paulsherwood | no, that has not worked for me | 17:48 |
| franred | SotK, AFAIK locallycompact has 2 commits to submit anyway | 17:48 |
| paulsherwood | but i may have been in a different hole | 17:48 |
| franred | locallycompact, if you have the gerrit hook, rebase your branch against master should do the trick | 17:49 |
| * SotK recommends git-review | 17:49 | |
| franred | locallycompact, you could check if it works before pushing checking that your commit messages have a ID:XXXXXXXXX | 17:49 |
| franred | SotK, that too | 17:49 |
| paulsherwood | gerrit can get confused if there's something under the ID: XX thing too | 17:50 |
| pedroalvarez | SotK: +1 | 17:50 |
| locallycompact | rebase did not owrk | 17:51 |
| richard_maw | paulsherwood: Lua is basically a completely different language for every major version (4.x vs 5.x), minor versions are similar languages that you could write something that works for both, but lua 5.0 and 5.1 are as similar as python2 is to python3 | 17:51 |
| pedroalvarez | gerrit for newbies: `pip install git-review; git review -R` | 17:51 |
| paulsherwood | richard_maw: tvm | 17:51 |
| *** jonathanmaw has quit IRC | 17:57 | |
| edcragg | locallycompact: `git rebase -i` and 'reword' each commit | 17:59 |
| edcragg | if you have the hook | 17:59 |
| locallycompact | gonna have to rerun the migration anyway master changed | 18:00 |
| * richard_maw would have preferred the Commit message for #1860 to be (without typos and) expanded to include a description of how different lua versions are, and a justification that luajit2 is an implementation of lua5.1 so should be under strata/lua51 | 18:00 | |
| * richard_maw was too slow to comment | 18:00 | |
| * richard_maw just worries that now the context that was in the IRC discussion has been lost to posterity | 18:01 | |
| ssam2 | indeed | 18:01 |
| jjardon | paulsherwood: ssam2 thanks for all the reviews! | 18:04 |
| jjardon | richard_maw: you can still send a patch to improve the stratum description maybe? | 18:05 |
| ssam2 | it's not really richard_maw's job to fix your commit messages :-) | 18:05 |
| paulsherwood | heh | 18:05 |
| jjardon | commit messages can not be fixed anymore, but the description: in the stratum still can | 18:07 |
| ssam2 | actually the stratum description is better than a commit message, too | 18:07 |
| ssam2 | i'm about to reboot a bunch of machines at baserock.org, there will be a couple of minutes downtime | 18:07 |
| ssam2 | ok, all working again | 18:10 |
| paulsherwood | +1 for the description | 18:18 |
| *** locallycompact has quit IRC | 18:32 | |
| rjek | paulsherwood: Major releases are not backwards compatible. (This is part of the reason it is tiny: no baggage) | 18:48 |
| *** rdale has quit IRC | 18:48 | |
| paulsherwood | rjek: ack, thanks | 18:49 |
| rjek | 5.1.0 and 5.2.0 are different major revisions, jjardon is taking the right approach | 18:49 |
| *** CTtpollard has quit IRC | 19:05 | |
| *** Lachlan1975 has quit IRC | 19:22 | |
| *** ssam2 has quit IRC | 19:23 | |
| *** edcragg has quit IRC | 19:36 | |
| *** richard_1aw has joined #baserock | 20:09 | |
| *** richard_maw has quit IRC | 20:12 | |
| *** toscalix has quit IRC | 20:36 | |
| *** edcragg has joined #baserock | 21:57 | |
| paulsherwood | i'm working on a new general theory of software productivity... | 22:17 |
| paulsherwood | so far may base premise is 'if backports > updates then goto hell' | 22:18 |
| paulsherwood | jjardon: any ideas about this (master ci.morph, armv7hlf) http://paste.baserock.org/oxifazujus | 22:20 |
| paulsherwood | sorry, x86_64 | 22:22 |
| jjardon | paulsherwood: yeah, seems I forgot to push one of the patches; will fix when I get home; gudev lives in networkmanager-common and it has to be moved to a common stratum | 22:32 |
| paulsherwood | no rush | 22:33 |
| * paulsherwood => sleep | 22:33 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!