| *** simonh_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:59 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 02:06 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 05:43 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 05:43 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:43 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 07:14 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 07:41 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 07:41 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:41 | |
| *** grahamfinney_ [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 07:51 | |
| *** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 07:54 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:16 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 08:17 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:17 | |
| pedroalvarez | True. I guess that I assume nobody is using minimal systems. | 08:18 |
|---|---|---|
| SotK | could I get a quick review of this lorry by any chance? (Kinnison +1'd it a few days ago but it got swept away before anyone gave a second +1) http://paste.baserock.org/izanerohas.diff | 08:26 |
| paulsherwood | SotK: +1 | 08:57 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:57 | |
| pedroalvarez | tiagogomes_: 2015-01-21 20:41:51 Build of baserock:baserock/definitions f2532705c6e110bf0012cac0933abcbf1c5ed848 systems/devel-system-ppc64-generic.morph ended successfully | 09:03 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:09 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:11 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:20 | |
| Kinnison | pedroalvarez: coo | 09:21 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:22 | |
| SotK | Kinnison: is your +1 of my lorry above still valid? | 09:24 |
| Kinnison | I remain confused as to why we pick https rather than git:// but that isn't worth complaining about, so yes +1 | 09:24 |
| SotK | thats what github provides in its link box, I'll change it to git if you like (I normally do, but forgot this time) | 09:25 |
| bashrc | to avoid port blocks? | 09:25 |
| Kinnison | if git.baserock.org is suffering from port blocks, we have worse things to contend with | 09:26 |
| Kinnison | SotK: I don't mind -- in theory https + certificate-checking is more secure | 09:26 |
| SotK | OK, merged, thanks! | 09:28 |
| Kinnison | :-) | 09:28 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 09:31 | |
| tiagogomes_ | pedroalvarez, cool, can I use the armv7lhf machine that I was using yesterday | 09:38 |
| pedroalvarez | tiagogomes_: yup | 09:38 |
| tiagogomes_ | ta | 09:39 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:47 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 276 seconds] | 10:00 | |
| franred | Im creating some lorries for some apache repositories, do we care if we mirror from the git repos which apache give to the comunity (http://git.apache.org/) ? or we want to lorry from the svn repositories (http://svn.apache.org/repos/asf/)? | 10:03 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:03 | |
| franred | the repositories are httpd, apr and apr-utils | 10:03 |
| pedroalvarez | hm.. I'd prefer git whenever possible | 10:05 |
| franred | said that the git repositories are a mirror from the svn repositories (which are the "in development" ones) | 10:06 |
| pedroalvarez | how frequent are they updated? can we know that? | 10:08 |
| Kinnison | Should they choose to switch to git, they're more likely to go with their conversions than any we produce, we should lorry their git repos unless they're abandonware | 10:09 |
| franred | pedroalvarez, "...These mirrors contain the full version histories (including all branches and tags) of the mirrored codebases and are updated in near real time based on the latest svn commits..." | 10:12 |
| franred | Kinnison, ok. | 10:12 |
| pedroalvarez | near real time sounds enough to me :) | 10:12 |
| pedroalvarez | and makes the lorry lighter (I believe) | 10:13 |
| franred | just a warning for the future, they have mirrors in github too, but these are not updated as frequent as the one in http://git.apache.org/ | 10:13 |
| franred | pedroalvarez, yeah, I just need to check if apr and apr-util git repos are fine, last time I've tried I cloned empty repositories | 10:14 |
| pedroalvarez | franred: maybe they didn't have a master branch? | 10:14 |
| franred | I will check | 10:15 |
| pedroalvarez | is the branch that git checks out by default | 10:15 |
| franred | that is a good point actually | 10:15 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:15 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:16 | |
| franred | ummm, pedroalvarez, no, apr looks empty | 10:22 |
| franred | and apr-util looks outdated | 10:22 |
| franred | but their github mirrors looks ok | 10:23 |
| pedroalvarez | franred: can you /msg me the git urls from apache.org and gihub? | 10:23 |
| franred | pedroalvarez, done | 10:26 |
| pedroalvarez | ta | 10:26 |
| pedroalvarez | "warning: You appear to have cloned an empty repository." | 10:29 |
| Kinnison | :-( | 10:29 |
| pedroalvarez | Hm... let me find someone from apache | 10:31 |
| franred | pedroalvarez, ta | 10:43 |
| franred | I have another question.... we have lorried psycop2 but for windows.... o.O! - can we remove that repo and its lorry? I want to lorry the one we need instead | 10:45 |
| pedroalvarez | who!? | 10:45 |
| pedroalvarez | hah | 10:45 |
| pedroalvarez | so I guess that it cannot be used at all | 10:47 |
| pedroalvarez | and it hasn't been used yet | 10:47 |
| franred | it is not in use if you are asking that | 10:47 |
| franred | we are using github:psycopg/psycopg2 instead | 10:47 |
| pedroalvarez | I think that updating its git url and change the lorry to force push all the things could be ok | 10:48 |
| pedroalvarez | (but, I'm never sure about lorries) | 10:48 |
| pedroalvarez | will downstream troves get the change? | 10:49 |
| pedroalvarez | I don't know | 10:49 |
| franred | pedroalvarez, so, what is your suggestion? | 10:50 |
| pedroalvarez | wait for opinions :) | 10:51 |
| franred | ok, waiting... :) | 10:57 |
| richard_maw | downstream troves will get the change | 10:57 |
| *** grahamfinney_ [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 11:14 | |
| jmalk | I seem to be using a not-up-to-date version of morph. given this guide - http://wiki.baserock.org/using-latest-morph/ - I'd have thought going to that directory and `git pull` would update it, but it's telling me everything is up to date. any advice please? | 11:46 |
| pedroalvarez | jmalk: if you do `git branch` it shows you master? | 11:47 |
| pedroalvarez | also, what shows this command? `cat /usr/bin/morph` | 11:47 |
| jmalk | pedroalvarez: git branch in /src/morph is master, yes | 11:47 |
| jmalk | pedroalvarez: http://paste.baserock.org/arihunahiv | 11:48 |
| pedroalvarez | jmalk: looks ok, I think you are using latest one | 11:49 |
| pedroalvarez | you can also run `morph --version` to doublecheck | 11:49 |
| pedroalvarez | it should show you: f2f3e4e5f3d5162890d03494f405cff5177aaad8 | 11:50 |
| franred | jmalk, is that morph script in /usr/bin? | 11:50 |
| jmalk | alas, 1cafde326cd1858980a5a13aa685b624792a8514 | 11:50 |
| pedroalvarez | franred: yes | 11:50 |
| jmalk | pedroalvarez: yes, /usr/bin/morph | 11:50 |
| franred | yes, sorry | 11:51 |
| franred | :) | 11:51 |
| pedroalvarez | jmalk: hm... odd | 11:51 |
| jmalk | pedroalvarez: very. maybe I should just remove morph and clone it afresh? | 11:51 |
| pedroalvarez | jmalk: does `/src/morph/morph --version` shows the same sha1? | 11:53 |
| jmalk | pedroalvarez: it does | 11:54 |
| pedroalvarez | then is a matter of upgrading the git clone | 11:54 |
| paulsherwood | jmalk: which morph? and is that a script? | 11:54 |
| paulsherwood | sorry `which morph`, and try editing the result | 11:54 |
| pedroalvarez | `which morph` is going to show always /usr/bin/morph | 11:54 |
| paulsherwood | pedroalvarez: 'always' is a very strong word | 11:55 |
| * paulsherwood doesn't trust software in general | 11:55 | |
| pedroalvarez | paulsherwood: haha, ok. I mean, following our "using latest morph" guide, doesn't modify the result of `which morph` | 11:55 |
| jmalk | which morph returns /usr/bin/morph | 11:56 |
| pedroalvarez | jmalk: rename the /src/morph folder and clone it again | 11:56 |
| paulsherwood | jmalk: and /usr/bin/morph is editable and is a script calling /src/morph ? | 11:57 |
| jmalk | paulsherwood: it is, yes | 11:57 |
| paulsherwood | and in /src/morph git status shows clean? | 11:57 |
| paulsherwood | and there git log shows the desired commit at the top? | 11:57 |
| jmalk | src/morph git status is not clean! it has an outgoing/ folder which I used to prepare a covering letter. | 11:58 |
| paulsherwood | aha. so maybe try causing /src/morph to be at the desired state via git checkout, or git reset, git pull etc? | 11:59 |
| jmalk | hmmm rm outgoing/, now directory is clean, but still can't pull to get to completely up-to-date | 12:00 |
| pedroalvarez | `git checkout master && git pull`? | 12:00 |
| SotK | where did you clone it from? | 12:00 |
| paulsherwood | git remote -v | 12:00 |
| jmalk | ah, git knows about "github" (my account) and baserock.org repo - do I need to specify origin (baserock.org) when pulling I presume? | 12:01 |
| pedroalvarez | `git fetch baserock.org` will fetch everything from that origin | 12:02 |
| pedroalvarez | and I'd use `git reset --hard baserock.org/master` to go to master of that origin | 12:03 |
| paulsherwood | +1 | 12:03 |
| jmalk | sorted! that was a fun little mystery, thanks for the help everyone | 12:03 |
| paulsherwood | :) | 12:07 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 12:18 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 12:20 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:33 | |
| * pedroalvarez deploys a baserock system to an usb stick using usb passthrough on his vm | 12:35 | |
| pedroalvarez | next step plug it into a machine and boot the system :) | 12:35 |
| nowster | Asking for background info: is Baserock now wedded to the facilities that btrfs provides? | 12:43 |
| nowster | (ie. would developing on a system without btrfs be an exercise in pain?) | 12:45 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 12:45 | |
| richard_maw | our update method currently relies on it, if you have an alternative way of doing updates, such as replacing the rootfs of a VM, then you could get away without it | 12:46 |
| persia | nowster: There has been talk about support also for ZFS, which has the same sort of features, but I don't believe that is yet either complete or merged. You should also be able to use a different write extension to cause the resulting filesystem to be anything (but updates won't work). | 12:53 |
| pedroalvarez | So, after deploying a system to the usb. My machine loads the initramfs system ok, then the kernel, and then it panics. Not sure about how to debug this, nor what can be the issue | 12:56 |
| pedroalvarez | richard_maw: any hint? | 12:56 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:56 | |
| richard_maw | pedroalvarez: I didn't even get that far with USB pass-through | 12:57 |
| persia | IF the iniitramfs stuff is working, then the kernel can *boot* on the hardware. Perhaps the kernel doesn't have the right drivers to access the / filesystem from USB? | 12:57 |
| pedroalvarez | aham... | 12:58 |
| pedroalvarez | good point | 12:58 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 12:59 | |
| richard_maw | it's difficult to guess without any further info, if the kernel panic text isn't useful, having scrolled away from the useful output, you could keep back-scroll if you were using a serial port | 13:00 |
| persia | Or a console with many rows: with the right arguments, some screens can provide 200 or so. | 13:00 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:01 | |
| persia | Something else to try is to use an initramfs that *doesn't* try to mount / off storage. | 13:02 |
| persia | Then try to mount the storage directly, and investigate the error messages. Once you can mount storage, mount some kernel modules, and start modprobing until you can mount your target / properly: this gives you a good guide to what needs to be turned on in the kernel configuration. | 13:03 |
| richard_maw | I think there may be a kernel command-line argument to say "run this in your initramfs, rather than /init" | 13:07 |
| richard_maw | if it exists, you could say to use /bin/sh as your init | 13:08 |
| persia | It does exist. I believe it is "init=", so "init=/bin/sh" for example. | 13:09 |
| richard_maw | ah, put `rdinit=/bin/sh` and you can see if it's the initramfs script that's at fault | 13:09 |
| richard_maw | persia: if you've got an initramfs, then the kernel expects init= to be handled by the initramfs | 13:09 |
| persia | Ah. Thanks for the correction. I thought the argument worked the same whether there was an initramfs or not. | 13:11 |
| pedroalvarez | thanks for your help. I'll try with that and see how it goes. | 13:14 |
| pedroalvarez | I managed to see the kernel panic test (by recording it: https://www.youtube.com/watch?v=0zUxRJwcLAQ) but is not useful at all. I will try rdinit now. | 13:22 |
| richard_maw | "ata3.01: failed to resume link" doesn't sound good | 13:43 |
| richard_maw | it does get as far as executing mount though | 13:44 |
| pedroalvarez | so, I assume that the kernel is not finding the usb stick | 14:14 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 14:17 | |
| * pedroalvarez adds usb3.0 support to the bsp | 14:22 | |
| *** pacon [~pacon@101.117.118.243] has joined #baserock | 14:26 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 14:34 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:36 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 14:38 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 14:38 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 14:38 | |
| *** pacon [~pacon@101.117.118.243] has quit [Read error: Connection reset by peer] | 14:40 | |
| *** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 14:47 | |
| *** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has joined #baserock | 15:00 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 15:07 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:09 | |
| richard_maw | https://asciinema.org/ looks like an interesting solution for recording videos of terminals, which is what we generally have | 15:15 |
| richard_maw | I wonder if it was inspired by Lars' live coding thing | 15:15 |
| paulsherwood | much o/win 33 | 15:16 |
| paulsherwood | bah@!@q@$@$ | 15:16 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 15:16 | |
| paulsherwood | :) | 15:16 |
| jmacs | Hmm, looks good | 15:17 |
| pedroalvarez | I gess I can't use it to record the kernel eror trace :/ | 15:19 |
| pedroalvarez | enabling usb3 has worked. Now the kernel says that it has found the usb device, but it's still panicking | 15:20 |
| richard_maw | pedroalvarez: if you use screen to attach to a serial port it would work, but at that point you don't need to turn it into an ascii video | 15:22 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:31 | |
| jmalk | I'm running cycle.sh on a VM, but keep getting asked for root@127.0.0.1's password: what have I forgotten to do? | 15:34 |
| persia | Grant passwordless ssh from your development VM to your development VM. | 15:34 |
| jmalk | ahh | 15:35 |
| persia | Easiest way is to generate a local id_rsa pair, and append id_rsa.pub to authorized_keys in .ssh/ | 15:35 |
| jmacs | ssh-keygen; ssh-copy-id root@localhost | 15:36 |
| jmacs | Does the same thing | 15:37 |
| jmalk | tvm folks | 15:37 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 15:42 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:01 | |
| persia | Does morph clear the ccache cache when the ABI for a build is changed (e.g. when patching the C library in interesting ways)? | 16:11 |
| * paulsherwood doubts it, but may be pleasantly surprised | 16:13 | |
| Kinnison | Seems unlikely, but the compiler ABI is part of the key for ccache | 16:18 |
| richard_maw | persia: is this the ABI of dependencies, or the ABI of the object you're compiling? | 16:21 |
| richard_maw | I don't think the ABI of dependencies can affect builds at this point, since ccache only caches .o files | 16:22 |
| persia | richard_maw: I'm thinking of the object: my thought is that if we have the same ABI string and the same arguments, ccache will try to reuse the blobs, even if we do this with a radically differently patched C library. | 16:22 |
| Kinnison | ccache only caches intermediate objects | 16:23 |
| Kinnison | so different libc shouldn't make any odds | 16:23 |
| Kinnison | if the patches alter the headers then the preprocessed code will differ and ccache will build it afresh | 16:23 |
| Kinnison | In general, you have to work hard to lie to ccache | 16:24 |
| Kinnison | (or be a compiler developer) | 16:24 |
| persia | Kinnison: As a thought example, do you want to assert that remains true if I build a bunch of armv7l objects, then modify the configuration so my new "armv7l" is identical to "armv7lhf" and try to rebuild things? | 16:24 |
| persia | Being changes to kernel API headers, libc, gcc, etc. | 16:25 |
| Kinnison | if it's identical then the compiler will have changed | 16:25 |
| Kinnison | and thus ccache will behave right | 16:25 |
| Kinnison | since the ABI will no longer be softfloat | 16:25 |
| persia | So ccache will automatically notice the ABI features, rather than the actual ABI? | 16:25 |
| persia | Even if the arguments passed to gcc are the same? | 16:26 |
| Kinnison | I believe the gcc specs form part of the key | 16:26 |
| Kinnison | I believe in Baserock, the cache key of the compiler forms part of ccache's key | 16:26 |
| persia | For morph, yes. For ccache? | 16:26 |
| Kinnison | richard_maw: ^^ ? | 16:26 |
| persia | Aha! If that is the case, then my worry is unfounded, and I am delighted. | 16:26 |
| Kinnison | lets hope richard_maw bears out my belief then | 16:27 |
| richard_maw | Kinnison: that's broadly correct, the current approach is to include the cache keys of the toolchain chunks in ccache's hashing algorithm | 16:27 |
| richard_maw | this is currently implemented by hashing the /baserock metadata files | 16:27 |
| Kinnison | during the ccache chunk prep? | 16:28 |
| richard_maw | it's a little fragile, so I'd prefer to alter morph to export the cache key of a build to its build commands, so we could include the cache id from morph in the hashing algorithm | 16:28 |
| richard_maw | Kinnison: no, at every build unfortunately, morph sets environment variables telling ccache that it needs to hash those files into ccache's key | 16:29 |
| Kinnison | hmm | 16:29 |
| Kinnison | I think that's overly worrisome | 16:29 |
| Kinnison | i.e. it will reduce cache hits dramatically | 16:29 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:29 | |
| richard_maw | when I looked, ccache didn't have a way to inspect the specs for hashing | 16:30 |
| richard_maw | its options were to hash the `gcc` binary (which doesn't always work, and they rely on this in their test suite) | 16:30 |
| richard_maw | include the mtime of the gcc binary | 16:30 |
| richard_maw | or include the version string of the gcc binary | 16:30 |
| richard_maw | or include a set of files as defined in an environment variable (what we do) | 16:30 |
| * paulsherwood notes that json.dumps(hash_factors, sort_keys=True).encode('utf-8') seems to provide a consistent result for hashing, even on nested dicts, which is rather easier to undertand than the current things morph does. | 16:31 | |
| Kinnison | richard_maw: If we passed in the chunk cache key during the build, for gcc to include as the build ID (which goes into the binaries) then hashing the gcc binary should be plenty | 16:32 |
| richard_maw | a lot of its correct operation assumes either you've got a distro handling this to ensure toolchains hash distinctly, or you're fully aware of the risks when you build your own toolchain | 16:32 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:32 | |
| straycat | paulsherwood, i don't follow that | 16:34 |
| paulsherwood | straycat: it may be a non-sequitur. i just thought if the cache algorithm might be getting some love, there appears to be a simpler way to code a soln. i may be wrong. i often am | 16:36 |
| simonh_ is now known as mauricemoss_ | 16:37 | |
| richard_maw | paulsherwood: it's constructing the hash_factors that is the difficult computation anyway, and to me it doesn't make a great amount of difference whether we do something to construct the hash_factors data structure, or pass hash factors directly to the hashing function. It does however take more memory to construct the hash factors and the dumped string before feeding into the hashing algorithm, instead of feeding the hashing data into the alg | 16:37 |
| paulsherwood | what's difficult about constructing the hash_factors? it's just a set of things? | 16:39 |
| richard_maw | Kinnison: true, but if we bake the hash of the ccache chunk into ccache, it doesn't need to hash the gcc binary at every build | 16:39 |
| persia | I think hasing every build is a feature. | 16:39 |
| straycat | what are hash factors? | 16:39 |
| richard_maw | paulsherwood: difficulty isn't the point. To me it's the same amount of work to construct the hash_factors structure as to feed the hash factors directly into the hashing algorithm. | 16:39 |
| persia | It was my worry that we might not do it for every build that caused me to raise the point in the first place | 16:39 |
| straycat | I know of load factors | 16:39 |
| richard_maw | paulsherwood: the difference is that you use more memory building the hash_factors structure | 16:40 |
| paulsherwood | in this context, hash factors are (say) *-commands, ref, repo, build-depends etc | 16:40 |
| paulsherwood | richard_maw: isn't that a very small amount of memory compared to other things ? | 16:41 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:42 | |
| richard_maw | paulsherwood: it's roughly the same amount of memory again, twice, since it needs to be kept in data structure form and string form at the same time. | 16:43 |
| richard_maw | but I agree that it's not enough memory that it should be the deciding factor | 16:44 |
| paulsherwood | it's maybe 1k of memory? | 16:44 |
| straycat | ok | 16:44 |
| paulsherwood | and this is one line of code vs several inscrutible functions? | 16:44 |
| paulsherwood | but as i've said elsewhere 'anyone who believes in egoless programming doesn't know many programmers', so i accept i may be failing to see straight | 16:46 |
| Kinnison | I think paulsherwood is trying to suggest a one-liner to replace the _hash_id method of cachekeycomputer -- wouldn't produce identical results but ought to be as safe | 16:49 |
| richard_maw | I agree it could do better. I don't know of any built-in dict-walking code that we could use to hash it easily. | 16:49 |
| Kinnison | But it'd rely on json being able to hash tuples as well as lists | 16:49 |
| Kinnison | and I don't know if it can | 16:49 |
| paulsherwood | i don't think there need to be tuples? | 16:49 |
| Kinnison | There are in morph right now | 16:49 |
| Kinnison | so we'd have to refactor more than the place your oneliner helps to be able to use it | 16:50 |
| Kinnison | if it can't | 16:50 |
| Kinnison | And yes, I'm aware that in changing the cache key computation algorithm we'd be rewriting not refactoring | 16:50 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:50 | |
| richard_maw | Kinnison: json will convert tuples to lists, so it's not round-trippable, and it doesn't take into account the types, however we currently hash both tuples and lists tot he same thing anyway, so that wouldn't be a regression | 16:50 |
| paulsherwood | understood :) | 16:50 |
| paulsherwood | if someone is going to actually think about this, please take a look at https://github.com/devcurmudgeon/ybd/blob/master/cache.py - i'm not saying it's hashing everything that morph does, but the mechanism could, and i think it's easier to grok | 16:52 |
| paulsherwood | i'll stop pitching, now | 16:53 |
| richard_maw | my only remaining concerns are that dumping to json is a bit of an abuse of the interface, when all we need is a stable serialisation | 16:53 |
| richard_maw | and if we were to change the computation to hashing dumped json, it would invalidate all our chunks, so we'd have to rebuild everything | 16:53 |
| paulsherwood | agreed | 16:54 |
| bashrc | Made a separate "scripted for virtualbox" http://wiki.baserock.org/guides/vb-script | 17:00 |
| paulsherwood | bashrc: why is that better than just cutting and pasting from http://wiki.baserock.org/guides/no-frills/ ? | 17:01 |
| paulsherwood | bashrc: i'm not trolling, am interested to know why you think this is better | 17:02 |
| bashrc | yes, that is quite similar | 17:02 |
| bashrc | probably a circular reference | 17:03 |
| persia | bashrc: Nice. Have you looked at vagrant? I'd like to be able to host something that lets folk run `git clone foo; cd foo; vagrant up` to get a basic development environment. | 17:03 |
| franred | "Hi, Im facing the following problem: iptables-restore v1.4.21: iptables-restore: unable to initialize table 'nat'\n\nError occurred at line: 2\nTry `iptables-restore -h'" | 17:04 |
| franred | with the 3.18 kernel | 17:05 |
| franred | AFAIK, nat module is available in the kernel --> strata/bsp-x86_64-generic/linux-x86-64-generic.morph:- scripts/config -e NF_NAT | 17:05 |
| franred | how can I debug this? (also note that lsmod does not give me any information) | 17:06 |
| nowster | trying to cross-bootstrap here... using a recent gcc... hitting a linker error in building gcc: http://paste.baserock.org/iyuzolemay | 17:12 |
| nowster | the compiler's missing crt?.o | 17:13 |
| richard_maw | that usually means the -B paths are wrong, but error handling when building gcc is... interesting | 17:14 |
| nowster | aye | 17:16 |
| nowster | It hasn't built any crt?.o files, but it has built some of their precursors. | 17:16 |
| richard_maw | at this point, it's supposed to be using those | 17:16 |
| richard_maw | I usually start by running gcc in verbose mode so it says which internal command is failing | 17:17 |
| richard_maw | sorry, this isn't something I can help someone else debug, I only know where to poke as I'm doing it | 17:17 |
| nowster | My gut feeling is that it hasn't built libgcc correctly | 17:18 |
| Kinnison | crt.o is from libc isn't it? | 17:19 |
| franred | ummm looks like NF_NAT_IPV4 was renamed as IP_NF_NAT in 3.17 kernel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765691 | 17:19 |
| Kinnison | heh | 17:20 |
| richard_maw | Kinnison: aye | 17:20 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:34 | |
| * richard_maw failed to catch up with his e-mail backlog, but is down to two pages, rather than 20 | 17:41 | |
| Kinnison | heh | 17:41 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:58 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:03 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:17 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 18:23 | |
| *** rdale [~quassel@204.Red-79-147-223.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 18:52 | |
| *** rdale [~quassel@153.Red-79-146-0.dynamicIP.rima-tde.net] has joined #baserock | 18:56 | |
| *** rdale [~quassel@153.Red-79-146-0.dynamicIP.rima-tde.net] has quit [Ping timeout: 244 seconds] | 19:00 | |
| *** grahamfinney [~grahamfin@cpc14-know11-2-0-cust234.know.cable.virginm.net] has quit [Quit: Ex-Chat] | 19:01 | |
| *** rdale [~quassel@79.Red-79-157-223.dynamicIP.rima-tde.net] has joined #baserock | 19:03 | |
| *** rdale_ [~quassel@171.Red-83-61-45.dynamicIP.rima-tde.net] has joined #baserock | 19:05 | |
| straycat | heh, pip's tests make morph's look fast | 19:06 |
| *** rdale [~quassel@79.Red-79-157-223.dynamicIP.rima-tde.net] has quit [Ping timeout: 246 seconds] | 19:08 | |
| franred | xD | 19:09 |
| *** rdale [~quassel@137.Red-79-158-207.staticIP.rima-tde.net] has joined #baserock | 19:12 | |
| *** rdale_ [~quassel@171.Red-83-61-45.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 19:12 | |
| *** rdale [~quassel@137.Red-79-158-207.staticIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 19:16 | |
| *** rdale [~quassel@97.Red-88-21-208.staticIP.rima-tde.net] has joined #baserock | 19:20 | |
| *** rdale_ [~quassel@126.Red-2-137-111.dynamicIP.rima-tde.net] has joined #baserock | 19:24 | |
| *** rdale [~quassel@97.Red-88-21-208.staticIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 19:25 | |
| *** rdale [~quassel@228.Red-83-35-57.dynamicIP.rima-tde.net] has joined #baserock | 19:25 | |
| *** rdale_ [~quassel@126.Red-2-137-111.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 19:29 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:44 | |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 19:59 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:28 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:31 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 20:38 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 21:29 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 22:11 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 22:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!