| *** thecorconian [~thecorcon@wsip-24-120-218-98.lv.lv.cox.net] has quit [Quit: Leaving.] | 01:48 | |
| *** thecorconian [~thecorcon@wsip-24-120-218-98.lv.lv.cox.net] has joined #baserock | 05:41 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 06:18 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:28 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:22 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 08:10 | |
| jjardon | t | 08:26 |
|---|---|---|
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:30 | |
| franred | jjardon, good morning | 08:34 |
| paulsherwood | pedroalvarez: i'm rebuilding with your ca-certs... | 09:03 |
| pedroalvarez | paulsherwood: if you don't want to rebuild everything you can maybe move them out of core.morph | 09:03 |
| paulsherwood | which is a lot of rebuild. would it make any sense to consider a separate stratum for this and other security related stuff? | 09:04 |
| paulsherwood | pedroalvarez: yes, i should have thought of that :) but it's nearly done now | 09:04 |
| pedroalvarez | paulsherwood: yeah, "network-securty" stratum maybe? I think franred is going to create a stratum to put things like that, so maybe we can move it there. | 09:05 |
| paulsherwood | +1 | 09:07 |
| * Kinnison thinks it being in core might make sense | 09:07 | |
| Kinnison | because it provides a potential trust chain for verifying upgrades fr.ex. | 09:07 |
| Kinnison | Of course, that's not necessary for that, just might be "nice" | 09:07 |
| paulsherwood | i prefer the network-security idea, but Kinnison probably has deeper knowledge here | 09:09 |
| Kinnison | I think overall we need a discussion of whether it makes sense to parallelise some more of what's in foundation and core | 09:10 |
| Kinnison | With parallel build opportunities, it'd be nice to have fewer choke points | 09:10 |
| richard_maw | paulsherwood: here's a reason why I think we need something like unpetrify-ref: your linux chunk for docker doesn't list which ref it needs, and you needed to create a branch that includes AUFS, but I have no idea which branch the ref: refers to | 09:14 |
| paulsherwood | richard_maw: noted. actually my build doesn't include AUFS, though | 09:21 |
| richard_maw | you enable it in your kernel config | 09:21 |
| paulsherwood | yes true | 09:21 |
| paulsherwood | but the only thing special about my linux is the config | 09:22 |
| paulsherwood | i think that ref was master at the time i did it | 09:22 |
| paulsherwood | i agree with your original point, though | 09:23 |
| paulsherwood | pedroalvarez: yes, it works :) | 09:27 |
| pedroalvarez | good to know | 09:27 |
| pedroalvarez | paulsherwood: thanks! | 09:28 |
| paulsherwood | pedroalvarez: i notice that curl doesn't seem to find the certs, though | 09:33 |
| Kinnison | paulsherwood: If you can give me access to a system running that, I can diagnose what it is | 09:36 |
| Kinnison | I'll bet it's a paths issue | 09:36 |
| richard_maw | /usr/etc strikes back? | 09:36 |
| Kinnison | possibly | 09:37 |
| Kinnison | It'll likely be a path baked into openssl | 09:37 |
| paulsherwood | Kinnison: i'm in vegas | 09:37 |
| Kinnison | aah, I thought you were using our new cloudy thing | 09:37 |
| paulsherwood | is there some magic you can do to access my mc? | 09:37 |
| Kinnison | Doubtful | 09:37 |
| paulsherwood | actually, i could maybe do the cloudy thing :) | 09:37 |
| * paulsherwood goes to try | 09:37 | |
| pedroalvarez | paulsherwood: how did you test curl? | 09:44 |
| paulsherwood | by running curl -O | 09:44 |
| paulsherwood | on a https file | 09:44 |
| paulsherwood | particularly: curl -k -O https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra124_Linux_R19.3.0_armhf.tbz2 | 09:45 |
| paulsherwood | tar xvf Tegra124_Linux_R19.3.0_armhf.tbz2 | 09:45 |
| paulsherwood | works with -k, doesn't work without | 09:45 |
| paulsherwood | (scrap the tar line) | 09:45 |
| Kinnison | the issuer for nvidia's certificate is issuer=/O=Cybertrust Inc/CN=Cybertrust Public SureServer SV CA | 09:46 |
| * Kinnison assumes that's in the ca-certificates chunk | 09:46 | |
| Kinnison | so we need to check path lists etc | 09:46 |
| Kinnison | paulsherwood: could you run: strace -s1024 -f -o /tmp/curl.trace curl -I https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra124_Linux_R19.3.0_armhf.tbz2 | 09:47 |
| petefoth | Kinnison: is that available on the fs1 jukebox? | 09:47 |
| Kinnison | paulsherwood: and then upload curl.trace to somewhere I can fetch it from? | 09:47 |
| paulsherwood | so, for a cloud-based devel machine - is it safe for me to run 'morph deploy --upgrade upgrade-devel.morph self.HOSTNAME=$(hostname) self.VERSION_LABEL=newlabel' | 09:47 |
| pedroalvarez | hm..... | 09:48 |
| Kinnison | paulsherwood: if the file is too large, then grep it for c692a373 and pastebin the matches | 09:50 |
| paulsherwood | Kinnison: http://fpaste.org/131728/01698411/ | 09:50 |
| pedroalvarez | paulsherwood: should be possible to upgrade. | 09:52 |
| Kinnison | paulsherwood: could you run `curl-config --ca` and tell me what it says? | 09:56 |
| Kinnison | pedroalvarez: In your ca-certificates chunk, do you create a bundle? | 09:57 |
| richard_maw | Kinnison: not unless the Makefile from the debian repo does it | 09:58 |
| pedroalvarez | Kinnison: no | 09:59 |
| Kinnison | No, Debian creates a bundle at postinst because they can disable/enable certificates at runtime | 09:59 |
| Kinnison | cURL requires a bundle | 09:59 |
| Kinnison | and requires to be configured to know where the bundle is | 09:59 |
| pedroalvarez | right, so I'm missing that part | 10:00 |
| pedroalvarez | paulsherwood: I'd prefer another way to do an upgrade in an openstack environment | 10:00 |
| Kinnison | 1. create a bundle (cat all the certificates together into one file, Debian calls it /etc/ssl/certs/ca-certificates.pem) | 10:00 |
| Kinnison | 2. configure cURL (--with-ca-bundle=/etc/ssl/certs/ca-certificates.pem) | 10:00 |
| Kinnison | that should solve that (and the git issue) | 10:00 |
| paulsherwood | Kinnison: curl-config --ca is empty | 10:01 |
| Kinnison | paulsherwood: yeah, see the two steps above :-) | 10:02 |
| Kinnison | paulsherwood: if you're okay to test those, then you can simulate with: | 10:03 |
| Kinnison | cat /etc/ssl/certs/*.pem > /tmp/bundle.pem | 10:03 |
| Kinnison | env CURL_CA_BUNDLE=/tmp/bundle.pem curl -I https://developer.nvidia.com/sites/default/files/akamai/mobile/files/L4T/Tegra124_Linux_R19.3.0_armhf.tbz2 | 10:03 |
| Kinnison | and see if it works | 10:03 |
| paulsherwood | Kinnison: yes, it works | 10:04 |
| Kinnison | cool, pedroalvarez ^^^^ | 10:04 |
| paulsherwood | Kinnison: tvm | 10:04 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 10:04 | |
| paulsherwood | pedroalvarez: +1 from me on ca-certificates if you fix the above | 10:05 |
| paulsherwood | (can stay in core for now) | 10:05 |
| Kinnison | pedroalvarez: I think richard_maw's suggestion on baserock-dev might be a tad less evil and more supportable too :-) | 10:13 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:23 | |
| SotK | is there a way to tell morph to not try to clone submodules? | 10:26 |
| Kinnison | I doubt it | 10:27 |
| Kinnison | It'd be very odd | 10:27 |
| richard_maw | Kinnison: I didn't suggest anything about the cert. bundle, since I didn't know it was a problem when I suggested the fix | 10:27 |
| Kinnison | richard_maw: that's what update-ca-certificates does | 10:28 |
| richard_maw | that was already in the systemintegration commands, so we're missing the curl chunk config | 10:28 |
| SotK | ok then, how should I handle the case I currently have, where there is a submodule with url: git@github.com:foo which gives me permission denied? | 10:29 |
| Kinnison | Make a fresh branch which disables that submodule I guess | 10:30 |
| richard_maw | rant at upstream or make a branch that changes the url to a git:// URL | 10:30 |
| Kinnison | richard_maw: update-ca-certificates needs the .conf in order to construct the bundle | 10:30 |
| SotK | ok, thanks | 10:30 |
| richard_maw | Kinnison: that was also constructed in system-integrations | 10:30 |
| Kinnison | aah | 10:30 |
| Kinnison | then curl needs the config in addition | 10:31 |
| pedroalvarez | Kinnison, paulsherwood, richard_maw: Thanks for the help with ca-certificates, I think I know what needs to be done :) | 10:31 |
| Kinnison | and all should be well | 10:31 |
| richard_maw | Kinnison: yep, which is what I said was missing | 10:31 |
| * richard_maw ponders whether it might make sense to do ansible integration | 10:31 | |
| Kinnison | I'm a little slow today | 10:31 |
| Kinnison | Having some ansible stuff for re-running update-ca-certificates in the case that new certs are installed might be worthwhile | 10:32 |
| Kinnison | to allow for deploy-time certificate addition to take effect | 10:32 |
| paulsherwood | on arm too, i hope :) | 10:33 |
| * Kinnison fails to see why architecture would affect this | 10:34 | |
| richard_maw | if the update-ca-certificates script had an option to disable cert hooks and add a root prefix (like $DESTDIR) then we could run the update-ca-certificates script at deployment time | 10:36 |
| richard_maw | and allow for added certificates then | 10:36 |
| Kinnison | I doubt upstream would be hostile to such a patch | 10:36 |
| richard_maw | I still think it would be useful to be able to do this at boot time | 10:42 |
| richard_maw | which means standardising our ansible hook unit I guess, rather than making it trove specific | 10:43 |
| Kinnison | Probably a good plan | 10:47 |
| * richard_maw would like a daemon that looks at changes to files in /etc and runs hooks | 10:48 | |
| richard_maw | I had a look at etcd, which is what the coreos guys wrote to handle this, but it appears to effectively be an eventual-consistency networked registry | 10:49 |
| paulsherwood | is that bad? | 10:50 |
| richard_maw | it's useless for what I want, since you need to rewrite your apps to talk to a networked configuration service, and they're hogging the name etcd | 10:51 |
| richard_maw | dconf backends would be more useful | 10:55 |
| richard_maw | if you could plug that into etcd, you might get something interesting | 10:57 |
| pedroalvarez | looks like 'curl' needs the certificates at build time, like 'git' | 10:59 |
| richard_maw | eww | 10:59 |
| richard_maw | AIUI git uses curl, so it's likely to be curl preventing it working in git | 10:59 |
| Kinnison | pedroalvarez: If you specify the location directly then it shouldn't | 11:04 |
| Kinnison | pedroalvarez: If the bundle is present in one of a number of places at build time, it'll default to that | 11:04 |
| Kinnison | pedroalvarez: but --with-ca-bundle=/path/to/bundle.pem it *should* take it | 11:04 |
| pedroalvarez | Kinnison: yeah, what I wanted was curl working with the default configuration | 11:06 |
| Kinnison | pedroalvarez: aah, then you need to place (at least an empty) bundle in the chunk | 11:06 |
| Kinnison | *or* implement staging-integration-commands | 11:06 |
| Kinnison | :-) | 11:06 |
| * Kinnison would prefer the latter | 11:07 | |
| * pedroalvarez ponders | 11:07 | |
| Kinnison | but the former is far easier | 11:07 |
| pedroalvarez | I wonder how can be the behaviour of the latter | 11:07 |
| Kinnison | I had a reasonable definition of them I can look up and provide to you later if you want | 11:08 |
| Kinnison | it's lunchtime for me now though | 11:08 |
| * richard_maw pondered implementing staging-integration-commands as creating a new chunk to be built before every chunk that transitively depends on the chunk that introduced the commands | 11:08 | |
| pedroalvarez | I was pondering: Run the system-integration commands when creating the staging area | 11:09 |
| pedroalvarez | so: | 11:12 |
| pedroalvarez | 1) uncompress all the chunks | 11:12 |
| pedroalvarez | 2) run system integration commands of the dependencies. (`run-parts /baserock/system-integration.`) | 11:12 |
| pedroalvarez | 3) linux-user-chroot (build and install chunks) | 11:12 |
| pedroalvarez | But 2) can be slow, and run more things than needed. | 11:13 |
| pedroalvarez | so maybe 2) can be replaced by "run whatever is described in staging-integration-commands" | 11:13 |
| pedroalvarez | But I think that the staging-integration-commands should be system-integration commands as well in some cases. | 11:20 |
| *** thecorconian [~thecorcon@wsip-24-120-218-98.lv.lv.cox.net] has quit [Ping timeout: 252 seconds] | 11:25 | |
| jjardon | FYI, I need libgcrypt (and its dependency libgeg-error) for the my GNOME stratum. But its also needed for modenr versions of systemd so it would be nice to have it somewhere in a lower stratum | 11:52 |
| Kinnison | pedroalvarez: there's implications regarding write-ability of staging areas, and that staging != system so needs to be different commands | 12:06 |
| richard_maw | jjardon: I thought libgcrypt was being deprecated, since GNUTLS switched to using libnettle instead | 12:09 |
| jjardon | richard_maw: Didnt know about that, but: http://git.baserock.org/cgi-bin/cgit.cgi/delta/systemd.git/tree/configure.ac#n639 | 12:28 |
| paulsherwood | pedroalvarez: did you get baserock on pi working? | 14:00 |
| pedroalvarez | paulsherwood: I have a bootstrap tarball ready to test. So, not yet. | 14:00 |
| paulsherwood | ooh ;) | 14:01 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 14:01 | |
| pedroalvarez | Also I had problems to uncompress the tarball in my external hard drive... :-( | 14:01 |
| liw-orc | can I have a quick review of this: http://pastebin.com/LvdD9d5Q -- I forgot to tell morph's setup.py to install the helper scripts for the sparse file deployment speedups; I've tested this patch by building a new system and the files are in the right place on that system | 14:03 |
| richard_maw | liw-orc: ack. looks good to me: +1, or +2 depending on whether you want more eyes | 14:06 |
| liw-orc | I'll take a +2, thanks | 14:07 |
| *** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 14:21 | |
| *** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:33 | |
| straycat | Oh cool, there are cross-bootstrap docs. | 15:42 |
| Kinnison | cross-bootstrap is currently a tad broken because we're still doing per binary-artifact building rather than per-source building | 15:43 |
| Kinnison | I believe richard_maw was working on fixing that last week, so hopefully we'll have something soon | 15:43 |
| straycat | Okay | 15:44 |
| pedroalvarez | straycat: do you want to port baserock to another architecture? | 15:48 |
| straycat | I'm just messing around really, I think rjek's already working on the port. | 15:49 |
| pedroalvarez | okay :) | 15:50 |
| * pedroalvarez is debugging a trove which has stopped lorrying | 16:25 | |
| paulsherwood | it's a pity the lc status doesn't allow followthrough on links | 16:26 |
| Kinnison | It only supports that in certain circumstances because of various raisins | 16:27 |
| paulsherwood | pedroalvarez: i'm assuming you mean this trove ... http://85.199.252.93/lc-status.html | 16:28 |
| pedroalvarez | yes | 16:29 |
| pedroalvarez | hm.. | 16:29 |
| pedroalvarez | odd things in the journal | 16:29 |
| Kinnison | pedroalvarez: how odd? | 16:29 |
| pedroalvarez | one sec | 16:29 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:31 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 268 seconds] | 16:36 | |
| pedroalvarez | the log was full of attempts of ssh connections | 16:37 |
| Kinnison | they should be harmless for the most part | 16:37 |
| Kinnison | probably someone portscanned the netblock, saw your ssh port, and "had a go" | 16:38 |
| Kinnison | shouldn't affect the lorrying process | 16:38 |
| pedroalvarez | but it affects me to find useful information in the journal :P | 16:39 |
| Kinnison | true | 16:39 |
| Kinnison | my guess would be that the lorries listed died for some reason and the minions are not being reallocated as a result | 16:40 |
| paulsherwood | pedroalvarez: how many attempts? i may have tried a couple of times, not more | 16:48 |
| pedroalvarez | paulsherwood: hundreds | 17:07 |
| pedroalvarez | paulsherwood: and I believe you are not in china | 17:07 |
| pedroalvarez | :) | 17:07 |
| paulsherwood | rofl | 17:10 |
| * straycat wonders why the conf exts don't live in their own dir | 17:10 | |
| paulsherwood | +1 | 17:11 |
| Kinnison | because we've not done that yet | 17:15 |
| Kinnison | simples. | 17:15 |
| * Kinnison updates his notes on jetson flashing and heads off for the night, ciau all | 17:17 | |
| paulsherwood | pedroalvarez: how would i check for chinese friends in my own cloud vm? | 17:31 |
| paulsherwood | anyone object to us adding smartdevicelink to genivi baseline? | 18:49 |
| Kinnison | Is it defined to be part of baseline? If not, I'd kinda prefer us to have a GENIVI++ system which included things like that | 18:50 |
| Kinnison | so baseline remains "pure" | 18:50 |
| Kinnison | If it's optional in baseline then sure, lets shove it in | 18:50 |
| paulsherwood | it's an optional component. but given it's actually visible, and usable, would be worth having it | 18:57 |
| Kinnison | nod. seems reasonable then. Does it add any unpleasant dependencies? | 18:58 |
| paulsherwood | i can't remember. am building it now - will let you know | 18:58 |
| paulsherwood | i had it integrated for a few demos last year | 18:58 |
| Kinnison | nod. | 18:59 |
| paulsherwood | istm it would be a useful thing to show alongside the things wr proposed for genivi demo | 18:59 |
| * paulsherwood is assuming that bluetooth still works :) | 19:00 | |
| paulsherwood | actually, it was easy last time.. http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morphs.git/commit/?h=baserock/ps/add-smartdevicelink&id=dd9e9e145c36f718f2cf896b211eaf8f9aec7849 | 19:04 |
| Kinnison | :-) | 19:09 |
| paulsherwood | bah. | 19:14 |
| paulsherwood | they want doxygen | 19:14 |
| paulsherwood | http://fpaste.org/131911/03797141/ | 19:16 |
| paulsherwood | and liblog4cxx - i wonder where that is | 19:20 |
| paulsherwood | https://github.com/apache/log4cxx | 19:23 |
| paulsherwood | bah #2 | 19:30 |
| paulsherwood | checking for APR... no | 19:30 |
| paulsherwood | configure: error: APR could not be located. Please use the --with-apr option. | 19:30 |
| * paulsherwood hopes he can persuade julius and friends at smartdevicelink to drop the logging | 19:53 | |
| Kinnison | APR isn't too hard | 20:11 |
| Kinnison | we did it for trove | 20:11 |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 250 seconds] | 20:13 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 20:17 | |
| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has quit [Quit: No Ping reply in 180 seconds.] | 20:17 | |
| *** pedroalvarez [~quassel@ec2-54-191-112-126.us-west-2.compute.amazonaws.com] has joined #baserock | 20:17 | |
| Mode #baserock +cnt by morgan.freenode.net | 20:17 | |
| radiofree | did we ever get smartdevicelink working? | 20:53 |
| radiofree | i remember there was an issue with displaying the interface in the qt5.0 demo browser | 20:53 |
| radiofree | i *think* it was due to some security key issue? there was a patch for it though.... | 20:54 |
| paulsherwood | is APR libapr, Kinnison ? | 20:55 |
| * paulsherwood answers his own question - yes | 20:55 | |
| paulsherwood | it just seems like a lot of spurious dependencies, to me | 20:56 |
| * paulsherwood notices that it was done from tarballs, for trove | 20:57 | |
| paulsherwood | radiofree: we had it working i believe | 20:58 |
| * paulsherwood would like to get it working again :) | 20:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!