*** jjardon [sid723@gateway/web/irccloud.com/x-hbjivuqcuwaqshew] has quit [Ping timeout: 272 seconds] | 05:47 | |
*** jjardon [sid723@gateway/web/irccloud.com/x-ncgloseelkgskohj] has joined #baserock | 05:49 | |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:38 | |
jjardon | Some numbers of gnome-continuous that could be of interest here: https://mail.gnome.org/archives/desktop-devel-list/2014-September/msg00152.html | 07:49 |
---|---|---|
*** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:49 | |
paulsher1ood | jjardon: yes. very impressive | 07:51 |
*** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:05 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:28 | |
*** juergbi [~juerg@vserver.paldo.org] has quit ["Ex-Chat"] | 08:29 | |
*** juergbi [~juerg@vserver.paldo.org] has joined #baserock | 08:32 | |
* pedroalvarez installs dialog in baserock | 08:33 | |
petefoth | Does the `morph git` command still exist? | 08:36 |
pedroalvarez | ERROR: unknown subcommand git | 08:37 |
pedroalvarez | I guess that's a no | 08:37 |
pedroalvarez | I never heard of it | 08:37 |
Kinnison | I don't remember us every having one | 08:38 |
pedroalvarez | petefoth: is that mentioned anywhere? | 08:38 |
petefoth | pedroalvarez: ta. I am looking at http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/doc/branching-merging-systems.mdwn whihc says that morph git runs git with the arguments on the command line in each local git repository in the workspace. (which seems like it might be useful) | 08:38 |
petefoth | I'm looking at what commands could be taken out / deprecated to simplify the workflows | 08:39 |
Kinnison | isn't that morph foreach ? | 08:39 |
Kinnison | e.g. | 08:39 |
Kinnison | morph foreach -- git push origin HEAD | 08:39 |
pedroalvarez | dangerous | 08:40 |
pedroalvarez | no mention of foreach in that document | 08:40 |
Kinnison | pedroalvarez: okay then, morph foreach -- git push origin $(morph show-system-branch) | 08:41 |
Kinnison | less dangerous | 08:41 |
petefoth | pedroalvarez: as far as I know that doc has no 'official' status but it was updated relatively recently (2014-08-12) by richard_maw | 08:41 |
richard_maw | I generally do `morph foreach -- sh -c 'git push -n origin HEAD 2>&1'` first, then remove the -n if it looks ok | 08:43 |
Kinnison | richard_maw: why do the 2>&1 ? | 08:46 |
richard_maw | because otherwise the stderr gets swallowed | 08:46 |
Kinnison | boo | 08:46 |
Kinnison | can we fix that? | 08:46 |
richard_maw | yeah, we didn't at the time because we also want to print the errors out for commands that fail after they have done, and we can report the error code | 08:47 |
richard_maw | the ExtensionSubcommand class would let us pass a callback for stderr handling that saved it and wrote it out to stderr | 08:48 |
* Kinnison would rather see normal UI from each subcommand | 08:48 | |
Kinnison | esp. given some commands won't produce verbose output if their stdout/stderr are not ttys | 08:48 |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:01 | |
pedroalvarez | I've found pythondialog as a python wrapper for dialog | 09:09 |
pedroalvarez | also, "import curses" from python doesn't work. | 09:09 |
Kinnison | :-( | 09:10 |
ssam2 | in Baserock ? | 09:11 |
pedroalvarez | I've read that can be caused because ncurses wasn't present when installing python | 09:11 |
pedroalvarez | ssam2: yeah! this is #baserock | 09:11 |
ssam2 | yeah, I expect that's the problem | 09:11 |
jmacs | "import curses" works OK on my baserock system | 09:11 |
pedroalvarez | jmacs: good to know, then is only my problem | 09:12 |
jmacs | It's strange. It should be a standard library. | 09:12 |
pedroalvarez | this is the error I get: http://pastebin.com/3tJ4SAap | 09:14 |
Kinnison | Hmm, looks like perhaps libncurses isn't available when cpython is built? | 09:16 |
ssam2 | works in my Baserock VM, too | 09:16 |
pedroalvarez | I see | 09:19 |
pedroalvarez | ncurses was moved to the build dependencies of cpython after my vm was built | 09:19 |
Kinnison | doh | 09:20 |
pedroalvarez | when I saw the problem I thought: ok, lets move ncurses, but it was already there, and hence my confusion | 09:20 |
jmacs | That explains it. I've got a pretty recent built | 09:20 |
jmacs | build. | 09:20 |
Kinnison | heh | 09:21 |
pedroalvarez | thanks for your help | 09:21 |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:21 | |
* Kinnison is tempted to ask for mosh support in Baserock | 09:28 | |
richard_maw | patches welcome | 09:28 |
Kinnison | :-) | 09:28 |
Kinnison | Unfortunately it needs a number of icky perl modules | 09:28 |
richard_maw | eww | 09:29 |
pedroalvarez | utf8 | 09:32 |
pedroalvarez | I tried to intall it once, and got blocked with utf8 | 09:33 |
ssam2 | Kinnison: would be fun to write a CPAN importer for the import tool | 09:36 |
ssam2 | for someone who finds writing Perl fun :) | 09:36 |
* Kinnison does not | 09:36 | |
*** De|ta [~arc@195.242.156.171] has quit [Quit: rebooting] | 09:41 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 09:51 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:51 | |
jjardon | Could someone merge my mesa branch? It already got two +1 :) . thanks! | 09:52 |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:55 | |
paulsher1ood | jjardon: are you still waiting +2 on others? | 09:55 |
ssam2 | can we sort jjardon with commit access, as agreed on the list several weeks ago? | 09:55 |
Kinnison | The one upstream person with the right to do that has not been around, we clearly need to repair that flaw | 09:56 |
richard_maw | jjardon: you can have a +1 for the dbus-glib one too. I'll respond on the ML | 09:56 |
jjardon | paulsher1ood: the dbus-glib ones | 09:56 |
jjardon | richard_maw: thanks | 09:56 |
paulsher1ood | jjardon: i built it. if there's something i can run to test it, i'll +1 | 09:57 |
Krin | morning all, here's your resident problem and headache causer :) so "morph --verbose build systems/devel-system-armv7lhf-jetson.morph" got terminated through a broken pipe at step 560 of 790 last night, is this likely to be recoverable? | 09:57 |
paulsher1ood | Krin: just restart | 09:57 |
Kinnison | yep, just start it again | 09:57 |
paulsher1ood | should pick up at 560 | 09:58 |
paulsher1ood | you might want to run screen first, so that it can continue even if your ssh drops | 09:58 |
jjardon | Kinnison: what is the process? Should I send my public SSH key to someone/somewhere? | 09:58 |
Kinnison | jjardon: Persia is supposed to have sorted all this, but he's not been around (very unwell as I understand) | 09:58 |
Kinnison | jjardon: I don't know what the Baserock upstream team decided for this | 09:59 |
Krin | starting again, at the end gives me "ERROR: Failed to update cached version of repo git://git.baserock.org/delta/kexec-tools" is this just it's way of saying "already up to date"? | 09:59 |
paulsher1ood | Krin: nope. can you ping anything on that jetson? | 09:59 |
paulsher1ood | s/on/from/ | 10:00 |
jjardon | Kinnison: OK, I will ping him when I see him around | 10:00 |
Krin | seem to be able to ping google.com fine. | 10:00 |
paulsher1ood | ok | 10:00 |
Kinnison | jjardon: I'm starting to think that the rest of the upstream team may have to make a decision about who else can grant these rights | 10:00 |
ssam2 | Kinnison: who has the ability to add users on git.baserock.org, other than you? Would you be willing to grant that ability to someone the upstream team ? | 10:00 |
Kinnison | jjardon: since clearly having a SPoF is a bad idea | 10:00 |
ssam2 | *someone on | 10:01 |
Kinnison | ssam2: Richard Maw is also in that team | 10:01 |
paulsher1ood | Krin: please retry your command with --no-git-update | 10:01 |
* paulsher1ood is confused as to what's breaking for Krin, though | 10:01 | |
ssam2 | ok. come in richard_maw! would you be able to grant jjardon commit access, in persia's absence ? | 10:01 |
* paulsher1ood considers requesting/using supercowpowers on gbo, since he's online at times when others aren't | 10:02 | |
Krin | that's one of my magic things paulsher1ood, if it can go wrong around me, it will, usually in spectacular fashion, sometimes involving fire :) | 10:02 |
paulsher1ood | Krin: it's a talent. nurture it. but also nurture precision in identifying and describing exactly what happens | 10:03 |
richard_maw | ssam2: only when I make it into the office, working from home this morning, and I haven't authorized my personal laptop to be able to do that | 10:04 |
Krin | huh... interesting. adding the --no-git-update command gave a result i would not have expected for git not | 10:06 |
Krin | git being told not to update | 10:06 |
ssam2 | ok. in the meantime I'll merge your mesa patch jjardon ! | 10:06 |
Krin | this requires a cup of tea. | 10:06 |
Krin | ERROR: Ref 9359b61ca44980d33c0bee42b9bb2e36e72835dd is an invalid reference for repo git://git.baserock.org/delta/kexec-tools | 10:06 |
jjardon | ssam2: thanks! | 10:07 |
*** De|ta [~arc@195.242.156.171] has joined #baserock | 10:14 | |
jjardon | richard_maw: you are rigth about the llvm dependency, I will send a new patch shortly. I got confused as mesa didnt depend on anything when I moved it to its own stratum from x-generic. But llvm is in x-common, not x-generic | 10:18 |
* ssam2 apologies for attempting push the whole of linux.git to baserock:baserock/definitions | 10:31 | |
ssam2 | i was wondering why 'git remote update' was taking so long ... | 10:31 |
pedroalvarez | who pushed morph.git into definitions.git in the past? | 10:32 |
SotK | that was me | 10:32 |
pedroalvarez | :) | 10:32 |
ssam2 | that wasn't on git.baserock.org, at least :) | 10:32 |
SotK | that is true :) | 10:32 |
pedroalvarez | I once screwed up morphs.git (old definitions.git), but I even don't know what I did, I was still learning git :) | 10:33 |
jjardon | mmm, seems that the llvm repo stop being updated. | 10:40 |
jjardon | like 3 weeks ago | 10:40 |
jjardon | also it didnt import the tags. llvm is a svn repo, maybe lorry still doesnt support this? | 10:42 |
Kinnison | Depends on the layout, git-svn should import tags | 10:42 |
jjardon | Kinnison: Do you know if this one is supported? https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_350/final/ | 10:45 |
jjardon | oh, wait, we are using their git mirror | 10:45 |
jjardon | http://llvm.org/git/llvm.git that seems to be empthy, that would explain the lack of updates | 10:46 |
Kinnison | oops | 10:47 |
jjardon | the github mirror is still working though: https://github.com/llvm-mirror/llvm | 10:49 |
pedroalvarez | jjardon: `git clone http://llvm.org/git/llvm.git` works for me | 10:50 |
jjardon | pedroalvarez: yeah, here too... problem with lorry then? | 10:51 |
pedroalvarez | jjardon: or maybe the mirror is out of date | 10:52 |
jjardon | pedroalvarez: just cloned it, last change is from today | 10:53 |
pedroalvarez | jjardon: right, I'll take at what's going on | 10:54 |
jjardon | pedroalvarez: thanks! | 10:54 |
Krin | ok, if anyone gets that above error again, with the git having issues picking up where it left off, the cache needed removing, the artifacts/*kexec* and gits/*kexec* | 10:55 |
pedroalvarez | Krin: corrupted data then? | 10:56 |
paulsher1ood | seemed to be | 10:56 |
ssam2 | oops, I have a feeling I just used git-send-email to spam a whole bunch of unrelated Linux people | 10:57 |
Kinnison | Oh dear | 10:57 |
paulsher1ood | ssam2: oops | 10:57 |
ssam2 | question is, is it better to send further spam to apologise to them ? | 10:57 |
jonathanmaw | ssam2: probably better to apologize, otherwise they don't know if you might do it again | 10:58 |
Krin | it's always better to send more spam, then they have more to moan about, and everyone in england is only happy when complaining :) | 10:59 |
ssam2 | yeah, I shall do | 10:59 |
* ssam2 changes sendemail.suppresscc from 'self' to 'all' in git config | 11:06 | |
pedroalvarez | Found what is causing llvm not to be updated: http://pastebin.com/vRS0A88h | 11:07 |
jmacs | Oh, no 'objects' directory in the source git repo... we saw this during the upgrade of gbo but I can't remember any more details :/ | 11:11 |
ssam2 | paulsherwood: seems you changed the command in http://wiki.baserock.org/devel-with/ to be 'morph --verbose build systems/base-system-x86_64-generic' | 11:16 |
pedroalvarez | so, lorry tries to do do a backup before lorry new content, but it fails if the things that it's trying to backup are not there | 11:16 |
ssam2 | paulsherwood: but that won't work with the 14.29.1 tag of definitions, it should be 'morph --verbose build base-system-x86_64-generic' | 11:17 |
ssam2 | paulsher1ood: should I change it back , or am I missing something ? | 11:17 |
pedroalvarez | versioned documentation! ftw! | 11:17 |
ssam2 | indeed | 11:19 |
pedroalvarez | jjardon: llvm lorry is working again | 11:19 |
paulsher1ood | ssam2: my mistake, please revert. | 11:19 |
paulsher1ood | i'm sure i had a reason, though | 11:19 |
paulsher1ood | lost in backscroll | 11:19 |
ssam2 | it'd have made sense if we also updated devel-with to be using latest morph | 11:21 |
ssam2 | (although it'd need to be 'morph --verbose build systems/base-system-x86_64-generic.morph' in that case) | 11:22 |
ssam2 | I've also updated http://wiki.baserock.org/contributing/ to recommend 'git send-email --supress-cc=all' so that others don't do the same dumb thing I just did | 11:22 |
paulsher1ood | ssam2: i want to propose use latest morph by default. since morphs-in-definitions release morph can't cope anyway | 11:25 |
ssam2 | I don't understand your last sentence ... morph from 14.29 can build the 14.29.1 tag | 11:26 |
ssam2 | I'm not necessarily against recommending using latest morph by default, but I think the real problem is we need a coherent release policy | 11:27 |
jjardon | pedroalvarez: thanks! what was the problem? | 11:27 |
paulsher1ood | ssam2: yes. but really, who cares? life is so much nicer with chunks-in-definitions | 11:27 |
ssam2 | even if that policy is "every commit to definitions is a release" | 11:27 |
paulsher1ood | (who cares that 1.49 can build 14.29.1) | 11:28 |
ssam2 | when new users are playing with master, it adds overhead for us to support them | 11:28 |
pedroalvarez | jjardon: there is a bug in the lorry code, I don't know all the codebase to do a fix though | 11:28 |
ssam2 | it also highlights new bugs, which is useful | 11:28 |
paulsher1ood | ssam2: yes, agreed. but to be clear as a project, we're moving forward -'stable' and 'backporting' are not what we're aiming at. by default our users should be expecting to move forwards on an ongoing basis. we need to make that process simpler and less error-prone, but that's definitely the direction imo | 11:31 |
paulsher1ood | if users want to stabilize and backport they are welcome to, of course | 11:31 |
ssam2 | Ok. using a 14.29 devel image with 'master' of Morph and 'master' of definitions is a good step towards that goal, then | 11:32 |
paulsher1ood | i agree. it's minimal pain, too | 11:34 |
paulsher1ood | interestingly, does mason use latest morph? | 11:34 |
ssam2 | as I understand it, Mason uses whatever it was built with | 11:34 |
paulsher1ood | hmmm... could we easily fix that? | 11:34 |
ssam2 | what it should do is build itself, then update itself to the new version that it just built | 11:34 |
paulsher1ood | that sounds different | 11:35 |
ssam2 | well, it's not just Morph that changes | 11:35 |
ssam2 | it's mostly Morph | 11:35 |
paulsher1ood | i was thinking of getting mason to do what you suggested as the good step | 11:35 |
ssam2 | oh. That'd be a good compromise too, I think | 11:36 |
ssam2 | in fact, it's really only when we mess with the bootstrap that the system needs to upgrade itself | 11:36 |
paulsher1ood | ie, if our default for user is [14.29 devel + latest morph + master definitions] until we s/14.29/XX.YY/ then cause mason to be the same thing | 11:36 |
ssam2 | makes sense | 11:37 |
paulsher1ood | it seems like a good place between - change machines every time we do a commit - and - 14.29 until we decide otherwise | 11:37 |
paulsher1ood | others may disagree, though. i expect persia in particular could throw a grenade at this | 11:39 |
pedroalvarez | paulsher1ood: public mason is not using latest morph, since in that morph, distbuild is broken | 11:39 |
paulsher1ood | heh :) | 11:39 |
pedroalvarez | I tried to upgrade it this tuesday | 11:39 |
paulsher1ood | and if it was, it would have spotted the problem at commit time | 11:39 |
paulsher1ood | so actually that's a datapoint in favour of this suggestion i think :-) | 11:40 |
pedroalvarez | I think mason should also run the morph test suite | 11:40 |
* persia doesn't have a grenade: until elastic instances are used for system testing, there's no point fussing about the version used to do a test (because we're doing post-commit testing). | 11:41 | |
paulsher1ood | +1 for whichever subset of tests currently pass :) | 11:41 |
persia | When we migrate to pre-merge testing, we should be testing with elastic instances of master. | 11:41 |
pedroalvarez | indeed | 11:41 |
paulsher1ood | persia: yup | 11:41 |
* persia crawls back in the no-distractions box, and will read backscroll later | 11:42 | |
paulsher1ood | so leave it as is on mason for the moment? but in the meantime fix the wiki to [14.29 devel + latest morph + master definitions], ssam2 ? | 11:42 |
pedroalvarez | we had automated deploy and test in openstack working | 11:42 |
paulsher1ood | pedroalvarez: can we return to that state? | 11:43 |
pedroalvarez | it was a workin progress, there is a branch in definitions iirc, but it nieed some extra work before it can be merged | 11:43 |
* paulsher1ood notes that the default wiki documentation covers build, not distbuild | 11:44 | |
ssam2 | paulsher1ood: ok, i'll fix the wiki | 11:44 |
ssam2 | (about latest morph, I don't know what you mean about build vs distbuild) | 11:44 |
paulsher1ood | ssam2: i just mean, for new users, the default examples are using build. setting up a distbuild network is, er, an advanced topic :) | 11:45 |
ssam2 | I agree | 11:45 |
paulsher1ood | but i've heard some discussion about scrapping one or the other to have only one path here | 11:46 |
ssam2 | oh, I've missed that | 11:46 |
paulsher1ood | shall i precis here, or on the ml? | 11:46 |
paulsher1ood | actually i notice i've started several threads about workflow, with limited uptake :) | 11:47 |
petefoth | Did you spot this in #baserock? | 11:48 |
petefoth | * persia crawls back in the no-distractions box, and will read backscroll later | 11:48 |
petefoth | He's alive ! | 11:48 |
paulsher1ood | petefoth: yes, be happy, and try not to distract him further :) | 11:48 |
petefoth | worng widnow error! | 11:49 |
paulsher1ood | others have started threads too, looking back | 11:49 |
* petefoth thinks (FWIW) that the command should be `morph build` and whether or not that build is actually a distbuil depends on current configuration | 11:51 | |
ssam2 | petefoth: that's how it used to be, but it can be annoying to have a single command that can change its behaviour in hard-to-understand ways | 11:52 |
ssam2 | config file changes can cause something that previously worked to fail with an unexpected error | 11:52 |
ssam2 | paulsher1ood: yes, I think a mailing list thread isn't really the right place to discuss something as complex as workflow | 11:53 |
ssam2 | such topics that involve a lot of design are hard to do via email | 11:53 |
petefoth | ssam2: hopefully the upcoming discussions about workflows can deal with issue and arrive at aconsensus onthe best way forward | 11:54 |
ssam2 | yeah, I'm looking forward to that | 11:54 |
paulsher1ood | ssam2: how then, if not email? irc is worse, clearly | 11:55 |
paulsher1ood | a meetup, perhaps? :) | 11:55 |
ssam2 | i don't know. Many distributed free software projects are terrible at design | 11:56 |
ssam2 | The good ones are usually lead by a few individuals | 11:56 |
paulsher1ood | :0 | 11:56 |
ssam2 | or have a dedicated 'design team' | 11:56 |
ssam2 | doesn't mean we should give up, but it's hard for me to make recommendations on what to do! | 11:57 |
petefoth | ssam2: where 'design team' is alos reponsible for deciding which features / requirments get implemented? | 11:57 |
ssam2 | petefoth: not necessarily | 11:57 |
ssam2 | but there must be core developers who respect the design team | 11:58 |
ssam2 | and try to implement the work they do | 11:58 |
* petefoth would really like to know of good ways of doing that! | 11:58 | |
ssam2 | otherwise the design team will realise nothing is changing and give up | 11:58 |
ssam2 | I prepared http://sprunge.us/QbTS in case we want to change the wiki | 11:59 |
ridgerunner | failed to upgrade Baserock on jetson TK1: http://pastebin.com/EVw2tq6V | 12:04 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 258 seconds] | 12:05 | |
petefoth | ssam2: b/devel-with.mdwn - s/mastere/master/ (says Mr Picky;) | 12:05 |
paulsher1ood | ssam2: works for me | 12:07 |
paulsher1ood | but then the build commands need fixing too | 12:07 |
paulsher1ood | since master has systems/foo | 12:07 |
paulsher1ood | and morph is now picky | 12:08 |
pedroalvarez | ridgerunner: Trying to figure out what happened | 12:08 |
ridgerunner | Thanks, do you want to see the .morph? | 12:08 |
paulsher1ood | pedroalvarez: this is the problem i had over the weekend. glad it's not just me :) | 12:09 |
ridgerunner | As a bugfinder I am in your shadow :-) | 12:09 |
paulsher1ood | heh | 12:09 |
pedroalvarez | paulsher1ood: also upgrading a jetson? | 12:09 |
paulsher1ood | yes | 12:10 |
paulsher1ood | i removed the hostname stuff to get round it | 12:10 |
paulsher1ood | ridgerunner: try morph deploy --upgrade jetson-upgrade.morph jetson.VERSION_LABEL=ridgerunner | 12:11 |
paulsher1ood | s/get round it/find a different problem further on/ | 12:11 |
pedroalvarez | paulsher1ood, ridgerunner: so you both were trying to self upgrade the jetson? | 12:12 |
paulsher1ood | yes | 12:13 |
ridgerunner | Running that now. | 12:13 |
paulsher1ood | which according to radiofree was/is possible | 12:13 |
jjardon | paulsher1ood: Im building llvm inside mesa-common at the moment. if you want it in different stratum, I think it should go in llvm-common and the "compiler" stratum (with clang and gcc) should depend on it | 12:13 |
paulsher1ood | i think :) | 12:13 |
pedroalvarez | paulsher1ood, ridgerunner: Is the upgrade process asking for passwords during the upgrade? | 12:14 |
ridgerunner | Not here, no | 12:14 |
pedroalvarez | this is a weird error and difficult to debug :( | 12:18 |
ridgerunner | Woot paulsher1ood that ran to "Finished deployment" | 12:18 |
ridgerunner | Onwards and upwards. | 12:18 |
jjardon | mmmm, where morph configure how many cpus it should use? Im using the c++ compiler and only 1 cpu has being used | 12:19 |
pedroalvarez | ridgerunner: was $VERSION_LABEL something useful? | 12:20 |
pedroalvarez | ridgerunner: if you are not familiar with shell, can you run `echo $VERSION_LABEL` ? | 12:20 |
pedroalvarez | I think the upgrade is failing because of that | 12:20 |
ridgerunner | I had set it to "rdj.v1" | 12:21 |
richard_maw | jjardon: it guesses based on the number of CPUs it has, or is limited to the number set in the morphology e.g. `max-jobs: 1`, or set globally on the morph command line/config file with --max-jobs | 12:22 |
paulsher1ood | pedroalvarez: do you have a jetson? | 12:23 |
paulsher1ood | it's easy enough to replicate | 12:24 |
paulsher1ood | (doesn't happen on x86 afaict) | 12:24 |
jjardon | richard_maw: no configure/command line option, and I have 4 cores (building llvm, I will check if the package itself only allow one compilation thread) | 12:24 |
jjardon | richard_maw: can be a difference that Its using the c++ (cc1plus) compiler instead the c one (gcc)? | 12:25 |
richard_maw | c++ shouldn't make a difference, but if they're doing something weird in the Makefile, such as re-defining their own MAKEFLAGS, then it will ignore the parallelism morph has determined for it, and default to 1 | 12:28 |
richard_maw | the linux chunk used to have this issue | 12:28 |
richard_maw | IIRC we fixed it by changing the build-commands to be `make $MAKEFLAGS` instead | 12:29 |
pedroalvarez | paulsher1ood: I don't have a jetson | 12:35 |
pedroalvarez | but this problem should be happening in x86 as well | 12:41 |
* SotK has a jetson, and has upgraded it in the past and has never seen that issue | 12:41 | |
paulsher1ood | SotK: try the command line with $(hostname) | 12:41 |
pedroalvarez | weird, HOSTNAME has nothing to do in that error | 12:43 |
SotK | paulsher1ood: my jetson needs reflashing atm, I can try later perhaps | 12:43 |
SotK | ridgerunner: what does your deployment morphology look like ooi? | 12:46 |
paulsher1ood | ridgerunner: my guess is that even though your deployment worked, rebooting puts you in factory, rather than your upgrade? | 12:48 |
SotK | ridgerunner: are you using jetson-upgrade.morph from master of definitions? | 12:48 |
pedroalvarez | SotK: this is the error: http://pastebin.com/EVw2tq6V | 12:49 |
SotK | the deployment name in jetson-upgrade.morph in master of definitions is "jetson" not "self" | 12:49 |
SotK | so self.VERSION_LABEL and self.HOSTNAME aren't setting anything | 12:50 |
ssam2 | second version of 'use latest morph in wiki` patch: http://sprunge.us/JVeW | 12:50 |
SotK | if that is the case in ridgerunner's morphology | 12:50 |
ssam2 | thanks for the comments on the first one | 12:50 |
* paulsher1ood hopes this self thing is not all his fault :) | 12:50 | |
pedroalvarez | that explains why it works in x86 and not in armv7 | 12:52 |
paulsher1ood | ssam2: looks good. did you grep for 'morph build' to be sure there are not other instances? | 12:52 |
pedroalvarez | now I wonder why it succeded without the hostname | 12:53 |
SotK | confusingly, it is self in the x86 upgrade morphology example | 12:53 |
ssam2 | paulsher1ood: I did :) | 12:53 |
* paulsher1ood really does not understand all the deploy magic, starting at calling them 'clusters' instead of 'deploys' | 12:53 | |
SotK | pedroalvarez: there is a default hostname in jetson-upgrade.morph | 12:53 |
* ssam2 has considered a `morph upgrade-self` command in the past | 12:55 | |
pedroalvarez | SotK: but the error that ridgerunner was hitting I think it was caused because the version label was not set | 12:57 |
SotK | paulsher1ood: A "cluster" contains "systems" which have one or more specified "deployments"/"deploys". Deploying a cluster defaults to deploying every deployment of every system in the cluster, but it is possible to specify individual deployments to do. | 12:59 |
SotK | pedroalvarez: hmm, then I too am confused | 12:59 |
jjardon | richard_maw: confirming the `make $MAKEFLAGS` trick worked, thanks! | 13:02 |
* jjardon using 100% of his 4 cores now | 13:02 | |
* jjardon has commit access now :) (thanks richard_maw) | 13:05 | |
* richard_maw ponders whether to give jjardon trove-admin access, so jjardon is on the hook to add people's keys next time | 13:06 | |
Kinnison | heh | 13:06 |
petefoth | is git help add-binary | 13:24 |
Kinnison | pardon? | 13:24 |
petefoth | Kinnison: EWRONGINDOW and ECRAPTYPING | 13:27 |
Kinnison | :-) | 13:27 |
*** dutch__ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:42 | |
*** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** sam__ [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** violeta_ [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** fay__ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** tpollard_ [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** jonathanmaw_ [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** Blacksnow [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:43 | |
*** flatmush1 [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:44 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:45 | |
*** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:45 | |
*** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 13:45 | |
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 13:45 | |
*** violeta [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 13:46 | |
*** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 13:46 | |
*** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 13:46 | |
*** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 13:46 | |
*** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 13:46 | |
ridgerunner | OK, when I reboot the TK1, I get offered a choice of 1. Factory and 2. ridgerunner. I selected 2 and it booted successfully. | 13:49 |
rjek | \o/ | 13:50 |
SotK | ridgerunner: great :) | 13:50 |
jonathanmaw_ is now known as jonathanmaw | 13:50 | |
ridgerunner | jooi, how does the bootloader know that there are now two systems on the disk? | 13:51 |
pedroalvarez | when upgrading the system, the bootloader gets updated | 13:52 |
richard_maw | config file for bootloader gets updated | 13:52 |
flatmush1 is now known as flatmush | 13:52 | |
* pedroalvarez is not familiar yet with these terms | 13:53 | |
paulsher1ood | ridgerunner: uname -a | 13:59 |
paulsher1ood | did it actually boot into 2. ? | 13:59 |
paulsher1ood | system-version-manager get-running | 13:59 |
paulsher1ood | ridgerunner: ^^ | 14:00 |
*** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 14:05 | |
ridgerunner | Sorry paulsher1ood my notifications cript failed again. | 14:07 |
ridgerunner | uname -a returned: Linux baserock-jetson 3.10.24-gde3664e #1 SMP PREEMPT Wed Sep 24 12:02:11 UTC 2014 armv7l GNU/Linux | 14:07 |
ridgerunner | Which sounds, to me, pretty good. Is it? | 14:07 |
paulsher1ood | sysem-version-manager get-running (should tell you you're still in factory, if i'm not mistaken) | 14:08 |
ridgerunner | That returns: [ 1349.746666] device label baserock devid 1 transid 1618 /dev/mmcblk0p1 | 14:10 |
ssam2_ | that's a kernel message that happened to be dumped on your console, not the output of `system-version-manager get-running` | 14:10 |
ssam2_ | i realise it's hard to tell the difference between those two things | 14:10 |
ridgerunner | It pretty reliably displays that when I enter the command. Oh, and it has "ridgerunner" at the end but line wrap cut it off when I pasted. | 14:11 |
pedroalvarez | that sounds good then :) | 14:11 |
ridgerunner | The transid changes (-> 1619, 1620, 1620...) | 14:12 |
SotK | I assume you changed self to jetson on your deploy command then? | 14:12 |
ssam2_ | ridgerunner: the tool mounts your root disk, which causes the kernel to log a message, which happens to go to your console | 14:12 |
ssam2_ | it'd be nice if that didn't happen, but I'm not sure what we'd need to tweak | 14:13 |
SotK | hooray, fuel-stop-advisor is finally built | 14:13 |
pedroalvarez | SotK: great! | 14:13 |
paulsher1ood | SotK: WOW! w00t! Fred at Wind River will be pleased :) | 14:13 |
SotK | *built*, not running yet :P | 14:13 |
paulsher1ood | heh | 14:14 |
ridgerunner | SotK: I don't know what that means. | 14:14 |
paulsher1ood | SotK: he'd probably be even more pleased if it stays like that :) | 14:14 |
SotK | paulsher1ood: indeed | 14:15 |
ridgerunner | SotK: that is re "self" not re "fuel-stop-advisor" | 14:15 |
paulsher1ood | ridgerunner: can you confirm what you did to achieve this 'working' upgrade? did you have to change anything vs the instructions on the wiki? | 14:15 |
paulsher1ood | or modify jetson-upgrade.morph? | 14:15 |
SotK | ridgerunner: when you did morph deploy --upgrade, what was the full command? :) | 14:15 |
ridgerunner | Hang on, I'll go back up the buffer... | 14:16 |
ridgerunner | morph deploy --upgrad | 14:16 |
ridgerunner | e jetson-upgrade.morph jetson.VERSION_LABEL=ridgerunner | 14:16 |
ridgerunner | scuse the line wrap | 14:17 |
ridgerunner | paulsher1ood: the first thing I realised whe it failed last night was that I hadn't actually built the .morph file mentioned in the deploy script. | 14:17 |
SotK | I guess switching from self.VERSION_LABEL to jetson.VERSION_LABEL fixed it then | 14:18 |
ridgerunner | I hope I'm using the right terms. | 14:18 |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 14:18 | |
* SotK wonders why the deployment "succeeded" when no hostname was given earlier | 14:18 | |
ridgerunner | paulsher1ood: So the TK1 spent a very large chunk of this morning doing that :-) | 14:19 |
ridgerunner | I had successfully built for a different target. | 14:19 |
ridgerunner | +1 for morph giving me an error message that made it clear what my goof had been | 14:20 |
paulsher1ood | ridgerunner: alternatively you could have adjusted the target in the jetsion-upgrade.morph to reflecyt what you had built :) | 14:21 |
SotK | now to figure out what on earth the run script is doing | 14:21 |
paulsher1ood | ridgerunner: if you ssh in to your jetson you can a) avoid the kernel logs and b) have more history and no spurious linewrap | 14:21 |
ridgerunner | Yes, I think I understand that now. But, of course, I then wouldn't have been able to deploy to the TK1 | 14:21 |
paulsher1ood | yes you would, assuming you built a jetson system? | 14:22 |
ridgerunner | I do ssh in. I only use serial for the boot. | 14:22 |
paulsher1ood | so the line-wrap is your terminal? | 14:22 |
paulsher1ood | weird | 14:22 |
ridgerunner | I think I had built a generic arm7xxx of the same processor type as the TK1, I was just trying to firure out how to get Baserock going, nit neccessarilt do anything useful per se. | 14:23 |
paulsher1ood | ok | 14:23 |
* pedroalvarez realises that our initramfs system kind of big, 114M | 14:24 | |
pedroalvarez | I somehow expected it to be smaller than that | 14:24 |
ridgerunner | re line wrap: yes, I haven't quite figured out why sometimes wrapped lines will transcribe with no newline, other times it puts a (very annoying) new line in at the wrap point. | 14:24 |
paulsher1ood | all of our sytems could do with a diet | 14:24 |
ridgerunner | I think my sausage fingers could do with going on a diet. They might it the correct keys then/ | 14:25 |
richard_maw | pedroalvarez: hm, it used to be smaller | 14:25 |
ridgerunner | *HIT* dammit *HIT* | 14:26 |
ridgerunner | I need a cuppaT | 14:26 |
pedroalvarez | ridgerunner: if you were getting kernel messages when running `system-version-manager get-running`, then I think you are not using the ssh session | 14:27 |
* paulsher1ood contemplates trying the upgrade again | 14:27 | |
richard_maw | pedroalvarez: the initramfs is big because gcc-libs contains stuff from /usr/libexec | 14:28 |
richard_maw | a large amount of the initramfs size is probably because we've accidentally fot the gcc compiler backends included | 14:28 |
* pedroalvarez hacks the bugsmagnet of paulsher1ood | 14:29 | |
richard_maw | pedroalvarez: if you want to make it tiny again, you could try adding the products: fields from http://git.baserock.org/cgi-bin/cgit.cgi/delta/gcc-tarball.git/tree/gcc.morph?h=baserock/richardmaw/S10786-finer-splitting | 14:30 |
pedroalvarez | I'd like it to be tiny, yeah | 14:31 |
pedroalvarez | I'll try to add that | 14:31 |
richard_maw | unfortunately it's going to require rebuilding everything from build-essential upwards | 14:31 |
pedroalvarez | yeah, but IMO is a nice improvement | 14:32 |
ridgerunner | pedroalvarez: Darn it, you're right I picked the wrong window. | 14:32 |
ridgerunner | They are in adjacent tabs :-( | 14:33 |
ridgerunner | On an ssh session it just outputs "ridgerunner". Which means it wasn't line wrap at all. Ho hum. | 14:34 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 250 seconds] | 14:36 | |
*** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Remote host closed the connection] | 14:37 | |
pedroalvarez | richard_maw: yeah, 289M of libexec | 14:37 |
*** thecorconian [~thecorcon@eccvpn1.ford.com] has joined #baserock | 14:37 | |
pedroalvarez | * /usr/libexec | 14:38 |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 14:49 | |
violeta_ | ridgerunner, how long did the upgrade take to build? | 14:51 |
violeta_ is now known as violeta | 14:51 | |
*** thecorconian [~thecorcon@eccvpn1.ford.com] has quit [Quit: Leaving.] | 14:52 | |
doffm | Hi guys, I'm still having difficulty lorrying some packages. If you take a look at http://git.baserock.org/lc-status.html there are alot of 'python-packages' that are scheduled to be lorried that arn't present in git.baserock.org. | 15:01 |
doffm | Its been stuck in that state for a while and I don't have any error output. | 15:02 |
Kinnison | Can you give us a list of the failing lorries, we think there was an FS issue which led to non-continuable lorries in some cases | 15:02 |
doffm | Kinnison: Sure. I think its a long list. | 15:04 |
Kinnison | no probs, if you have a list, we can cross-check it against the todo list of things we know are wrong | 15:05 |
Kinnison | if your list contains things we're not aware of, then that'll help us find other things to check for | 15:05 |
pedroalvarez | richard_maw: i rebased your gcc finer splitting in definitions.git (baserock/pedroalvarez/finer-splitting-gcc) | 15:05 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 260 seconds] | 15:21 | |
doffm | Kinnison: http://sprunge.us/EaCP There might be a few more, but thats what I think i'm missing. | 15:24 |
doffm | all under 'python-packages' | 15:24 |
Kinnison | doffm: ta, I'll just turn that into something I can use :-) | 15:25 |
Kinnison | is that *all* of python-packages/ or just some? | 15:25 |
doffm | Just some. | 15:26 |
doffm | About 50% :) | 15:26 |
Kinnison | heh | 15:27 |
Kinnison | ouch | 15:27 |
*** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 15:32 | |
Kinnison | doffm: interesting intersection but neither ours nor yours is a subset :-( | 15:34 |
* Kinnison will investigate | 15:34 | |
cyndis_ is now known as cyndis | 15:37 | |
pedroalvarez | Kinnison: to start te investigation; https://admin.codethink.co.uk/pnopaste/?1884 | 15:49 |
* pedroalvarez releases tje 12765 port of g.b.o | 15:49 | |
paulsher1ood | pedroalvarez: is that public? | 15:49 |
pedroalvarez | grrr | 15:50 |
paulsher1ood | :) | 15:50 |
pedroalvarez | wrong channel | 15:50 |
pedroalvarez | nothing private, though, here is a public copy: http://pastebin.com/NMScUDXB | 15:51 |
pedroalvarez | some lorry errors | 15:51 |
Kinnison | doffm: Right, I've worked out what's going on, we just need to work out the best way to fix things | 15:52 |
jjardon | ssam2_: fix coming for the NetworkManager issue | 15:53 |
doffm | Kinnison: Whats the problem? | 15:53 |
Kinnison | doffm: I think there was some corruption on g.b.o at some point | 15:53 |
doffm | Oh dear. | 15:54 |
Kinnison | doffm: we're currently tracing the extent of the damage so we can do some restores | 15:54 |
jjardon | oh Its already there: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-10&id=302b438162e4f14bc2652832e5d2f3a44077b804 ;) | 15:55 |
jjardon | I think the upgrade to new linux-headers is still worth though | 15:56 |
* paulsher1ood confirms that he can build and use latest cmake in baserock, on top of our bootstrapped cmake | 16:03 | |
ssam2_ | jjardon: oh, interesting | 16:06 |
jjardon | paulsher1ood: upgrade everything! :) | 16:06 |
ssam2_ | still, cleaning up the linux-api-headers branch was worthwhile, I guess | 16:06 |
ssam2_ | in fact, I just successfully built the genivi baseline on x86_64 with that branch, so I guess I'll send a patch for definitions | 16:07 |
paulsher1ood | cool | 16:07 |
jjardon | ssam2_: sure | 16:07 |
ridgerunner | violeta: you asked how long the upgrade took. The actual morph deploy --upgrade only took a few minutes. The preceding build took about another 10 minutes but I had previously run a build for the same processor (arm7lhf) which had taken about 3 hours 25 minutes. I suspect if I had gone straight to the correct build it would have been about three and a half hours. | 16:13 |
paulsher1ood | i fear i've asked this before - is there a good reason why morph and tbdiff should be in with other stuff? why not have a baserock-tools stratum? | 16:16 |
violeta | ridgerunner, I'm 1.30h into the 3.30h build, thanks ;-) | 16:16 |
paulsher1ood | we need to establish a public distbuild network for jetsons | 16:17 |
ridgerunner | violeta: the other thing I have determined is that you can control-C a build and then run it again later and it will resume more or less where it left off. | 16:19 |
ridgerunner | Very handy if you don't want to leave something on overnight :-) | 16:19 |
violeta | yes, very handy, thanks | 16:19 |
*** genii [~quassel@ubuntu/member/genii] has joined #baserock | 16:23 | |
ssam2_ | paulsher1ood: I don't remember you asking that. Not sure of any convincing arugments either way | 16:24 |
paulsher1ood | why would you not leave it overnight? | 16:24 |
paulsher1ood | it's not like a build needs a babysitter! | 16:24 |
rjek | win 21 | 16:26 |
rjek | gah | 16:26 |
* rjek is paulsher1ood | 16:26 | |
*** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:32 | |
paulsher1ood | :) | 16:36 |
*** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 260 seconds] | 16:39 | |
paulsher1ood | ERROR: System time is far in the past, please set your system clock | 16:40 |
paulsher1ood | on jetson... that's a first for me :) | 16:40 |
rjek | Does jetson have an RTC? | 16:40 |
paulsher1ood | normally yes, i think | 16:41 |
rjek | Have you ever put truth into it? :) | 16:42 |
paulsher1ood | truth? | 16:42 |
paulsher1ood | reboot, same problem. dead battery, maybe? doesn't baserock get its time from the network anyway? | 16:43 |
rjek | IIRC, the ntp client may panic and not touch the clock if it's /way/ out | 16:45 |
ssam2_ | baserock spams your console with systemd error messages if it failed to get the time from the network, in my experience | 16:45 |
rjek | Also, not sure if Baserock does the "write system clock back into RTC" thing at shutdown | 16:45 |
rjek | paulsher1ood: Probably the best approach is to set the time manually with `date`, shutdown cleanly, reboot, see if it's happier. | 16:46 |
paulsher1ood | i'm back in Feb 2000... probably in Sweden, celebrating | 16:46 |
jjardon | is baserock using the same kernel for all the bsp or different one? | 16:49 |
ssam2_ | jjardon: same commit of Linux for all systems, I believe | 16:50 |
paulsher1ood | jetson kernel is the nvidia one by default | 16:50 |
paulsher1ood | so different | 16:50 |
ssam2_ | ah, true | 16:50 |
ssam2_ | different kernel config for each system, too | 16:51 |
* paulsher1ood and bash date are confusing each other. now i'm in 2012 - marty mcfly is dating my daughter | 16:51 | |
paulsher1ood | 2021 | 16:51 |
paulsher1ood | http://fpaste.org/136493/ | 16:53 |
jjardon | ssam2_: ah, ok. the version to build is replicated in every bsp, rigth? It would be good to have that in a single place instead but not sure if you can specify a different morph file depending on some configuration parameter ? | 16:53 |
paulsher1ood | i mean wtf | 16:53 |
jjardon | paulsher1ood: date --set 201409251900 | 16:55 |
Kinnison | and then hwclock --systohc | 16:57 |
*** Blacksnow [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:02 | |
*** ssam2_ [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:09 | |
paulsher1ood | that worked, thanks | 17:13 |
*** dutch__ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 17:30 | |
*** dutch__ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:47 | |
jjardon | any idea why lsmod doesnt work in genivi-baseline system? | 17:48 |
*** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 17:53 | |
*** ridgerunner [~robjones@access.ducie-dc1.codethink.co.uk] has quit [Remote host closed the connection] | 17:53 | |
*** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 17:53 | |
*** paulsher1ood [~paulsherw@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 17:53 | |
*** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 17:53 | |
*** petefoth [~petefothe@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 17:53 | |
*** mwilliams_ct [~mikewilli@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 17:53 | |
*** pdar [~patrickda@access.ducie-dc1.codethink.co.uk] has quit [Read error: Connection reset by peer] | 17:53 | |
*** liw-orc [~liw@access.ducie-dc1.codethink.co.uk] has quit [Quit: Coyote finally caught me] | 17:53 | |
*** dutch__ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:30 | |
*** doffm [~mdoff@23.226.235.108] has quit [Remote host closed the connection] | 18:36 | |
*** ridgerunner [~robjones@access.ducie-dc1.codethink.co.uk] has joined #baserock | 19:31 | |
*** tiagogomes [~tiagogome@host-92-25-175-163.as13285.net] has joined #baserock | 19:32 | |
*** tiagogomes [~tiagogome@host-92-25-175-163.as13285.net] has quit [Client Quit] | 19:34 | |
pedroalvarez | jjardon: if it should work make is because we remove all the gplv3 chunks from the system | 20:47 |
*** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 21:42 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!