IRC logs for #baserock for Wednesday, 2014-09-10

*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock07:31
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock07:59
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08: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 #baserock08:46
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:51
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:17
*** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09: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 #baserock09:34
paulsherwoodpersia: are you around?09:40
* Kinnison hasn't seen hide-nor-hair of him for a few days. I fear he is unwell09:41
paulsherwoodack09: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
Kinnisonsounds sensible10:57
pedroalvarezstraycat: apologies for my english :/10:58
liw-orcANNOUNCEMENT: 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 objection10:58
KinnisonGood luck liw-orc10:59
pedroalvarezstraycat: btw, I think there is an step missing before doing the chroot10:59
pedroalvarezeglibc was failing to build in my raspberry pi porting because it needed /dev/null11:00
Kinnisonpedroalvarez: did you forget to bind /dev into your chroot?11:01
pedroalvarezthat's what is missing in the instructions11:01
pedroalvarezafter that, it worked ok11:01
pedroalvarezafter binding /dev11:01
straycatAhh, I noticed that some other instructions had that step11:01
Kinnisonpedroalvarez: updated the instructions?11:02
pedroalvarezKinnison: do you think that makes sense to suggest mounting proc, sys, and tmp?11:02
Kinnisonprobably11:03
KinnisonIf that's not done in the cross-bootstrap script it writes out11:04
straycatRight now the native-bootstrap script fails for me, possibly because something expects bash I'm not sure.11:04
KinnisonThere's definitely some bashisms which need ironing out properly11:05
rjekstraycat: Yes, you need to symlink bash to sh in tools/bin11:05
rjek(for it to work at all)11:05
Kinnisonand that the script writes out multiple builds of the same source11:05
rjekYes.11:05
KinnisonHopefully richard_maw will fix some of this with his WIP branch which changes how we build stuff11:05
pedroalvarezstraycat:OOI,  what chunk?11:05
liw-orcturning 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 that11:05
rjeklinux-headers needs bash11:05
straycatyeah linux-api-headers11:06
KinnisonI *think* it's just that it thinks it needs it, rather than that it actually does11:06
Kinnisonhence the symlink hack works11:06
pedroalvarezhm... I think I haven't had any problem with linux-api-headers11:06
straycatarch docs seem to use --rbind, I guess --bind is enough though?11:24
richard_mawKinnison: 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
rjekOr that there's bash.12:18
richard_mawhm, 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 already12:25
richard_mawI'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 code12:25
richard_mawand it's already going to be a massive headache to split this up enough that it's possible to be reviewed12:26
KinnisonIndeed12:34
*** robtaylor [~robtaylor@floopily.codethink.co.uk] has joined #baserock12:36
robtaylorwow, that was odd12:37
* robtaylor appeared to have ended up on some alternate universe freenode12:37
richard_mawI'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 change12:37
robtayloranyhoo, i have a question!12:37
robtaylorhey guys, is there much thinking been donw wrt security updates and baserock?12:38
robtaylorI ask as there is a baserock relevent thread happeing on gnome-os-list12:38
ssam2we discussed it in a small meetup we had back in august12:40
paulsherwoodrobtaylor: can you point to the thread please?12:41
ssam2robtaylor: this one ? https://mail.gnome.org/archives/gnome-os-list/2014-September/msg00000.html12:46
ssam2if it's on gnome-os-list it must be that one, really :)12:46
ssam2I 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
ssam2if we are aiming to provide mainly source, nothing really can be done beyond that12:49
ssam2if we provide binaries beyond the reference images needed to bootstrap a Baserock installation, maybe things could get more complex12:50
ssam2in that thread I guess the participants are discussing whether GNOME should be providing a binary runtime, or not12:51
ssam2there 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
paulsherwoodssam2: yes13:00
ssam2ok, i'll do a patch13:00
ssam2using our internal trove, as it seems git.baserock.org is still down13:01
robtaylorssam2: yup13:02
robtaylorssam2: fancy chatting it over with alex and co?13:02
ssam2i'm nearing stack overflow right now13:05
ssam2i don't think I have the headspace for that too13:05
robtaylornp13:07
robtaylormaybe 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 #baserock13:40
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:18
franredIm 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
franredIm using this command: morph deploy --verbose clusters/open-stack-gerrit.morph openstack-image.OPENSTACK_PASSWORD=mypassword14:30
franredcould I missing something in my morphology? I have configuration-extension in one chunck, not sure if this is related or not14:31
ssam2franred: no, that's bad code in openstack.write14:31
ssam2is this latest morph ?14:32
franredssam2, it is the commit fc245d337c5b9799579a0d03d5596e926bf6037d14:32
franredssam2, looks like it is old enough... with latest version of morph it works14:38
franredssam2, cheers14:38
pedroalvarezfranred: sorry, i broke the openstack deployment and then fixed it14:40
liw-orcgit.baserock.org should be up and running normally (since a while ago, actually)14:40
franredpedroalvarez, no worries, it works now ;-)14:42
Kinnisonliw-orc: thanks14:43
liw-orcit has not been upgraded, however; we ran into a problem with the upgrade, which takes too long to sort out today14:44
KinnisonOh :-(14:45
franredwhen we create the system-integration scripts, where are they physically placed?14:49
pedroalvarezliw-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
Kinnisonfranred: 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
franredKinnison, how can I know if something went wrong with them?14:50
pedroalvarezliw-orc: Is that still correct?14:50
Kinnisonfranred: look at the system artifact I guess :-(14:50
franredurhg!14:51
Kinnisonindeed14:51
liw-orcpedroalvarez, I'm not sure right now14:51
pedroalvarezthere is only one way to know14:52
pedroalvarezscience!14:52
franredKinnison, 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
Kinnisonthe scripts are run at the time that the system artifact is constructed15:04
Kinnisonthere's no earlier time to catch it15:04
franredYes, but I won't notice until I run the image after deploy time - too late15:04
franredmy question is that we don't catch errors on system-integration errors, if I'm not worng15:05
franredwrong15:05
Kinnisonhave your script spit out a lot of diagnostics and look at the build log for the system artifact?15:05
Kinnisonno need to deploy and run15:05
KinnisonAlso, if a system integration script exits with failure, I'm fairly sure we stop the artifact build15:06
franredthe script only creates an user with adduser15:06
Kinnisonpedroalvarez: ^^^ ?15:06
franredand it does not show anything at build time15:06
pedroalvarezit should stop15:06
pedroalvarezif it fails15:06
franredyeah, it fails, the problem was that we don't catch bad system-integration yaml syntax and defo it ignores when this happen15:25
franredhappens15:25
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]15:59
franredwell we end up that I need /dev/tty to run: su - user -c "mycommand"16:22
paulsherwoodKinnison: am i right you managed to brain a jetson from Baserock in a chroot?16:23
franredwe mount /dev/shm but not /dev nor /dev/tty - are there any good reason why we shouldn't mount /dev?16:23
Kinnisonpaulsherwood: No you are wrong16:23
Kinnisonpaulsherwood: I have not attempted such a process16:23
paulsherwoodah16:24
paulsherwooddid you manage to brain a jetson from a non-baserock host? maybe i was just dreaming16:24
paulsherwoodor confusing you with someone else :)16:25
KinnisonI brained a Jetson from a Debian host without using root16:25
Kinnisonthat was my magic16:25
paulsherwoodaha :-)16:25
KinnisonBecause like feck am I running random nvidia shizzle as root on my laptop16:25
Kinnisonesp. stuff intended to brain drives16:25
KinnisonNot that I'm paranoid or anything :-)16:26
paulsherwoodwould 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_mawfranred: 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 nfsroot16:26
Kinnisonpaulsherwood: the rootliness isn't explained in the instructions, it shows up as a side effect of running the script assuming your /bin/sh is bash16:27
Kinnisonpaulsherwood: And my solution involved writing udev rules16:27
Kinnisonpaulsherwood: which might be considered more scary than just running the script as root16:27
paulsherwoodah.16:27
* paulsherwood ponders16:28
franredrichard_maw, what do you mind by "another /dev"?16:29
richard_mawfranred: I mean mounting another devtmpfs on the /dev in your chroot16:29
franredrichard_maw, I've tried that and it works, but coudl morph do this for us as it does for /dev/shm?16:30
pedroalvarezrichard_maw: wrt devtmps - does this implies security risks?16:33
richard_mawfranred: morph should never mount a devtmpfs at /dev, as this would allow builds to alter things they shouldn't even know exists16:34
richard_mawthe set of nodes in /dev during staging builds is defined as part of fhs-dirs16:34
pedroalvarezthat answered my question16:34
richard_mawthe set of nodes in /dev *before* staging builds is determined by your host system16:35
richard_mawit's not allowed to write to any of them, but it can see and read them16:35
richard_mawif you're missing /dev/null etc. from /dev, it's because your chroot isn't set up properly16:35
pedroalvarezthe nodes defined in fhs-dirs are in the chroot environmet16:36
franredrichard_maw, I have console, full, null, shm, urandom and zero16:36
franredbut this is not enough to use the su - username -c "command" command16:37
richard_mawgood, now what exactly is the problem, I've gotten a bit lost16:37
richard_mawoh, /dev/tty wasn't it16:37
pedroalvarezrunning ` su - username -c "command"` fails because /dev/tty is not there16:37
liw-orcis this busybox su?16:38
liw-orcdoes sudo work better?16:38
franredliw-orc, yes is busybox su16:38
pedroalvarezhm.. sudo, can "sudo" run a command?16:39
pedroalvarezas another user/16:39
pedroalvarez?16:39
liw-orcyes16:39
pedroalvarezfranred: sudo -u gerrit2 "java -version"16:39
franredliw-orc, yes, that looks that resolve the problem16:40
franredI didn't know we have sudo16:40
Kinnisonwhy quote the command and its arguments?16:40
KinnisonThat'd surely break it16:40
franredKinnison, in sudo you don't need it, with su you need to do it16:41
franreds/in/with16:41
Kinnisonfranred: yes, pedro was showing sudo with it16:42
Kinnisonhence my confusion16:42
pedroalvarezyeah, I only used "su" to do this, I didn't know it was different with sudo16:43
franredliw-orc, pedroalvarez, richard_maw, ssam2, cheers for your help :)16:45
ssam2no worries, I'm glad there was a nicer solution than mounting /dev !16:46
pedroalvarezfranred: I only said "Maaan, you are fucked", but you are welcome, anyway :)16:47
franred:)16:48
pedroalvarezHmm 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 finished16:54
liw-orcwhat'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 #baserock17: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
pedroalvarezI'm using a USB stick as storage... Maybe that's why is running slow17:25
richard_mawit won't help, but there's a lot of reasons why rPI is going to be painfully slow to build on17: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
radiofreei think richard dale once tried to compile Qt on one17:38
*** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock17: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 mirrored18:28
paulsherwooduggg... any ideas what's happening here? http://fpaste.org/132562/41037768/19:34
paulsherwoodwith 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
jjardonpaulsherwood: 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
jjardonpaulsherwood: what system are your trying to build?19:57
paulsherwoodjjardon: a genivi baseline with extra anchovies, on x8620:06
paulsherwoodi want to add qt520:07
paulsherwoodi'll re-run my build20:07
jjardonbuilding Qt should be independent of the architecture now20:08
jjardonpaulsherwood: any idea if the qt5-devel system is failing too? I can give it a try here if not20:09
paulsherwoodso qt5-tools should have x-generic as a dependency?20:09
paulsherwoodi can try that20:09
* paulsherwood => boarding20:11
jjardonpaulsherwood: yes, thats what is already in the definitions repo since 2b10a9677817377618e33d2b07ab7caefe31663320:13
paulsherwoodyes20:14
paulsherwoodjjardon: sadly, gstreamer is not happy... http://fpaste.org/132578/38028914/20:17
paulsherwoodthat's from master20:18
jjardonpaulsherwood: there is a patch sent by radiofree ages ago to fix that. I think he has a branch in gstramer repo20:18
jjardonpaulsherwood: http://git.baserock.org/cgi-bin/cgit.cgi/delta/gstreamer.git/log/?h=baserock/james/0.1020:19
paulsherwoodhmm. why is it not applied, then? :-)20:20
paulsherwoodthank you very much :)20:20
jjardonpaulsherwood: 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 configuration20:21
KinnisonI am working on getting that integrated into master20:22
Kinnisonbut not right now20:22
jjardonpaulsherwood: you can also use the upstream 0.10 branch and it should build20:24
paulsherwoodok20:25
juergbistill no gstreamer 1.x support in qt?20:28
jjardonjuergbi: unfortunately no :(20:30
juergbi:/20:31
jjardonIve just found an unoficial port here: https://github.com/jhodapp/qtmultimedia20:34
juergbithis looks more recent and more official https://qt.gitorious.org/qt/qtmultimedia/commits/6668bdf6cccaeb2ba22ee104f6cb1eccc2d623fe20:35
juergbibut no idea about the status. the branch is called wip20:36
jjardonyeah, just found that one too. https://codereview.qt-project.org/#/c/37266/ ?20:36
jjardonWould 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
radiofreejuergbi: the only recent commits to that are to update it to qt 5.2..5.322:11
radiofreethe actual "meat" was done ages ago22:11
radiofreeqtwebkit uses gstreamer 1.022:11
radiofreeso at least there's that...22:11

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!