| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 00:08 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 04:13 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 04:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 04:36 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:37 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 265 seconds] | 04:41 | |
| *** circ-user-HhgcW [~circuser-@2601:9:7680:971:744f:cd36:351b:c653] has joined #baserock | 06:09 | |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-foiupxvydubaayvx] has quit [Ping timeout: 260 seconds] | 06:09 | |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-hhzujylmdusfoekc] has joined #baserock | 06:10 | |
| *** sam_ [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:11 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 06:12 | |
| *** circ-user-HhgcW [~circuser-@2601:9:7680:971:744f:cd36:351b:c653] has quit [Ping timeout: 265 seconds] | 06:32 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:11 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:34 | |
| pedroalvarez | Ok, I will merge it then doing that change | 07:39 |
|---|---|---|
| pedroalvarez | richard_maw: btw, thank you for doing a yarn for system-integration commands | 07:39 |
| pedroalvarez | ugh... one needs around 6G of free space to run the morph test sute | 07:57 |
| pedroalvarez | /sute/suite | 07:57 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:16 | |
| pedroalvarez | I wonder what PYTHONPATH i have to use to run the lorry-controller test suite | 08:19 |
| pedroalvarez | I see... it needs some python libraries to run | 08:23 |
| pedroalvarez | e.g. boottle | 08:23 |
| Kinnison | Aye, bottle, likely flup | 08:28 |
| pedroalvarez | they work in a trove :) | 08:30 |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:32 | |
| Kinnison | hehe | 08:34 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:37 | |
| Mode #baserock +v ssam2 by ChanServ | 08:37 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 08:45 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:45 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 09:03 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:03 | |
| ssam2 | it's often an education reading richard_maw's patches... today I learned about the Python 'textwrap' module | 09:05 |
| Kinnison | :-) | 09:06 |
| rjek | I thought python had a module for everything :) | 09:06 |
| straycat | ssam2, Indeed I didn't realise you could do partial application in python, nor did I know about asyncore | 09:07 |
| Krin | rjek, python even has a module for python :) | 09:08 |
| franred | rjek, s/a module/multiple modules/ | 09:08 |
| rjek | heh | 09:09 |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 09:09 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:09 | |
| richard_maw | there's a reason why the section in https://docs.python.org/2/ called "Library Reference" has the subtitle _keep this under your pillow_ | 09:14 |
| * rjek keeps another pillow under his pillow. | 09:15 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 09:16 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:16 | |
| * richard_maw keeps two half pillows under his pillow, so he has neck support from the other halves if he rolls in his sleep, and can get away with 3 pillows rather than 4 | 09:17 | |
| pedroalvarez | I put my arm under my pillow :) | 09:18 |
| * persia always worries about cracking the PCB when doing that | 09:19 | |
| rjek | Yeah, my arm is normally sandwiched between the two pillows. | 09:19 |
| pedroalvarez | persia: pcb? | 09:19 |
| rjek | what else are you meant to do with arms when in bed, anyway? | 09:20 |
| persia | pedroalvarez: The printed circuit board on which my ARM is mounted | 09:20 |
| pedroalvarez | hahahahah | 09:20 |
| rjek | persia: Do you wear SoCs in bed? | 09:21 |
| rjek | I'll get my coat. | 09:21 |
| persia | rjek: No, I specifically don't tend to put them under my pillow because of fear of breaking them | 09:21 |
| richard_maw | now, who's going to make a raspberry pi joke? | 09:21 |
| franred | richard_maw, no hungry at the moment, I already have breakfast | 09:23 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 09:35 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:39 | |
| ssam2 | git.baserock.org's IO appears to be saturated | 10:08 |
| ssam2 | lots of 'cvsps' processes in 'top' | 10:08 |
| ssam2 | I don't know if this is normal or if something is wrong | 10:08 |
| richard_maw | cvs import most likely | 10:08 |
| * pedroalvarez thinks we should increase the lorries interval | 10:10 | |
| ssam2 | yeah, nothing overly worrying to me in the journal | 10:10 |
| ssam2 | pedroalvarez: that sounds like it might be a good plan | 10:11 |
| Kinnison | pedroalvarez: We need to work out a way to horizontally scale lorry | 10:11 |
| pedroalvarez | Kinnison: what do you mean? | 10:11 |
| Kinnison | pedroalvarez: something like NFS-sharing the /home/lorry between multiple cloud instances, and having minions on several systems | 10:11 |
| pedroalvarez | that would be great | 10:12 |
| pedroalvarez | so the lorry-controller has workers, and every worker lorry things with one or multiple minions, and they push things to a git server | 10:13 |
| pedroalvarez | which can be gitano, gerrit, or gitlab | 10:13 |
| pedroalvarez | or whatever | 10:13 |
| Kinnison | lorry controller has minions | 10:13 |
| Kinnison | I believe thouse could, in theory, be on different systems without issue | 10:13 |
| persia | For horizontal scaling, can we do something like separate workers and a dispatch system? | 10:22 |
| * persia doesn't quite understand why /home/lorry needs be shared | 10:23 | |
| Kinnison | the working area for lorry needs to be shared, or else lorries need to be tied to minions | 10:26 |
| Kinnison | Some conversions are strictly reliant on the stability of their working area | 10:26 |
| persia | Ah, so a given lorry needs to have the leftovers from the previous run to run smoothly? | 10:27 |
| pedroalvarez | yes | 10:29 |
| persia | Hmm. That makes it harder. Storing separate lorry working areas in separate shares gets annoying quickly. | 10:29 |
| richard_maw | pedroalvarez: do you recall why you used chroot rather than linux-user-chroot for the system-integration commands? | 10:31 |
| pedroalvarez | I remember I tried to reuse the existing code used to build chunks | 10:33 |
| pedroalvarez | I also remember I tried to use linux-user-chroot, but i can't remember why I finally used chroot | 10:34 |
| ssam2 | neither the commit logs nor the code seem to mention why ... bad Pedro ! | 10:35 |
| Kinnison | persia: I was thinking either NFS private to the cluster, or perhaps ceph | 10:39 |
| persia | Does Ceph file store work reliably yet? I know the block store is in good shape | 10:40 |
| Krin | hi i have spotted a bug in my endless bumbling through baserock, it seems kvm.check is not validating that the target path is writeable when doing a deploy, | 10:42 |
| * straycat nods | 10:43 | |
| straycat | The validation in the kvm ext is generally not that great | 10:43 |
| pedroalvarez | given the flexivbility of the write and check extensions, it would be possible to add | 10:43 |
| pedroalvarez | s/vb/b/ | 10:43 |
| richard_maw | pedroalvarez: I prefer that spelling, more stuff needs v in the middle of it | 10:44 |
| * straycat thought richard_maw would prever it | 10:44 | |
| Kinnison | persia: no idea, hence ", or perhaps ceph" | 10:44 |
| persia | heh | 10:44 |
| persia | But yeah, if we need that, then a shared network filestore seems the sensible model. If there was a way not to need that, it would be nice, but that's harder. | 10:45 |
| Kinnison | Basically to not need it would either need us to package up and move around these work areas on demand, or else to lock given lorries to given minions | 10:46 |
| Kinnison | the former is extra resource consumption, the latter is potential bottlenecks | 10:46 |
| persia | The latter also reintroduces SPF issues. | 10:47 |
| Kinnison | Aye, SPoF is a pain | 10:47 |
| persia | Which means either packaging it up, or some scalable namespace that can be used to address individual filestores. | 10:47 |
| persia | EIther of which requires extra resources: compute in the first case, and storage and system complexity in the second | 10:48 |
| Kinnison | Mmm | 10:52 |
| Kinnison | Which leads back to NFS-share (which is backed up) being the least-cost initial implementation to see if it helps to have more minions | 10:52 |
| persia | Yes. | 10:54 |
| pedroalvarez | Anyway, I think we could start decoupling the lorry controller from the git server. | 10:59 |
| Kinnison | I think that'd be quite easy frankly | 10:59 |
| Kinnison | given it interacts entirely over ssh | 10:59 |
| pedroalvarez | indeed | 11:00 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 11:11 | |
| pedroalvarez | hm.. instructions about how to configure a generic trove have been removed from the wiki :( | 11:15 |
| persia | :( | 11:16 |
| pedroalvarez | also, I don't understand why the instructions now to deploy a trove to openstack suggest you to use an "ephimeral" disk | 11:16 |
| pedroalvarez | it should use a volume | 11:17 |
| persia | Yes, and if it wants to use something else, it should probably spell it ephemeral | 11:17 |
| pedroalvarez | oh, that was me | 11:18 |
| pedroalvarez | "efimero" in spanish | 11:18 |
| persia | heh. Silly insistance an orthography that maps directly to pronunciation | 11:19 |
| pedroalvarez | yeah, but this way is easier to learn to speak english, although not to write it properly as you can see | 11:21 |
| persia | Indeed :) | 11:23 |
| * straycat reduced the docs to make it quicker to get going with trove | 11:28 | |
| straycat | I suggested using an ephemeral because that's simpler | 11:30 |
| pedroalvarez | I agree now is easier to read, and the example is simpler | 11:35 |
| persia | I suspect sticking with ephemeral for "trove" makes sense. As we deconstruct it into constituent parts, we can pick the best solution for each. | 11:37 |
| persia | For example, the git server probably wants a volume, so the volume can be snapshotted and backed up independently from the git server, etc. | 11:38 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 13:38 | |
| jonathanmaw | http://i.imgur.com/oLC5Q.jpg | 13:46 |
| jonathanmaw | oops | 13:46 |
| *** rdale_ [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:16 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 14:16 | |
| jjardon | rdale_: as far as I understand -qt-xcb is only needed to use some internal libraries instead the ones in the system: this is not needed for us as we have all the xcb stuff in x-common | 14:20 |
| rdale_ | yes, i agree | 14:20 |
| rdale_ | so i need to ask radiofree why he used that option | 14:21 |
| jjardon | and the xserver in x-generic | 14:21 |
| radiofree | rdale_: that stratum is from when i was making a wayland only system | 14:29 |
| radiofree | and probably the x strata weren't so well defined | 14:29 |
| *** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:29 | |
| radiofree | probably safe to not use that now if you build depend on x-common | 14:29 |
| rdale_ | if it doesn't find any x libs, it just won't build the xcb plugin, so i think we can just do away with the -qt-xcb option | 14:30 |
| radiofree | if you're sure about that then go ahead and leave it out | 14:30 |
| radiofree | i remember having to add that because it failed | 14:31 |
| rdale_ | my jetson, just seems to have died on me now. once i get it going again i'll try building without the flag. it fails with the flag unfortunately atm | 14:31 |
| radiofree | rdale_: how did it die?! | 14:32 |
| radiofree | kernel panic? | 14:32 |
| radiofree | you're a test case for that kernel that i'd like to send a patch to use everywhere | 14:32 |
| rdale_ | the serial port connection and ssh connections got less and less reponsive, although the hdmi seemed ok | 14:33 |
| rdale_ | now i've tried to reboot and it's stuck | 14:33 |
| radiofree | stuck where? | 14:33 |
| rdale_ | 'Retrieving file: /systems/default/dtb' | 14:34 |
| rdale_ | in u-boot | 14:34 |
| radiofree | did you do a cycle on it? | 14:35 |
| radiofree | (before rebooting) | 14:35 |
| rdale_ | i just unplugged it | 14:35 |
| radiofree | reboot an interupt u-boot, is there a "ums" command there? | 14:35 |
| rdale_ | yes | 14:36 |
| radiofree | hmm | 14:36 |
| radiofree | do a btrls mmc 0 | 14:36 |
| radiofree | then sysboot mmc 0 btrfs 0x90000000 extlinux.conf | 14:36 |
| rdale_ | <DIR> systems | 14:36 |
| rdale_ | <DIR> state | 14:36 |
| rdale_ | <FILE> extlinux.conf | 14:36 |
| rdale_ | i should boot off the sd card? | 14:37 |
| radiofree | no | 14:37 |
| radiofree | mmc 0 is the emmc | 14:37 |
| rdale_ | ah ok | 14:37 |
| rdale_ | that's doing something now | 14:37 |
| radiofree | it's booting? | 14:38 |
| rdale_ | yes | 14:38 |
| rdale_ | it has booted ok | 14:38 |
| radiofree | these btrfs patches are a bit... sensitive | 14:38 |
| rdale_ | i'll try building without -qt-xcb now and see what happens | 14:39 |
| rdale_ | for a wayland only system, i think '-no-xcb-xlib' might be best | 14:48 |
| *** dabukalam [~danny@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 15:02 | |
| *** jjardon [sid723@gateway/web/irccloud.com/x-aaclcmsbhblxrjoi] has quit [] | 15:27 | |
| *** jjardon [~jjardon@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:29 | |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 265 seconds] | 15:54 | |
| *** dutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 16:10 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:18 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 16:50 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 17:08 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:08 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:11 | |
| *** rdale_ [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 17:12 | |
| straycat | persia, Wrt what I just read on the list regarding documentation, I don't see how we can achieve much more than we're achieving currently, work on documentation is very ad hoc. | 17:22 |
| straycat | Also, having finally read the huge thread on reproduceibility, I think that as persia says, we just need better tooling. | 17:58 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Quit: No Ping reply in 180 seconds.] | 19:07 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 19:08 | |
| persia | straycat: Sadly, I fear you might be right. My issue is that most of the interesting things I want to do aren't well documented, but I'm not sure how to document them without making the existing documentation less good for folk trying to fgure out what can be done, or how to do it. | 19:15 |
| ratmice_______ | there was a rant yesterday about docs on one of the gcc mailing lists, i haven't gotten around to watching it yet, but it linked to this talk http://www.youtube.com/watch?v=z3fRu9pkuXE | 19:28 |
| ratmice_______ | hopefully that url works, as my ability to copy/paste seems to have disappeared | 19:29 |
| persia | ratmice_______: Thanks for the link: it indeed works, and it worth watching, although a bit longer than it needed to be. | 20:06 |
| persia | And it mentions a part of the documentation I failed to list: troubleshooting guides. | 20:06 |
| persia | It does express that the developers need to be the folk who write the docs, and explains why in a way that makes sense if one can be sympathetic to the speaker. | 20:07 |
| persia | But it doesn't magically provide motivation for folk to do so :) | 20:07 |
| straycat | Well it's time as well as motivation I think. | 20:08 |
| persia | Depends on how one looks at it. The speaker speaks from the perspective of django, where proper documentation is a requirement for code merge. | 20:12 |
| persia | Given that when something is done, the person developing it understands it clearly, it's a similar class of extra effort to write docs as tests, and possibly less as the docs aren't being executed so one can skip the syntax errors. | 20:13 |
| persia | As such, it becomes a matter of either 1) estimating the time to do something differently, or 2) spending more time polishing things before submission. | 20:14 |
| persia | That said, it takes a fair amount of commitment by everyone to decide that every code patch needs to include a relevant documentation fix. | 20:15 |
| persia | And unless a plurality of the contributors genuinely want this, it is hard to impose. | 20:16 |
| ratmice_______ | I do find it is helpful when reviewing patches, (when developing them not so much) | 20:35 |
| ratmice_______ | well, I suppose helpful as motivation, but I tend to want to delay until after code review, which makes it not helpful for reviewers :) | 20:36 |
| persia | That's a strong argument for django's position :) | 20:37 |
| straycat | Oh deary me | 21:12 |
| straycat | It's a sign you've been doing something too long when you don't realise you've fixed your bug | 21:16 |
| straycat | I like the idea of providing documentation before merge | 21:18 |
| persia | heh. That only happens to me when I get involved in yak shaving, and end up moving off on a tangent. | 21:20 |
| persia | I think documentation before merge works well for interfaces and reference documentation. I'm less certain I understand how to do tutorials, guides, and troubleshooting docs in that model. | 21:21 |
| persia | But even if we just had outstanding reference documentation, I suspect I'd be happy (and it ought make it easier for folk working in other areas). | 21:21 |
| persia | Perhaps guides could be written when someone does a cool new feature, showcasing the feature, and tutorials subtly adjusted when things get easier, or behaviour changes. | 21:22 |
| straycat | On the other hand some of the documentation we've written ourselves hasn't been that great. | 21:22 |
| persia | That's OK. When we have something, we can improve it. | 21:24 |
| * straycat nods | 21:25 | |
| persia | I'm unsure that the wiki is the best place, because of how folk think about wikis. In the talk there is a comment that wikis are where documentation goes to die. | 21:25 |
| persia | But our wiki is in git, so we ought be able to just fix stuff using patches, rather than needing to make special docs repos, write sphinx in them, and render them to somewhere. | 21:25 |
| persia | I suspect it's mostly about mindset, really. If we focus on docs like we do on code, it should all be fine. | 21:26 |
| straycat | I agree | 21:27 |
| straycat | It's late here, I should probably eat something. | 21:30 |
| * straycat disappears | 21:30 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
