IRC logs for #baserock for Thursday, 2016-02-18

*** bwh_ has joined #baserock00:47
*** bwh has quit IRC00:48
*** bwh_ is now known as bwh00:49
*** edcragg has quit IRC01:16
*** gtristan has quit IRC04:25
*** gtristan has joined #baserock04:42
*** CTtpollard has joined #baserock07:58
*** paulw has joined #baserock08:29
*** perryl has joined #baserock08:46
*** tiagogomes_ has joined #baserock08:55
*** edcragg has joined #baserock08:57
*** ctbruce has joined #baserock09:04
*** edcragg has quit IRC09:18
*** edcragg has joined #baserock09:35
*** jonathanmaw has joined #baserock09:47
*** toscalix has joined #baserock09:51
*** rdale has joined #baserock09:52
mwilliams_ctHey! I mentioned yesterday I couldnt convince trove to deploy to openstack and pasted . ybd is also giving the same issue09:57
mwilliams_ctssam2 suggested deploying to a rawdisk which worked fine09:57
pedroalvarezthat's weird...09:58
pedroalvarezI mean, when deploying to openstack, openstack.write extension creates a rawdisk image09:58
pedroalvarezso if the latter worked, former should09:59
* pedroalvarez goes to see the log09:59
paulsherwoodpedroalvarez: while you're on, any thoughts on ?10:00
paulsherwooddoes that script now depend on specific content/format in metafiles?10:00
*** benbrown_ has joined #baserock10:02
*** ssam2 has joined #baserock10:03
*** ChanServ sets mode: +v ssam210:03
pedroalvarezpaulsherwood: yeah, it depends on metafiles being json files10:03
*** benbrown_ has quit IRC10:03
*** benbrown_ has joined #baserock10:04
paulsherwoodrdale: aren't ybd's metafiles json, now?10:04
pedroalvarezand it needs the files of the artifact listed in the metafile too, in some way10:05
rdaleno, they're yaml10:05
pedroalvarezregarding "does that script now depend on.. ", nope, that has been the case since it was created I believe10:06
paulsherwoodpedroalvarez: json is a subset of yaml, iiuc. would it make sense to adapt it to deal with yaml?10:06
paulsherwoodit may be that ybd has never been able to run that script, then :)10:07
pedroalvarezpaulsherwood: that would make sense10:07
paulsherwoodok, i'll take a look, thanks10:07
pedroalvarezI'd like them to have a similar structure though10:07
paulsherwoodwe can all dream :)10:08
rdalethere 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 format10:09
paulsherwoodi'm not going to try, sorry.10:09
rdalei agree there isn't much point10:11
rdaleexcept inter operating with spdx perhaps10:11
paulsherwoodthat would be cool10:12
paulsherwoodand may ultimately be a requirement10:12
pedroalvarezmwilliams_ct: I think I may know where your problem is. I'll try to help you in a moment :)10:21
mwilliams_ctthanks pedroalvarez :D10:22
*** gtristan has quit IRC10:26
*** Lachlan1975 has joined #baserock10:27
*** Lachlan1975 has quit IRC10:33
*** franred has joined #baserock10:38
*** locallycompact has joined #baserock10:40
*** Lachlan1975 has joined #baserock10:47
*** gtristan has joined #baserock11:05
*** tiagogomes_ has quit IRC11:07
*** tiagogomes_ has joined #baserock11:19
paulsherwoodis there any way (in python) to stop tar generating a flood of errors on ENOSPACE?11:21
richard_mawpaulsherwood: is this with the tarfile module, or running tar in a subprocess?11:22
paulsherwoodwith tarfile11:23
richard_mawpaulsherwood: got a log snippet I can look at?11:24
paulsherwoodthe code is at
ssam2I upgraded a devel system to master of definitions (plus glibc patch) and my prompt is no longer colourful :-(11:27
paulsherwoodssam2: think yourself lucky. i upgraded my laptop a few months ago, and all of my baserock vms no longer work :/11:28
paulsherwoodiirc Kinnison described my problem as 'interesting'11:28
ssam2GLIBC update seems to work, anyone fancy giving another +1 ?11:31
franredssam2, done11:32
locallycompacthere's a new whatsit whats less badder
locallycompactthat migration library is very good thanks11:34
pedroalvarezlocallycompact: just spotted a "+  submodules: {}"11:36
locallycompactyeah that's because kafka-python has an empty .gitmodules file11:36
locallycompactI'm tempted to just leave it11:37
pedroalvarezalso, I wonder if the migration handles recursive submodules11:37
pedroalvarez(dunno if "recursive" is the right word here)11:38
locallycompactmigration doesn't handle nested submodules because we don't have any, but the schema supports and ybd supports building them11:38
paulsherwoodlocallycompact: on your branch. '0 16-02-18 00:00:37 [0/41/574] [polkit] ERROR: No definition found for polkit'11:41
paulsherwoodwith master ybd, building ci.morph?11:41
* paulsherwood needs to get the schema validation integrated into ybd... that error is not very helpful11:42
*** cosm has quit IRC11:42
paulsherwoodlocallycompact: presumably you tested different build targets?11:42
paulsherwoodactually, maybe this is a hold-over from jjardon's recent work11:43
locallycompactI'll test as fast as my cpu can go11:45
locallycompactBut if anything is failing because submodules then everything should be11:45
paulsherwoodlocallycompact: yup, this issue is not with your changes11:45
locallycompactpaulsherwood, is ybd rebuilding everything because I changed the VERSION file?11:45
paulsherwoodpls could you re-run your migration against master?11:45
locallycompactthis was against master11:46
locallycompactas of 5pm yesterday11:46
paulsherwoodpls hold11:46
paulsherwoodmaster now is not the same as master then11:47
locallycompactwill rerun11:47
paulsherwoodshouldn't be different, but hey :)11:48
paulsherwoods/different/a different result/11:48
locallycompactstunningly, that rebases.
jjardonHi, ok to lorry this stuff and ?11:50
jjardonpaulsherwood: that's fixed in master11:50
paulsherwoodlocallycompact: rebase is not the same operation as re-running your migration11:50
paulsherwoodlocallycompact: it *might* have the same result, but it's not the same thing11:51
paulsherwoodjjardon: don't we already have lua?11:51
locallycompactif it weren't the same result it would have conflicted11:51
jjardonpaulsherwood: we have, but from and old repo thats is not being updated anymore11:52
paulsherwoodlocallycompact: i don't know what you mean, sorry11:52
paulsherwoodjjardon: ok, do we need to move it to -disabled ?11:52
ssam2Artifacts should now be available on for a devel system built against patched GLIBC11:52
paulsherwoodssam2: when did you start that process, fwiw?11:52
paulsherwood(ie how long did it take to do)11:53
ssam2yesterday morning11:53
jjardonpaulsherwood: Id like to, but the repo is being used by some strata/systems11:53
ssam2but it probably finished a few hours after I went home11:53
jjardonwe could when we migrate all of them11:53
paulsherwoodjjardon: ah, ok11:54
locallycompactpaulsherwood, 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
locallycompactStill I'm rerunning it anyway11:55
paulsherwoodlocallycompact: 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
locallycompactwe'll see in a bit11:57
paulsherwoodjjardon: is that navit's official git resting place? we have 2 navit repos already11:58
jjardonthanks ssam2 !11:58
jjardonpaulsherwood: thats the current one, yes; they moved to github around june 201511:58
*** ctbruce has quit IRC11:58
*** ctbruce has joined #baserock11:59
jjardonpaulsherwood: I didnt disable the other for the same reason: its being used in some system11:59
paulsherwoodis lorry struggling on gcc, by any chance?12:10
pedroalvarezpaulsherwood: I can have a look. Why are you asking?12:11
paulsherwoodwell upstream seems to keep moving, but it seems ours is 3 days old?12:12
pedroalvarezoh yes, it is struggling yes12:13
pedroalvarezseen this error before, never fixed it12:13
pedroalvarezseems like `git remote update` runs `git gc` in background, making the latter `git gc` fail12:15
pedroalvarezwe can disable that it seems12:16
pedroalvarez`git config --global 0`12:16
pedroalvareztesting that solution now, if that works I'll  send a patch12:18
paulsherwood+1, if you know what you're doing. i'm unable to comment competently on this12:18
richard_mawwouldn'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
pedroalvarezrichard_maw: hm.. I don't know how to achieve that12:26
richard_mawthere's some locking on the artifact cache in ybd12:27
richard_mawmight be worth looking at that code12:27
richard_mawI also wrote
richard_mawand I also wrote after that article, to package up what I was doing12:29
ssam2does Git not already do that?12:29
ssam2seems like quite an oversight12:29
richard_mawssam2: git uses locking to know when two processes could interfere12:30
richard_mawbut it doesn't appear to have a mode to block until the other process has done the operation12:30
richard_mawto effectively coalesce the operation12:30
ssam2I'm still not sure how Lorry could run a 'git gc' at the same time it's running 'git remote update' though12:31
ssam2surely random Git processes doesn't fork in the background to GC ?12:31
pedroalvarezno no, it says that gc will run in the background12:32
benbrown_"Auto packing the repository in background for optimum performance.12:32
pedroalvarezand then we run gc again, causing the failure12:32
richard_mawoh, damn, I had misinterpreted it as ybd's git cache or something12:32
* benbrown_ wonders whether setting gc.autodetach to 0 would help?12:32
pedroalvarezI didn't want to start doing sometihng complex right now12:33
richard_mawoh wow, I've never heard of gc.autodetach before12:33
richard_maweww, why is that a featureā€½12:33
paulsherwoodpedroalvarez: everything is complicated, here in the trenches :)12:33
richard_mawand why did they make that on by defaultā€½12:34
pedroalvarezpaulsherwood: I agree :)12:34
pedroalvarezindeed, eww12:34
pedroalvarezso, is  `git config 0` a good idea for you?12:35
richard_mawnot exactly12:35
pedroalvarezI can also try/catch12:35
richard_mawsince I prefer whenever possible, to avoid modifying state12:35
ssam2gc.autodetach=0 seems like a winner to me12:35
richard_mawyou probably want autogc12:35
richard_mawbut not autodetach12:35
richard_mawgit -c gc.autodetach=false remote update12:36
richard_mawgc.autodetach makes me want to swear12:36
richard_mawit'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 mode12:37
richard_mawalong with turning off git-replace12:37
paulsherwoodwell, i believe baserock has broken things from time to time too, so maybe we need to be tolerant :)12:37
pedroalvarezrichard_maw: so, your suggestion is to:
pedroalvarezgood, thanks!12:41
* richard_maw is angry at git now12:41
pedroalvarezmove to svn :P12:41
richard_mawpedroalvarez: I thought the goal was to become less angry12:41
pedroalvareznow you are less angry at git :)12:42
jjardonpaulsherwood: how up-to-date is the ybd cache?12:45
paulsherwoodit's populating now12:46
paulsherwoodit was uptodate prior to the gcc change12:46
paulsherwoodsorry glibc12:46
paulsherwood(take master ybd)12:46
paulsherwood1 16-02-18 00:53:50 [295/963/969] [libpcap] Uploaded libpcap.23b0e91e96e886dbfd4e0abfa40438f6308ac7f6597d6eb870b9a0238b60019d to
paulsherwoodwill be uptodate with the glibc stuff in an hour or so, i think12:48
richard_mawpaulsherwood: your tar problem is not with the python tarfile module, python is incapable of producing those messages, it's definitely the tar binary12:48
jjardonpaulsherwood: all ci.morph? nice12:48
paulsherwoodrichard_maw: does the tarfile module use the tar binary?12:49
richard_mawbut you use tar as part of extract12:49
pedroalvarezPatch for lorry sent.
paulsherwoodany thoughts on how to fix, richard_maw ?12:52
richard_mawconverting your logic to extract with the tarfile module rather than the tar command would do it12:52
richard_mawthere might be an option you can pass to tar to make it stop at the first write fail, but I haven't seen it12:53
paulsherwoodit's not my logic :)12:54
locallycompactscript finished
richard_maw7fa1b047     (Paul Sherwood      2015-08-30 19:30:41 +0000 133)     if call(['tar', 'xf', tmpfile, '--directory', unpackdir]):12:55
paulsherwoodah, that's definitely mine! sorry, i was looking in the wrong place12:56
paulsherwoodlocallycompact: i'll kick off a build of that as soon as my curent one finishes13:15
richard_mawpaulsherwood: oh, and I did a bit of digging, it's apparently desired behaviour for the version of tar you're using, that it does that13:29
richard_mawand no way to tell it not to13:30
paulsherwoodwell, it certainly catches the eye :)13:30
*** gtristan has quit IRC13:32
*** gtristan has joined #baserock13:38
paulsherwoodeek 1 16-02-18 01:43:19 [859/963/969] [gnome-getting-started-docs] ERROR: git clone failed for e50ec428ee080513f059a5cab0a41174f99f041313:39
paulsherwoodah, ENOSPACE13:41
paulsherwood20GB is no longer enough to build ci.morph13:42
pedroalvarezmwilliams_ct: I've created a story for the error you found. I hope I can get to it soon!/story/7613:43
mwilliams_ctpedroalvarez: thanks :)13:44
*** ctbruce has quit IRC14:04
benbrown_ooi, does gnome-system-x86_64 build from master of definitions?14:13
paulsherwoodbenbrown_: i'm testing that now14:17
paulsherwooddo you believe it should not?14:17
benbrown_paulsherwood: Just something in the morphology that I'd expect parsing to trip over14:17
benbrown_"- name: strata/privileges-management" the name doesn't match up to what's in strata/privileges-management.morph14:18
paulsherwoodack. please send a patch?14:18
*** ctbruce has joined #baserock14:19
benbrown_paulsherwood: done:
jjardonbenbrown_: is that with morph or ybd?14:25
paulsherwoodi think ybd managed to build it somehow, but still istm benbrown_'s patch is correct14:26
jjardonagree, trying to know if its a bug or not that morph manages to build that without any warnings14:27
paulsherwoodwe need to have the schema checking, lax first. then ratchet it up14:30
pedroalvarezjjardon: I think this patch will help preventing possible errors because of that14:37
jjardonah, nice14:39
jjardonI 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
paulsherwoodybd should support that our-of-the-box i think14:41
paulsherwoodbut it's a schema change14:42
paulsherwoodwhich leads to a big topic...14:43
jjardonok, 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 morph14:43
paulsherwoodi 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 morph14:44
paulsherwoodjjardon: backwards compatibility i think14:44
jjardonpaulsherwood: include ybd in a baserock release, so we have a fallback?14:46
paulsherwoodi'd be happy to. it's already lorried. not sure how others feel about it14:47
ssam2jjardon: i still don't like the idea of removing 'name' field, it's useful in cases where the data is stored without a filename14:47
ssam2paulsherwood: 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
paulsherwoodssam2: 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 definitions14:48
paulsherwoodssam2: false dichotomy14:49
ssam2what other options are there?14:49
paulsherwoodthere already other tools parsing definitions14:49
ssam2i'm not trying to imply that this means you should have to fix Morph, by the way14:49
paulsherwoodafaik there are only two tools *building* from definitions so far14:50
ssam2right, 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
paulsherwoodbut ack14:50
paulsherwoodi believe the preferable solution would be a library, that n tools can use14:50
ssam2that would help a lot14:51
paulsherwoodso, if such a library existed, how would it present definitions to consuming programs?14:51
locallycompacta library that converts what to what14:51
ssam2i can't answer that usefully as an IRC message14:52
paulsherwoodlocallycompact: parses definitions (maybe validates them too), hands over an object that (say) build tools can use14:52
paulsherwoodssam2: fair enough :)14:52
* paulsherwood previously wondered if the 'library' should be (say) some python code in the definitions repo itself14:54
paulsherwood(since we already have scripts, and migrations)14:54
ssam2would 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
paulsherwoodi think the spec, and the library, should be colocated, to avoid breakage between moving parts14:56
ssam2i 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 it14:56
paulsherwoodi prefer that there's a spec, too14:56
ssam2as long as there is a spec, and it's possible to use an implementation other than the 'reference' implementation, then fine14:57
ssam2otherwise, we risk the format becoming an implementation detail of that implementation, again14:57
paulsherwoodare you ok with the json-schema approach as spec?14:57
ssam2that can form part of a spec14:57
paulsherwoodwhat else is needed?14:57
ssam2imagine trying to write a program that built Baserock definitions, given only a json-schema file14:58
ssam2what other info would you need to write that program ?14:58
ssam2mainly, a description of what each of the fields in the YAML files actually *mean*14:58
edcragg+1 a spec is a document, usually14:58
ssam2it'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 means14:59
paulsherwoodwell, ok. so the documentation should be in the repo too :)15:00
paulsherwood(along with the examples, which already exist)15:00
ssam2yes, that would be fine15:00
paulsherwoodcool :)15:00
paulsherwoodnow to work out how to make it so :)15:01
perrylso 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
ssam2do those files have debug info included ?15:06
paulsherwoodlocallycompact: i've tested your branch, i'll be +1 once you put it in gerrit15:06
ssam2debug info usually includes the full path to each source file that was built15:06
perrylssam2: cc1 doesn't afaict, it seems to just be miniscule filesize changes in headers and minor address changes15:06
ssam2although that should be consistent in Baserock, since we built in a chroot..15:06
perrylssam2: i've got a bit of cc1 diff output here if you want to check it out
perryllibstdc++ may; it seems to be including file lists and permissions, and hardcoding build-dates that way15:08
jjardonok, storage-management is next15:12
perrylthe 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
ssam2also the information is total gibberish15:15
ssam2well, almost total15:15
ssam2maybe there are toolchain patches that would fix this? i'm sure debian-reproducible must have solved this already15:15
perryli would assume so; or that there are certain file extensions they don't bother to examine?15:17
ssam2i very much doubt that15:18
ssam2certainly they will be examining the toolchain itself15:18
* perryl pops over to #debian-reproducible to investigate15:19
perrylalso an output of over a quarter of a million lines seems ludicrous15:19
ssam2seems their gcc is not quite reproducible, but the differences are in the hundreds, not tens of thousands15:19
paulsherwoodwhat does 'cannot merge' mean in gerrit?15:20
perrylseems to be 4.9.3 so slightly ahead of what i've been building15:20
ssam2paulsherwood: it means gerrit is dumb. it might been you need to rebase15:20
ssam2or it might mean that you are trying to merge a patch that depends on something unmerged15:21
paulsherwoodok, thanks ssam215:21
mwilliams_ctprobably 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 empty15:27
mwilliams_ctis there something I need to set elsewhere to make sure lorry clones?15:27
pedroalvarezhm.. it should work as it is15:29
pedroalvarezmwilliams_ct: you can try to access to the lorry controller control panel (I just made that name up)15:29
pedroalvarezif you do `ssh -L 12765:localhost:12765 root@<IP>`15:30
pedroalvarezand you leave that connection open15:31
pedroalvarezyou will be able to open a browser and go to localhost:12765/1.0/status-html15:31
locallycompactThe sign in/signup whatever doesn't work on gerrit.baserock15:36
mwilliams_ctfor 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_ctanyway chowning, chgrping fixed everythin15:37
mwilliams_ctwhich means I have earned a nice cup of tea15:37
pedroalvarezmwilliams_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 trove15:37
pedroalvarezlocallycompact: do you get any errors?15:38
locallycompactServer Error (500)15:38
pedroalvarezthat's weird15:39
pedroalvarezthat's broken15:40
locallycompactI'll use the list15:40
pedroalvarezthanks for trying though :)15:40
pedroalvarezI'll let you know whenever we are ready for your next try15:41
*** ssam2 has quit IRC15:44
*** ssam2 has joined #baserock15:55
*** ChanServ sets mode: +v ssam215:55
ratmiceperryl: beyond the debian patches, also noticed
perrylratmice: 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
jjardonis there any reason why trove builds lua instead depend on the lua stratum?16:08
paulsherwoodjjardon: its use of lua may pre-date the lua stratum16:09
ratmicemaybe, 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 hand16:09
ssam2jjardon: no reason I know of16:09
ssam2Sorry for the breakage, it should be fixed now16:09
ssam2the 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.916:10
paulsherwoodssam2: abandoned, in favour of something else?16:10
ssam2i don't think so, no, just not maintained16:12
ssam2if I had infinite time I'd set up a fork and push all our local fixes to it16:12
ssam2but I still have about 9 other machines to upgrade16:12
paulsherwoodssam2: maybe i need to find you an underling? :)16:13
mwilliams_ctwould that be ssam3 or ssam2junior (or ssam2nior)?16:13
locallycompactpaulsherwood, what's this doing
pedroalvarezmwilliams_ct: that was a good one :)16:14
mwilliams_ctI must tell you my switzerland joke sometime...16:14
paulsherwoodlocallycompact: when i originally proposed a schema, that code worked with it16:15
*** ssam2 has quit IRC16:16
locallycompactthat was a single schema file?16:17
paulsherwoodiiuc the actual schema content in definitions was originated by ssam, not sure if he considered my stuff16:18
*** ssam2 has joined #baserock16:19
*** ChanServ sets mode: +v ssam216:19
paulsherwoodanyone have netsurf running on a reasonably powerful machine?16:35
ssam2tlsa seems absent from this channel16:38
paulsherwoodnever mind... seems concourse doesn't play nice in netsurf16:38
paulsherwoodssam2: 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 stuff16:39
ssam2i didn't see that16:39
ssam2what was the context?16:39
locallycompact<locallycompact> paulsherwood, what's this doing
paulsherwood16:15 < paulsherwood> locallycompact: when i originally proposed a schema, that code worked with it16:40
ssam2i see. I just added json-schema schemas, I didn't update any build tools to make use of them16:40
paulsherwoodack. i wonder if there's any possibility to re-open this and go for one schema file instead of several?16:41
locallycompactI'm not sure that's clearer16:41
ssam2the 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 messages16:41
paulsherwoodalright, i demur to wiser folks16:42
ssam2unless 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 errors16:42
paulsherwoodlocallycompact: any chance you could submit your submodules stuff to gerrit?16:44
ssam2ANNOUNCMENT: Baserock infrastructure will be a bit broken for the next 15 minutes or so, I need to upgrade the database16:44
locallycompactpaulsherwood, after that  ^ :)16:44
ssam2another 15 minutes or so, mail relay is done but not yet database17:06
paulsherwoodwin 4317:07
*** ctbruce has quit IRC17:18
*** tiagogomes_ has quit IRC17:23
*** jmacs has joined #baserock17:31
ssam2Everything should be working again17:33
ssam2Still more stuff to upgrade, but shouldn't be as disruptive17:34
paulsherwoodw00t :)17:34
jjardonthanks ssam2 !17:34
paulsherwoodrjek: are lua versions not backwards compatible? jjardon is proposing a lua51 stratum17:40
locallycompactWhy does gerrit feel the need to fill my commit message with shit?17:44
pedroalvarezit needs that shit to make some magic happen17:45
pedroalvarezis not too annoying though.. I hope17:45
locallycompactwell it didn't work anyway17:46
paulsherwoodlocallycompact: get the uncommitted files, and create new commits, i think17:47
locallycompactare you joking17:47
paulsherwood(assuming you've got the change-id hook magic)17:47
franredor rebase17:47
paulsherwoodi'm not joking, it's worked for me :)17:48
SotKdoesn't git commit --amend work?17:48
paulsherwoodno, that has not worked for me17:48
franredSotK, AFAIK locallycompact has 2 commits to submit anyway17:48
paulsherwoodbut i may have been in a different hole17:48
franredlocallycompact, if you have the gerrit hook, rebase your branch against master should do the trick17:49
* SotK recommends git-review17:49
franredlocallycompact, you could check if it works before pushing checking that your commit messages have a ID:XXXXXXXXX17:49
franredSotK, that too17:49
paulsherwoodgerrit can get confused if there's something under the ID: XX thing too17:50
pedroalvarezSotK: +117:50
locallycompactrebase did not owrk17:51
richard_mawpaulsherwood: 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 python317:51
pedroalvarezgerrit for newbies: `pip install git-review; git review -R`17:51
paulsherwoodrichard_maw: tvm17:51
*** jonathanmaw has quit IRC17:57
edcragglocallycompact: `git rebase -i` and 'reword' each commit17:59
edcraggif you have the hook17:59
locallycompactgonna have to rerun the migration anyway master changed18: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/lua5118:00
* richard_maw was too slow to comment18:00
* richard_maw just worries that now the context that was in the IRC discussion has been lost to posterity18:01
jjardonpaulsherwood: ssam2 thanks for all the reviews!18:04
jjardonrichard_maw: you can still send a patch to improve the stratum description maybe?18:05
ssam2it's not really richard_maw's job to fix your commit messages :-)18:05
jjardoncommit messages can not be fixed anymore, but the description: in the stratum still can18:07
ssam2actually the stratum description is better than a commit message, too18:07
ssam2i'm about to reboot a bunch of machines at, there will be a couple of minutes downtime18:07
ssam2ok, all working again18:10
paulsherwood+1 for the description18:18
*** locallycompact has quit IRC18:32
rjekpaulsherwood: Major releases are not backwards compatible. (This is part of the reason it is tiny: no baggage)18:48
*** rdale has quit IRC18:48
paulsherwoodrjek: ack, thanks18:49
rjek5.1.0 and 5.2.0 are different major revisions, jjardon is taking the right approach18:49
*** CTtpollard has quit IRC19:05
*** Lachlan1975 has quit IRC19:22
*** ssam2 has quit IRC19:23
*** edcragg has quit IRC19:36
*** richard_1aw has joined #baserock20:09
*** richard_maw has quit IRC20:12
*** toscalix has quit IRC20:36
*** edcragg has joined #baserock21:57
paulsherwoodi'm working on a new general theory of software productivity...22:17
paulsherwoodso far may base premise is 'if backports > updates then goto hell'22:18
paulsherwoodjjardon: any ideas about this (master ci.morph, armv7hlf)
paulsherwoodsorry, x86_6422:22
jjardonpaulsherwood: 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 stratum22:32
paulsherwoodno rush22:33
* paulsherwood => sleep22:33

Generated by 2.14.0 by Marius Gedminas - find it at!