IRC logs for #baserock for Friday, 2014-11-21

persiaCatching up on the ML: did the 404s at http://cache.baserock.org:8080/ get resolved?  Is this a filtering issue, or something more complex?03:36
persiaAlso, now that we have a nice system with a nice name, how would I go about submitting changes to cause it to provide x86_32 artifacts as well?03:36
*** elevenarms__ [~elevenarm@c-69-181-189-77.hsd1.ca.comcast.net] has quit [Quit: Be back later ...]04:53
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock08:03
paulsher1oodpersia: I believe that petefoth had misunderstood how this works - cache.baserock.org:8080 is working fine for morph. it's just that url is not browsable. maybe we could extend the api to report something useful there, but i'm not sure it's worth the effort08:24
paulsher1oods/that url/the root url/08:25
paulsher1oodpersia: by submitting changes, do you mean code? if so, mailing list i think08:25
petefothpaulsher1ood: indeed I was trying to browse to that url. Failed to understand / notice that was not its purpose :(08:26
paulsher1oodpetefoth: no problem. i did the same originally... the only diff is i didn't email the list :-)08:26
petefothpaulsher1ood: :)08:27
persiapaulsher1ood: Heh, of course the lst, but I don't know precisely what is needed.  I presume a tested cluster morphology (or an extension to the existing one), but I'm not sure of the details.08:27
petefothpaulsher1ood: before I go searching, did you find the Storyboard roadmap that krotschec referred to in #storyboard?08:29
paulsher1oodnor am i, sadly, persia. this seems to fall somewhere between the current mason which folks don't want to improve, because it's only a poc, and future mason which doesn't exist yet08:30
paulsher1oodpetefoth: https://wiki.openstack.org/wiki/StoryBoard/Roadmap08:31
persiaIt's not just that, it is also that the deployments into production seem to be non-automated: the deploy commands we're using for infrastructure don't seem to be in a git repo anywhere.08:31
petefothpaulsher1ood: tvm08:31
paulsher1oodincidentally, i like how logical that url is 08:31
paulsher1oodpersia: that is probably true08:32
persiapaulsher1ood: smaffuli just completed a large effort to more logically structure all those URLs :)08:33
paulsher1oodpersia: but in the context of this, where is the deploy? current mason just builds stuff, successfully or not, from master definitions? and cache is populated as a by-product of that i think?08:33
persiaRight, so the changes would be to cause to exist a mason for the desired architecture, deployed in such a way to populate that cache.08:34
paulsher1oodpersia: pity they are case-sensitive! :)08:34
paulsher1oodpersia: yup08:34
persiamediawiki08:34
paulsher1oodsucks, imo. :-)08:34
paulsher1oodoops. i should never do that. i'm sorry, any mediawiki fans08:35
petefothso w.b.o should have urls like mason/reference-manual and (some more examples that I haven’t made up yet). WE could look at the structure for the wiki that was proposed in the ML and restructure the urls to match08:35
paulsher1oodwe've had lots of good use out of mediawiki. 08:35
persiaThey volunteered, and made lots of changes to meet the desires of the openstack folk.08:35
paulsher1oodpetefoth: talk is cheap :)08:35
persiapetefoth: I don't think current mason ought be documented, because I'll be delighted when it dies (I liked the previous jenkins-based Mason better)08:36
paulsher1oodpersia: i disagree. the previous one didn't really work, afaict. this one seems to :)08:36
petefothpaulsher1ood: https://trello.com/c/t0M2NL9L/18-experimental-restructured-wiki-to-match-documentation-complexity-email-thread - it’s on my ToDo list08:36
persiaBut rather, I think that we need a way to store operational deployments for automation, and we ought be doing that as best-practice in the baserock project.08:36
persiaAnd I want to add to that (by using the existing scripts as reference) another architecture.08:37
* paulsher1ood sighs...the kanban wars are like the wiki wars all over again08:37
paulsher1oodpersia: acknowledged, and i wholeheartedly agree08:37
* persia suspects that two non-operators agreeing doesn't help as much as it might seem08:38
paulsher1oodpersia: i think we have some standing in the community... 08:38
paulsher1oodbut you're right :)08:38
paulsher1ood(and maybe i'm deluding myself about the standing)08:39
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:48
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:03
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:04
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:11
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:24
pedroalvarezgood morning!09:27
paulsher1oodhi!09:27
pedroalvarezI wonder if we are going to do something with the systemd misconfiguration, and if anybody else is having problems with it09:28
persiaWhich systemd misconfiguration?09:28
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:29
pedroalvareznetwork configuration, networkd is configured to use DHCP in en* interfaces, but my systems is still having eth* interfaces for ethernet09:29
pedroalvarezs/is/are/09:29
persiaOh, ugh.09:33
*** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has joined #baserock09:48
Mode #baserock +v ssam2 by ChanServ09:48
rdale_i've just tried to push a branch to baserock/definitions but i'm not authorized09:56
pedroalvarezrdale_: odd.. can you `ssh git@git.baserock.org whoami`09:56
rdale_it lists my laptop ssh key ok09:58
pedroalvarezrdale_: I'm interested on the groups that this commands lists09:58
pedroalvarezI assume you need to be in "baserock-writers"09:58
rdale_local-config-writers: Users who are permitted to write to the local-config project09:59
pedroalvarezand I assume you already are in "local-config-writers:"09:59
rdale_i'm not in baserock-writers then09:59
pedroalvarezi don't have permissions to add you, I believe that richard_maw can do that10:00
rdale_ok10:00
pedroalvarezhas anybody built mesa since the latest upgrade on armv7lhf? : http://paste.baserock.org/ipobunatij10:01
* pedroalvarez upgrades his baserock-almost-14 system using cycle.sh10:06
pedroalvarezlooks like to have a version with eglibc and a version with new glibc living together in the same baserock system, you need  4.5G10:07
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:11
ssam2rdale: hi! you should be a member of baserock-writers now and be able to push10:13
ssam2sorry, must have been an oversight that you were only given access to local-config/lorries.git !10:13
ssam2pedroalvarez: once we have some infrastructure i'd really like to actually implement stripping of debug symbols at build time!10:14
persiaHrm?  Did I miss the mail about rdale_ being added to the set of folk who can commit?10:22
persiaOr do I misundestand the procedures?10:22
ssam2rdale_ has had commit access for a couple of years, but had let it lapse. That's my understanding, anyway.10:23
pedroalvarezit is also my understanding10:23
rdale_yes, i think i used to have write access10:23
persiaI'm not good at email, so it might be failure to read, but I believe we should document such changes by list traffic.10:25
persiaI can imagine a case where someone who once had access might be expected to do some work (as rdale has been) for a while before having access restored.10:25
persiaNote that I'm making a procedural fuss: I'm more than happy with rdale having access.10:25
ssam2persia: fair point. would you be happy if I sent a mail to baserock-dev explaining that I re-added his access ?10:26
persiaEntirely, along with the rationale.  Extra points for convincing someone to +1 it :)10:26
straycatI'm not sure it's reasonable to allow more than 2 people named Richard push access to definitions on gbo10:26
persiaheh10:27
pedroalvarezIt's unlikely that there is another Pedro :)10:27
* pedroalvarez gets a grammar book10:28
straycatI'm more worried that outsiders might think we have some sort of bias promoting people named Richard above others10:28
rdale_although i don't have a beard10:29
ssam2we also have a pretty bad bias against people with names beginning with X. I don't think we have a single committer whose name begins with X, actually.10:29
petefothHow can I find out who w.b.o user ‘Robert’ is? He has made some wiki changes that I would like to understand better 10:29
pedroalvarezXavier?10:29
pedroalvarezpetefoth: Robert Jones?10:30
ssam2petefoth: I think it's bashrc10:30
ssam2petefoth: I used intuition rather than any technical solution to work that out, though10:30
pedroalvarezindeed, because bashrc is Bob, here at least10:31
petefothpedroalvarez: ssam2: thanks. It would be good to be able to identify users of the wike edit-in-place functionality10:31
ssam2yes. Once we have our own OpenID provider we could potentially limit wiki access to those with Baserock OpenIDs, perhaps10:32
ssam2although that would raise the barrier for contributing a little, which I don't particularly like10:32
ssam2there may be a way to go from a Google OpenID to a full name10:32
ssam2I don't know what it is, though10:33
persiaThere isn't, and Google has been making noises about deprecating OpenID support for some time.10:33
petefothbashrc is Bob Mottram, who may or may not be Robert on w.b.o!10:35
ssam2I know that Bob likes emacs, that's why I figured it might be him who added those instructions ;)10:37
pedroalvarezoh, bob == robert??10:39
ssam2Indeed. If that doesn't blow your mind, did you know Jack is actually short for John?10:40
richard_mawTHEY'RE THE SAME LENGTH10:40
ssam2it dates from the days when it was traditional for a guy named John to name his first son John, at which point you need a way of distinguishing them.10:40
bashrcpetefoth: bashrc/bmottram10:41
pedroalvarezother that john junior?10:41
Kinnisonrichard_maw: Kate is short for Bob, so I don' tknow what you're whinging about :-)10:41
pedroalvarezmeh10:41
De|ta:D10:42
pedroalvarezPepe is short of Jose :)10:42
petefothbashrc: yes I got that, but are you also SUer Robert on wiki.baserock.org?10:42
bashrcno10:42
richard_mawI think "short for" got confused for "shorter than"10:42
petefothbashrc: OK thanks10:42
ssam2bashrc: ah! my apologies for assuming it was you.10:43
bashrcI have edited the wiki in recent times. I don't think I supplied any credentials though so the edits are probably just anon10:43
*** zoli_ [~zoli_@linaro/zoli] has quit []10:43
bashrcI added some image hashes and some startup instructions for getting a VM going10:44
petefothbashrc: were you ctearing and editing the guides/vm-script page?10:44
petefoths/ctearing/creating/10:44
bashrcyes10:44
petefothIn that case tou *are* user ‘Robert’ :)10:45
petefoth I am looking at that apge and working out where it mignth fit in best to the wikie structure, boith as it is and as proposed in the 'Documentation Complexity' email thread (http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2014-October/008897.html)10:46
petefothBut I don’t have any answers yet, and I may have to do some other stuff first10:47
bashrcpetefoth: it must have generated that username automagically from my Google account10:49
petefothbashrc: Indeed. 10:49
* bashrc unmasked again!10:49
paulsher1oodgithub has decided i'm not human.... wtf????10:54
bashrcreally??10:54
paulsher1oodyup. they've taken down my profile10:54
bashrcI don't remember github having CAPTCHAS10:54
bashrceesh. Any reasoning to it?10:55
straycatwow10:55
pedroalvarezpaulsher1ood: yeah, they decided that you should stop hacking :)10:55
Kinnisonpaulsher1ood: how strange10:56
bashrc:) but seriously, if github are doing that arbitrarily that's worring10:56
bashrcs/worring/worrying10:56
* Kinnison checks his github identities10:56
paulsher1ood"One of our mostly harmless robots seems to think you are not a human.10:57
paulsher1oodBecause of that, it's hidden your profile from the public. If you really are human, please contact support to have your profile reinstated.10:57
paulsher1oodWe promise we won't require DNA proof of your humanity."10:57
jmacsGosh10:58
richard_mawah, cutesy messages10:58
bashrcjeepers10:58
* petefoth signs in to github and is reminded he has a repo called Hobokan - eeek!10:58
robtaylorpaulsher1ood: mm, this is why i've decided to steer clear of proprietary centralised services for my code!11:05
* rjek read that as petefoth sighs into github11:05
petefothrjek: that too!11:05
* straycat has been using bitbucket since 2011 and hasn't had any reason to complain11:07
paulsher1oodjust when robtaylor expresses preference against github, it drops my profile... coincidence? :)11:07
straycatThough it would be nicer to use something open source ofcourse.11:07
Kinnisonpaulsher1ood: presumably if you contact their support they'll fix things11:07
paulsher1oodi have done. and tweeted. dunno what more to do, except switch to something else :_)11:08
paulsher1oodanyway, sorry for the noise, i'm in a venting mood :)11:08
straycatif you have your own server gitano works very well11:09
robtaylorpaulsher1ood: they must have been listening to us all the time! maybe facebook feeds them info by listening on the messanger app? =)11:09
paulsher1oodno facebook here11:09
robtaylorpaulsher1ood: There was on my phone though...  DUM DUM DUUMMMMM11:10
* robtaylor may be in a silly mood today11:10
paulsher1oodit appears my github profile is alive again...11:51
Kinnisonpaulsher1ood: what had happened?11:51
paulsher1oodno clue..11:52
rjekA robot decided paulsher1ood was a robot.11:52
paulsher1oodah.... email response ... 'Sorry for the trouble. We use some automated measures to fight spam, and your account was incorrectly flagged as spammy. I've cleared that flag now, so everything should be back to normal.'11:53
* straycat could do with http://sprunge.us/SeVV now11:53
paulsher1oodstraycat: does it need to be in master?11:58
paulsher1ood(of definitions)11:58
paulsher1ood(for what you're doing)11:58
straycatif anybody wants to import python packages they'll need the patched version of pip11:58
paulsher1oodstraycat: would be better if proposed a patch which was potentially upstreamable, rather than hacky?12:00
* paulsher1ood is reluctant to approve a patch which we know is not good enough12:00
straycatit's good enough for us12:01
straycatright now the main thing is that we have a way to import python packages12:01
straycatI can ask upstream how best to go about it once we're happy with the import tool12:02
persiaIs there any reason we need that order?  I'd be happy with a hacky patch if there was active discussion upstream that could lead to fixing it.12:03
persiaOne of the lovely things about how definitions work is that one can jump to git branches that don't include the history of prior refs, so one has less worries about dead-end patches.12:04
paulsher1oodstraycat: i'm disagreeing, i'm afraid. i don't think we should apply a lower standard  of review to some patch we create for an upstream, than we do to patches we create to code in baserock in general?12:04
KinnisonWhile I agree that carrying patches upstream won't like is a potential stone around our neck, it's also sometimes the only way to get enough of a prototype together to convince upstream of our usefulness12:06
paulsher1oodfair point12:06
KinnisonWe shouldn't not review it12:07
Kinnisonbut we shouldn't say "upstream won't like this" as a reason to veto12:07
paulsher1oodso if others want to +1 straycat's propsal, i'm ok12:07
Kinnisonpaulsher1ood: you should make your concern known on-list, but I'd be confused if, based on what you've said here, you gave it -112:07
Kinnisonpaulsher1ood: I can understand -0 for "I don't like it but I'm not vetoing it" though12:07
* paulsher1ood doesn't consider himself competent enough to review python12:08
* persia wants the discussion with upstream to have begun, regardless of the conclusion. Carrying patches without discussion leads to disagreements and blandishments and annoyed upstreams.12:08
* Kinnison believes straycat has been talking with upstream on IRC12:08
* straycat has every intention of discussing with upstream12:08
straycatIt's just that currently I'm focusing on the tool itself.12:08
persiaThat's fine.  Mentioning IRC discussion in the cover letter is sufficient for me.12:08
paulsher1oodKinnison: i'm not -1, or even -012:10
Kinnisonpaulsher1ood: fair enough12:10
Kinnisonpersia: that'd be a good approach12:10
*** robtaylor [~robtaylor@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Bye!]12:10
Kinnisonstraycat: can you follow up with any notes from any chats you *have* had, and any details of overtures you intend to make going forward, I think that'll be enough to convince most people12:10
persiaThe key thing is that in the event things get odd, it is exceedingly helpful to be able to point to old mail messages detailing that discussion was had.12:11
paulsher1oodone thing - is the patch in question actually in the emailed patch series? or just a ref to it?12:11
persiaOnce everyone agrees any disagreements are accidental, fixing things becomes lots easier.12:12
straycatKinnison, *nod* I haven't spoken to them about this patch, yet, again because my main focus is the tool itself12:14
jjardonhttp://cache.baserock.org:8080/ <-- amazing12:16
jjardonis that configured by default in the baserock images?12:16
paulsher1oodjjardon: no, but we can fix the wiki instructions (and should do)12:17
persiaWhy not just fix the default of morph?12:18
paulsher1oodwe should do that too :-)12:18
persiaWith the cache server, and the patch pedroalvarez recently sent for more architectures, this will make everyone faster.12:18
paulsher1oodup12:18
paulsher1oodyup12:18
jjardonmmm, cant edit the wiki: "Error: OpenID failure: naive_verify_failed_network: Could not contact ID provider to verify response."12:19
* paulsher1ood tries12:19
jjardonnevermind, it worked with another gmail account12:19
paulsher1oodhave you done it?12:20
* paulsher1ood was going to do it12:20
jjardonpaulsher1ood: done, feel free to review12:28
* jjardon thinks maybe this should be more publicity available, IMHO is one of the main features of baserock12:29
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]12:35
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock12:35
petefothHow lomg does it take to kickstart the storyboard - it’s still not there :(12:38
paulsher1oodjjardon: don't tell everyone, or the bandwidth costs will kill us :-)12:39
petefothsorry - wrong window. (first in a long time :)12:40
paulsher1oodjjardon: i've changed it... http://wiki.baserock.org/quick-start/?updated#index4h212:43
jjardonpaulsher1ood: thanks, I like that more12:44
paulsher1oodtmv12:44
paulsher1oodtvm12:44
paulsher1oodwill someone submit a patch to make morph default to this, or shall i?12:45
pedroalvarezI'm not sure if morph should default to this12:50
pedroalvarezI assume that morph is defaulting to TROVE_HOST:808012:51
pedroalvarezso when someone else creates a trove, he can populate its cache, and then this default value is ok12:52
persiaBut most folk don't have troves.12:53
persiaEspecially most folk downloading an image for the first time.12:53
pedroalvarezso, the patch would be that morph uses cache.baserock.org, but if there is a TROVE_HOST configured in /etc/morph.conf use TROVE_HOST:8080?12:54
persiaI think we should *support* setting a different cache host in morph.conf, but defaulting to "git.baserock.org" is just broken: not only is that cache usually out of date, but it specifically reinforces the idea that the artifact cache and the git server need to be the same machine.12:54
persiapedroalvarez: That would be an ideal patch from my perspective, yes.12:54
pedroalvarezgit.baserock.org cache is not broken. it just only have cache for latest releases12:55
persiaI'd also like to drop "TROVE_HOST" in favour of separate specification of curated archive and cache server, but that's a separate patch :)12:55
persiapedroalvarez: I assert that defaulting there is broken, not that the server is broken.  The problem is that it is always out of date.12:56
persiaSo one cannot usefully follow development with that default.12:56
pedroalvarezpersia: yeah, I agree12:56
persiaAh, good.  Sorry for any confusion caused by my excessive verbosity.12:57
pedroalvarezwell... I think we have to make a plan to clean cache.baserock.org12:59
pedroalvarezis going to be full of artifacts soon now that we are going to put more masons13:00
pedroalvarezbtw, I've created an armv7lhf mason: http://85.199.252.156/13:01
pedroalvarezbut this mason is building also the genivi system, and looks like mesa doesn't buiild :/13:02
petefothpersia: in your latest email to the list you mention ‘cross and canadian builds’. What’s a canadian build?13:03
ssam2that's still fucking amazing that we can have an ARMv7lhf Mason!13:03
ssam2even if the build log is pretty nonsensical.13:04
persiapedroalvarez: Never removing artifacts is the best plan.13:05
radiofreeERROR: Failed to build baserock:baserock/definitions 67be3d4a749a18d2e2ff3ce3dce3a1122e8bc89e systems/build-system-armv7lhf-jetson.morph: Building failed for pytz-misc13:06
persiapetefoth: http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross13:06
radiofreeERROR: In staging area /srv/distbuild/tmp/staging/tmpXFLQqE: running command 'sh -c make' failed.13:07
radiofreebuilds/build-step-itzam-tarball-misc.log13:07
persiapetefoth: Also https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html13:07
radiofreeignore the builds/build-step-itzam-tarball13:07
radiofree*** [freedreno_screen.lo] Error 113:07
radiofreehas the genivi image been updated to use the latest libdrm?13:07
radiofreewith the freedreno api?13:07
radiofreejjardon: ^13:08
radiofreethis might be my fualt, when i +1'ed the new mesa, i had only tested it without freedreno support13:08
radiofreeit's possible it needs a newever libdrm13:08
pedroalvarezradiofree: odd, that chunk is also in the devel system, not only in the build system13:09
petefothpersia: thank you. I don’t think I would *ever* have found those links13:11
persiaThe nomenclature is a bit eccentric :)13:12
petefothpersia: are you sure you are not British - http://www.understatementexamples.com/for/british-understatement/13:14
jjardonradiofree: we are using baserock/jetson/drm so thats 2.4.56 + patches for tegra (latest is 2.4.58)13:16
* straycat likes http://www.understatementexamples.com/understatement/ladies-and-gentlemen-this-is-your-captain-speakin/1039/13:17
* persia also13:17
jjardonradiofree: freedreno support is already in 2.4.5613:18
radiofreejjardon: it's just according to that mason log, mesa failed to build freedreno13:20
radiofreewhich i hadn't tested when i gave it my +1, sorry :\13:20
jjardonradiofree: so mesa in ARM is not building?13:20
radiofreei have no idea if it's just a glitch or not13:21
radiofreei'll test it at some point today13:21
jjardonoh, just see the pedroalvarez mesage about the arm mason13:21
* jjardon taking a look13:21
radiofreedo you think we can make an assumption that most systems come with "pv" installed?13:25
radiofreethe output for kill -USR1 $(pgrep ^dd) is a bit spammy13:25
radiofreeactually scrap that, fedora doesn't13:25
jjardonpedroalvarez: what reference system is being build in cache.baserock.org?13:36
jmacsssam2: What strata should I be importing to get as much chef support as possible?13:36
jmacsruby, I'm guessing - anything else?13:37
jjardonradiofree: seems is actually a bug in mesa: we need libdrm 2.4.57 but mesa only checks for 2.4.5513:47
* jjardon happy to see baserock is already helping to fix bugs upstream :)13:47
ssam2jmacs: I pushed a branch a while back which has the chef client and all its RubyGem deps, it should still be there and should still work13:51
ssam2jmacs: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/sam/chef13:52
ssam2created with an old version of the import tool13:52
jmacsCouldn't find it on the mailing list13:52
ssam2sorry, I never got to properly finishing it13:52
jmacsNo problem, I'll give it a try. Thanks.13:52
ssam2if you have problems, it may well make sense for me to spend time looking at it next week. We can discuss on Monday13:53
ssam2chef has been a good way to drive the development of the Baserock Import tool, and in fact I think it's one of the original requirements for it13:53
jmacsYep13:54
jmacs"Field x-build-dependencies-rubygems not allowed in morphology strata/chef/chef-master.morph"13:59
ssam2jmacs: oh, yeah13:59
ssam2could you remove the 'x-' fields from all the morphs in strata/chef/* and try again ?14:00
ssam2I was using a patched morph that ignored all fields with 'x-'14:00
jmacsSure14:00
richard_mawI had assumed we merged that change, I beliege I +1'd it14:00
ssam2I think in the end I decided it wasn't needed14:00
ssam2although my recent thinking is that it might be needed after all :)14:00
ssam2one of the hard parts of the baserock-import tool is for it to look in an existing definitions.git and say 'hmm, I'm importing something called 'rake', but there's already a morphology for 'rake' -- is that an existing morph for the thing I'm trying to import, or a morph for a totally unrelated component that has the same name' ?14:01
ssam2currently it punts on that problem and just adds everything, leaving the user to sort it out14:02
*** persia [quassel@ubuntu/member/persia] has quit [Read error: Connection reset by peer]14:06
*** persia [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock14:06
*** persia [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]14:06
*** persia [quassel@ubuntu/member/persia] has joined #baserock14:06
paulsher1oodssam2: can we be a bit smarter and look at the basename of repo: when comparing whether proposed 'rake' is the same as the 'rake' we already have?14:17
ssam2that's harder than it should be because 'repo' is in the stratum, not the chunk14:18
ssam2and 'rake' could be in many strata, or none14:18
persiaYet another argument for merging strata and chunks14:18
ssam2indeed14:18
ssam2I think adding x- fields would be better, because then we can keep track of what upstream version is in use14:19
ssam2so the tool could tell if it's importing rake 2.1 and the existing definition is for rake 1.0 or something14:19
persiaAh, where it might even be the same git repo, but the versions are (importantly) different?14:21
persiaI don't like your suggested nomenclature (with x-), because I consider that to be "experimental", or "extention", but otherwise I think I agree.14:22
ssam2I was using the x- to mean exactly that, in fact :)14:22
paulsher1oodso on a related note... i'd like to submit patches to make all of our names for things unique...14:23
persiaFor testing, I liked your use of "x-": as a merge proposal, I'm unhappy with the idea.14:23
paulsher1oodso for example i would like to establish u-boot|jetson and u-boot|wandboard etc14:23
persiapaulsher1ood: I'd like to see that.14:23
pdarI've noticed some repeated information at http://wiki.baserock.org/guides/build-failures/, is there a recomended procedure for changing this? Or editing w.b.o in general? 14:23
paulsher1oodwould folks be happy with that convention?14:23
pedroalvarezjjardon: x86_64 mason is just building the devel system14:24
paulsher1oodpdar: please fix what you think needs fixing, then mention that you've done so here14:24
* richard_maw doesn't like the | symbol, and would prefer we were in a world where we don't care about duplicate names in definitions, so long as they're not involved in what you're building14:24
pedroalvarezjjardon: arm one is building the devel and genivi system, but just because it's using clusters/release.morph14:24
persiapaulsher1ood: I thought you wanted to use | for versions, whereas that sounds more like flavours to me.14:24
* richard_maw would prefer @ for versions14:24
persiarichard_maw: That means we can't have any tooling that can inject stuff into definitions, because it can't know what you mean.14:25
* persia likes the semantics of @ for versions (plus, I have an @ key, and I don't have a | key, making @ easier to type)14:25
paulsher1oodpersia: u-boot|jetson and u-boot|wandboard are different versions. i'm suggesting it could be equally u-boot|some-version-identifier - let users do what they want with this string14:25
pdarpaulsher1ood: cool, thanks! 14:26
paulsher1oodi'm ok with @ instead, i think, but | looks slightyl shinier to me14:26
richard_mawpersia: you could if you tell it which system to start with, but this may not be a suitable time to discuss this14:27
* Kinnison is worried that | has semantic meaning in yaml14:27
richard_mawpaulsher1ood: I object to |, since if we ever have command-line tooling that requires names, you'd have to escape the | symbol to avoid it being interpreted by the shell14:27
paulsher1oodrichard_maw: as a user, i care to get us to avoid duplications, since they cause confusion.14:27
Kinnisonalso @ is read as 'at' rather than any of 'pipe' 'bar' 'given' etc.14:27
paulsher1oodrichard_maw: ack. what would be the best symbol to use?14:27
persiarichard_maw: Hrm.  Maybe.  On time: yes, we need to get through 1) runtime-depends ,2) merge chunks and strata, and 3) fix cache computation first.14:27
* paulsher1ood thought of : for example14:28
Kinnisoncolon is bad because shells14:28
*** genii [~quassel@ubuntu/member/genii] has joined #baserock14:28
paulsher1oodok, not |, not : 14:28
KinnisonLots of revision control systems use '@' for introducing a version14:28
paulsher1oodwould there be consensus on @ ?14:28
persiaAnd shells consider @ a normal character14:28
* SotK likes @14:28
persiaWe could generate one if we all post to the mailing list fast :)14:28
rjekMany many many other things use @ to indicate revision or time.  I think it would be surprising if we used something different.14:29
paulsher1oodok, i'll submit a patch, to get the ball rolling14:29
richard_mawI have no objections to disambiguating chunks with "@$VERSION", but I'll resist attaching any semantic meaning to the version string after the @14:36
persiarichard_maw: Do you resist asserting that the string after the @ is for "version" as opposed to other classes of disambiguation?14:37
richard_mawI resist any form of machine parsing of the name or version string. I'm happy for it to be a nice human friendly description of what's provided14:38
persiaAh, so it must have arbitrary human meaning?  My question was mostly about whether it must be a version.14:38
persiarake@1.0 vs. rake@2.1 is obvious.14:38
persiau-boot@devboardA vs. u-boot@devboardB is less obvious, especially if they both claim to be 2014.1014:39
paulsher1oodin passing, what is the effect of a -1 vs two +1s?14:41
Kinnisona -1 from someone trusted is a veto14:41
Kinnisonno amount of +1s and +2s should counteract it14:42
paulsher1oodok. so... i wonder what the scores on the doors will be, for this... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/ps/unique-u-boots&id=e40bd7f09c0f754b0dab83573ef4795137f4857b14:42
persiaIn the event that a -1 has been sitting around forever, despite folk trying to engage the -1'er, resubmitting the patch series should be considered an acceptable workaround.14:43
persiaIf the -1'er is responsive, this is nonoptimal, as it will just be -17d again.14:44
paulsher1oodpersia: ack. i was just unclear about whether scores got added or not14:44
paulsher1oodanyway... if i submit the above, is someone going to -1 it?14:44
* persia would +1 it as obvious, nondisruptive, and helpful14:45
richard_mawpaulsher1ood: it won't be from me, it's valid and allows the cases where we currently require unique names to work, +114:45
paulsher1oodah,ok. that's great. i was misunderstanding the comment about semantic meaning of the version string. jetson and wandboard have semantic meaning, to me :-)14:46
persiaThe discussion was whether it could have specific semantic meaning, as opposed to human-readable meaning.14:47
paulsher1oodaha14:47
persiaI believe we agreed on human-readable.14:47
paulsher1oodexcellent14:47
richard_mawI might -1 anything that suggests we should be parsing the name e.g. using stuff after the @ as a replacement for the ref field14:47
persiaSo if it is required to be @jetson for a jetson system, there is too much magic, and exorcism is required14:47
* paulsher1ood goes to write email14:47
paulsher1oodunderstood14:48
richard_mawyou've already got +2, so an email isn't required if you have your own push access14:48
paulsher1oodi see. i've never merged anything into master, as far as i remember14:49
paulsher1oodi'm a bit reluctant to start now, tbh. better that i continue to believe i can't do it ,to stop me trying in the dark hours of the weekend :)14:49
richard_mawstrictly there's a risk that we've not given anyone time to -1 it, who might have good reason to, but reverting is easy enough14:49
persiaSend it to the ML if you prefer, and we can do it all again via email.14:50
paulsher1oodcan someone tell me their preferred merge git command sequence?14:51
persiagit rebase master14:51
persiaBut I don't think that's the popular one around here :)14:51
ssam2paulsher1ood: git merge --no-ff --no-commit14:52
ssam2fix any conflicts, check it works, then 'git commit' and add Reviewed-By tags to the commit message14:52
persiaThat would be the popular one (that makes visualisation tools sad)14:52
ssam2makes 'git log --topo-order' quite happy14:53
mwilliams_ctHi baserockers :). I'm doing some looking into ZFS and whether we could get it on Baserock. I'm only just getting started on this, but one concern is that ZFS is licensed as CCDL which might mean we can't "ship" it as a kernel module. I briefly looked into DKMS as a way round this, but this is a bit un-baserocky. any thoughts?14:53
ssam2if we can use such terms to describe inanimate bundles of code14:53
* persia was thinking of things like gitk, gitg, tig, etc.14:53
persiamwilliams_ct: According to http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue it seems that ZFS can never be merged, but can be distributed as source and as binary.14:55
persiaSo if you can create a chunk artifact that contains only the ZFS modules, you should be safe.14:55
mwilliams_ctahh! OK I've misunderstood that then. thanks persia! Right now I'm focusing on building it at all14:56
persiaDKMS is useful for environments where one updates the kernel separately from the modules, so one has to rebuild when the new kernel arrives.14:56
persiaIn Baserock, we don't do things that way.14:56
persiaSince it is all a consistent system, we would autorebuild at build time, rather than when the kernel is updated.14:56
paulsher1oodssam2: http://paste.baserock.org/akiveturoq.coffee ?14:57
persiaThat said, I'm not sure that shipping a system with working ZFS already baked in is sufficiently separate.14:57
ssam2paulsher1ood: works for me14:57
richard_mawmy previous discussions about this with rjek suggested that it might not be so clear cut, since in some interpretations you can't distribute binaries, but if the zfs project's interpretation is that you can distribute binaries, I think that counts for a lot14:57
persiaIt may be the case that we can populate the artifact cache with a ZFS module artifact, but not publish a reference image containing ZFS.14:57
* persia would need to learn more to be confident suggesting references offering an authoritative opinion on this14:58
ssam2paulsher1ood: although since upstream master has moved, you'll need to 'reset  --hard HEAD~1', 'pull --rebase', and do the merge again :(14:58
ssam2at least, that's how I see it14:58
ssam2(i note that I don't have a preferred merge workflow, I just value consistency)14:58
persiaI just try to pretend I magically did everything 5 seconds ago: my local history is almost always wrong, but it means the merge command is easy to remember :)14:59
* richard_maw grubles at protobuf's configure script attempting to download tarballs at configure time14:59
persia(note, this strategy does not work for people who have shared their work)14:59
rjekrichard_maw: !14:59
richard_mawrjek: it tries to download gtest, as it assumes if you're not building a pre-packaged version you might want to run tests15:00
persiarichard_maw: One of those: "it appears you don't have my favorite library: let me install it in some random way to build" things?15:00
ssam2persia: tracker's git repo uses non-fastforward merges for feature branches and looks fine in 'tig'15:00
ssam2persia: but it has various commits (translations etc) to master too15:00
ssam2perhaps it's the fact that we have nothing but merge commits that makes tig produce confusing output15:01
straycat11:54 ! straycat could do with http://sprunge.us/SeVV now15:02
persiassam2: It isn't confusing, just wider than I'd prefer, because it keeps all these extra merged branches around.15:03
persiaIn my preferred workflow, my branches are private, and there are a few public branches for collaboration.15:03
persiaSeeing every patchset as a branch in the history seems overly verbose to me.15:03
ssam2straycat: if you'd like people of this channel to do something, direct requests are generally best. If you'd like patches reviewed I recommend sending them to the mailing list15:04
straycatit's a ref change15:04
straycatthere's no need to for such ceremony15:04
ssam2I can break every baserock system in definitions.git with one ref change15:05
* straycat sighs15:05
ssam2I'm not trying to be awkward, simply advising why you might not be getting responses15:05
persiaDidn't we talk about this before?15:06
* persia is definitely -0 until upstream discussion happens, but isn't fussed enough to get in the way of other's positive votes.15:06
persias/happens/starts/15:06
straycatOkay, I will send the pip patch for the associated change to the list15:09
paulsher1oodstraycat: i'm guessing you're blocked until this lands? if so we can get it reviewed today15:11
straycatnot blocked exactly, but i won't be around for a while over the next few weeks so I want to ensure this is all in a useable state for other people. Which is why I'm deferring upstreaming the change.15:13
paulsher1oodack15:13
radiofreedoes github have a git:// clone address?15:14
radiofreeor is it fine to use https in a lorry file?15:14
richard_mawgithub does git:// urls, just replace the https?:// with it15:16
radiofreeta15:16
jmacsssam2: chef stratum seems to be building now.15:25
pedroalvarezwow, I wasn't aware about the u-boot naming change15:25
rdale_the xserver chunk from the master branch is failing to build for me - is that a known problem?15:26
pedroalvarezpaulsher1ood: looks like you missed this bit: http://paste.baserock.org/opokizeqiz.sm15:27
pedroalvarezbtw, the non-official arm mason spotted this: http://85.199.252.156/log/16a188525677106d87373327443ecd83a4fbbdb8--2014-11-21%2015:24:39.log15:28
pedroalvarez(not-official = not yet published, testing it before that)15:28
radiofreeeh15:30
radiofreewhat's that?15:30
radiofreestrata/bsp-jetson/u-boot@jetson.morph ??15:30
pedroalvarezlooks like a u-boot renaming to have unique names15:31
radiofreei see15:31
radiofreewas that automatic?15:31
persiaAnd generally introducing the use of @ to allow differentiation when identical names are tempting.15:31
persiaPatch from paulsher1ood15:31
radiofreeu-boot@jetson.morph looks like an e-mail address now though15:32
persiaPut on your subversion spectacles, and look again :)15:32
*** robtaylor [~robtaylor@xvm-124-143.dc2.ghst.net] has joined #baserock15:33
*** rdale [~quassel@140.Red-79-144-56.dynamicIP.rima-tde.net] has joined #baserock15:44
*** rdale_ [~quassel@123.Red-79-147-219.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds]15:47
paulsher1oodpedroalvarez: gah! i should not merge to master. _1 for that15:53
paulsher1ood+115:53
pedroalvarezpaulsher1ood: hahah no worries, you had a +215:53
paulsher1oodpedroalvarez: shall i fix it? or will you?15:54
pedroalvarezpaulsher1ood: I was merging it 15:54
paulsher1oodyou're a star :)15:54
mariaderidderI have asked SotK and perryl to use Trello from now on since their work is upstreamed - I would be grateful if the relevant people grant permission please? I believe pedroalvarez would need to grant them access 15:55
robtaylorradiofree: will i need to build my own image to get systemd 217?15:55
richard_mawmariaderidder: perefoth or I can also do it15:56
pedroalvarez yeah! more people collaborating with the baserock project!!15:56
radiofreerobtaylor: a devel image?15:56
radiofreepedroalvarez: any jetson devel images from master around?15:56
robtaylorradiofree: sure15:56
pedroalvarezmariaderidder: I've seen theirs RFC's and I wouldn't mind if they use the trello board to track their work15:56
* robtaylor is sad a closed source project is being used for the kanban15:57
richard_mawassuming perryl is perryl on trello, everyone involved has access now15:57
pedroalvarezradiofree: i'm trying to do the relevant fixes so I can populate cache.baserock.org with the cache of the *build* system of arm15:57
perrylrichard_maw: thanks! 15:57
mariaderidderthank you pedroalvarez and richard_maw :)15:58
radiofreerobtaylor: i can build one for you if there's no images about already, but i'll have to wait until later (using non-flashing jetson for something testing atm)15:58
SotKthanks richard_maw 15:58
SotKalso pedroalvarez 15:58
robtaylorradiofree: no worries. i have a jetson here. I can try your new scrips15:58
* robtaylor can do without for now15:59
radiofreerobtaylor: sure, when they're finished15:59
paulsher1oodradiofree: do you have any way of flashing my jetson? my usb problems seem to make it impossible for me now16:02
* paulsher1ood is sad about the trello thing too... but life is too short16:03
radiofreepaulsher1ood: usb problems?16:07
paulsher1oodflashing on my mac takes a variable time. worst case it seems to tend towards more than a day... 16:07
radiofreein a baserock vm?16:08
paulsher1oodyup16:08
radiofreeouch16:08
radiofreei can flash it later16:08
paulsher1oodi know i don't have usb3 support in vbox16:08
radiofreebut i'm currently running through the things we need to add to baserock to allow baserock to flash a jetson16:08
radiofree(using the open tools)16:08
radiofreeso... a bit busy atm, do you need it right now?16:09
straycatrichard_maw, SotK, thanks16:10
paulsher1oodno, i'll live16:13
radiofreeso i suppose we want to be able to do this in a baserock vm by default?16:13
persiaI'd be unhappy if we forced people to use Trello to track their baserock work16:14
radiofreewould require adding "nvidia-jetson-flash" to the devel-systems-* though16:14
radiofreethat would contain the flashing tools needed to run the flash/installer script16:14
paulsher1ooderk16:15
radiofreepaulsher1ood: or you could just run the script and let it clone everything you need and build it16:15
paulsher1oodradiofree: it would be ok to say - download nvidi-jetson-flash16:15
paulsher1oodradiofree: that seems fine16:15
radiofreewhich is what is going to happen on a normal laptop16:15
persiaradiofree: Was 546F641A.3090407@codethink.co.uk intended to have non-quoted content?16:23
* Kinnison was close to asking that himself, so is glad persia got there first16:23
persiaThe first couple times I read it, I thought it was my mailreader doing something odd16:24
Kinnisonhehe16:24
jjardonradiofree: Ive rebased the drm patches in http://git.baserock.org/cgi-bin/cgit.cgi/delta/drm.git/log/?h=baserock/jjardon/drm_2.4.58/jetson if you want to give them a try16:25
robtaylorradiofree: do we just use 3.18 mainline for the jetson?16:31
pedroalvarezhm.. the feedback of the armv7lhf mason is going to be really slow given that its distbuild network associated is using a different trove than g.b.o16:44
pedroalvarezwe might want to think about this 16:45
pedroalvarezbut anyway: first green! http://mason-armv7lhf.baserock.org/16:45
* straycat finds an excuse for a multiplexing generator16:45
* straycat hides16:45
persiaAll three masons' distbuild networks should be using the same git server.16:46
persiaArtifact cache is a bit trickier: I'd prefer they only uploaded artifacts if the build passed, but that means having separate ephemeral artifact cache servers for each distbuild network.16:47
paulsher1oodpersia: istm that if mostly if artifacts are built, from master, they've passed?16:49
persiaThat presumes that it is impossible to misbuild.16:49
paulsher1ood(even if some later part of the build fails, we'll need them usually)16:49
paulsher1oodi said mostly, usually16:49
pedroalvarezI guess we could configure the armv7 distbuild network to use g.b.o, but that would cause the creation of build branches in g.b.o if we use the distbuild network to build other things16:49
persiaConsider the case where something builds, but builds in a way that breaks a future build.  We don't really want that artifact cached.16:49
* persia dislikes the distbuild architecture harder16:50
paulsher1oodmason won't catch that anyway... ?16:50
pedroalvarezpersia: is a good point that we have to consider16:50
persiaOh, and I added an item to my wishlist for morph today: it should neither notice nor care whether definitions happens to be a git repo (or any class of VCS) :)16:50
paulsher1oodouch!16:50
paulsher1oodwell, ybd would be fine with that already i think :-)16:51
persiapaulsher1ood: It will, if it causes a future build to fail.  What we don't catch with the current set of tests is when we build something that doesn't work at all, but isn't on the critical path to self-building.16:51
straycat>.>16:51
paulsher1oodstraycat: what does that symbol mean?16:51
persiaYes, ybd meets that particular wishlist requirement (and may have been part of the generation thereof, as it was today that I reviewed ybd)16:51
straycatahh well that would be telling :)16:52
pedroalvarezpaulsher1ood: you have to upgrade yourself!! :) 16:52
pedroalvarez(using cycle.sh?)16:52
paulsher1oodpersia: if it builds, but causes a future build to fail, mason won't spot it?16:52
paulsher1oodor will it?16:52
pedroalvarezpaulsher1ood: if I change bison, and then gstreamer doesn't build, then I don't want that bison artifact16:53
pedroalvarez(is what I uderstood from what persia said)16:53
persiaIf it misbuilds, and sometihng else build-depends on it, mason will probably catch it (depending on the specific nature of the misbuild and the build-dependency)16:53
paulsher1oodah, ok. yes. sorry. i'll shut up16:53
persiaIf it misbuilds, and nothing else build-depends on it in the mason-tested build tree, mason won't catch it.16:54
persiapedroalvarez: Precisely.16:54
pedroalvareznote: atm there isn't any artifact uploading, all the artifacts are there becasuse the distbuild networks  are using this artifact-cache-server16:54
pedroalvarezbut we can change this16:55
persiaAh, so all the misbuilds are also available.  Hrm.16:55
pedroalvarezwe only need to think about this16:55
persiaI'm not that fussed: SotK has a good plan.16:55
paulsher1oodi think that's ok, tbh. we need some gardening of cached artifacts, is all16:55
persiaThe extra cache we have now slightly increases the chance of collision and uses extra space, but it probably isn't worth trying to fix the current mason.16:56
persiapaulsher1ood: But we don't know *which* artifacts are misbuilds today.16:56
paulsher1oodpersia: i'd suggest just remove artifacts that have not been used after 6 months, or something?16:56
jjardonpedroalvarez: uh? how is that possible (the green in http://mason-armv7lhf.baserock.org/)? AFAIK we need a new version of libdrm to compile our mesa in arm16:57
paulsher1ood(unless part of a 'release')16:57
pedroalvarezjjardon: is only building the build-system16:57
jjardonpedroalvarez: ah, ok, sorry16:57
pedroalvarezjjardon: we will consider adding the genivi systems to the ci16:57
pedroalvarez(also, I wanted to se the green :) )16:58
paulsher1ood:-)16:58
franredwen we enable anything in the kernel do we enable it for all the bsps?16:58
jjardonpedroalvarez: maybe you can add a link to the system you are building somewhere in that page?16:58
richard_mawpaulsher1ood: ybd appears to not require the definitions tree to be in a git repository, as it currently requires you to run it in the top-level directory. This is one reason why I'd prefer relative file paths to other definitions16:58
richard_mawfranred: I tend to16:58
persiapaulsher1ood: I hope there aren't any more releases in 6 months, causing that to be less useful than one might think.16:58
richard_maws/why/one of the reasons why/16:58
franredrichard_maw, cheers16:59
persiaBecause some folk will still want older cache.16:59
pedroalvarezjjardon: it's in the log: http://mason-armv7lhf.baserock.org/log/da6ead621f82a8fa3fd38c263e498c3d856b2e9e--2014-11-21%2016:41:39.log16:59
* richard_maw had to add a bunch of config for CRIU to the kernels recently, so added it to them all16:59
pedroalvarezjjardon: yeah, is not clear enough, but I think is fine for now16:59
paulsher1oodrichard_maw: i could make it take a full or relative path easily enough. but i'd still want it to process *all definitions* in the tree16:59
paulsher1ood(i've convinced myself that there is no appreciable time penalty, so don't need relative file path info)17:00
persiaBeing able to know what are the set of all definitions in the tree is one of the advantages to having definitions in a git repo.17:01
persiaIt forces the bottom of the tree in a well-defined way.17:01
paulsher1oodtrue. but you have a reason for wanting to deal with things that are not in a VCS?17:01
persiaMostly that I thought it would be a nice separation of stuff.17:02
persiaThat deifnitions is in git encourages morph to use more git internals, which encourages a lot of the things I don't like about morph.17:02
persiaBut there are also advantages.17:02
paulsher1oodwell, i think we get more benefits from git than problems17:03
paulsher1oods/more/way more/17:03
persiaDon't conflate the use of git to collaborate on definitions with the on-disk representation of definitions at the time one runs the `morph` command.17:04
persiaIf we're including the former, I agree.  If we're only considering the latter, I'm really not sure.17:04
paulsher1oodi was talking much more broadly than both your cases. as for the latter, i agree it doesn't matter much17:05
paulsher1ood(if at all)17:06
persiaIn the much broader sense, I couldn't agree with you more.  It's just this particular very narrow case.17:06
paulsher1oodack17:06
* persia has to go do physical things, and stops paying attention for a while17:06
* paulsher1ood escapes from cyberspace too17:06
radiofreerobtaylor: no, some cpufreq patches17:11
radiofreeflashing a jetson from another jetson gives some.. odd behaviour17:11
radiofreei'll investigate that later...17:12
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]17:32
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock17:33
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit]17:37
*** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit]17:48
radiofreepaulsher1ood: if you leave your jetson on my desk i'll flash it over the weekend17:51
*** darryl [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has joined #baserock17:54
darryl is now known as duderdice17:56
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection]17:56
*** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has quit [Client Quit]17:56
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal]17:57
*** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat]17:58
*** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has joined #baserock17:59
*** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving]18:06
*** rdale [~quassel@140.Red-79-144-56.dynamicIP.rima-tde.net] has quit [Ping timeout: 255 seconds]18:08
paulsher1oodradiofree: too late... i'll try it again myself. thanks anyway18:09
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds]18:26
*** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds]18:34
*** ssam2 [~ssam2@cpc7-asht7-2-0-cust170.10-1.cable.virginm.net] has quit [Quit: Leaving]18:54
*** duderdice [~chatzilla@c-73-184-236-199.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds]19:57

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