| *** edcragg_ has joined #baserock | 00:41 | |
| *** edcragg has quit IRC | 00:43 | |
| *** edcragg_ has quit IRC | 01:40 | |
| *** gtristan has quit IRC | 01:50 | |
| *** gtristan has joined #baserock | 02:23 | |
| gtristan | hmmm, anyone tell me why ca-certificates in core.morph is... such a mess ? | 06:03 |
|---|---|---|
| gtristan | actually, what it is intended to actually do, it does not do | 06:04 |
| gtristan | I cannot explain why there is a baserock/debian/... delta there either | 06:04 |
| gtristan | Well, I can hazard a guess | 06:04 |
| gtristan | Here is my guess: The really important system-integration semantics for chunk morphologies was added as an afterthought | 06:05 |
| gtristan | For a really long time, it would seem that we worked around that missing piece by hacking things in weird ways at make install time | 06:05 |
| gtristan | this would explain why system-integration remains undocumented | 06:06 |
| gtristan | and would explain why strata/core/ca-certificates.morph tries to do at make install time, what it really only needs to do at system-integration time | 06:06 |
| gtristan | and maybe explains the downstream hackery/patch against the update-ca-certificates script | 06:07 |
| gtristan | The problem is, this morph... which literally *nothing* in the build depends on... will cause me to rebuild, literally everything... just because it is in core... so if I get this wrong, it will be a huge waste :-/ | 06:08 |
| gtristan | So the question which really needs answering is: Is there any reason at all for the certificates to be actually installed properly in the staging area during the build phase ? | 06:09 |
| gtristan | Is there some packages which rely on fully installed certs, just in order to build ? | 06:09 |
| gtristan | If that is the case, the patch I will propose will be invalid | 06:09 |
| gtristan | For now I will try a "trick" to do it in a chunk in gnome.morph, upgrade to the latest debian tag with fresh certs and do it without the downstream patch | 06:11 |
| gtristan | aha, beautiful, that explains it | 06:31 |
| gtristan | http://paste.baserock.org/mapozasoci | 06:32 |
| gtristan | That is why the ca-certificates build is broken and we dont know about it | 06:32 |
| gtristan | The simple GNU makefiles in the upstream package are really badly implemented | 06:33 |
| gtristan | as such they dont propagate errors in sub makes | 06:33 |
| gtristan | Interestingly, it automatically answers the question I asked before - the builds we are making have no problem without properly installed certs | 06:34 |
| gtristan | Ergo, it should be totally safe to remove the crackpot update-ca-certificates at install time, along with the downstream delta, and just do that part in system-integration | 06:35 |
| gtristan | jjardon, I think you should take another look at 893259d724707190f763a980bc055ad9c87f7535 | 06:43 |
| gtristan | jjardon, that commit is what breaks the ca-certificates chunk in core | 06:44 |
| gtristan | jjardon, simply by making ca-certificates depend on python3 instead of python2 | 06:44 |
| gtristan | Is there a reason why python3 sits in core.morph and python2 does not ? | 06:47 |
| gtristan | it looks like we need python2 to also be in core.morph, simplest option | 06:47 |
| gtristan | hmmm, well, I guess the breakage introduced by 893259d724707190f763a980bc055ad9c87f7535 should be fairly limited | 06:49 |
| gtristan | this is one specific case where a chunk's build fails but it is not apparent without actually checking the build log | 06:49 |
| gtristan | that shouldnt be too common | 06:50 |
| *** gtristan has quit IRC | 07:25 | |
| straycat | someone should point gtristan to http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010416.html and http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010432.html when he gets back | 08:01 |
| straycat | then finally to http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013348.html | 08:01 |
| straycat | i guess we should add a comment in the definitions | 08:01 |
| *** gtristan has joined #baserock | 08:02 | |
| straycat | 08:01 straycat$ someone should point gtristan to | 08:02 |
| straycat | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010416.html and | 08:02 |
| straycat | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-January/010432.html when he gets back | 08:02 |
| straycat | 08:01 straycat$ then finally to http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013348.html | 08:02 |
| straycat | 08:02 straycat$ i guess we should add a comment in the definitions | 08:02 |
| straycat | gtristan, hello, ^ | 08:02 |
| * gtristan opens links | 08:03 | |
| gtristan | hi straycat :) | 08:03 |
| gtristan | straycat, regarding the first two links... I saw that in the history | 08:04 |
| gtristan | straycat, what boggles my mind is why was the install stuff not removed ? | 08:04 |
| gtristan | and the baserock/debian/<date> delta ? | 08:04 |
| straycat | gtristan, did you see pedro's response to the v1 of the patch i sent? | 08:05 |
| straycat | when we removed the install stuff, we could no longer git clone over https, which is what pedro expected | 08:05 |
| gtristan | I see | 08:06 |
| * gtristan followed the links: curl | 08:06 | |
| gtristan | hmmm | 08:06 |
| straycat | so we probably should have added a comment to the definitions for future reference | 08:06 |
| gtristan | well, today we have to fix the python problem at least | 08:06 |
| straycat | merging the patch i sent the other week should fix that problem | 08:07 |
| gtristan | straycat, I'll add a comment and git review that, indeed - that certainly deserves a comment at least for now | 08:07 |
| straycat | sounds good :) | 08:07 |
| gtristan | oh you have a patch for python ? | 08:07 |
| straycat | i have a patch for upstream's python install script | 08:08 |
| straycat | i spoke to the upstream who seems willing to take the patch if it works, i just haven't had time to submit it to them | 08:08 |
| gtristan | :-/ | 08:08 |
| gtristan | We need better policy in baserock | 08:09 |
| straycat | ? | 08:09 |
| gtristan | We cannot allow our hell-bent insistence on fixing upstream cost us a day of malfunctioning systems in baserock | 08:09 |
| gtristan | that just doesnt work, at least not for me :-/ | 08:10 |
| straycat | i think there's some misunderstanding | 08:10 |
| gtristan | There has to be a priority on our own definitions producing usable output | 08:10 |
| straycat | we are not blocked by upstream | 08:10 |
| straycat | all we have to do is merge the patch i sent to the list to the land i suggested | 08:10 |
| gtristan | I see, ok sorry - so lets do that ? | 08:11 |
| gtristan | at least we can do that today | 08:11 |
| straycat | if you think my patch is sane and are willint to +1 it, then i'd be happy to merge it today if no one else here objects | 08:11 |
| straycat | *willing | 08:11 |
| gtristan | straycat, how about we do this in a new delta based on this years version of ca-certs ? | 08:11 |
| straycat | i'd rather not, i've only tested that branch | 08:12 |
| straycat | if you want to update the certs that's a separate issue | 08:12 |
| gtristan | tested = ... checking that popular modern software still works with the produced certs ? | 08:12 |
| gtristan | hmmm | 08:13 |
| gtristan | I think we can do with last years certs for now | 08:13 |
| straycat | tested here = verified that the certificate filenamed produced by the python2 version match the certificate filenames produced by the python3 version, which both in turn match the certificate filenames produced without the patch AND building a system with the change, deploying it and ensuring i could clone over https from bitbucket and github | 08:13 |
| * straycat assumes you mean 'without' there | 08:14 | |
| gtristan | straycat, that sounds like a thorough test for the python script yes | 08:15 |
| gtristan | I mean, I think we can do _with_ last years certs... as I can see the currently used delta is based on a 2014... debian tag | 08:16 |
| gtristan | 2014's certs :) | 08:16 |
| gtristan | well, soon they will be 2 years old :) | 08:16 |
| * straycat nods | 08:18 | |
| * gtristan +1s on the list | 08:21 | |
| *** ctbruce has joined #baserock | 08:26 | |
| straycat | okay cool, let's wait a while for others and if they don't object i'll merge it | 08:26 |
| gtristan | https://gerrit.baserock.org/1460 <-- comment in ca-certificates.morph | 08:31 |
| gtristan | straycat, I wonder if the downstream patch we already have there could be avoided with a manual chroot issued in the install commands | 08:32 |
| gtristan | chroot $DESTDIR update-ca-certificates | 08:32 |
| gtristan | or | 08:33 |
| gtristan | chroot $DESTDIR /sbin/update-ca-certificates | 08:33 |
| gtristan | chroot might not be functional at core though, may bail out due to missing bash | 08:33 |
| gtristan | eh, it's more complicated than that :-/ | 08:34 |
| *** ctbruce has quit IRC | 08:50 | |
| *** ctbruce has joined #baserock | 08:53 | |
| *** bashrc_ has joined #baserock | 09:06 | |
| *** franred has joined #baserock | 09:10 | |
| *** jonathanmaw has joined #baserock | 09:19 | |
| *** toscalix has joined #baserock | 09:22 | |
| *** tiagogomes has joined #baserock | 09:29 | |
| richard_maw | gtristan: yeah, DESTDIR isn't a full chroot, it's just a packaging directory, and we overlay those directories on top of each other when making staging areas | 09:29 |
| richard_maw | plus, you're not allowed to use chroot in the build sandbox | 09:29 |
| gtristan | richard_maw, yeah I was mixed up thinking that... DESTDIR in fact $sandbox/${package}.inst | 09:33 |
| richard_maw | ☺ | 09:34 |
| gtristan | I think I have found something interesting though :) | 09:34 |
| gtristan | straycat, https://github.com/bagder/curl/blob/master/acinclude.m4#L2556 | 09:34 |
| gtristan | I havent finished digesting the m4 macro just yet, but I believe that we totally dont need to stage the certs | 09:35 |
| gtristan | we just need to pass an appropriate configure flag to libcurl | 09:35 |
| richard_maw | ah, another case of potentially being able to break a dependency by configuration | 09:35 |
| gtristan | to tell it where the certs should be at runtime | 09:35 |
| richard_maw | this approach came up at the time, but I don't know whether we decided against it explicitly, or whether we just failed to find the way. | 09:36 |
| gtristan | richard_maw, today when looking at this particular issue, the staging of dependencies came back to mind, of course | 09:37 |
| gtristan | I was thinking (and it's really just a wild idea at this point), since we have system-integration - if there could be a potential stage of the build at which point we could assert that system-integration staging were possible | 09:39 |
| gtristan | and perhaps optionally, or by default, after that point; run the system-integration hooks while staging any build after that point | 09:39 |
| *** mariaderidder has joined #baserock | 09:39 | |
| *** mariaderidder has joined #baserock | 09:40 | |
| gtristan | richard_maw, it's a good point that one can potentially break by configuration - quite a philosophical discussion: "is it better to rely on configure scripts to deduce as much as possible about the target system, or not" | 09:41 |
| *** mariaderidder has quit IRC | 09:41 | |
| pedroalvarez | at the time I integrated ca-certificates I don't think I could have read that m4 macro... | 09:42 |
| gtristan | in this case I tend to think it better to pass a configure flag rather than to patch ca-certificates | 09:42 |
| gtristan | pedroalvarez, you write the python, I'll write the m4 ;-) | 09:42 |
| pedroalvarez | heh | 09:42 |
| pedroalvarez | well, I think if we can avoid that delta... it will be good | 09:43 |
| pedroalvarez | ca-certificates delta | 09:43 |
| * gtristan asks daniel in #curl | 09:44 | |
| richard_maw | I think the delta for python3 support is acceptable, since I like the flexibility of being able to run it with fewer dependencies | 09:44 |
| richard_maw | I also like libcurl not depending on ca-certs, since it forces a spurious rebuild when updating certificates | 09:44 |
| straycat | it's likely onlt temporary | 09:44 |
| straycat | richard_maw, does that patch look sane to you? | 09:44 |
| * richard_maw hasn't had his caffeine yet | 09:45 | |
| richard_maw | which patch is this? | 09:45 |
| richard_maw | context is difficult | 09:45 |
| straycat | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-November/013348.html | 09:46 |
| richard_maw | oh yes, I reviewed that earlier, it looked good at the time | 09:47 |
| richard_maw | +1 | 09:48 |
| straycat | okay great i'll merge it thanks | 09:48 |
| straycat | will submit it upstream as soon as i can | 09:48 |
| gtristan | pedroalvarez, http://paste.baserock.org/ovorinivef | 09:50 |
| gtristan | pedroalvarez, there is a cut-paste of my convo with daniel | 09:51 |
| gtristan | in short --with-ca-bundle=/usr/share/ca-certificates should do the trick | 09:51 |
| gtristan | and we can drop that delta safely | 09:51 |
| *** gary_perkins has joined #baserock | 09:52 | |
| richard_maw | gtristan: except that when we do run ca-certificates we need to depend on python2 | 09:55 |
| straycat | gtristan, if you're talking about the delta i'm about to merge, then we can't drop it | 09:56 |
| gtristan | richard_maw, there are 2 deltas | 09:56 |
| gtristan | one of them for the python2 python3, another to hack the paths | 09:56 |
| gtristan | I mean we can drop the delta which hacks the paths, and drop the make install thing in the definition | 09:57 |
| gtristan | ... if we add the --with-ca-bundle flag to libcurl of course :) | 09:58 |
| gtristan | pr --with-ca-path sorry | 09:58 |
| gtristan | or, even | 09:58 |
| pedroalvarez | good! | 09:59 |
| pedroalvarez | +1 to drop "sbin/update-ca-certificates" delta | 10:00 |
| gtristan | :) | 10:00 |
| gtristan | ideally we should tear out the ca-certificates.morph from core, but that's a whole other story :-/ | 10:01 |
| * richard_maw thinks being able to have update-ca-certificates generate things into "$DESTDIR" is generally useful | 10:01 | |
| gtristan | richard_maw, I'm not entirely sure I agree or disagree - I think it's unneeded baggage to carry though, do *we* have a use for that ? | 10:03 |
| pedroalvarez | we could try to submit that upstream: http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/commit/?h=baserock/debian/20140325&id=e9b06b26d9e57444e74a5cb6beca3f12726fc3c6 | 10:04 |
| gtristan | perhaps if it was considered generally useful, that delta could sit in a patch in an upstream bug report instead of in our downstream delta ? | 10:04 |
| gtristan | pedroalvarez, right, I would advocate not blocking on that and still dropping it locally, whether or not it was proposed upstream | 10:05 |
| pedroalvarez | of course, I don't want to block it | 10:07 |
| gtristan | Ok, gnome-online-accounts mostly works now... virtual-box internet was shakey this startup... so I'm not sure if geoclue worked | 10:09 |
| gtristan | regarding the certs, since I got annoyed, I dont mind being the one picking up the pieces :) | 10:10 |
| *** edcragg has joined #baserock | 10:10 | |
| gtristan | Proposed course of action: straycat pushes the python fix to baserock/debian/<thing> branch (and probably makes a commit to core.morph to pick up the new commit)... that problem is solved | 10:11 |
| gtristan | Then, I will create a new branch with straycat's python related delta but without the other, and I will prepare a definitions branch for review which does A.) Drops the make install mumbo-jumbo and B.) Passes the needed configure switch (with comments) to libcurl.morph | 10:12 |
| gtristan | I will boot the GNOME vm with that and git clone an https://git.something.repository | 10:12 |
| gtristan | to test it | 10:12 |
| gtristan | ... sounds good ? | 10:12 |
| pedroalvarez | it does sound good | 10:20 |
| gtristan | great | 10:20 |
| * gtristan elects pedroalvarez as the benevolent dictator and follows his lead | 10:20 | |
| pedroalvarez | :) | 10:21 |
| pedroalvarez | I'll try to submit the other delta upstream in the meantime | 10:21 |
| *** ssam2 has joined #baserock | 10:21 | |
| *** ChanServ sets mode: +v ssam2 | 10:21 | |
| gtristan | pedroalvarez, ok well... dont hold your breath... this is core we're talking about | 10:22 |
| gtristan | so... probably I will clean out my artifact cache completely... I'm about due for that... and let the build heat my room overnight | 10:23 |
| paulsherwood | gtristan: why clean it out? ybd should do that itself, now? :) | 10:24 |
| gtristan | paulsherwood, does it ? how so ? | 10:24 |
| paulsherwood | it checks available space, culls artifacts oldest first | 10:24 |
| gtristan | ah not bad | 10:25 |
| straycat | paulsherwood, is there an option to disable that? | 10:25 |
| gtristan | there should probably be indeed - I would think setting a limit on the overall artifact cache size would be a good semantic | 10:26 |
| paulsherwood | straycat: default is min-gigabytes: 10. if you set it to zero, it won't cull. it won't work, either, if there's no space :) | 10:26 |
| gtristan | allowing an unlimited | 10:26 |
| gtristan | paulsherwood read my mind :) | 10:26 |
| paulsherwood | :) | 10:26 |
| straycat | i personally prefer having a command to do garbage collection, but okay | 10:27 |
| gtristan | straycat, right, there are semantic issues with that I think though... you garbage collect for which target exactly ? | 10:28 |
| gtristan | straycat, and for which active branches do you want to keep artifacts :) | 10:28 |
| tiagogomes | is there a reason why morph doesn't is not using the schemas to do a basic validation of the morphologies other than lack of time to do implement that functionality? | 10:28 |
| ssam2 | morph's validation code predates the json-schema schemas | 10:29 |
| ssam2 | I have reservations about just switching to json-schema, because its error messages can be a bit rubbish | 10:29 |
| ssam2 | but probably makes sense to switch and then manually handle any errors are really confusing | 10:30 |
| straycat | gtristan, agreed, i just personally don't like the idea of a tool secretly removing artifacts without my knowledge | 10:30 |
| gtristan | straycat, yeah, it's a tricky problem :) | 10:31 |
| *** nowster has joined #baserock | 10:31 | |
| *** locallycompact has joined #baserock | 10:32 | |
| * richard_maw objected to moving to purely json schema because it only does syntactic validation, rather than semantic too | 10:34 | |
| richard_maw | you'd need an ontology like ssam2 was looking at for automated tooling around that level of validation | 10:34 |
| tiagogomes | "to do a basic validation" ... | 10:34 |
| richard_maw | ah, I missed a detail there | 10:35 |
| *** tiagogomes has left #baserock | 10:37 | |
| richard_maw | I'm still unsure if the definitions providing the validation schema makes sense for anything more than a "coding style" level where you opt to deny old aliases or deprecated features, effectively allowing you to restrict yourself to a subset of the format the tooling understands | 10:38 |
| *** tiagogomes has joined #baserock | 10:38 | |
| richard_maw | since the point of the validation that the build tool does is to be able to provide a better error message if the definitions aren't in a form it understands, so the tool also needs a schema | 10:38 |
| richard_maw | which may potentially make using schema in the definitions a redundant feature | 10:39 |
| *** paulsherwood has left #baserock | 10:39 | |
| richard_maw | anyway, that's an old argument | 10:40 |
| * pedroalvarez plans to redeploy storyboard.baserock.org | 11:05 | |
| Zara | \o/ | 11:06 |
| pedroalvarez | I was planning on doing it with ansible, but looks like the deployment is already implemented in puppet | 11:06 |
| ssam2 | that's what I used to deploy the original | 11:08 |
| ssam2 | it wasn't smooth sailing for 2 reasons: the Puppet scripts expect to run on Ubuntu but I used Fedora, and also they seem to use a fork of the Apache puppet module, but I didn't realise at the time and used the upstream one | 11:09 |
| ssam2 | also puppet is a bit crazy, but just about usable | 11:09 |
| pedroalvarez | ssam2: so, suggestions? | 11:09 |
| pedroalvarez | I'd love to go with ansible tbh | 11:09 |
| pedroalvarez | On the same way as everything else in our infra | 11:09 |
| ssam2 | depends how much time you have :-) | 11:10 |
| pedroalvarez | that's true | 11:12 |
| pedroalvarez | Ok, I'll start playing with puppet | 11:12 |
| tiagogomes | Ansible rocks | 11:14 |
| Zara | I know nothing of storyboard's puppet scripts, but there may be other puppet scripts within openstack projects that have switched to ansible (I see a lot of talk about ansible in the channels I'm in, though it's not something I've paid much attention to). so you might be able to find some helpful things around, not sure... | 11:15 |
| Zara | seems you can have a puppet in your ansible https://github.com/openstack-infra/ansible-puppet | 11:17 |
| Zara | or an ansible in your puppet: https://github.com/openstack-infra/puppet-ansible | 11:17 |
| tiagogomes | lol | 11:18 |
| Zara | the words 'ansible' and 'puppet' no longer look like words to me, so I'm off. | 11:18 |
| pedroalvarez | hahahh this is crazy | 11:20 |
| pedroalvarez | what's next, running python from shell and shell from python? | 11:20 |
| pedroalvarez | hm.. hang on | 11:20 |
| * gtristan files https://bugs.freedesktop.org/show_bug.cgi?id=92915 and tests... | 11:30 | |
| gtristan | if this fixes geoclue, there will be only one remaining system integration bug left to deal with in GNOME's platform: the keyring issues | 11:31 |
| pedroalvarez | gtristan: that bug has been answered | 11:34 |
| pedroalvarez | saying that you don't need those rules | 11:34 |
| gtristan | I just saw that | 11:34 |
| gtristan | and disagree | 11:34 |
| gtristan | ModemManager seems to install the action | 11:34 |
| gtristan | and geoclue would clearly need to be authorized to ask modemmanager for this | 11:35 |
| gtristan | maybe the problem is upstream modemmanager ? | 11:35 |
| tiagogomes | is there any documentation of the archs supported in Baserock and that the possible valid fields for it? | 11:41 |
| gtristan | pedroalvarez, see the new comment | 11:42 |
| gtristan | pedroalvarez, we will install the rule... the alternative is that we compile ModemManager without "strict" mode, allowing any old user to query location info, this doesnt sound more desirable | 11:45 |
| gtristan | pedroalvarez, also, see IRC with hadess: http://paste.baserock.org/uhesogobor | 11:46 |
| pedroalvarez | <hadess> the problem is the debian developers not reporting back upstream about those problems... | 11:48 |
| pedroalvarez | heh | 11:48 |
| *** locallycompact has quit IRC | 11:48 | |
| pedroalvarez | I guess they will fix that upstream :) | 11:48 |
| *** locallycompact has joined #baserock | 11:48 | |
| ssam2 | tiagogomes: not really | 11:50 |
| ssam2 | in http://wiki.baserock.org/definitions/current/#index7h3 I just linked to the relevant Morph code | 11:50 |
| ssam2 | i don't think it really makes sense to standardise them, makes more sense to make definitions flexible enough that we don't need a canned list of architectures in each the build tool | 11:50 |
| ssam2 | -the | 11:50 |
| tiagogomes | ssam2 right, I asked because I am tempted to remove the armv7 to armv7l normalization that occurs in morphologyloader | 11:54 |
| ssam2 | i guess that's some backwards compatibility thing | 11:54 |
| gtristan | pedroalvarez, so... what would be the policy for branching ca-certificates... I will create a baserock/tristanvb/debian/20140325 branch to test against ? | 12:00 |
| gtristan | pedroalvarez, basically its just the same branch with the delta reverted I guess ? reverting it allows for a later merge | 12:01 |
| pedroalvarez | gtristan: didn't you want also to upgrade the certs? | 12:01 |
| gtristan | I do | 12:02 |
| gtristan | if that's alright, that makes things a bit less complicated | 12:02 |
| gtristan | then we get a branch without that delta, and I just test against a local file:///repo | 12:02 |
| pedroalvarez | although.. I still don't see straycat's patch | 12:03 |
| pedroalvarez | straycat: have you failed to merge it? | 12:04 |
| gtristan | it's merged in the delta | 12:04 |
| gtristan | http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/commit/?h=baserock/debian/20140325&id=c9124556cfc5d29d4fd0d7b688bf4873a6098bf3 | 12:04 |
| gtristan | but no definitions patch yet | 12:04 |
| pedroalvarez | I see, sorry cgit was confusing me | 12:04 |
| gtristan | we could skip it and live with another day of broken certs until after I test the changeover | 12:05 |
| gtristan | instead of having everybody build everything from core upwards two days in a row | 12:05 |
| pedroalvarez | that's ok | 12:06 |
| pedroalvarez | regarding upgrading to latest certs... I'm not sure now :) | 12:07 |
| pedroalvarez | if it has been tested I won't mind | 12:07 |
| pedroalvarez | I'm just worried about these encoding/decoding issues that the patch solves | 12:08 |
| gtristan | pedroalvarez, the new certs are just the new tag: debian/20150426 | 12:08 |
| gtristan | I have been building with that, its most probably just a couple of added certs | 12:09 |
| straycat | pedroalvarez, i've rebased the sha change it's building, i'll submit the change once it's done | 12:11 |
| gtristan | http://paste.baserock.org/acoqehakal <-- git log debian/20140325...debian/20150426 | 12:11 |
| pedroalvarez | gtristan: diff: http://git.baserock.org/cgi-bin/cgit.cgi/delta/ca-certificates.git/diff/?h=baserock/debian/20140325&id=1ce8e63dcfea6b9258da356dc023895e6f694144=651de1c8439c6206ea76b7d502daa9de05b5a461 | 12:13 |
| gtristan | pedroalvarez, you want me to review the certs by eye ? | 12:15 |
| gtristan | o_O | 12:15 |
| gtristan | I can see it has "\231\213\120\224\327"... must be good ! | 12:16 |
| pedroalvarez | that wasn't my intention | 12:16 |
| pedroalvarez | It's clear that nothing else changes but the certs | 12:17 |
| gtristan | yes, that is unclear, it's an upgrade to mozilla 2.4 certs | 12:18 |
| pedroalvarez | note that you don't have to build the entire sytem to test this change. A base system has git in it | 12:19 |
| gtristan | I am connecting to google and facebook accounts with GOA using the new certs fwiw | 12:21 |
| gtristan | not that that means much | 12:21 |
| straycat | gtristan, is that new cert change based on the the change i just merged? | 12:21 |
| gtristan | straycat, no, I am building with the new certs as a hacked workaround from the gnome strata | 12:22 |
| gtristan | I have not dared to rebase master, I will lose a day - trying to resolve geoclue before I dive that deep | 12:22 |
| straycat | okay i don't understand how that fixes your problem | 12:22 |
| gtristan | straycat, I have python2 of course | 12:23 |
| gtristan | once you reach gnome you have that :) | 12:23 |
| straycat | but the ca-certs are in core which doesn't? | 12:23 |
| gtristan | alternatively, we could have just built ca-certificates with the python it wanted, also :) | 12:23 |
| gtristan | not the ca-certs which are in GNOME, locally in my definitions sandbox, unstaged | 12:23 |
| straycat | right okay | 12:24 |
| gtristan | sigh, ok blast it, geoclue still has problems as we approach 10pm | 12:31 |
| * gtristan migrates to home | 12:31 | |
| * gtristan thinks geoclue does not run as the geoclue user | 12:32 | |
| *** gtristan has quit IRC | 12:33 | |
| *** nowster has quit IRC | 12:50 | |
| *** nowster has joined #baserock | 12:52 | |
| *** nowster has quit IRC | 12:56 | |
| *** nowster has joined #baserock | 13:01 | |
| *** gtristan has joined #baserock | 13:21 | |
| *** toscalix has quit IRC | 13:33 | |
| tiagogomes | yikes, I tried the validation example on jsonschema website and the output is not nice indeed | 13:43 |
| tiagogomes | It jut says field $foo isnot valid under any given schemas | 13:43 |
| gtristan | pedroalvarez, what is the "base system"... I dont see it in clusters/ | 13:48 |
| gtristan | there is one in systems... | 13:49 |
| gtristan | bah, 11pm is not the time to try to figure anything out... never mind me :) | 13:50 |
| pedroalvarez | yeah, we don't have clusters for everything | 13:51 |
| pedroalvarez | it used to be build-essential + core + foundation + bsp | 13:51 |
| pedroalvarez | (before we started moving things out from them) | 13:51 |
| gtristan | if it doesnt do it all by itself, I'm not interested :) | 13:52 |
| gtristan | anyway, assuming the patch is accepted, the overnight heating build will give me artifacts I can use :) | 13:52 |
| gtristan | Curl build config: http://paste.baserock.org/uriruqeseh | 13:53 |
| gtristan | 'ca cert bundle' is what is generated by update-ca-certificates | 13:54 |
| gtristan | should work fine | 13:54 |
| pedroalvarez | yeah, it should | 13:54 |
| *** toscalix has joined #baserock | 14:05 | |
| *** paulwaters_ has joined #baserock | 14:37 | |
| *** Walkerdine has joined #baserock | 14:37 | |
| *** paulwaters_ has quit IRC | 14:38 | |
| Walkerdine | Hi | 15:19 |
| pedroalvarez | hello! | 15:34 |
| Walkerdine | Is there anyway to check if a particular repository is having problems? | 15:35 |
| pedroalvarez | hm... with which one are you having problems? | 15:37 |
| pedroalvarez | I can try to reproduce the error if that helps | 15:38 |
| *** Walkerdine has quit IRC | 15:43 | |
| *** Walkerdine has joined #baserock | 15:58 | |
| Walkerdine | I am having problems with genivi-demo-platform-0.1-rebase | 16:02 |
| Walkerdine | I keep getting a preconfigure error when its building the HMI | 16:04 |
| Walkerdine | [Build 352/355] [genivi-demo-platform-hmi] Running pre-configure-commands | 16:04 |
| * tiagogomes ponders writing his own validator based on jsonschema | 16:05 | |
| Walkerdine | pre-configure failed | 16:05 |
| tiagogomes | Walkerdine mm, it doesn't show anything else? | 16:24 |
| pedroalvarez | Note that I don't know the status of the genivi-demo-platform system on that branch | 16:25 |
| pedroalvarez | Walkerdine: Could you build the version in master branch please? | 16:26 |
| Walkerdine | which version is that | 16:26 |
| pedroalvarez | Walkerdine: can you point me to the instructions that you are following so that I can understand what you are doing ? | 16:27 |
| Walkerdine | http://wiki.projects.genivi.org/index.php/Hardware_Setup_and_Software_Installation/Jetson | 16:28 |
| pedroalvarez | right | 16:28 |
| radiofree | that probably needs updating | 16:29 |
| pedroalvarez | Walkerdine: can you tell me what version of morph do you have? | 16:29 |
| pedroalvarez | radiofree: yes, I'll try to do that | 16:29 |
| Walkerdine | Which ever is in 15.25 | 16:29 |
| pedroalvarez | aha, ok | 16:29 |
| pedroalvarez | thing is that I don't know if that baserock 15.25 can build latest version | 16:32 |
| pedroalvarez | gah | 16:32 |
| Walkerdine | I did build it a few weeks ago but now I haven't been able to | 16:35 |
| pedroalvarez | Instructions updated | 16:43 |
| Walkerdine | Which instructions? | 16:50 |
| pedroalvarez | Walkerdine: is now all in the wiki. but basically you need to do: http://paste.baserock.org/inamowecax | 16:50 |
| Walkerdine | Is this for a newer version of baserock? | 16:51 |
| pedroalvarez | newer version of morph, but in those commands it's inlcuded what's needed to use the version you need | 16:52 |
| pedroalvarez | it's also in the wiki | 16:52 |
| Walkerdine | Ah but is it better now to use the newest version? | 16:53 |
| Walkerdine | I knew morph was the reason why I was using 15.25 | 16:54 |
| pedroalvarez | now a newer version is needed | 16:55 |
| *** CTtpollard has quit IRC | 16:58 | |
| Walkerdine | Hm okay | 16:58 |
| *** jonathanmaw has quit IRC | 17:01 | |
| gary_perkins | Hi, I hope someone can help. Trying to properly deploy a trove to openstack, but it seems the cloud-init isn't being run (no /etc/trove/trove.conf being created) and there is nothing in /home. I've tried 'systemctl restart trove-setup' and it seemed to do nothing. is there a script I can try manually running to create the git,lorry,etc. directories? | 17:10 |
| ssam2 | cloud-init and trove-setup are different things... | 17:13 |
| ssam2 | but both will need to run | 17:13 |
| ssam2 | and should | 17:13 |
| ssam2 | can you paste the errors from `systemctl status` for trove-setup.service and cloud-init.service ? | 17:13 |
| *** ctbruce has quit IRC | 17:20 | |
| *** franred has quit IRC | 17:21 | |
| gary_perkins | ssam2: Here: http://paste.baserock.org/ujopizipay | 17:25 |
| pedroalvarez | Note that the trove setup service needs trove.conf to run | 17:25 |
| pedroalvarez | Mi guess is that this file was supposed to be created with cloud init | 17:26 |
| pedroalvarez | My* | 17:26 |
| ssam2 | yeah, "ConditionPathExists=/etc/trove/trove.conf was not met" | 17:26 |
| ssam2 | so that's why trove-setup.service does nothing | 17:26 |
| ssam2 | if you add that file manually, then run trove-setup.service, it'll work | 17:27 |
| gary_perkins | ok, so the root cause is the cloud-init I supply on the nova boot cmd line? | 17:27 |
| gary_perkins | ok, I'll try manually running the cloud-init script, thanks :) | 17:28 |
| gary_perkins | \o/ It's working now! Thanks ssam2 & pedroalvarez :) | 17:35 |
| gary_perkins | supplying a script to nova boot never seems to work for me :( | 17:36 |
| *** tiagogomes has quit IRC | 17:49 | |
| *** ssam2 has quit IRC | 17:54 | |
| *** bashrc_ has quit IRC | 18:02 | |
| gary_perkins | I've now re-run nova boot with a tweaked cloud-config.sh (I removed the "runcmd:" and "- |" lines which seem to yamlise it) and it works!! | 18:04 |
| *** locallycompact has quit IRC | 18:26 | |
| gary_perkins | hmmm... actually, no it didn't :( So re-ran the cloud-config.sh script manually and I'm happy :) | 18:31 |
| *** toscalix has quit IRC | 18:39 | |
| *** edcragg has quit IRC | 18:57 | |
| *** Walkerdine has quit IRC | 18:58 | |
| *** zoli_ has left #baserock | 19:06 | |
| *** Walkerdine has joined #baserock | 19:10 | |
| *** zoli_ has joined #baserock | 19:25 | |
| *** edcragg has joined #baserock | 20:36 | |
| *** Walkerdine has quit IRC | 20:37 | |
| *** Walkerdine has joined #baserock | 20:39 | |
| *** Walkerdine_ has joined #baserock | 22:04 | |
| *** Walkerdine has quit IRC | 22:06 | |
| *** Walkerdine_ has quit IRC | 22:20 | |
| *** Walkerdine_ has joined #baserock | 23:01 | |
| *** Walkerdine_ has quit IRC | 23:05 | |
| *** gary_perkins has quit IRC | 23:50 | |
| *** gary_perkins has joined #baserock | 23:51 | |
| *** edcragg has quit IRC | 23:52 | |
| *** edcragg has joined #baserock | 23:52 | |
| *** wdutch has quit IRC | 23:54 | |
| *** wdutch has joined #baserock | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!