*** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 245 seconds] | 06:04 | |
*** vmeson [~quassel@128.224.252.2] has joined #baserock | 06:05 | |
Mode #baserock +ov richard_maw richard_maw by asimov.freenode.net | 07:02 | |
*** richard_maw [~richard_m@xvm-21-133.ghst.net] has joined #baserock | 07:02 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:16 | |
Mode #baserock +o ChanServ by asimov.freenode.net | 07:16 | |
Mode #baserock +oov ChanServ richard_maw richard_maw by asimov.freenode.net | 07:37 | |
*** Kinnison [~dsilvers@gateway/shell/pepperfish/x-hhzujylmdusfoekc] has joined #baserock | 07:39 | |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 07:39 | |
*** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has joined #baserock | 07:56 | |
Mode #baserock +v ssam2 by ChanServ | 07:56 | |
ssam2 | pedroalvarez: are you merging the 14.40-fixes branch or waiting for another +1 in order to do so? | 07:59 |
---|---|---|
ssam2 | if so, +1 to merge it ... | 07:59 |
ssam2 | or I can do the merge if you want | 07:59 |
pedroalvarez | ssam2: thanks! | 07:59 |
pedroalvarez | I rememberd this morning that it never had a +2 | 07:59 |
radiofree | erm | 07:59 |
radiofree | is there any chance i can get a fix into 14.40? | 08:00 |
radiofree | it's for nouveau-drm, has been tested | 08:00 |
pedroalvarez | hmm.. what's broken? | 08:00 |
pedroalvarez | ahh | 08:00 |
radiofree | it's loading the in-tree kernel module and not the out-of-tree kernel module | 08:00 |
radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/james/genivi-demo-platform&id=9e25cbaf5f9ee42f3a65da2fd28b3eac78b6f2d7 | 08:01 |
pedroalvarez | nice | 08:01 |
ssam2 | getting it in to 14.40 would be difficult :) we could do a 14.40.2 jetson-only release if you think it necessary | 08:01 |
pedroalvarez | actually it would be only the genivi system, no? | 08:02 |
radiofree | it's necessary for the genivi baseline | 08:02 |
ssam2 | right. So it's merging back something that you had to do to get the baseline demo based on 14.40 to actually work, I guess ? | 08:03 |
radiofree | well i don't actually know, violeta's branch did work when we tested it, but when i was building a branch (not based on master) based off the genivi platform, it didn't work | 08:04 |
radiofree | this patch will guarantee that it works though | 08:04 |
pedroalvarez | this is an important fix actually. I gess we could do a 14.40.2. To do that this patch should be sent for review and merged in the baserock/release/baserock-14.40 branch. Then tag the HEAD of the branch with "baserock-14.40.2" and rebuild and redeploy the genivi-jetson system. | 08:05 |
ssam2 | pedroavalrez: do you want me to merge 14.40-fixes or are you doing it? | 08:08 |
radiofree | pedroalvarez: ok i'll submit it for review | 08:09 |
pedroalvarez | ssam2: please merge them into master | 08:11 |
pedroalvarez | ssam2: and thanks :) | 08:11 |
ssam2 | OK | 08:13 |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:16 | |
petefoth | ratmice_______: thanks for the link to Writing great documentation. | 08:17 |
radiofree | "Your message to baserock-dev awaits moderator approval" | 08:19 |
pedroalvarez | radiofree: uh? | 08:19 |
radiofree | sent from my personal laptop, different e-mail | 08:20 |
pedroalvarez | ahh | 08:20 |
pedroalvarez | I think I can moderate,but don't know how | 08:23 |
Kinnison | pedroalvarez: You can if you got a mail telling you how :-) | 08:23 |
pedroalvarez | Kinnison: yeah, but, I can't remember the password | 08:24 |
Kinnison | aah | 08:24 |
rjek | I can moderate it, I think :) | 08:25 |
Kinnison | Don't | 08:25 |
Kinnison | Let Pedro do it | 08:25 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:27 | |
pedroalvarez | heheh i can add him to a sender filter, and ban him at the same time :) | 08:27 |
Kinnison | best do that, radiofree is nothing but a troublemaker | 08:28 |
* Kinnison ruffles radiofree | 08:28 | |
pedroalvarez | so, there are 2 options that I don't know what they do: Preserve messages for the site administrator and Forward messages (individually) to: | 08:29 |
pedroalvarez | well, what are they for | 08:29 |
Kinnison | the first means that you're preserving the message so that the site admin (me/rjek) can do something about it -- this is something you could do with spam | 08:29 |
pedroalvarez | aha, I understand | 08:29 |
Kinnison | the second allows you to extract the mails from the mailman queue to a target address without sending them (or in addition to sending them) to the list | 08:29 |
pedroalvarez | ok, makes sense :) | 08:30 |
* pedroalvarez moderates | 08:30 | |
Kinnison | Mailman's UI is fairly well documented in other places :-) | 08:30 |
pedroalvarez | not too many buttons to document :) | 08:30 |
radiofree | :\ | 08:31 |
pedroalvarez | radiofree: ? | 08:33 |
radiofree | nothing! | 08:33 |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:34 | |
pedroalvarez | radiofree: I'd appreciate some instructions about how to test it | 08:34 |
pedroalvarez | is it simple as running weston with the right backend? | 08:35 |
radiofree | pedroalvarez: boot up the genivi image | 08:41 |
radiofree | export XDG_RUNTIME_DIR=/tmp | 08:42 |
radiofree | export EGL_DRIVER=egl_dri2.so | 08:42 |
radiofree | weston | 08:42 |
radiofree | if you see weston, it worked! | 08:42 |
pedroalvarez | radiofree: thanks! :) | 08:44 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:17 | |
ssam2 | my branch seems to have broken Mason :( | 09:19 |
ssam2 | or rather, Mason has broken. it seems to be a cache server related issue | 09:20 |
ssam2 | '2014-10-24 09:18:52 DEBUG <urlopen error [Errno 104] Connection reset by peer>' when 85.199.252.93 tries to fetch the built libyaml artifact from 85.199.252.101 | 09:21 |
pedroalvarez | ssam2: :) we are debugging the same | 09:22 |
Kinnison | connection reset by peer usually indicates the webserver in front of the cache has hiccoughed | 09:23 |
Kinnison | I'd poke that | 09:23 |
pedroalvarez | this doesn't work even from the mason system itself | 09:24 |
pedroalvarez | so I'd restart the morph-cache-server | 09:24 |
pedroalvarez | ssam2: btw, do you think that the morph-cache-server-write logs that you are looking at are useful? I added them in that trove for debugging. | 09:26 |
ssam2 | they are definitely useful | 09:30 |
ssam2 | i did 'systemctl stop mason.timer' on the mason to stop it going hugely red | 09:30 |
ssam2 | but yeah, the artifact server can't even ping the mason | 09:31 |
pedroalvarez | ssam2: ping is disabled in our datacentred tenant | 09:33 |
pedroalvarez | :) | 09:33 |
ssam2 | oh, right. :) | 09:33 |
pedroalvarez | telnet against the 8080 works | 09:33 |
Kinnison | and making a request? | 09:33 |
Kinnison | try curl | 09:33 |
pedroalvarez | I tried with wget, and fails | 09:33 |
ssam2 | i'll enable cache server logs on the mason | 09:34 |
pedroalvarez | even from the same host | 09:34 |
Kinnison | I'd restart the cache server frontend then | 09:34 |
Kinnison | I believe it's fronted by lighttpd | 09:34 |
pedroalvarez | in troves, but not in the distbuild workers, which is the case now | 09:36 |
pedroalvarez | so the problem here is when the trove tries to fetch the artifact from the worker | 09:37 |
Kinnison | aah | 09:37 |
Kinnison | interesting | 09:37 |
Kinnison | what does strace on the worker suggest? | 09:37 |
Kinnison | (stracing the cache server on the worker) | 09:37 |
ssam2 | interestingly, there are two morph-cache-server processes ... | 09:40 |
pedroalvarez | ssam2: is not that normal? | 09:40 |
ssam2 | not on a distbuild node, I think | 09:40 |
Kinnison | yes | 09:40 |
Kinnison | parent and worker | 09:40 |
ssam2 | right | 09:40 |
Kinnison | if the worker dies, the parent restarts it | 09:40 |
Kinnison | iirc | 09:40 |
Kinnison | it's a bottle.py thing | 09:40 |
ssam2 | well, one process is waiting on a bottle lock file, the other is stuck in a recv() | 09:41 |
ssam2 | recvfrom() rather | 09:41 |
pedroalvarez | (bottle lock log: http://pastebin.com/Dcqg3yyT) | 09:41 |
Kinnison | which way around are they? | 09:41 |
ssam2 | the locking one is the parent | 09:42 |
Kinnison | sounds right | 09:43 |
Kinnison | so the child is stuck in a recvfrom | 09:43 |
Kinnison | hmm | 09:43 |
pedroalvarez | radiofree: wrt the "Jetson TK1" email from Gavin in baserock-dev. Am I right assuming that is not possible to upgrade the kernel of a JetsonTK1 without flashing a new u-boot? | 09:52 |
Mode #baserock +v ssam2 by asimov.freenode.net | 09:53 | |
radiofree | pedroalvarez: the kernel will boot fine, just that the gpu won't work | 09:55 |
radiofree | and maybe hdmi won't either | 09:55 |
ssam2 | Kinnison, pedroalvarez: are you still debugging the morph-cache-server issue, or should I restart the cache server (which now has logging enabled) ? | 09:56 |
radiofree | pedroalvarez: nor the pcie, so no networking | 09:56 |
* Kinnison has only been debugging by suggestion | 09:57 | |
radiofree | pedroalvarez: i'll reply to him if you want | 09:57 |
radiofree | i actually have http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/james/jetson-3.17-rc5-cpufreq branch which could be used for a devel image | 09:57 |
radiofree | means we can get away with using one version of u-boot, and one kernel | 09:58 |
radiofree | rdale is currently testing that kernel | 09:58 |
radiofree | if it's stable enough to use, i'll submit a patch to start using it in genivi/devel images | 09:58 |
ssam2 | Kinnison, pedroalvarez: ok, I'll restart it and see if we get anywhere | 09:59 |
ssam2 | oh, logs are in the journal | 10:00 |
ssam2 | public mason works again after I restarted its cache server | 10:44 |
Kinnison | nod. | 10:45 |
Kinnison | I wonder what caused that | 10:45 |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 10:45 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:47 | |
pedroalvarez | ssam2: thanks! | 11:03 |
pedroalvarez | radiofree: I think you are the right person to answer that email :) | 11:03 |
pedroalvarez | Although it seems to me he shouldn't upgrade it | 11:05 |
* petefoth approves of public pledges to fix documentation being a: included in patch review emails and b: honoured / fulfilled :) | 11:12 | |
straycat | If we had something that could render from branches we could submit docs as patches just like we do with code. | 11:13 |
petefoth | straycat: I did that once: submitted the patch to the ML, and was tols, just make the chnage directly in master. | 11:15 |
petefoth | straycat: I think that is the correct approach because ti reduces friction, and friction discourages people from making the effort to work on docs | 11:16 |
petefoth | Having some people who care enough about the docs to keep an eye on any changes and revert / change anything that it obvioulsy wrong, will probably work | 11:17 |
straycat | My point is that we're not really making good use of git with our wiki, because you have to push to master to see your changes. | 11:17 |
petefoth | Though I think it is worht having a thought-out, discussed and sgreed vision of what should be in the docs and how they should be structured, so that any changes people do make can go in the correct place | 11:18 |
petefoth | straycat: or you can edit directly and use the 'Preview' feature | 11:19 |
petefoth | but yes, a 'rensder some branch' feature would be useful | 11:19 |
petefoth | I recall having something like that on the Mustard instances I worked with | 11:20 |
ssam2 | trying to deploy a system with non-Baserock tools, I've somehow ended up with different, incompatible versions of Django in my production deployment to my development deployment | 11:48 |
ssam2 | if anyone has been thinking 'why bother with Baserock when you can just use 'pip' to install things', here's an answer :) | 11:48 |
* straycat thinks ssam2 may possibly be preaching to the converted :p | 11:51 | |
ssam2 | it's not too hard to fix, I can just say 'pip install django==1.7' in my deployment script, instead of 'pip install django' | 11:51 |
ssam2 | oh, actually I'm being too hasty here in any case | 11:58 |
ssam2 | seems the problem is in fact that my disk image got corrupted during deploymeny | 11:58 |
ssam2 | -y +t | 11:58 |
rdale | radiofree: i have a qt 5.3.2 build on the jetson running | 12:21 |
*** genii [~quassel@ubuntu/member/genii] has quit [Ping timeout: 244 seconds] | 13:08 | |
radiofree | rdale: in weston? | 13:29 |
rdale | unfortunately the samegame demo doesn't run | 13:29 |
rdale | so i was a bit optimistic saying that qt 5.3.2 was running | 13:30 |
radiofree | rdale: can you try | 13:30 |
radiofree | git clone git://git.baserock.org/delta/wayland.git && cd wayland && git checkout 1.6.0 && ./autogen.sh --prefix=/usr --disable-documentation && make -j6 && make install | 13:31 |
radiofree | aaaaannd | 13:31 |
radiofree | cd && git clone git://git.baserock.org/delta/weston.git && cd weston && git checkout baserock/james/weston-1.6.0 && ./autogen.sh --prefix=/usr --disable-libinput-backend --disable-weston-launch | 13:32 |
rdale | i've got meetings now, will try later | 13:32 |
radiofree | make -j6 && make install | 13:32 |
rdale | ok thanks | 13:32 |
radiofree | might need to disable some other backends for weston, can't remember | 13:32 |
radiofree | then try it in that weston, could be a problem with the weston-ivi-shell on there | 13:32 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 13:39 | |
*** jjardon28 [~jjardon@ec2-54-171-110-224.eu-west-1.compute.amazonaws.com] has joined #baserock | 14:29 | |
*** jjardon28 [~jjardon@ec2-54-171-110-224.eu-west-1.compute.amazonaws.com] has quit [] | 14:31 | |
*** jjardon_ [sid723@gateway/web/irccloud.com/x-kcnlxhpledlirbpg] has joined #baserock | 14:32 | |
jjardon_ | Hi, seems http://testirclogs.baserock.org/ is not working? | 14:34 |
ssam2 | seems so. thanks for pointing it out, but it's just a test anyway so I don't know when we'll get around to fixing it | 14:37 |
richard_maw | perhaps we should remove it from the topic then | 14:37 |
ssam2 | oh, actually I know why it's not working | 14:37 |
ssam2 | I stole its IP address and didn't realise ;) | 14:37 |
ssam2 | we have a couple more IPs available so I'll fix that | 14:38 |
rdale | radiofree: i can't get weston to start: 'weston --backend=wayland-backend.so' gives 'cant open display' | 14:42 |
ssam2 | http://testirclogs.baserock.org/ is working again. thanks Javier :) | 14:46 |
radiofree | rdale: wayland-backend is to launch weston in weston | 14:46 |
radiofree | you don't need a backend, we use the drm | 14:46 |
jjardon_ | ssam2: cheers! :) | 14:46 |
*** paulsherwood [~paulsherw@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:53 | |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 15:05 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 15:08 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:21 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 15:25 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 15:25 | |
*** ratmice_______ [bosshog@nightfall.forlorn.net] has quit [Ping timeout: 246 seconds] | 15:33 | |
*** ratmice_______ [bosshog@nightfall.forlorn.net] has joined #baserock | 15:33 | |
radiofree | rdale: in your /root/weston.log | 15:38 |
radiofree | erm.. can you fpaste it? | 15:38 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 15:39 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:40 | |
rdale | radiofree: http://pastebin.com/pRchfSvf | 15:41 |
radiofree | you're using a different version of mesa | 15:44 |
rdale | ah | 15:44 |
radiofree | do you have a /usr/lib/libGL* ? | 15:45 |
radiofree | /usr/lib/libGL.so | 15:45 |
rdale | yes | 15:45 |
radiofree | hmm | 15:45 |
radiofree | what does you strata/mesa-common/mesa.morph look like? | 15:45 |
rdale | surely the same as yours? http://pastebin.com/KQvUbsHd | 15:48 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 15:50 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 15:50 | |
radiofree | yeah it's the same, can't imagine it's mesa causing the problem | 15:51 |
radiofree | my qt stuff works in weston 1.6 | 15:51 |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Disconnected by services] | 15:52 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:52 | |
*** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Disconnected by services] | 15:53 | |
*** dutch__ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:53 | |
rdale | i've built without the '-qt-xcb' option, maybe that affects mesa etc in some way | 15:54 |
radiofree | i wouldn't have thought so | 15:56 |
radiofree | i'll build that version of mesa and see what happens | 15:56 |
radiofree | hmm pedroalvarez was going to test my drm fixes :\ | 15:58 |
radiofree | did he go home? | 15:58 |
rdale | yes | 15:59 |
radiofree | you're using those fixes right? | 15:59 |
rdale | i'm not sure | 15:59 |
radiofree | rdale: cat /baserock/nouveau-drm-bins.meta | grep -A6 system-int | 16:00 |
radiofree | if you see two lines removing nouveau.ko and nouveau_platform.ko | 16:00 |
radiofree | you're using it | 16:00 |
rdale | yes, i have those | 16:01 |
radiofree | is that good enough for +2 | 16:04 |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:05 | |
*** sam_ [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:50 | |
*** dutch__ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:51 | |
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 17:02 | |
paulsherwood | am i right in thinking that i the dc mason is publishing all its artifacts? | 17:06 |
paulsherwood | so i should be able to use --artifact-cache-server=85.199.252.101 ? | 17:07 |
ssam2 | it's a little more complex, but yes | 17:10 |
paulsherwood | how much more complex? :) | 17:10 |
ssam2 | the Mason uploads its artifacts to 85.199.252.93 | 17:11 |
paulsherwood | ok | 17:11 |
ssam2 | and you need to pass a base URL, so --artifact-cache-server=http://85.199.252.93:8080/1.0/ | 17:11 |
ssam2 | that should work | 17:11 |
paulsherwood | ah, ok | 17:12 |
ssam2 | we should set up appropriate DNS and default configuration so that this is a bit easier | 17:12 |
paulsherwood | so much magic to know :) | 17:12 |
persia | I thought Kinnison created DNS for the DC services. | 17:12 |
paulsherwood | yay, it's working :) | 17:12 |
ssam2 | sweet ! | 17:13 |
persia | Is the mason dual-arch, or single-arch? | 17:14 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:14 | |
paulsherwood | great question! :) | 17:14 |
paulsherwood | ssam2: ^^ | 17:14 |
paulsherwood | i know there are a bunch of jetsons sitting near it | 17:14 |
ssam2 | single arch | 17:15 |
persia | That should enable it to be tri- or even quad- arch. | 17:15 |
persia | I suppose for multiple architectures, we'd actually need multiple masons, all pushing to the same cache server. | 17:16 |
paulsherwood | i don't see why, but maybe | 17:17 |
ssam2 | I'm not sure exactly what'd be required, but it's more than just a config change | 17:18 |
ssam2 | I believe SotK is looking at Mason right now so he's the man to make this happen :) | 17:19 |
persia | My memory is that the way Mason works is that it does stuff locally, then reports, and polls the repo. This would probably need restructuring to trigger multiple distbuilds, and collate the results. | 17:19 |
paulsherwood | no collation needed, i think.? | 17:20 |
persia | No? Do you not want to see the results for the various architectures? | 17:21 |
* paulsherwood pushes his luck, by shooting for a jetsoncloud distbuild | 17:21 | |
paulsherwood | not collated? | 17:21 |
persia | If it's not collated, then you are running multiple masons. If you want one mason to do it, that mason needs to be able to understand architectures, and store the results appropriately. | 17:22 |
paulsherwood | maybe. i haven't even begun to understand the current mason. i just look at the pretty colours and whine when it's red. i could continue to do that, without collation i think? | 17:23 |
persia | You could, but you'd have to look at one page for each enabled architecture to see if anything turned red. | 17:25 |
paulsherwood | hmmm. i'm still not convinced, but i've been wrong before. | 17:26 |
persia | I think the right answer is to just add "multiple architectures" to the general wishlist. There's a lot of different things that folk have wanted out of Mason, most of which seem to be causing it to become a more distributed system, which helps make this easier. | 17:26 |
paulsherwood | anyways, anyone know why the jetsons might time out? did someone switch them off? | 17:27 |
persia | Maybe what I mean when I say "collation" is different than what you understand. | 17:27 |
paulsherwood | i just expect mason fires off a bunch of tasks, reports success or fail | 17:27 |
paulsherwood | if it can do them in parallel, fabulous. but all i really care about is green, or an error log if red. | 17:28 |
*** violeta_ [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 17:29 | |
persia | Hrm. Perhaps dispatching to each architecture in series, and limiting the information to one bit would work, but it might be slow. | 17:30 |
paulsherwood | parallel would be fab, as i said. and i'm assuming that caching happens as a happy by-product | 17:32 |
*** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has quit [Ping timeout: 246 seconds] | 17:32 | |
paulsherwood | what info do you think mason should be collating? | 17:33 |
persia | In the event that we want multiple bits of data, we'd need to collate distinct data points and present a more complex dashboard. | 17:36 |
persia | Personally, I'd like to see the results on a per-architecture basis, as it helps distinguish the case of something being just plain bad from the case of something being specific to one or more architectures. | 17:36 |
paulsherwood | oh, well if we're heading on to dashboards, there's all kinds of things i'd like to see. but for something to tell the project whether things are currently working or not, i still think plain red/green is more likely to get noticed and acted on :) | 17:40 |
persia | I suppose, although if we only have one bit, I'd prefer to get the info faster (single-arch), rather than waiting to run everything. | 17:41 |
paulsherwood | maybe we should wait and see what SotK is actually cooking? :) | 17:45 |
* paulsherwood is trying to work out what the pros and cons of gearman and celery are, before starting to reply to the thread hijackers | 17:45 | |
persia | I like gearman mostly because zuul was using it. | 17:46 |
paulsherwood | was using it? has that changed? | 17:46 |
persia | Not to my knowledge. | 17:48 |
persia | http://ci.openstack.org/zuul/gating.html | 17:48 |
persia | Or perhaps without the "gating" :) | 17:49 |
jjardon_ | Hi, trying to clone a repo from github Im getting this: http://fpaste.org/144944/14173086/ (works fine in my laptop) any ideas why is not working? | 17:52 |
paulsherwood | in a baserock system? | 17:52 |
jjardon_ | baserock chroot, yes | 17:52 |
paulsherwood | ca certs were added recently... if your br system predates that, it has not certification.... | 17:53 |
franred | jjardon, you don't have the latest devel system which includes the ca-certificates | 17:53 |
paulsherwood | you could git config http.sslVerify "false" maybe | 17:53 |
jjardon_ | will try that, thanks! | 17:54 |
franred | or try to change the http[s] by git | 17:54 |
franred | should work | 17:54 |
paulsherwood | yes, that works too | 17:54 |
jjardon_ | can I ask here to lorry libepoxy? https://github.com/anholt/libepoxy | 17:55 |
paulsherwood | yes... why do we need it? :) | 17:56 |
jjardon_ | paulsherwood: gtk3! | 17:57 |
paulsherwood | :) | 17:57 |
jjardon_ | and probably more important: xserver | 17:57 |
jjardon_ | (for xwayland) | 17:58 |
paulsherwood | ok | 17:58 |
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:58 | |
jjardon_ | gtk3 just added opengl support so it can be used to easily test if 3d acceleration is working correctly | 18:00 |
jjardon_ | rjek: readline is used for nmcli: a command line utility to control NetworkManager | 18:04 |
jjardon_ | Was there any agreegement about the best way to allow the upgrade of readline? | 18:06 |
* paulsherwood has no clue | 18:08 | |
jjardon_ | paulsherwood: thanks! :) only a little note: its needed by "xwayland", ie, the module needed to run X apps on top of wayland | 18:10 |
paulsherwood | jjardon_: i've submitted the lorry. now lc seems stuck. perhaps it's me, again | 18:11 |
paulsherwood | ang gbo maintainers able to check what lc thinks is going on? | 18:37 |
paulsherwood | well, it figured things out... | 19:03 |
paulsherwood | jjardon_: http://git.baserock.org/cgi-bin/cgit.cgi/delta/libepoxy.git/ | 19:03 |
jjardon_ | \o/ thanks! | 19:05 |
paulsherwood | any idea how i could extract the rootfs from a baserock img file? | 19:21 |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 19:31 | |
Kinnison | mount it? | 19:35 |
paulsherwood | i thought i'd tried that and failed... will repeat | 19:36 |
paulsherwood | in any case, i found an alternative hack. | 19:36 |
paulsherwood | thanks though :-) | 19:37 |
* paulsherwood does wonder, for the nth time, why anyone ever objects to tagging morph at the same time as a release | 19:41 | |
rjek | jjardon_: Patch it so it doesn't need readline, or the latest version of readline? | 19:45 |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:05 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 20:05 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:05 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:07 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:24 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:48 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 21:12 | |
*** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 21:12 | |
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:12 | |
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 21:20 | |
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 21:20 | |
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 21:20 | |
*** persia [quassel@ubuntu/member/persia] has quit [Ping timeout: 272 seconds] | 21:20 | |
*** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 21:28 | |
*** tiagogomes [~tiagogome@host-2-99-200-67.as13285.net] has joined #baserock | 21:28 | |
*** tiagogomes [~tiagogome@host-2-99-200-67.as13285.net] has quit [Client Quit] | 21:28 | |
*** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 258 seconds] | 21:32 | |
paulsherwood | although i like wikicat, i'm delighted it's not here to see my shambolic editing tonight | 22:07 |
pedroalvarez | paulsherwood: the jetsoncloud is only usable now from our datacentred tenant. I can't debug anything this weekend, sorry | 22:09 |
paulsherwood | ah. i forgot about that. | 22:13 |
paulsherwood | thanks | 22:14 |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 22:31 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!