| jjardon_ is now known as jjardon | 00:38 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 03:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 07:06 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 07:06 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 07:06 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:06 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 07:06 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 07:08 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 07:08 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:08 | |
| *** petefoth [~petefoth@host-92-11-21-246.as43234.net] has joined #baserock | 07:27 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:04 | |
| *** mariaderidder [~maria@213.91.201.213] has joined #baserock | 08:16 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:22 | |
| *** mariaderidder [~maria@213.91.201.213] has quit [Ping timeout: 245 seconds] | 08:45 | |
| *** mariaderidder [~maria@213.91.201.213] has joined #baserock | 08:49 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:02 | |
| Mode #baserock +v pedroalvarez_ by ChanServ | 09:17 | |
| pedroalvarez is now known as pedroalvarez | 09:19 | |
| Mode #baserock +o pedroalvarez by ChanServ | 09:19 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:24 | |
| *** mariaderidder [~maria@213.91.201.213] has quit [Quit: Ex-Chat] | 09:29 | |
| Kinnison_ is now known as Kinnison | 09:31 | |
| *** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:37 | |
| paulsherwood | rdale: sorry, but the world at large has no interest in ct internal systems, so no point in lorrying those repos at gbo | 09:38 |
|---|---|---|
| rdale | ah ok | 09:38 |
| * rjek_ applauds straycat's vim change. | 09:44 | |
| rjek_ is now known as rjek | 09:44 | |
| SotK | Could I get a quick review on this lorry? I want to use it when caching tree SHAs. http://paste.baserock.org/izanerohas.diff | 09:45 |
| Kinnison | why using https rather than git:// ? | 09:46 |
| Kinnison | And do you truly need an LRU cache? | 09:47 |
| Kinnison | rather than just keeping the active set of SHAs needed in a file in the definitions? | 09:47 |
| persia | I'm not a huge fan of the file solution, because the existence of a file invites folk to try to change it, regardless of the documentation | 09:48 |
| Kinnison | I see | 09:48 |
| SotK | Kinnison: oops, I pasted and forgot to change to git:// | 09:49 |
| Kinnison | SotK: I don't mind either way | 09:49 |
| * Kinnison allows +1 for either git:// or https:// (but I feel git:// will be faster) | 09:49 | |
| franred_ | Kinnison, ummm, we have a lot of https://bla@github .. would be worth to change them to git:// ? | 09:50 |
| Kinnison | Naah | 09:50 |
| Kinnison | don't change stuff unless you need to | 09:50 |
| Kinnison | In *theory* we should prefer https | 09:51 |
| Kinnison | but since we don't actually validate the certificates, there's no security gain | 09:51 |
| persia | I thought that with the ca-certificates chunk, we *could* validate the certificates. Should we start doing so? | 09:52 |
| pedroalvarez | franred_: lorry controller ignores them | 09:54 |
| pedroalvarez | ignores, or not uses them | 09:54 |
| De|ta_ is now known as De|ta | 09:55 | |
| Kinnison | persia: I think l-c needs a way to be given extra certificates to trust before we can turn that on | 09:55 |
| pedroalvarez | franred_: the use of https I mean, no the lorry itself | 09:55 |
| persia | Kinnison: Why l-c specifically? We have a means to add certificates generally. | 09:55 |
| Kinnison | persia: because it's configuration data for lorrying | 09:55 |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 09:56 | |
| Kinnison | persia: and I don't know about anyone else, but I don't want to have to redeploy a lorrying system (trove/whatever) just to get a trust anchor in place for lorrying | 09:56 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:56 | |
| persia | Ah, as in the lorry file should specify the certificate in some way, rather than just blindly trusting a set of CAs? | 09:56 |
| * Kinnison is, as always, a statistical outlier | 09:56 | |
| Kinnison | persia: essentially I'm thinking there should be an *additional* ca bundle in local-config/lorries.git | 09:56 |
| persia | And if we're just adding a new certificate, redploy should be fast (tiny delta). | 09:57 |
| Kinnison | *iff* we get to the point of not needing reboots | 09:57 |
| persia | How long does a reboot take? Isn't it just a couple minutes? | 09:59 |
| persia | Or is the issue that the lorry controller is running in the same environment as the git server, the cache server, etc. so everything falls down at once? | 09:59 |
| Kinnison | Not if there're lorries in progress which would have to be waited for, etc | 10:00 |
| Kinnison | I'm just imagining lorrying now | 10:00 |
| Kinnison | ignoring the shared context that trove *currently* causes | 10:00 |
| Kinnison | if you have a lorrying effort in progress, cancelling or waiting for it, in order to add a ca certificate just for lorrying seems sad | 10:00 |
| persia | Ah, right, and given a sensible system size, there are probably enough components to assume constant lorrying. | 10:03 |
| Kinnison | mmm | 10:03 |
| * Kinnison should really have explained that at the start of his commentary | 10:03 | |
| * Kinnison has difficulty realising that what is in his head, is often *only* in his head | 10:03 | |
| persia | In that case, even if the reboot issue is resolved, unless there is a way to continue without breaking lorries-in-progress, it makes sense to have a separate CA store for l-c. | 10:04 |
| persia | Since it is a small config change to cause an additional CA store to be used, and there is an online command that refreshes the current CA database, this is not a blocking issue. | 10:04 |
| Kinnison | well, without a need to reboot, updating the ca bundle should not adversely affect any running processes | 10:04 |
| persia | Ah right, and we don't care if currently-running lorries don't have the updated certificates. | 10:06 |
| Kinnison | indeed | 10:07 |
| Kinnison | If we were to go down this route, I'd also like it if we could put ssh host keys into the config | 10:07 |
| Kinnison | so that in case of mob-ssh pull uris we can pre-accept the keys, ditto for upstream troves | 10:07 |
| Kinnison | rather than the current approach | 10:07 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:11 | |
| persia | Sounds sensible. | 10:12 |
| persia | If you have a good idea how this might work, it is probably worth documenting the model on the wiki, and referencing it from the stories page. | 10:12 |
| Kinnison | Sadly all I have is nebulous burblings at this time | 10:13 |
| persia | :( | 10:13 |
| DavePage | Kinnison: DNSSEC and SSH keys in DNS \o/ | 10:14 |
| * Kinnison needs to sort DNSSEC for his domains | 10:14 | |
| * Kinnison also apparently needs to renew his client cert and thence SSL certificates anchored with it | 10:14 | |
| Kinnison | here goes another few hundred quid :-) | 10:14 |
| persia | DavePage: Yes, but having that as the *only* way to do things is annoying, especially for folk trying to use the software in large organisations. | 10:15 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:21 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:22 | |
| lachlanmackenzie | How many other toolchains have been generated to build baserock (apart from baserock itself)? | 10:23 |
| Kinnison | A long time ago we used a Debian toolchain to bootstrap us into Baserock, but since then, only toolchains built within Baserock have been used IIRC | 10:24 |
| lachlanmackenzie | Thanks | 10:24 |
| Kinnison | These days, morph depends on an awful lot of stuff such that trying to bring it up outside of a Baserock environment will likely be hard | 10:25 |
| persia | lachlanmackenzie: What are you trying to accomplish? There's a lot of flexibility in the definition of the "Baserock toolchain" that may meet your goals. | 10:27 |
| lachlanmackenzie | persia: Hi I'm just doing some research about the practicalities of porting Baserock to a MIPS architecture as part of a project. | 10:29 |
| persia | Someone was doing a cross-bootstrap to MIPS some months ago, but I don't remember patches hitting the list. | 10:30 |
| persia | Aside from the mechanical stuff, I think there were some issues with the compiler support at the time, but given the increasing use of MIPS in Debian, I think that's probably sorted now. | 10:30 |
| persia | If you try a cross-bootstrap, does anything break? | 10:30 |
| lachlanmackenzie | At the minute it's just some research, I will have a look at what's been done on MIPS. | 10:37 |
| persia | My recommendation would be to ignore that: it was done a long time ago, and with an older version of gcc than the devel systems use today. | 10:39 |
| persia | Just try a cross-bootstrap, and report what breaks. | 10:39 |
| persia | We can probably suggest where to look to work around things, until it works. | 10:39 |
| Kinnison | I believe tiagogomes_ has been working on updating binutils to 2.25 and gcc to 2.9.2 if that helps you | 10:40 |
| pedroalvarez | that's good. | 10:44 |
| pedroalvarez | Do we know how is that looking? | 10:44 |
| Kinnison | Last I heard from him, he's tracking down an issue in syslinux (-Werror or something) | 10:45 |
| Kinnison | I imagine he'll be posting on baserock-dev soon | 10:45 |
| tiagogomes_ | Kinnison is correct. | 10:46 |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 10:46 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 10:46 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 10:46 | |
| Kinnison | Vindication at last! | 10:46 |
| Kinnison | :_) | 10:46 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 10:46 | |
| pedroalvarez | cool | 10:47 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:55 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 10:56 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:13 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 12:16 | |
| straycat | rjek, :) | 12:26 |
| * SotK notices that the ref for morph in the cross-bootstrap stratum is from November, as opposed to January 2nd in morph-utils... | 13:09 | |
| persia | Is there a way to play with strata that would allow cross-bootstrap to automatically pick up that sort of update? | 13:10 |
| SotK | persia: you mean somehow include morph-utils in cross-bootstrap? | 13:12 |
| SotK | patch to fix: http://paste.baserock.org/azucacujux.diff | 13:12 |
| persia | +1 | 13:13 |
| persia | That was my thought,yes. I'm not sure how to accomplish it with the current semantics though. | 13:13 |
| richard_maw | persia: we ought to be able to build the "build" system as part of the cross-bootstrap. The cross-bootstrap stratum only exists because we didn't have fine grained strata when it was created, and to ease cycle time we created a stripped-down stratum for it | 13:13 |
| persia | lachlanmackenzie: Even if it takes a while to get to master, you might want to apply that patch for cross-bootstrapping | 13:13 |
| persia | richard_maw: That sounds like a good improvement. Every time someone tries cross-bootstrap, it seems we find something that we forgot to migrate previously. | 13:14 |
| mwilliams_ct | hi folks, I'm trying to spin up a jetson and not having a lot of success. after following the guide on w.b.o, I'm getting the error "*** Warning - bad CRC, using default environment" -- not sure if I've missed a step? | 13:43 |
| Kinnison | sounds like u-boots environment is corrupt | 13:45 |
| Kinnison | can you saveenv from u-boot to clear that? | 13:45 |
| mwilliams_ct | save'd env and will reboot | 13:46 |
| mwilliams_ct | Wekk bew errirs at least! "Retrieving file: /extlinux.conf; btrfs proble failed" | 13:47 |
| mwilliams_ct | s/wekk bew errirs/well, new errors/ -- it's definitely a friday | 13:48 |
| Kinnison | :-) | 13:48 |
| Kinnison | pedroalvarez: regarding the bug you and I diagnosed the other day -- I've finally sent the patch to baserock-dev | 13:48 |
| Zara_ | mwilliams_ct: I thought that was some kind of programmer slang I was just unfamiliar with. | 13:49 |
| persia | mwilliams_ct: At least you've successfully demonstrated your classical touchtyping strategy :) | 13:49 |
| mwilliams_ct | persia: I remember one day noticing that I was touchtyping. never tried to learn it, it just happened! | 13:50 |
| persia | Are you trying to boot from MMC, or SD? If SD, how did you generate the SD? | 13:50 |
| mwilliams_ct | mmc | 13:51 |
| mwilliams_ct | I've just followed this guide http://wiki.baserock.org/guides/baserock-jetson/ | 13:51 |
| persia | Try flashing again. | 13:53 |
| mwilliams_ct | persia: shall give that a shot | 13:53 |
| mwilliams_ct | this may take some time | 13:54 |
| * Kinnison has a question regarding morph and its use in definitions -- in morph-utils the SHA1 looks to be a non-trivial number of commits back on master and the one in cross-bootstrap is from november last year. Is this oversight or deliberate for making things work? | 13:54 | |
| * SotK is pretty sure its an oversight, it always has been before anyway | 13:55 | |
| Kinnison | Someone who can usefully analyse what changed from 30aaa46e250a1bd8081283839abd7d5aab97fb1e probably wants to check and update morph-utils.morph, and then possibly cross-bootstrap.morph too | 13:56 |
| Kinnison | Or perhaps cross-bootstrap.morph could be altered and/or dropped in favour of morph-utils to some extent? | 13:56 |
| * persia gets confused by a long string of hex | 13:57 | |
| persia | Do you mean between that commit and master? | 13:58 |
| Kinnison | yes | 13:58 |
| Kinnison | that commit being what morph-utils refers to for morph | 13:58 |
| persia | The cross-bootstrap one was discussed earlier and thought to be oversight. richard_maw suggested that we may be able to just build "build" in cross-bootstrap now, as we have more fine grained strata. | 13:59 |
| persia | This would reduce the issues in the future. | 14:00 |
| Kinnison | that would be nice | 14:00 |
| Kinnison | But don't build systems include BSPs? | 14:00 |
| paulsherwood | can we make cross-bootstrap part of build-system? | 14:00 |
| Kinnison | IIRC we don't do BSP building in cross-bootstrap because it's very awkward | 14:00 |
| persia | How do we expect the cross-bootstrap environment to boot without a target-appropriate BSP? | 14:01 |
| paulsherwood | initially by taking a provided bsp from elsewher,e i think | 14:01 |
| * persia reads the docs again before complaining at more length | 14:01 | |
| persia | Oh Ugh. | 14:07 |
| persia | We should be able to generate a cross-built BSP for the target, and deploy that system. | 14:08 |
| persia | The current model is such that Baserock cannot be used for hardware bringup. | 14:08 |
| richard_maw | It can provide the userland for bringup, it just doesn't do the whole job | 14:09 |
| persia | How? | 14:09 |
| richard_maw | assuming we share an understanding of what hardware bringup means, the result of cross-bootstrap is a tarball that can be unpacked onto storage of the new machine, and set init= in the kernel command-line | 14:11 |
| Kinnison | Okay, so without getting into the complexities of building BSPs using bootstrap compilers, what would we prefer the shape of things to be? | 14:11 |
| persia | richard_maw: Interesting. Perhaps we should recommend that method in the docs? | 14:12 |
| persia | Kinnison: My preferred shape would be able to cross-bootstrap a system that could be deployed to a target, for remaining bootstrap. | 14:13 |
| Kinnison | Since cross-bootstrapping is often done very early in the project's interaction with a given architecture, that's not really something I'd aim for directly | 14:13 |
| persia | So the user runs some command to build stuff, then another command to deploy stuff, then possibly some extra fiddling to get the deployment in the right place, then boots the target, and it completes the bootstrap. | 14:13 |
| Kinnison | Although I can see how it'd be useful later for verifying bootstrap | 14:13 |
| persia | Kinnison: My assumption is that I would not have working userspace for a target *except* via cross-bootstrap. | 14:14 |
| Kinnison | That's rarely the case for stuff we're working on, but it might happen | 14:14 |
| Kinnison | esp. if a HW vendor takes us on | 14:15 |
| persia | I have several bits of hardware for which I don't have shell access to userspace, but have source for kernels. | 14:15 |
| persia | I've been using OpenWRT to TFTP-boot them into something from which I could install something more interesting. | 14:16 |
| persia | But I'd rather not have to use that sort of method. | 14:16 |
| Kinnison | Are those bits of hardware things you'd be using to complete Baserock bootstraps?! | 14:16 |
| Kinnison | Remember, we're talking about bootstrapping support for a CPU architecture, not a given target unit | 14:16 |
| persia | At least one of the devices that I've used OpenWRT to access is an architecture not currently supported by definitions master. | 14:17 |
| persia | I can't authoritatively say what I might encounter in the future. | 14:17 |
| * Kinnison believes you're aiming for a nebulous idea of what you might encounter rather than something more concrete for architecture bootstrap | 14:17 | |
| Kinnison | I won't complain if you make it so we can do as you suggested, but I don't personally see the benefit in the effort | 14:18 |
| persia | I don't know how to so make it, but you asked what shape I wanted :) | 14:20 |
| Kinnison | :-) | 14:20 |
| Kinnison | Certainly I agree that the current shape is wasteful and causing issues | 14:20 |
| persia | I've definitely tried to use Baserock on a few architectures that were unsupported, but not yet managed to cause cross-bootstrap to do what I wanted. | 14:20 |
| persia | It may be just that I'm playing with the wrong kit :) | 14:23 |
| Kinnison | I wouldn't say that :-) | 14:23 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 14:41 | |
| jmacs | Oops, we're lorrying delta/libyajl2-gem and delta/ruby-gems/libyajl2-gem now... | 15:17 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 15:26 | |
| Kinnison | Odd sequence of log: | 15:34 |
| Kinnison | 2015-01-16 15:33:58 [Build 3/173] [stage2-linux-api-headers] Not updating git repository upstream:linux because it already contains sha1 df2e1b9168a7ab5dd8149e38b5ac70cdef86d1fa | 15:34 |
| Kinnison | 2015-01-16 15:33:58 # git remote update origin --prune | 15:34 |
| Kinnison | anyone know why that might happen? | 15:34 |
| richard_maw | I can't think of a sensible reason for it to do that | 15:35 |
| Kinnison | Can you think of any non-sensible reason? | 15:36 |
| richard_maw | accidental inversion of the test | 15:36 |
| straycat | Looking at SotK's series, I'm a little unsure of the need for all the caching we currently have, we check the local checkout, then the remote, finally the remote. Given all the morphs are in defs is not enough to just check the local checkout? I guess distbuild might stop us from doing that? | 15:39 |
| straycat | *then the local cache, finally the remote | 15:39 |
| persia | straycat: Does morph always check, or only on a cache-miss? | 15:39 |
| straycat | only on miss | 15:40 |
| persia | I suspect that on a cache-miss we ought update the local cache, rather than go checking remotely. | 15:40 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:40 | |
| straycat | persia, huh? if the local checkout doesn't contain the morph we want, we look in the local cache, if the local cache doesn't contain the morph we want, we look in the remote cache. | 15:41 |
| persia | That doesn't make any sense to me. | 15:41 |
| straycat | persia, which part? | 15:42 |
| persia | For morphologies, if the local checkout doesn't contain it, then I think we want to error out. | 15:42 |
| SotK | persia: why? | 15:42 |
| persia | SotK: Because if I'm building from the working area (something I don't like, but believe to be current morph behaviour), and I delete a file, I don't want it randomly showing up because it existed in some cache. | 15:42 |
| persia | Thinking about that more, is this to support the old behaviour of morphologies-in-source-repos? | 15:44 |
| SotK | pretty much, yes | 15:44 |
| straycat | yes | 15:44 |
| straycat | which is why it's looking overly complex to me right now | 15:44 |
| persia | Yes. | 15:45 |
| persia | But everything I've said should be ignored. | 15:45 |
| persia | Because it doesn't apply. | 15:46 |
| persia | Actually, it would be nice to add a "version" file to definitions. If present, and containing the single character "1", the legacy behaviours can be skipped. | 15:46 |
| * SotK wants ssssam's temporary build branch patch merged | 15:47 | |
| persia | If not present, they should be retained. If present with a different value, morph should complain that it does not understand how to parse that version of definitions. | 15:47 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 15:49 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 15:49 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:49 | |
| straycat | SotK, can look at that next? | 15:49 |
| SotK | straycat: thanks :) | 15:49 |
| * paulsherwood would love to shred this logic, but cannot participate now | 15:55 | |
| SotK | straycat: thanks for the review! | 16:31 |
| jmacs | I apologise in advance for the Chef/Ceph patch that's about to hit the mailing list but I've been rebasing it for a week and no longer know who I am or what words are. | 16:33 |
| robtaylor | bibble | 16:35 |
| Zara_ | drat, I was hoping that rebasing would stop having that effect on me, once I had some years of experience | 16:37 |
| straycat | SotK, :] | 16:38 |
| * paulsherwood doesn't rebase. he does git reset --hard, and git cherry-pick | 16:38 | |
| paulsherwood | but didn't JPohlmann once talk about how easy and exciting interactive rebase is | 16:39 |
| paulsherwood | ? | 16:39 |
| straycat | yes | 16:39 |
| richard_maw | he did | 16:39 |
| * paulsherwood wishes he'd seen that talk | 16:39 | |
| straycat | it makes us all feel happy inside | 16:39 |
| De|ta | "Don't fear the rebase" | 16:40 |
| paulsherwood | that was the one | 16:40 |
| robtaylor | heh | 16:40 |
| * paulsherwood can hear Blue Öyster Cult already | 16:40 | |
| * robtaylor too | 16:40 | |
| * SotK three | 16:41 | |
| Kinnison | all I can hear is the hDD in the server behind me | 16:41 |
| Kinnison | and some people who type loudly | 16:42 |
| jmacs | I seem to have accumulated 55G of /src/cache/artifacts... is there any way to determine what's what in here so I can sensibly remove some? | 16:43 |
| straycat | jmacs, might want to check out morph gc | 16:44 |
| paulsherwood | straycat: it won't do anything unless he's short of space, iiuc | 16:44 |
| straycat | oh yeah you have to set --cachedir-min-space to something high for it to do that >.> | 16:45 |
| paulsherwood | even then, there's no reason gc will be particularly intelligent in its choices, i think? | 16:45 |
| * paulsherwood may be mistaken | 16:46 | |
| jmacs | Oh, morph gc does clear them. | 16:46 |
| straycat | it removes everything older than some set constant | 16:46 |
| jmacs | No idea what it's removed, but it's done now | 16:46 |
| jmacs | OK, that sounds fine. | 16:46 |
| richard_maw | the rules are 1. everything older than configured value, 2. least recently used that's older than a configured value | 16:47 |
| * persia likes rebase, and used to do it for several parallel patch series multiple times daily | 16:48 | |
| * franred likes rebase too, it is pretty useful and good for clean the result of using the "commit often" commandment | 16:50 | |
| Zara_ | whoa, just saw jmac's patch @_@ | 16:50 |
| * Krin is slowly working through that patch | 16:51 | |
| jmacs | Already spotted a reference to github in there :( | 16:51 |
| paulsherwood | jmacs: that could be fixed on merge ;) | 16:55 |
| jmacs | As I said, it needs testing anyway, and I'm sure people will find bigger problems than that | 16:57 |
| paulsherwood | jmacs: how much of a box does it need for testing? could i build it on my machine, for example? | 16:58 |
| * Krin holds up his hands after getting to the 4th of 19 patches "your doing stuff that i dont know about, i cant really review it when i am unsure on the result of commands your using jmacs" | 16:58 | |
| jmacs | paulsherwood: You can't do anything useful with it as it needs some upstream repositories changing to ones on my github account | 17:00 |
| jmacs | You could attempt to build it, but you'll need a baserock machine with at least 8GB of RAM | 17:00 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:02 | |
| paulsherwood | ah, my physical machine doesn't have that much | 17:20 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:34 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:40 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:52 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:14 | |
| *** rdale [~quassel@219.Red-83-61-47.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds] | 18:18 | |
| *** grahamfinney_ [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:22 | |
| *** tiagogomes_ [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:29 | |
| *** grahamfinney_ [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:30 | |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 19:02 | |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:07 | |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 19:08 | |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:12 | |
| *** grahamfinney_ [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:19 | |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 19:19 | |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:23 | |
| *** grahamfinney [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 19:23 | |
| *** grahamfinney_ [~grahamfin@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 276 seconds] | 19:25 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 20:44 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!