| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer] | 00:38 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 00:41 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds] | 00:55 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 00:57 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer] | 01:00 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 01:02 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer] | 01:38 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 01:40 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds] | 05:27 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 05:27 | |
| richard_maw | well, we can build a devel system without /dev/shm in the staging area | 07:17 |
|---|---|---|
| *** tiagogomes [~tiagogome@213.15.255.100] has joined #baserock | 07:34 | |
| paulsherwood | is there source of radiofree's jetson flasher script somewhere? | 07:54 |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:10 | |
| richard_maw | paulsherwood: not that I know of, just inside the tarball | 08:11 |
| paulsherwood | ok | 08:16 |
| richard_maw | I know it didn't get sent for review anywhere, or I would have pointed out the bashism which caused the confusion when people were running it on systems that weren't fedora. | 08:17 |
| paulsherwood | ok. we should get james or someone to submit it, for inclusion in scripts | 08:18 |
| Kinnison | richard_maw: I'd be concerned that some build systems might run tests or tools which require /dev/shm during build | 08:26 |
| Kinnison | richard_maw: i.e. if we can have /dev/shm I'd be happier | 08:26 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:35 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Ping timeout: 260 seconds] | 08:41 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 08:41 | |
| paulsherwood | what is /dev/shm and what do we need it? | 08:47 |
| paulsherwood | s/it/it for/ | 08:47 |
| Kinnison | It's where shared memory segments come from for SYSV shm segments | 08:50 |
| paulsherwood | Kinnison: sorry, i don't understand that - too tech for me i'm afraid. what do we need it for please? | 08:51 |
| Kinnison | According to Richard Maw, nothing currently | 08:52 |
| Kinnison | But I'd be concerned that build systems might behave differently in the absence of it | 08:52 |
| Kinnison | e.g. if a configure script *tested* for shmget working | 08:52 |
| Kinnison | rather than just its presence | 08:52 |
| Kinnison | or a build system was metaprogrammed and needed shm for running a build tool | 08:52 |
| Kinnison | It just feels odd not to have it available | 08:52 |
| paulsherwood | ok thanks | 08:53 |
| jjardon | Hi! Is there a page with the list of components a system should have to be genivi compliant ? | 08:53 |
| Kinnison | I imagine in GENIVI's documentation there will be | 08:55 |
| Kinnison | I doubt we maintain a separate one | 08:56 |
| paulsherwood | we cannot maintain apublic one.. the spec is confidential | 09:04 |
| rjek | ... really? | 09:05 |
| wikicat | rjek: Error: ".." is not a valid command. | 09:05 |
| rjek | Wow! | 09:05 |
| rjek | wikicat: Be silent. | 09:05 |
| wikicat | rjek: Error: "Be" is not a valid command. | 09:05 |
| * Kinnison assumes straycat will disable wikicat's interaction with the channe; | 09:06 | |
| Kinnison | s/;$/l/ | 09:06 |
| * Kinnison rephrases... | 09:07 | |
| Kinnison | straycat: Please disable wikicat's interaction with the channel. | 09:07 |
| paulsherwood | don't we like wikicat, then? | 09:07 |
| Kinnison | I'm happy for wikicat to tell us when things happen | 09:08 |
| petefoth | I think there are other ways of being kept informed of vhanges to w.b.o without adding to traffic in this channel | 09:08 |
| Kinnison | I don't want it responding to people who start lines with a dot | 09:09 |
| rjek | I like wikicat's edit announcements. | 09:09 |
| rjek | But public commands are an abomination. | 09:09 |
| Kinnison | At least ones which aren't obviously directed | 09:09 |
| jjardon | Oh, didn't know the spec was confidential; that explain why I was struggling trying to find it in the genivi docs yesterday | 09:10 |
| Kinnison | GENIVI is a commercial entity | 09:10 |
| Kinnison | their *output* is, to some extent, free software | 09:10 |
| Kinnison | but their intermediates are proprietary | 09:11 |
| robtaylor | richard_maw: have you seen this wotrk by harald hoyer? https://github.com/haraldh/particle/ | 09:11 |
| richard_maw | robtaylor: an earlier version of it | 09:12 |
| richard_maw | it was posted to google+ soon after Lennart's proposal for apps. | 09:13 |
| paulsherwood | robtaylor: what does it *do*? | 09:18 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:19 | |
| jjardon | I'd say commercial and free software are orthogonal things. But thanks for the info | 09:20 |
| paulsherwood | :) | 09:20 |
| Kinnison | At least it's not free-core-proprietary-full | 09:21 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:22 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has quit [Read error: Connection reset by peer] | 09:28 | |
| *** radiofree [radiofree@unaffiliated/radiofree] has joined #baserock | 09:31 | |
| ssam2 | ripsum: I pushed code to the baserock:baserock/import repo last night | 09:37 |
| ssam2 | still needs quite a bit of tidying up | 09:38 |
| ssam2 | but no longer needs the x-dependencies fields, it uses a separate .foreign-dependencies file instead | 09:38 |
| ssam2 | which means it doesn't need a patch to morph in order to work | 09:38 |
| ssam2 | and I split out the dependency calculation into a separate .find_deps extension instead of doing it in the .to_chunk extension | 09:38 |
| ssam2 | you should move your pip work to a branch in that repo, when convenient | 09:39 |
| Zara | if I'm editing a stratum, where would I find the ref I need for the 'ref' field? | 09:50 |
| robtaylor | paulsherwood: read only rootfs | 09:52 |
| robtaylor | richard_maw: so, apparently for btrfs write stability we need to regularly defrag and balance | 09:52 |
| robtaylor | richard_maw: i suspect a patch to systemd to add a unit to do this would be well received | 09:53 |
| ssam2 | zara: you can actually put any valid Git ref there | 09:53 |
| ssam2 | e.g. 'master' | 09:53 |
| ssam2 | but as a policy we restrict the ones in the master branch of definitions.git to be exact commit SHA1s | 09:54 |
| ssam2 | to resolve a git ref to a SHA1 you can use the `git show-ref` command | 09:54 |
| richard_maw | or `git rev-parse $REF` | 09:55 |
| ssam2 | wow. "ERROR: Conflicting versions of stratum 'tools-devel' appear in the build. Check the contents of the system against the build-depends of the strata." | 11:04 |
| ssam2 | that's an error I've not seen for a while | 11:04 |
| paulsherwood | shouldn't be possible any longer? :) | 11:05 |
| ssam2 | indeed | 11:05 |
| ssam2 | but jjardon seems to have worked magic :) | 11:06 |
| jjardon | ssam2: sorry, I only tested the genivi-baseline to check that branch | 11:09 |
| ssam2 | ok | 11:18 |
| ssam2 | it's a pretty unexpected error to be honest | 11:18 |
| ssam2 | the problem is that the 'tools' stratum appears in the build graph twice | 11:19 |
| ssam2 | since all strata are in the same repo now, it's not the old problem we had where two versions of the same stratum could be pulled in | 11:20 |
| ssam2 | in fact, i'm so confused | 11:20 |
| * straycat sees that '.' was not a good choice for a command character | 11:21 | |
| ssam2 | hah, OK, I see the problem | 11:32 |
| ssam2 | coreutils-common.morph has 'name: tools' at the top :) | 11:32 |
| ssam2 | maybe it's time for Morph to enforce morph name == file basename | 11:33 |
| straycat | Could we get rid of the name key now? | 12:02 |
| straycat | I mean name field | 12:02 |
| ssam2 | I like having it. I fear holy war. | 12:03 |
| straycat | Well, if we are to enforce morph name == file basename, that suggests we're storing redundant data. | 12:04 |
| ssam2 | depends if the morphology has a filename. It could be in a pastebin, or a presentation slide, or a design document, or inlined in a test case | 12:04 |
| ssam2 | only when its stored in a file in a git repo or on disk does it necessarily have a filename | 12:05 |
| straycat | And in all of those cases you can give it a meaningful name. | 12:05 |
| * Kinnison would rather not enforce name == basename | 12:05 | |
| * Kinnison would rather report a better error: | 12:05 | |
| Kinnison | "ERROR: name 'tools-devel' is present in some/file.morph and some/other/file.morph" | 12:06 |
| Krin | i heard tell a while back about a strata for Java on baserock, is this true and if so could someone point me in the direction to start walking to add said strata? | 12:06 |
| Kinnison | And I'd like it if the graph was checked so that build-depends (which state both morph and name) get the name checked | 12:06 |
| Kinnison | Krin: franred did some work to add a stratum for Java | 12:06 |
| Kinnison | Krin: But it was not ideal | 12:06 |
| ssam2 | Kinnison: i'm not sure what you mean about build-depends. | 12:07 |
| Krin | Kinnison, not ideal meaning... not working? or... | 12:07 |
| ssam2 | Kinnison: changing the 'conflicting versions of strata' error to what you described there seems reasonable | 12:08 |
| straycat | Or we could just remove the name field and make conficting strata impossible. | 12:08 |
| Kinnison | ssam2: I mean, in strata (and systems) when we refer to other strata, we mention both name and morph -- we should validate that the name in the morph matches the name in the includer morphology | 12:08 |
| * Kinnison likes the idea that there might be multiple variants of the "foo" stratum | 12:09 | |
| Kinnison | But ultimately if the upstream project chooses to dump the name field, I won't whinge | 12:09 |
| Kinnison | well, I will, but I'll try and do it quietly and far away :-) | 12:09 |
| straycat | I can't see why that would be useful, things we have multiple variants of, such as bsps already have unique names. | 12:09 |
| franred | Krin, java 8 works in baserock in the gerrit stratum | 12:09 |
| franred | as Kinnison said it is not the baserock way but java is difficult to bootstrap | 12:10 |
| Krin | ok so i need to add the gerrit stratum before i add the zookeeper one? (as zookeeper requires java it seems) | 12:11 |
| Krin | s/add/make | 12:11 |
| Kinnison | short-term I'd abstract the javaness out of the gerrit stratum, and then make a zookeeper stratum which depended on the java one | 12:11 |
| franred | Krin, no, you need to add java to an stratum or add the part of the chunk which install java | 12:11 |
| franred | Kinnison beats me | 12:12 |
| Krin | still kind of trying to work out how to construct chunks / strata, begining to realise i dont understand baserock uch, well i understand the concept, it's the actual doing that i'm clueless on *goes back to the wiki and feels he needs a reading hat* | 12:13 |
| * Kinnison grins | 12:13 | |
| Kinnison | Have you followed the adding-something-to-baserock tutorial? | 12:13 |
| paulsherwood | Krin: it's because some of our nomenclature sucks, tbh. | 12:14 |
| Krin | to be honest Kinnison most of that tutorial simply says to "do this bit" when "this bit" is what i'm struggling to work out how to do :) | 12:14 |
| Kinnison | aah | 12:15 |
| Kinnison | Krin: Please do try to go through the tutorial first, and where you're confused, ask here for assistance -- when you are unconfused, *please* augment the wiki page :-) | 12:15 |
| Krin | add a new stratum to it | 12:16 |
| Krin | create your new stratum file | 12:16 |
| Krin | add new chunk(s) in that for your component(s), specifying repo as ... | 12:16 |
| Krin | those bits are kind of... brief :) | 12:16 |
| Kinnison | aah | 12:16 |
| Kinnison | mmm, very true | 12:16 |
| Kinnison | petefoth: Do you fancy (a) helping Krin understand and (b) helping augment the docs? | 12:16 |
| Kinnison | petefoth: You're better at wording than I am | 12:17 |
| richard_maw | petefoth wordulates most cromulently | 12:17 |
| straycat | If the name field is desireable from a ui point of view we could keep it but in the morphs, but drop it internally. | 12:18 |
| straycat | s/but// | 12:18 |
| richard_maw | but then it gets out of sync and confuses | 12:18 |
| * petefoth reponds in a less public channel | 12:18 | |
| * straycat nods | 12:19 | |
| paulsherwood | can someone just recommend a small chunk of FOSS goodness that isn't in baserock, and is likely to build without too much pain? | 12:24 |
| Kinnison | Hmm | 12:26 |
| * Kinnison ponders | 12:26 | |
| richard_maw | nothing springs to mind | 12:26 |
| paulsherwood | bonnie? | 12:26 |
| rjek | FOSS goodness to do anything specific? | 12:26 |
| Kinnison | something whose b-ds are all already in there? | 12:26 |
| * paulsherwood will make a tutorial | 12:26 | |
| richard_maw | I think we've built bonnie before | 12:26 |
| rjek | http://bzr.rjek.com/public/fakeline :) | 12:26 |
| * Kinnison thinks it'd be nice to have moreutils and/or extrautils | 12:26 | |
| * Kinnison would like emacs in the devel system too | 12:27 | |
| Kinnison | Also gdb | 12:27 |
| richard_maw | we have gdb | 12:27 |
| Kinnison | oooh | 12:27 |
| Kinnison | yay | 12:27 |
| * richard_maw remembers watching it build | 12:27 | |
| paulsherwood | I'm not doing emacs. ever | 12:27 |
| Kinnison | pfeh, emacs is easy | 12:27 |
| Kinnison | benbrown_ proved that | 12:27 |
| * rjek wonders if binetd builds anymore | 12:27 | |
| richard_maw | binetd? | 12:28 |
| petefoth | we (i.e. Codethin internally) have scripts for many tutorials (including one that builds bonnie IIRC. | 12:28 |
| petefoth | Perhapes we should make those public rather than startign from scratch? | 12:28 |
| richard_maw | rjek: google isn't revealing the meaning of binetd | 12:28 |
| rjek | http://bzr.rjek.com/public/binetd :) | 12:29 |
| rjek | Bob's inetd. Trivial command-line inetd kinda thing | 12:29 |
| paulsherwood | petefoth: publish and be damned. but i bet it's not currnet | 12:29 |
| rjek | ie, it listens on a socket and spawns things when there are connections so unprivileged users can easily run inetd-expecting things | 12:29 |
| petefoth | paulsherwood: OK. I'll publish with a health warning | 12:30 |
| richard_maw | rjek: ah, I've written a couple of those. One even doing udp nowait | 12:30 |
| rjek | Ah, this is trivial and only does tcp | 12:30 |
| rjek | It's so trivial it doesn't even have a makefile | 12:30 |
| rjek | ls -l | 12:31 |
| * rjek is petefoth. | 12:31 | |
| richard_maw | rjek: got a python version of that, hard-coded to launch a git-daemon http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/scripts/git-daemon-wrap | 12:33 |
| richard_maw | except it spawns an ephemeral port and tells you what is is, rather than letting you pass one in | 12:34 |
| * rjek nods | 12:35 | |
| richard_maw | busybox also has udpsvd and tcpsvd when you don't want to use inetd | 12:36 |
| * rjek wrote binetd over a decade ago while learning BSD sockets. | 12:37 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 13:05 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:19 | |
| ssam2 | Zara: I saw this article recently which may give useful info about NPM: http://sandervanderburg.blogspot.co.uk/2014/10/deploying-npm-packages-with-nix-package.html | 13:29 |
| ssam2 | it's written by the Nix guys, Nix being a package manager, distro, build environment, and CI system which manages to be even more complex than Baserock | 13:29 |
| Zara | haha, ok, I'll have a read through | 13:29 |
| Zara | btw, I tried to build a system with express by editing a stratum and the corresponding system (and also by creating a stratum and a corresponding system), but I kept getting the error 'couldn't find morphology'. Is there something else I need to do? the stratum and system are definitely in the right directories (and have the right names!) | 13:32 |
| ssam2 | ah, right | 13:34 |
| ssam2 | you sometimes need a chunk morphology too, if the project's build system doesn't follow a pattern that Morph knows about | 13:35 |
| ssam2 | and I very much doubt that Morph knows how to build 'express' ? | 13:35 |
| ssam2 | do they provide instructions on how to build it from git? | 13:35 |
| Zara | ah, ok, I thought it might be that (if that corresponds to " | 13:35 |
| Zara | Unless the software you're adding is has a 'normal' build system recognised by Baserock (currently autotools, cmake) you'll probably need to script the build instructions in a morph file for your repo (see other morph files for examples), stored as chunkname.repo in the root of the git repository you created in your branch. " | 13:36 |
| ssam2 | wow, the end of that sentence is rather weird | 13:36 |
| Zara | they might provide instructions somewhere or other, though I don't think they're in the readme | 13:38 |
| ssam2 | yes, they want you to just use NPM | 13:39 |
| Zara | ok, I bookmarked a generic 'installing node packages sans npm' page a little while ago, but I wanted to check that was the problem before I spent too much time on it. :) | 13:39 |
| ssam2 | cool | 13:40 |
| ssam2 | it's probably easier to try the commands at the commandline, then once you have a process that works, put it into a morphology | 13:40 |
| ssam2 | also, it's not forbidden to use NPM in Baserock: we just don't want it to download and install dependencies from the internet as part of the build process | 13:41 |
| ssam2 | so maybe you can work out how to get 'npm install' to run without doing that | 13:41 |
| Zara | ssam2: it does *seem* to work (it doesn't report any errors), but then express doesn't run so I assume there's another step. | 13:42 |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 13:47 | |
| Zara | anyway, going from the wiki instructions above: I'm not sure where to find a morph file with build instructions to use as a example/template for this; does anyone have any recommendations? | 13:50 |
| pedroalvarez | Zara: there are loads of them in definitions.git | 13:51 |
| pedroalvarez | Zara: so if you go to "strata/name-of-stratum/" inside you will find the chunk morphologies needed to build the stratum with name "strata/name-of-stratum.morph" | 13:52 |
| Zara | ahhh, right | 13:56 |
| *** thecorconian [~thecorcon@136.1.1.102] has joined #baserock | 13:56 | |
| *** thecorconian [~thecorcon@136.1.1.102] has quit [] | 13:56 | |
| Zara | so the chunk morphologies are like files in directories? | 13:56 |
| Zara | where the directory title is the name of the stratum | 13:57 |
| pedroalvarez | Zara: yup! :) | 13:57 |
| pedroalvarez | does that makes sense to you? | 13:57 |
| Zara | yes, it does :) | 13:57 |
| pedroalvarez | Zara: it is flexible though, so you can point from one stratum to the chunk morphology of another stratum directory, but that would make it complex | 13:58 |
| richard_maw | you could put the chunk morphology anywhere, we just put it in a directory per stratum because it's tidy | 13:59 |
| Zara | pedroalvarez: Ok, well I won't worry about that for now :) I think I was just confused by the terminology. | 13:59 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:25 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 14:26 | |
| paulsherwood | fwiw while globetrotting i've started hacking to explore some of the ideas from the baserock user meetup which happened in August.... | 14:28 |
| paulsherwood | https://github.com/devcurmudgeon/brock/blob/master/doc/readme.md | 14:29 |
| rjek | paulsherwood: OOI, "brock" ? | 14:29 |
| paulsherwood | for fun | 14:29 |
| paulsherwood | anything not morph would be fine for me | 14:29 |
| paulsherwood | note it doesn't actually *build* anything, but on the other hand it eats the whole definitions dataset into build order in approx 1 second | 14:31 |
| Kinnison | Incl. everything being locked down to tree shas? | 14:32 |
| paulsherwood | not quite, but i think i know how to do that | 14:32 |
| straycat | the morph codebase is actually not that bad. | 14:32 |
| paulsherwood | i've started fiddling with the git stuff since i last pushed | 14:32 |
| Kinnison | Call me back when it constructs the same dataset twice in a row, even when someone moves a git ref along | 14:32 |
| Kinnison | :_) | 14:33 |
| paulsherwood | oh, i'm sure i can do that. | 14:33 |
| Kinnison | The reason morph is slow at constructing that dataset is because it has to go examine repos for data it *could* cache in the definitions instead | 14:33 |
| straycat | I've recently been looking at much simpler tools that are in much worse shape. | 14:33 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:33 | |
| paulsherwood | Kinnison: i think we'll have to agree to differ, until such time as a can prove my point :) | 14:34 |
| * Kinnison shrugs | 14:34 | |
| Kinnison | It depends on where your priorities are | 14:34 |
| Kinnison | you don't need to lock down to tree SHAs if you don't care about rebuilds happening unnecessarily | 14:34 |
| Kinnison | fr.ex. | 14:35 |
| paulsherwood | i do care about that | 14:35 |
| paulsherwood | i just think it can be much simpler than what we've come up with | 14:35 |
| Kinnison | We have a non-trivial amount of complexity, which could possibly be simplified. But in a lot of cases, it's complexity to support use-cases which would otherwise fail. | 14:36 |
| straycat | What we have at the moment is quite simple, at least conceptually. | 14:36 |
| paulsherwood | anyway, i know others have other ideas, and in the meantime i have noticed that morph seems to have got a lot faster this week, unless it's my imagination | 14:36 |
| Kinnison | We have done a lot to get rid of useless re-doing of work in morph I believe | 14:36 |
| wikicat | Wiki change: Improve 'adding-stuff' a bit (hopefully it's an improvement) http://source.baserock.branchable.com/?p=source.git;a=commitdiff;h=f87d951 | 14:37 |
| Kinnison | :-) | 14:38 |
| paulsherwood | :) | 14:39 |
| straycat | It might be nice to replace local build with distbuild, this has been suggested before I'm just repeating it. | 14:41 |
| * Kinnison would like that too, and I think richard_maw's work is heading in that direction | 14:41 | |
| Kinnison | we need to improve the error feedback and debugability for distbuilt though | 14:41 |
| Kinnison | otherwise we lose functionality | 14:42 |
| richard_maw | s/may/need/g | 14:42 |
| richard_maw | wait, that's wrong | 14:42 |
| richard_maw | s/may/will/ | 14:42 |
| straycat | It would definitely be great to optimise the processes involved in determining build order, cache keys etc. As far as I'm aware that's not really something we've focused on too much. | 14:42 |
| straycat | Kinnison, *nod* | 14:42 |
| richard_maw | I was going to have a crack at that after parallel test suite, since my goal yesterday was to see if I could bring the testing time down | 14:42 |
| straycat | We were planning to drop workspaces too I thought | 14:46 |
| straycat | I'm not sure I understand "users can understand and diagnose the cache naming scheme" | 14:47 |
| richard_maw | $SHA.chunk.name currently | 14:48 |
| rjek | chunk.name.$SHA would be better for tab-completion :) | 14:48 |
| richard_maw | or a directory tree | 14:48 |
| Kinnison | tbf, humans shouldn't be interacting with the cache | 14:48 |
| Kinnison | that they do, is an abstraction leak | 14:49 |
| richard_maw | paulsherwood has proposed "$name|${hash}.cache" | 14:49 |
| * Kinnison dislikes filenames with shell metacharacters in | 14:49 | |
| * richard_maw fails to see how this is better than "${hash}.chunk.${name}" | 14:49 | |
| straycat | I think we tend to interact with the cache more than we would because we've ended up doing things that cause the cache keys to change on us in unexpected ways. | 14:51 |
| Kinnison | I think we interact with it more than we should because we lack some commands, and we leak artifact ids into standard logging | 14:52 |
| straycat | Do you think it would be nice to have a command that gave you the cache status of a chunk? | 14:53 |
| Kinnison | No | 14:53 |
| Kinnison | But a command which streamed you the chunk artifact contents as a tarball would be good | 14:53 |
| Kinnison | Ditto for systems etc | 14:54 |
| * straycat nods | 14:54 | |
| ssam2 | since we rebuild more is needed, users will always be curious about the cache | 14:54 |
| Kinnison | since people sometimes just want to poke at it and say "Did it include the files I wanted?" | 14:54 |
| ssam2 | *more than | 14:54 |
| Kinnison | ssam2: s/needed/commonly expected/ | 14:54 |
| Kinnison | ssam2: if we rebuild more than is needed, we're doing it wrong | 14:54 |
| ssam2 | ok, we're doing it wrong | 14:54 |
| ssam2 | changing README.txt in gcc.git shouldn't require me to rebuild the whole operating system | 14:55 |
| richard_maw | yes, but I'm not convinced ABI manifests are feasible | 14:55 |
| Kinnison | ssam2: So you say -- but what if it *does* have an effect | 14:55 |
| richard_maw | *that* would be the game changer for rebuilds | 14:55 |
| Kinnison | ssam2: there's little we can algorithmically do for that | 14:55 |
| ssam2 | our build process may be the best available compromise | 14:55 |
| ssam2 | but it's always going to make users confused about why things were rebuilt and not cached. I don't think we can pretend that the caching is "magic" | 14:56 |
| Kinnison | richard_maw: aye, it is certainly hard to see how they might be tractable | 14:56 |
| *** violeta_ [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 14:59 | |
| richard_maw | the best I think we could get is to build-depend on an abi manifest, and if we've got anything of an older ABI manifest, we can build against that, rather than having to build the new version of its dependency first | 14:59 |
| richard_maw | but we'd still need to build the new version, and fail the build if after we've built it, it turns out not to have the right ABI | 14:59 |
| Kinnison | Perhaps | 14:59 |
| Kinnison | Constructing the manifest, and comparing them, are the two big things to work out | 15:00 |
| Kinnison | However, perhaps we've overcomplicated things again | 15:00 |
| Kinnison | I don't know for sure | 15:00 |
| richard_maw | plus, you _need_ to be able to extend it to arbitrary chunks, rather than just C, so we'd need new tooling | 15:00 |
| richard_maw | and not everything _has_ an ABI | 15:01 |
| richard_maw | the best fallback would probably be to hash everything in DESTDIR in a stable order | 15:01 |
| Kinnison | mmm | 15:02 |
| Kinnison | it's hard | 15:02 |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:06 | |
| *** violeta_ [~violeta@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:14 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 15:32 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:40 | |
| rdale | is it possible to build baserock for arm in a chroot? | 15:55 |
| *** tiagogomes [~tiagogome@213.15.255.100] has quit [Ping timeout: 240 seconds] | 15:55 | |
| richard_maw | if you have an arm device to build it on | 15:55 |
| rdale | yes | 15:55 |
| doffm | rdale: A chroot on an X86 machine? Not as far as i'm aware. There is no cross compile currently. | 15:55 |
| rdale | no a chroot on an arm based laptop | 15:56 |
| richard_maw | it should be possible if your kernel is recent enough and has mount and network namespaces enabled | 15:56 |
| pedroalvarez | is there any easy test to check that? | 15:58 |
| rdale | it has linux 3.8.11 on it | 15:58 |
| Kinnison | rdale: I regularly use a baserock chroot on x86_64 to use an armv7lhf distbuild cluster | 15:58 |
| rdale | it looks like chrome os uses network namespaces itself and so they must be in the kernel and the chros shell has a mount command in it | 16:08 |
| richard_maw | it stands a chance then. How much storage do you have available? | 16:11 |
| rdale | not much in the laptop itself, and so i'm formatting a 16gb usb stick in ext4 | 16:15 |
| pedroalvarez | rdale: any chance you can get a bigger thingy to use as storage? | 16:16 |
| rdale | yes, i could - is 16 gb enough to see if it works or not? | 16:17 |
| pedroalvarez | I think is enough to see if it works, yes. | 16:18 |
| pedroalvarez | we didn't create a tarball release of armv7lhf on the latest release | 16:19 |
| pedroalvarez | but is would be possible to extract the rootfs from the jetson image | 16:20 |
| Krin | if you need more storage rdale , the jets i was using previusly was packaged away again with a SSDD | 16:28 |
| Krin | s/jets/jetson | 16:28 |
| rdale | ok, so i would copy the rootfs from that into the chroot then? | 16:29 |
| pedroalvarez | we have tools to make easier the use of baserock in a chroot, and I think that these tools use tarballs | 16:32 |
| pedroalvarez | not sure though | 16:32 |
| Kinnison | They do | 16:32 |
| Kinnison | they expect chroot systems built and deployed as tarballs | 16:32 |
| pedroalvarez | so, if he creates a tar file with the rootfs extracted, he can use the tools? | 16:33 |
| pedroalvarez | btw, these tools are explained here: http://wiki.baserock.org/guides/chroot/ | 16:33 |
| Kinnison | probably, yes | 16:34 |
| Kinnison | Note, those tools expect schroot to be available | 16:34 |
| pedroalvarez | Kinnison: yup, that is noted in the wiki page I've linked | 16:34 |
| Kinnison | cool | 16:34 |
| * Kinnison crawls back under his rock ;-) | 16:35 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:36 | |
| *** vmeson [~quassel@128.224.252.2] has quit [Ping timeout: 240 seconds] | 16:39 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 16:45 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:16 | |
| *** thecorconian [~thecorcon@136.1.1.104] has joined #baserock | 17:19 | |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 17:33 | |
| *** rdale [~quassel@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 17:37 | |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:47 | |
| *** vmeson [~quassel@128.224.252.2] has joined #baserock | 18:04 | |
| *** thecorconian [~thecorcon@136.1.1.104] has quit [Ping timeout: 260 seconds] | 18:49 | |
| *** dutch_ [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 18:57 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Read error: Connection reset by peer] | 21:02 | |
| *** wikicat [~wikicat@ec2-54-77-166-165.eu-west-1.compute.amazonaws.com] has quit [Remote host closed the connection] | 22:21 | |
| *** wikicat [~wikicat@ec2-54-77-166-165.eu-west-1.compute.amazonaws.com] has joined #baserock | 22:21 | |
| *** rjek [~rjek@gateway/shell/pepperfish/x-ngxsjnmkijdsfmse] has quit [Ping timeout: 258 seconds] | 22:24 | |
| *** rjek [~rjek@gateway/shell/pepperfish/x-rjmkpdzfhqiuguqz] has joined #baserock | 22:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!