*** edcragg_ has quit IRC | 00:40 | |
*** richard_maw has quit IRC | 04:18 | |
*** richard_maw has joined #baserock | 04:19 | |
*** ChanServ sets mode: +v richard_maw | 04:19 | |
*** pedroalvarez has quit IRC | 05:02 | |
*** dabukalam has quit IRC | 05:02 | |
*** pedroalvarez has joined #baserock | 05:03 | |
*** ChanServ sets mode: +v pedroalvarez | 05:03 | |
*** gtristan has quit IRC | 05:25 | |
*** gtristan has joined #baserock | 05:48 | |
*** brlogger has joined #baserock | 07:05 | |
*** CTtpollard has joined #baserock | 08:15 | |
*** paulw has joined #baserock | 08:32 | |
*** paulw has quit IRC | 08:34 | |
*** bruce_ has joined #baserock | 08:57 | |
*** bashrc has joined #baserock | 09:07 | |
*** toscalix has joined #baserock | 09:15 | |
*** ssam2 has joined #baserock | 09:19 | |
*** ChanServ sets mode: +v ssam2 | 09:19 | |
*** jonathanmaw has joined #baserock | 09:33 | |
paulsherwood | do we have a shortage of reviewers, presently? | 09:37 |
---|---|---|
ssam2 | I would say so, yes | 09:41 |
paulsherwood | ok, i'll see what i can do :) | 09:42 |
jjardon | Maybe change the current policy of 2 +1 to a single one would be a good idea | 09:46 |
paulsherwood | i was thinking of encouraging some more folks to contribute reviews | 09:47 |
ssam2 | jjardon: i tend to +1 anything that has a +1, so i don't think it would make much difference :-) | 09:55 |
paulsherwood | :) | 09:55 |
paulsherwood | ssam2: is the gap mainly on tools, definitions, trove, infrastructure, or spread across all of these | 09:56 |
ssam2 | well, infra is special because the main work is maintenance, not patch review | 09:59 |
paulsherwood | ack | 09:59 |
ssam2 | other than that, the gap is wherever we have outstanding patches, really | 10:00 |
ssam2 | simple patches to anything get through fine, it's the big changes which get stuck | 10:00 |
paulsherwood | right | 10:01 |
paulsherwood | ssam2: while you're on, i (only last night) noticed that you opted for separate schemas for each 'kind' in definitions - do you remember why you did that? | 10:02 |
paulsherwood | (i'm wondering how to re-incorporate schema validations in the definitions loading step) | 10:02 |
ssam2 | paulsherwood: there was definitely a reason | 10:06 |
ssam2 | I think it was so they are tighter, in fact | 10:07 |
ssam2 | there's no way in json-schema to say "this element is allowed only if the kind field was set to 'chunk'" | 10:07 |
richard_maw | ssam2: enum | 10:08 |
ssam2 | ah ,ok | 10:08 |
ssam2 | then maybe it's just because using an enum was messy | 10:08 |
jjardon | Mmm, not sure i agree; trivial patches get stuck as well; the vala separation took more than 3 months, for example | 10:08 |
richard_maw | no other way AIUI | 10:08 |
paulsherwood | ssam2: my original schema was deliberately lax, because actual historical definitions have quite a lot of small breakages | 10:09 |
ssam2 | aha! | 10:10 |
ssam2 | i documented my rationale in schemas/README :-) | 10:10 |
ssam2 | "It is possible to merge all these | 10:10 |
ssam2 | into one file, and use the 'oneOf' field to say that any .morph file should | 10:10 |
ssam2 | match exactly one of the layouts. The only issue with this approach is that | 10:10 |
ssam2 | the Python 'jsonschema' model will give you totally useless errors if anything | 10:10 |
ssam2 | is invalid (along the lines of "<dump of entire file> is not valid under any of | 10:10 |
ssam2 | the given schemas"). So for now they are separate." | 10:10 |
*** edcragg has joined #baserock | 10:11 | |
paulsherwood | ok. did you actually try validating actual definitions against the schema? | 10:11 |
ssam2 | yes | 10:11 |
paulsherwood | cool - is there code for that anywhere? | 10:11 |
* paulsherwood would like to crib, if possible :) | 10:12 | |
ssam2 | schemas/tools/jsonschema-validate | 10:12 |
ssam2 | in definitions | 10:12 |
ssam2 | that does a single file | 10:12 |
paulsherwood | of any 'kind' ? | 10:12 |
ssam2 | yes | 10:13 |
paulsherwood | cool! | 10:13 |
ssam2 | or does it? | 10:13 |
* tiagogomes_ points to https://gerrit.baserock.org/#/c/1542/, which produces, IMO, nice error messages | 10:13 | |
ssam2 | no, it is not at all smart | 10:13 |
ssam2 | (my tool) | 10:13 |
paulsherwood | tiagogomes_: thanks for that! | 10:13 |
ssam2 | the best that tool can do is `schemas/tools/jsonschema-validate schemas/stratum.json-schema strata/*.morph` | 10:14 |
ssam2 | etc | 10:14 |
ssam2 | I did fix definitions to all be valid against the schema, but seems some have regressed (which is not surprising) | 10:14 |
*** franred_ has quit IRC | 10:16 | |
*** franred has joined #baserock | 10:29 | |
*** bruce_ has quit IRC | 11:03 | |
*** bruce_ has joined #baserock | 11:18 | |
*** gtristan has quit IRC | 11:30 | |
*** gtristan has joined #baserock | 11:42 | |
pedroalvarez | just in case anybody is wondering about the gcc lorry not showing up: http://paste.baserock.org/ehozanisoy | 12:07 |
rjek | wat | 12:09 |
pedroalvarez | wat indeed | 12:11 |
rjek | Is the upstream repo somehow corrupt? | 12:12 |
ssam2 | good catch! | 12:13 |
ssam2 | does look like something might be wrong with their git server.. | 12:13 |
ssam2 | searching shows that it could also be a https issue, or a proxy issue | 12:15 |
jmacs | I'm getting errors from my VM too. | 12:21 |
pedroalvarez | jmacs: is that somethiing that you weren't having before? or did just tested the commands that are failing for us to reproduce the error? | 12:24 |
jmacs | All I'm doing is "git clone https://gcc.gnu.org/git/gcc.git" | 12:24 |
jmacs | Which I have done before (although I can't remember how recently) | 12:25 |
pedroalvarez | I see | 12:25 |
pedroalvarez | --depth 3 works | 12:25 |
pedroalvarez | I was trying to check if the commits on github mirror have the same sha | 12:27 |
*** locallycompact has joined #baserock | 12:28 | |
pedroalvarez | and they do | 12:30 |
jmacs | "git clone git://gcc.gnu.org/git/gcc.git" has no such problems | 12:30 |
pedroalvarez | then we have a winner | 12:31 |
pedroalvarez | jmacs: thanks! | 12:31 |
paulsherwood | hmmm... could someone pls check what happened to lc's initial attempt to clone gcc? | 12:32 |
pedroalvarez | paulsherwood: http://paste.baserock.org/ehozanisoy | 12:33 |
pedroalvarez | we have been doing that since 12:07 :) | 12:33 |
paulsherwood | ah, ok | 12:33 |
pedroalvarez | and here the patch: https://gerrit.baserock.org/#/c/1813/ | 12:36 |
paulsherwood | i've approved :) | 12:38 |
* paulsherwood crosses fingers | 12:38 | |
paulsherwood | tiagogomes_: i think https://gerrit.baserock.org/#/c/1542/ will get proactive review this week | 12:43 |
tiagogomes_ | great :) | 12:45 |
paulsherwood | ssam2: i'm hopeful we could make both ybd and morph verify schema before doing anything else. that should nip regressions in the bud? :) | 13:18 |
ssam2 | yes, that would be good. I think that's what Tiago's patches do in fact | 13:31 |
ssam2 | should probably warn to begin with rather than failing though | 13:31 |
paulsherwood | conf flag :) | 13:53 |
tiagogomes_ | I'd fail. if you warn instead of failing you would need to add code to handle the case when the definitions are not valid | 13:58 |
paulsherwood | actually, +1 | 13:59 |
tiagogomes_ | And then you'd lose some advantages of using the schema for validation | 13:59 |
paulsherwood | (except that for ybd i still aim to support retrospective definitions) | 13:59 |
tiagogomes_ | They key is, ensuring that the error messages are helpful to find out the root cause of the validation failure | 14:00 |
paulsherwood | +11 :) | 14:00 |
paulsherwood | http://git.baserock.org/cgi-bin/cgit.cgi/delta/gcc.git/ | 14:02 |
paulsherwood | WWWWWWW0000000000000000000000000000000000000000000T :) | 14:02 |
rjek | Calm down, dear. | 14:03 |
paulsherwood | now, for the avoidance of unnecessary pain, am i correct that downstream troves don't have to mirror everything by default? :) | 14:03 |
* rjek tries cloning it :D | 14:06 | |
rjek | It's... taking a while | 14:08 |
jmacs | gcc is a big repository. | 14:09 |
rjek | It's just saying "Cloning into git..." atm; not got to a stage where it provides progress feedback | 14:09 |
rjek | Done. the .git is 1.6GB! | 14:15 |
paulsherwood | that's pretty fast :) | 14:16 |
paulsherwood | is trove doing the tarball trick for it? | 14:16 |
jmacs | I was trying to do a binary chop between gcc 4.7 and 4.8 a while back; it was 12000 revisions | 14:17 |
rjek | Well, that's interesting. git gc makes .git grow from 1.6GB to 3.2GB | 14:21 |
paulsherwood | owwww | 14:21 |
paulsherwood | sounds like a bug? | 14:21 |
rjek | Perhaps "gc" stands for "garbage creation" ? | 14:22 |
* rjek assumes some magic has happened here that perhaps does not interact well with a garbage collection. | 14:23 | |
*** edcragg_ has joined #baserock | 14:23 | |
*** edcragg has quit IRC | 14:24 | |
pedroalvarez | paulsherwood: yes, trove is doing th tarball trick for it, but this tarbal is 9.7G big | 14:32 |
paulsherwood | owww! | 14:33 |
pedroalvarez | the gcc-tarball one is 154M | 14:33 |
pedroalvarez | tiny <3 | 14:33 |
*** tiagogomes_ has quit IRC | 14:34 | |
pedroalvarez | so, if Morph fetches the whole repo this is going to be really slow to build | 14:35 |
pedroalvarez | actually, if Morph/ybd try to fetch the tarball before trying git clone.. this is going to be really slow | 14:36 |
richard_maw | rjek: it's probably repacking with a smaller window than the repo it was fetched from | 14:36 |
richard_maw | paulsherwood: downstream troves can be configured to not fetch gcc, but the default config is to get evertying in delta/ | 14:36 |
paulsherwood | richard_maw: ack, thanks | 14:38 |
paulsherwood | is the tarball trick optional? | 14:39 |
paulsherwood | seems we'd be better turning it off for this | 14:39 |
pedroalvarez | I wonder... if this was a shallow lorry... | 14:40 |
richard_maw | pedroalvarez: if it was shallow then we'd have different problems | 14:41 |
pedroalvarez | :) | 14:41 |
ssam2 | tiagogomes_, paulsherwood: so you'd be ok if a 'git pull' of YBD caused some definitions to suddenly fail to build? | 14:42 |
ssam2 | i would find that pretty annoying | 14:42 |
paulsherwood | ssam2: with a conf flag, off by default, i'd be fine | 14:42 |
ssam2 | yes, that would be perfect | 14:42 |
ssam2 | maybe we should stick with gcc-tarball.git in the reference system definitions, and leave gcc.git as an 'opt-in' for folk who want latest GCC ? | 14:44 |
paulsherwood | fine by me | 14:48 |
paulsherwood | but still, i wonder why the tarball is so much bigger than the repo | 14:48 |
pedroalvarez | tarball is actually smaller, the repo is 12G ish | 14:48 |
*** tiagogomes_ has joined #baserock | 14:48 | |
pedroalvarez | and a checkout is from 1.6GB to 3.2GB | 14:49 |
paulsherwood | ah, ok | 14:49 |
*** rdale has joined #baserock | 15:10 | |
*** gtristan has quit IRC | 15:25 | |
*** gtristan has joined #baserock | 15:34 | |
jjardon | paulsherwood: any idea why this is failing to build, same definition works in morph?: | 15:57 |
jjardon | https://www.irccloud.com/pastebin/a0FrqfKE/ | 15:57 |
jjardon | this is the chunk definition: | 15:58 |
jjardon | https://www.irccloud.com/pastebin/Q8a7XKnX/ | 15:58 |
*** gtristan has quit IRC | 16:08 | |
paulsherwood | jjardon: at risk of sounding like a stuck record, please could you try master ybd? | 16:11 |
jjardon | paulsherwood: same problem | 16:13 |
paulsherwood | what kind of ref is that? | 16:13 |
jjardon | paulsherwood: seems like a normal commit: https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/?id=a182447a13103c5b78eefc8f742cb6b779f120eb | 16:14 |
paulsherwood | jjardon: fatal: bad object a182447a13103c5b78eefc8f742cb6b779f120eb | 16:14 |
paulsherwood | from a fresh git clone | 16:15 |
jjardon | mmm, how on earth is working with morph then? | 16:16 |
*** gtristan has joined #baserock | 16:16 | |
richard_maw | already had good objects in the morph git cache? | 16:16 |
paulsherwood | morph doesn't check for trees in the same way? | 16:16 |
richard_maw | looks like upstream gstreamer changed a tag | 16:18 |
richard_maw | and morph had fetched it before they changed it | 16:18 |
paulsherwood | ouch | 16:18 |
richard_maw | and now that object is not referenced by any ref, hence their git server isn't sending it | 16:18 |
richard_maw | and that link only works because that commit hasn't been gc'd by their git server yet | 16:18 |
jjardon | thats probably, Ive complained the other they about the tag not being pushed correctly in the repo | 16:19 |
paulsherwood | sounds plausible | 16:19 |
richard_maw | this is one reason I recommended making anchor refs | 16:19 |
jjardon | but anyway, Im using sha, not tags here | 16:20 |
*** CTtpollard has quit IRC | 16:20 | |
richard_maw | jjardon: yeah, but the sha you used isn't referenced by anything you can clone from git://anongit.freedesktop.org/gstreamer/gstreamer-vaapi | 16:21 |
richard_maw | not any more anyway | 16:21 |
richard_maw | so we've reliably locked down what contributed to the build, but because there wasn't an anchor ref, we can no longer build it, because that commit is no longer available, except in jjardon's morph git cache | 16:22 |
*** CTtpollard has joined #baserock | 16:23 | |
richard_maw | so… if jjardon can dig into his morph git cache and push that to a branch on git.baserock.org, then things will be better | 16:23 |
jjardon | ah, ok; I will change the patch then (still a bit surprised you can access the commit through the web interface tough). Thanks for the help! | 16:23 |
paulsherwood | richard_maw: i assume that jjardon will want to provide a better sha than this | 16:23 |
jjardon | richard_maw: the patch is still not merged, so dont think that would be needed | 16:24 |
richard_maw | ok then, just change the sha1 to that of the new version of the tag, and assume they moved the tag for a good reason | 16:25 |
richard_maw | (or use your local cache to see if they've made any significant change between the versions) | 16:25 |
*** jonathanmaw_ has joined #baserock | 16:25 | |
*** jonathanmaw_ has quit IRC | 16:27 | |
*** jonathanmaw_ has joined #baserock | 16:27 | |
*** jonathanmaw has quit IRC | 16:29 | |
*** gtristan has quit IRC | 17:00 | |
*** gtristan has joined #baserock | 17:01 | |
*** bashrc has quit IRC | 17:05 | |
*** bashrc has joined #baserock | 17:12 | |
*** gtristan has quit IRC | 17:20 | |
*** bruce_ has quit IRC | 17:22 | |
paulsherwood | locallycompact: looking at your RFC, this will require a fix for each component with submodules? | 17:37 |
paulsherwood | so ansible is just an example you've come across? | 17:37 |
paulsherwood | i wonder how hard it would be to track down the rest? | 17:37 |
locallycompact | It would require that | 17:38 |
tiagogomes_ | I'd prefer the genericity of supporting multiple sources for a component | 17:39 |
locallycompact | tiagogomes_, That requires updating every sha for every submodule everytime the parent repo changes, no? | 17:39 |
* paulsherwood makes a whooshing sound, as this goes over his head | 17:40 | |
franred | locallycompact, you still need to modify the parent repository to point to the trove submodules. Or you lost track/reproducibility of the submodules | 17:41 |
locallycompact | No you don't, the reproducibility is tracked by definitions | 17:41 |
*** jonathanmaw has joined #baserock | 17:42 | |
richard_maw | if you encode submodule url rewrite rules in the cache key, you can safely have the build tool perform translation to build from a trove | 17:42 |
richard_maw | s/build from a trove/fetch submodule commits from repositories lorried to the trove/ | 17:42 |
tiagogomes_ | locallycompact, that should be the default, but you should be able to fix a sha for the submodule if needed | 17:42 |
tiagogomes_ | locallycompact, related https://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013358.html | 17:43 |
locallycompact | I'm confused, all I want to do is consume upstream tags for repos that have submodules | 17:43 |
locallycompact | The shas are already tracked | 17:43 |
*** jonathanmaw_ has quit IRC | 17:44 | |
locallycompact | Some repositories like for example concourse, are repositories that consist of more or less only submodule increments for a hundred submodules, we would be constantly curating it. | 17:47 |
*** jonathanmaw has quit IRC | 17:56 | |
*** franred has quit IRC | 17:57 | |
*** ssam2 has quit IRC | 18:04 | |
paulsherwood | locallycompact: would you mind creating a patch for all of the definitions, rather than just ansible? | 18:06 |
paulsherwood | (i'm assuming it would be possible to use ybd or morph to iterate through the chunks (eg for ci.morph) and identify them) | 18:07 |
locallycompact | Sure | 18:07 |
paulsherwood | ybd no-build: True might help | 18:08 |
locallycompact | tvm | 18:08 |
paulsherwood | (or not, can't remember if it does all the git operations) | 18:08 |
*** bashrc has quit IRC | 18:09 | |
paulsherwood | jjardon: have you tested https://gerrit.baserock.org/#/c/1807/ ? | 18:12 |
jjardon | paulsherwood: Ive built a gnome system, yes; the upgrade is needed because 1.6.3 is the minimum requirement for gstreamer-vaapi | 18:14 |
paulsherwood | merged | 18:15 |
jjardon | paulsherwood: thanks! mind take a look to https://gerrit.baserock.org/#/c/1814/ as well? | 18:17 |
paulsherwood | done | 18:17 |
*** toscalix has quit IRC | 18:24 | |
*** locallycompact has quit IRC | 18:33 | |
*** edcragg_ has quit IRC | 18:35 | |
*** rdale has quit IRC | 18:36 | |
*** gtristan has joined #baserock | 19:34 | |
*** locallycompact has joined #baserock | 20:14 | |
*** gtristan has quit IRC | 20:18 | |
*** gtristan has joined #baserock | 20:32 | |
*** gtristan has quit IRC | 20:46 | |
*** gtristan has joined #baserock | 20:53 | |
*** gtristan has quit IRC | 21:01 | |
*** edcragg has joined #baserock | 21:02 | |
*** gtristan has joined #baserock | 21:25 | |
*** gtristan has quit IRC | 21:35 | |
*** gtristan has joined #baserock | 21:45 | |
*** gtristan has quit IRC | 22:05 | |
*** zoli_ has quit IRC | 22:25 | |
*** gtristan has joined #baserock | 22:45 | |
*** gtristan has quit IRC | 23:39 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!