*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:31 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:59 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:20 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 08:46 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:46 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:51 | |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:17 | |
*** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:32 | |
*** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 09:32 | |
*** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:34 | |
paulsherwood | persia: are you around? | 09:40 |
---|---|---|
* Kinnison hasn't seen hide-nor-hair of him for a few days. I fear he is unwell | 09:41 | |
paulsherwood | ack | 09:47 |
* straycat was slightly confused by "chroot /path/to/uncompressed/tarball /bin/sh" since you chroot into a directory not a tarball. | 10:57 | |
straycat | 'extracted' rather than 'uncompressed' would make more sense maybe? | 10:57 |
Kinnison | sounds sensible | 10:57 |
pedroalvarez | straycat: apologies for my english :/ | 10:58 |
liw-orc | ANNOUNCEMENT: I and petefoth are starting an upgrade of git.baserock.org and as the first step we'll be making image copies of the virtual disks, for safety and recovery speed just in case everything goes really badly wrong; for this, we need to turn git.baserock.org for a while; I will be turning off git.baserock.org in about five minutes, unless there is strong objection | 10:58 |
Kinnison | Good luck liw-orc | 10:59 |
pedroalvarez | straycat: btw, I think there is an step missing before doing the chroot | 10:59 |
pedroalvarez | eglibc was failing to build in my raspberry pi porting because it needed /dev/null | 11:00 |
Kinnison | pedroalvarez: did you forget to bind /dev into your chroot? | 11:01 |
pedroalvarez | that's what is missing in the instructions | 11:01 |
pedroalvarez | after that, it worked ok | 11:01 |
pedroalvarez | after binding /dev | 11:01 |
straycat | Ahh, I noticed that some other instructions had that step | 11:01 |
Kinnison | pedroalvarez: updated the instructions? | 11:02 |
pedroalvarez | Kinnison: do you think that makes sense to suggest mounting proc, sys, and tmp? | 11:02 |
Kinnison | probably | 11:03 |
Kinnison | If that's not done in the cross-bootstrap script it writes out | 11:04 |
straycat | Right now the native-bootstrap script fails for me, possibly because something expects bash I'm not sure. | 11:04 |
Kinnison | There's definitely some bashisms which need ironing out properly | 11:05 |
rjek | straycat: Yes, you need to symlink bash to sh in tools/bin | 11:05 |
rjek | (for it to work at all) | 11:05 |
Kinnison | and that the script writes out multiple builds of the same source | 11:05 |
rjek | Yes. | 11:05 |
Kinnison | Hopefully richard_maw will fix some of this with his WIP branch which changes how we build stuff | 11:05 |
pedroalvarez | straycat:OOI, what chunk? | 11:05 |
liw-orc | turning off git.baserock.org for now; it'll be back later, then get upgraded, at which point it will be rebooted, and hopefully everything will work after that | 11:05 |
rjek | linux-headers needs bash | 11:05 |
straycat | yeah linux-api-headers | 11:06 |
Kinnison | I *think* it's just that it thinks it needs it, rather than that it actually does | 11:06 |
Kinnison | hence the symlink hack works | 11:06 |
pedroalvarez | hm... I think I haven't had any problem with linux-api-headers | 11:06 |
straycat | arch docs seem to use --rbind, I guess --bind is enough though? | 11:24 |
richard_maw | Kinnison: so to clarify, as well as building the same chunk multiple times (I fix this), we also need the script to ensure the usual things are mounted, and that there's a /tools/bash symlink? | 12:17 |
rjek | Or that there's bash. | 12:18 |
richard_maw | hm, I can change the script to ensure it has the usual things mounted, but it was written to expect to be an nfsroot rather than a chroot, hence /dev should have been mounted by the kernel already | 12:25 |
richard_maw | I'd rather not scope creep by change to include that too though, there's already a lot of unrelated fixes that just happened to happen because I touched the same code | 12:25 |
richard_maw | and it's already going to be a massive headache to split this up enough that it's possible to be reviewed | 12:26 |
Kinnison | Indeed | 12:34 |
*** robtaylor [~robtaylor@floopily.codethink.co.uk] has joined #baserock | 12:36 | |
robtaylor | wow, that was odd | 12:37 |
* robtaylor appeared to have ended up on some alternate universe freenode | 12:37 | |
richard_maw | I've seen a metric that 200 lines is about as much as you can expect people to review, and last time I looked the code change was an order of magnitude higher, though that included the show-dependencies output change | 12:37 |
robtaylor | anyhoo, i have a question! | 12:37 |
robtaylor | hey guys, is there much thinking been donw wrt security updates and baserock? | 12:38 |
robtaylor | I ask as there is a baserock relevent thread happeing on gnome-os-list | 12:38 |
ssam2 | we discussed it in a small meetup we had back in august | 12:40 |
paulsherwood | robtaylor: can you point to the thread please? | 12:41 |
ssam2 | robtaylor: this one ? https://mail.gnome.org/archives/gnome-os-list/2014-September/msg00000.html | 12:46 |
ssam2 | if it's on gnome-os-list it must be that one, really :) | 12:46 |
ssam2 | I think the conclusion we came to was that long term, we want to provide a feed of 'the following CVE affects the Baserock Reference Systems in definitions.git between commit a235 and commit b124' | 12:49 |
ssam2 | if we are aiming to provide mainly source, nothing really can be done beyond that | 12:49 |
ssam2 | if we provide binaries beyond the reference images needed to bootstrap a Baserock installation, maybe things could get more complex | 12:50 |
ssam2 | in that thread I guess the participants are discussing whether GNOME should be providing a binary runtime, or not | 12:51 |
ssam2 | there are some files in distbuild that still say 'All rights reserved.' for copyright, should we change those to be GPL2 like the rest ? | 12:59 |
paulsherwood | ssam2: yes | 13:00 |
ssam2 | ok, i'll do a patch | 13:00 |
ssam2 | using our internal trove, as it seems git.baserock.org is still down | 13:01 |
robtaylor | ssam2: yup | 13:02 |
robtaylor | ssam2: fancy chatting it over with alex and co? | 13:02 |
ssam2 | i'm nearing stack overflow right now | 13:05 |
ssam2 | i don't think I have the headspace for that too | 13:05 |
robtaylor | np | 13:07 |
robtaylor | maybe persia would be up for it =) | 13:10 |
*** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 276 seconds] | 13:22 | |
*** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:40 | |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:18 | |
franred | Im trying to deploy from openstack into openstack using this cluster morphology: http://fpaste.org/132460/14103593/ but Im getting the following error: http://fpaste.org/132459/10359287/ | 14:29 |
franred | Im using this command: morph deploy --verbose clusters/open-stack-gerrit.morph openstack-image.OPENSTACK_PASSWORD=mypassword | 14:30 |
franred | could I missing something in my morphology? I have configuration-extension in one chunck, not sure if this is related or not | 14:31 |
ssam2 | franred: no, that's bad code in openstack.write | 14:31 |
ssam2 | is this latest morph ? | 14:32 |
franred | ssam2, it is the commit fc245d337c5b9799579a0d03d5596e926bf6037d | 14:32 |
franred | ssam2, looks like it is old enough... with latest version of morph it works | 14:38 |
franred | ssam2, cheers | 14:38 |
pedroalvarez | franred: sorry, i broke the openstack deployment and then fixed it | 14:40 |
liw-orc | git.baserock.org should be up and running normally (since a while ago, actually) | 14:40 |
franred | pedroalvarez, no worries, it works now ;-) | 14:42 |
Kinnison | liw-orc: thanks | 14:43 |
liw-orc | it has not been upgraded, however; we ran into a problem with the upgrade, which takes too long to sort out today | 14:44 |
Kinnison | Oh :-( | 14:45 |
franred | when we create the system-integration scripts, where are they physically placed? | 14:49 |
pedroalvarez | liw-orc: so, before my work in trove-setup, if you wanted to deploy a trove without UPSTREAM_TROVE, the trove would end up with an empty "trovehost" configuration in lorry-controller.conf. | 14:49 |
Kinnison | franred: they start life in the chunk morphologies and are put into the chunk artifacts at chunk build time. run at system build time. | 14:50 |
franred | Kinnison, how can I know if something went wrong with them? | 14:50 |
pedroalvarez | liw-orc: Is that still correct? | 14:50 |
Kinnison | franred: look at the system artifact I guess :-( | 14:50 |
franred | urhg! | 14:51 |
Kinnison | indeed | 14:51 |
liw-orc | pedroalvarez, I'm not sure right now | 14:51 |
pedroalvarez | there is only one way to know | 14:52 |
pedroalvarez | science! | 14:52 |
franred | Kinnison, so I won't be able to notice that something go wrong until I run the image (after deploy time) and I have to have a look to the chunk in part of the log at build time... ummm can not we detect this early? | 15:03 |
Kinnison | the scripts are run at the time that the system artifact is constructed | 15:04 |
Kinnison | there's no earlier time to catch it | 15:04 |
franred | Yes, but I won't notice until I run the image after deploy time - too late | 15:04 |
franred | my question is that we don't catch errors on system-integration errors, if I'm not worng | 15:05 |
franred | wrong | 15:05 |
Kinnison | have your script spit out a lot of diagnostics and look at the build log for the system artifact? | 15:05 |
Kinnison | no need to deploy and run | 15:05 |
Kinnison | Also, if a system integration script exits with failure, I'm fairly sure we stop the artifact build | 15:06 |
franred | the script only creates an user with adduser | 15:06 |
Kinnison | pedroalvarez: ^^^ ? | 15:06 |
franred | and it does not show anything at build time | 15:06 |
pedroalvarez | it should stop | 15:06 |
pedroalvarez | if it fails | 15:06 |
franred | yeah, it fails, the problem was that we don't catch bad system-integration yaml syntax and defo it ignores when this happen | 15:25 |
franred | happens | 15:25 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:59 | |
franred | well we end up that I need /dev/tty to run: su - user -c "mycommand" | 16:22 |
paulsherwood | Kinnison: am i right you managed to brain a jetson from Baserock in a chroot? | 16:23 |
franred | we mount /dev/shm but not /dev nor /dev/tty - are there any good reason why we shouldn't mount /dev? | 16:23 |
Kinnison | paulsherwood: No you are wrong | 16:23 |
Kinnison | paulsherwood: I have not attempted such a process | 16:23 |
paulsherwood | ah | 16:24 |
paulsherwood | did you manage to brain a jetson from a non-baserock host? maybe i was just dreaming | 16:24 |
paulsherwood | or confusing you with someone else :) | 16:25 |
Kinnison | I brained a Jetson from a Debian host without using root | 16:25 |
Kinnison | that was my magic | 16:25 |
paulsherwood | aha :-) | 16:25 |
Kinnison | Because like feck am I running random nvidia shizzle as root on my laptop | 16:25 |
Kinnison | esp. stuff intended to brain drives | 16:25 |
Kinnison | Not that I'm paranoid or anything :-) | 16:26 |
paulsherwood | would you mind tweaking the wiki instructions please? we have a customer who may need a similar approach (http://wiki.baserock.org/guides/baserock-jetson/) | 16:26 |
richard_maw | franred: if you're able to mount another /dev, then sure, but we've not done so because the expected environment for the script generated by cross-bootstrap is *not* a chroot. It was written to expect an nfsroot | 16:26 |
Kinnison | paulsherwood: the rootliness isn't explained in the instructions, it shows up as a side effect of running the script assuming your /bin/sh is bash | 16:27 |
Kinnison | paulsherwood: And my solution involved writing udev rules | 16:27 |
Kinnison | paulsherwood: which might be considered more scary than just running the script as root | 16:27 |
paulsherwood | ah. | 16:27 |
* paulsherwood ponders | 16:28 | |
franred | richard_maw, what do you mind by "another /dev"? | 16:29 |
richard_maw | franred: I mean mounting another devtmpfs on the /dev in your chroot | 16:29 |
franred | richard_maw, I've tried that and it works, but coudl morph do this for us as it does for /dev/shm? | 16:30 |
pedroalvarez | richard_maw: wrt devtmps - does this implies security risks? | 16:33 |
richard_maw | franred: morph should never mount a devtmpfs at /dev, as this would allow builds to alter things they shouldn't even know exists | 16:34 |
richard_maw | the set of nodes in /dev during staging builds is defined as part of fhs-dirs | 16:34 |
pedroalvarez | that answered my question | 16:34 |
richard_maw | the set of nodes in /dev *before* staging builds is determined by your host system | 16:35 |
richard_maw | it's not allowed to write to any of them, but it can see and read them | 16:35 |
richard_maw | if you're missing /dev/null etc. from /dev, it's because your chroot isn't set up properly | 16:35 |
pedroalvarez | the nodes defined in fhs-dirs are in the chroot environmet | 16:36 |
franred | richard_maw, I have console, full, null, shm, urandom and zero | 16:36 |
franred | but this is not enough to use the su - username -c "command" command | 16:37 |
richard_maw | good, now what exactly is the problem, I've gotten a bit lost | 16:37 |
richard_maw | oh, /dev/tty wasn't it | 16:37 |
pedroalvarez | running ` su - username -c "command"` fails because /dev/tty is not there | 16:37 |
liw-orc | is this busybox su? | 16:38 |
liw-orc | does sudo work better? | 16:38 |
franred | liw-orc, yes is busybox su | 16:38 |
pedroalvarez | hm.. sudo, can "sudo" run a command? | 16:39 |
pedroalvarez | as another user/ | 16:39 |
pedroalvarez | ? | 16:39 |
liw-orc | yes | 16:39 |
pedroalvarez | franred: sudo -u gerrit2 "java -version" | 16:39 |
franred | liw-orc, yes, that looks that resolve the problem | 16:40 |
franred | I didn't know we have sudo | 16:40 |
Kinnison | why quote the command and its arguments? | 16:40 |
Kinnison | That'd surely break it | 16:40 |
franred | Kinnison, in sudo you don't need it, with su you need to do it | 16:41 |
franred | s/in/with | 16:41 |
Kinnison | franred: yes, pedro was showing sudo with it | 16:42 |
Kinnison | hence my confusion | 16:42 |
pedroalvarez | yeah, I only used "su" to do this, I didn't know it was different with sudo | 16:43 |
franred | liw-orc, pedroalvarez, richard_maw, ssam2, cheers for your help :) | 16:45 |
ssam2 | no worries, I'm glad there was a nicer solution than mounting /dev ! | 16:46 |
pedroalvarez | franred: I only said "Maaan, you are fucked", but you are welcome, anyway :) | 16:47 |
franred | :) | 16:48 |
pedroalvarez | Hmm I thinnk I'm not going to use the Raspberry Pi to build ever. It has been building gcc for 8 hours, and it hasn't finished | 16:54 |
liw-orc | what's it using for storage? | 16:55 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Quit: Leaving] | 17:02 | |
*** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 17:05 | |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 17:07 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:07 | |
*** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 17:13 | |
*** liw-orc [~liw@access.ducie-dc1.codethink.co.uk] has quit [Quit: Coyote finally caught me] | 17:14 | |
pedroalvarez | I'm using a USB stick as storage... Maybe that's why is running slow | 17:25 |
richard_maw | it won't help, but there's a lot of reasons why rPI is going to be painfully slow to build on | 17:28 |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving.] | 17:36 | |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:38 | |
radiofree | i think richard dale once tried to compile Qt on one | 17:38 |
*** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:43 | |
*** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 17:59 | |
* paulsherwood has managed to add smartdevicelink to genivi.morph, now we have log4cxx mirrored | 18:28 | |
paulsherwood | uggg... any ideas what's happening here? http://fpaste.org/132562/41037768/ | 19:34 |
paulsherwood | with the log... http://fpaste.org/132564/14103778/ | 19:36 |
* paulsherwood guesses that jjardon's graphics cleanup needs to be applied to the qt5 strata? | 19:46 | |
jjardon | paulsherwood: doesnt seem anything related with Qt is failing to build there. Also x-generic builds fine here (Its the same for GTK+ and Qt) | 19:56 |
jjardon | paulsherwood: what system are your trying to build? | 19:57 |
paulsherwood | jjardon: a genivi baseline with extra anchovies, on x86 | 20:06 |
paulsherwood | i want to add qt5 | 20:07 |
paulsherwood | i'll re-run my build | 20:07 |
jjardon | building Qt should be independent of the architecture now | 20:08 |
jjardon | paulsherwood: any idea if the qt5-devel system is failing too? I can give it a try here if not | 20:09 |
paulsherwood | so qt5-tools should have x-generic as a dependency? | 20:09 |
paulsherwood | i can try that | 20:09 |
* paulsherwood => boarding | 20:11 | |
jjardon | paulsherwood: yes, thats what is already in the definitions repo since 2b10a9677817377618e33d2b07ab7caefe316633 | 20:13 |
paulsherwood | yes | 20:14 |
paulsherwood | jjardon: sadly, gstreamer is not happy... http://fpaste.org/132578/38028914/ | 20:17 |
paulsherwood | that's from master | 20:18 |
jjardon | paulsherwood: there is a patch sent by radiofree ages ago to fix that. I think he has a branch in gstramer repo | 20:18 |
jjardon | paulsherwood: http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/log/?h=baserock/james/0.10 | 20:19 |
paulsherwood | hmm. why is it not applied, then? :-) | 20:20 |
paulsherwood | thank you very much :) | 20:20 |
jjardon | paulsherwood: gstreamer 0.10 is using deprecated api from GLib, so the build fails because gstreamer is configured to not use deprecated api. tha patches in that branch remove that configuration | 20:21 |
Kinnison | I am working on getting that integrated into master | 20:22 |
Kinnison | but not right now | 20:22 |
jjardon | paulsherwood: you can also use the upstream 0.10 branch and it should build | 20:24 |
paulsherwood | ok | 20:25 |
juergbi | still no gstreamer 1.x support in qt? | 20:28 |
jjardon | juergbi: unfortunately no :( | 20:30 |
juergbi | :/ | 20:31 |
jjardon | Ive just found an unoficial port here: https://github.com/jhodapp/qtmultimedia | 20:34 |
juergbi | this looks more recent and more official https://qt.gitorious.org/qt/qtmultimedia/commits/6668bdf6cccaeb2ba22ee104f6cb1eccc2d623fe | 20:35 |
juergbi | but no idea about the status. the branch is called wip | 20:36 |
jjardon | yeah, just found that one too. https://codereview.qt-project.org/#/c/37266/ ? | 20:36 |
jjardon | Would it be possible to move the ref: parameter of a chunk to the chunk definition itself, instead in the stratum? Currently feels a bit odd that the info to build a specific chunk is in 2 different places (in the stratum you have the ref to build and in the morphology you have the configuration parameters) | 20:56 |
radiofree | juergbi: the only recent commits to that are to update it to qt 5.2..5.3 | 22:11 |
radiofree | the actual "meat" was done ages ago | 22:11 |
radiofree | qtwebkit uses gstreamer 1.0 | 22:11 |
radiofree | so at least there's that... | 22:11 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!