| *** De|ta [~arc@195.242.156.171] has quit [Ping timeout: 264 seconds] | 00:15 | |
| *** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 245 seconds] | 00:16 | |
| *** De|ta [~arc@195.242.156.171] has joined #baserock | 00:16 | |
| *** br_logger [~ubuntu@85.199.252.189] has quit [Ping timeout: 245 seconds] | 00:16 | |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 245 seconds] | 00:16 | |
| *** br_logger [~ubuntu@85.199.252.189] has joined #baserock | 00:16 | |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:16 | |
| *** SotK [~adamcoldr@access.ducie-dc1.codethink.co.uk] has joined #baserock | 00:16 | |
| *** rdale [~quassel@196.Red-79-153-62.dynamicIP.rima-tde.net] has joined #baserock | 01:10 | |
| *** rdale_ [~quassel@200.Red-83-59-206.dynamicIP.rima-tde.net] has quit [Ping timeout: 264 seconds] | 01:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:28 | |
| *** petefoth [~petefoth@host-92-25-64-58.as13285.net] has joined #baserock | 06:34 | |
| *** petefoth [~petefoth@host-92-25-64-58.as13285.net] has quit [Quit: petefoth] | 07:03 | |
| *** petefoth [~petefoth@host-92-25-64-58.as13285.net] has joined #baserock | 07:05 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:06 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 08:31 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:34 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:02 | |
| paulsher1ood | franred: one email would have been enough :) | 09:06 |
|---|---|---|
| franred | paulsher1ood, true, Im from the old school and use to remark all the errors, I will send only one next time | 09:08 |
| paulsher1ood | :-) | 09:12 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:46 | |
| Mode #baserock +v ssam2 by ChanServ | 09:46 | |
| ssam2 | could anyone cast a 'yes or no' vote on my 'morph: Error message improvements' patch series please? | 10:09 |
| ssam2 | it seems to be getting various eyes but nobody dares give a final +1 or -1 | 10:09 |
| ssam2 | Thanks Krin for reviewing it by the way. Maybe you could be a bit more confident and give it a +1 :) | 10:11 |
| * Kinnison has cast an eye over it, agrees with straycat and richard_maw and gives you a conditional +1 on those cleanups | 10:11 | |
| ssam2 | ok, thanks | 10:11 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:12 | |
| Kinnison | In general, I approve of improving messages | 10:12 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:27 | |
| *** rdale_ [~quassel@117.Red-83-49-223.dynamicIP.rima-tde.net] has joined #baserock | 10:35 | |
| *** rdale [~quassel@196.Red-79-153-62.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 10:36 | |
| Krin | hey all, if anyone has the time, could i have a second reviewer on the zookeeper work? | 10:51 |
| Krin | as added incentive for anyone in the CT building, I will attempt to do the shuffle when I leave today for everyone's amusement if it gets a second reviewer (has a feeling he's going to regret saying that as it's a long way from his desk to the door and the shuffle is not a very efficient movement) | 10:53 |
| Kinnison | is it as bad as concertina motion for snakes? | 10:54 |
| Krin | roughly. only on foot is involved in moving across the surface | 10:55 |
| Kinnison | oh my | 10:56 |
| radiofree | does anyone know how i would fix this http://i.imgur.com/s0wJIgD.png | 10:57 |
| radiofree | genivi baseline image, looks fine on a devel image | 10:57 |
| Kinnison | looks like a terminal issue | 10:58 |
| Kinnison | what is TERM set to? | 10:58 |
| radiofree | xterm | 10:58 |
| radiofree | i don't have the tools stratum on a genivi image, if that makes a difference? | 10:59 |
| radiofree | this is what it looks like when i reboot into factory http://i.imgur.com/C2M7Hj0.png | 11:00 |
| Kinnison | might be a different pager? | 11:00 |
| radiofree | i suppose it's a minor issue, since you're not really supposed to be using a genivi image as a development system anyway | 11:01 |
| radiofree | i'll try adding the tools to see if that fixes it | 11:02 |
| pedroalvarez | radiofree: genivi images doesn't have 'less' I believe | 11:19 |
| *** rdale [~quassel@97.Red-81-35-54.dynamicIP.rima-tde.net] has joined #baserock | 11:38 | |
| *** rdale_ [~quassel@117.Red-83-49-223.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 11:40 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 11:42 | |
| ssam2 | Krin: looking at the 'baserock/mikesmith/zookeeper' branch of definitions, it looks like you didn't squash the fix you did into the previous commit | 11:53 |
| ssam2 | not everyone agrees that this is needed, but it does make things neater, and Pedro did say "+1 Assuming that the git history is not "commits-of-first-patch-series and | 11:53 |
| ssam2 | commits-of-fixes", and that the fixes are squashed in the first commits." | 11:53 |
| Krin | no, i have not ssam2 i was intending to squish it ata merge | 11:53 |
| ssam2 | right | 11:53 |
| Krin | i thought that during review it may be better to leave a trail of what has been done to fix and address concerns raised so far | 11:54 |
| ssam2 | yes, not a bad plan | 11:55 |
| ssam2 | i'll continue reviewing then :) | 11:55 |
| * Krin realises he is likely going to have to shuffle out of the office today, starts actually looking at his rout out and if it is safe to do so | 11:56 | |
| pedroalvarez | I'll record it a publish it :) | 11:58 |
| * Krin whimpers | 11:59 | |
| Kinnison | pedroalvarez: I think you have to buy a boy lunch before you're allowed to do that kind of thing | 12:01 |
| Krin | in addition, i'm not a very good shuffler. so it would only be worth publishing for humor :P | 12:02 |
| Krin | and if you are looking through the branch ssam2, the most recent is baserock/mikesmith/zookeeper-for-review-v3 | 12:03 |
| ssam2 | ah OK | 12:04 |
| ssam2 | I have some comments by the way, you may yet be saved the shuffle ;) | 12:05 |
| Krin | :) | 12:05 |
| ssam2 | oh, actually seems they are addressed in baserock/mikesmith/zookeeper-for-review-v3 already | 12:05 |
| Krin | :( | 12:05 |
| ssam2 | shuffle it is. | 12:06 |
| pedroalvarez | Krin: you should be happy! | 12:06 |
| Krin | damn my efficiancey | 12:06 |
| petefoth | Krin: not to mention your efficiency ;) | 12:06 |
| Krin | we dont speak of that petefoth :P | 12:07 |
| Krin | right, now comes the bit where i have to remember how to merge/squish | 12:09 |
| petefoth | `git rebase -i master` ? | 12:12 |
| Krin | yup :) | 12:12 |
| jmacs | Is there a list of environment variables available in chunks anywhere? $DESTDIR, etc | 12:16 |
| jmacs | ? | 12:17 |
| radiofree | i think the morph log might print into about them? | 12:17 |
| radiofree | e.g http://fpaste.org/160909/18905125/ | 12:18 |
| ssam2 | I think morph.log is the best place to look | 12:18 |
| ssam2 | 'man morph' also has a list | 12:19 |
| ssam2 | with documentation! | 12:19 |
| ssam2 | but it may be out of date :) | 12:19 |
| ssam2 | looks ok to me though | 12:19 |
| jmacs | "man morph" doesn't mention DESTDIR, so it can't be a complete list | 12:20 |
| ssam2 | hmm, true. I *think* that's the only one missing | 12:20 |
| radiofree | PREFIX | 12:20 |
| ssam2 | oh yeah, that too | 12:21 |
| ssam2 | the two main ones ! | 12:21 |
| jmacs | I was hoping for something like $VERSION, although I know we don't like Baserock version numbers | 12:25 |
| ssam2 | what do you need it for ? | 12:25 |
| ssam2 | I often miss version numbers. | 12:25 |
| jmacs | It's one of the fields in /etc/lsb-release, which Chef checks to determine the distro type. | 12:26 |
| jmacs | I *may* be able to get away without it though. | 12:26 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 12:26 | |
| ssam2 | oh, so you want a way of getting the Baserock version into /etc/lsb-release ? | 12:26 |
| jmacs | Yes | 12:26 |
| ssam2 | getting the SHA1 of definitions in there would be cool, but it might need to be Morph itself that did that ... | 12:26 |
| ssam2 | `morph deploy` already knows the SHA1 of definitions (and writes the output of `git describe` to /baserock/deployment.meta`) , but it doesn't pass that to configure extensions | 12:27 |
| ssam2 | wouldn't be too hard to make `morph deploy` set something like DEFINITIONS_SHA1 in the environment for configure and write extension though ... | 12:28 |
| jmacs | I'm sure I can figure something out if it is necessary | 12:28 |
| ssam2 | one of the many little tweaks I'd like to do would be make /etc/os-release contain more info than just "Baserock = Baserock (baserock)" | 12:29 |
| Zara_ | haha | 12:30 |
| Krin | damnit history! let me re-write you! | 12:31 |
| Krin | should this be being squished so that i shows all of it as one big commit before pushing the branch into master? | 12:32 |
| ssam2 | I don't know | 12:32 |
| ssam2 | in your case, I think so yes | 12:33 |
| Krin | well that will make life easyer :) | 12:33 |
| ssam2 | in general, you want each commit in a branch to be one change | 12:33 |
| ssam2 | so if there are 4 commits that all say "make output blue", squash them all together | 12:33 |
| ssam2 | if there are 4 that do different things, leave them separate | 12:33 |
| ssam2 | maybe you want two, one that adds the strata and one that adds the example systems. But it's not super important here. | 12:34 |
| jmacs | Can I have a chunk which has no repo/ref? I want to run my lsb chunk which only has install-commands to write a file to /etc/lsb-release. Am I going about this the right way? | 12:35 |
| ssam2 | you can't have a chunk with no repo/ref (although it might be a nice feature) | 12:36 |
| ssam2 | you can use 'repo: baserock:baserock/definitions' or something as a hack | 12:36 |
| ssam2 | I think configure-extension might be better for adding /etc/lsb-release | 12:36 |
| jmacs | Certainly possible to do it with a configure extension, but then it's specified in the system definition, rather than in chef.morph where I think it belongs | 12:37 |
| ssam2 | I think in future we should add system-integration commands for strata | 12:38 |
| ssam2 | maybe you could add it to 'integration-commands' for the chef chunk or something for now? | 12:38 |
| ssam2 | (grep definitions.git for some examples of 'integration-commands') | 12:39 |
| jmacs | ssam2: Will do, thanks | 12:39 |
| ssam2 | sorry, the field is system-integration | 12:39 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 12:46 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 13:54 | |
| *** franred [~franred@37.205.56.35] has joined #baserock | 14:18 | |
| franred | hi folks, do we have Django lorried? I though that paulsher1ood sent a patch to create a chunck for it time ago, unless was just an attempt in a pastebin (I can't find the mail with the patch) | 14:19 |
| pedroalvarez | it is not lorried afaik | 14:20 |
| pedroalvarez | franred: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/pedroalvarez/django | 14:21 |
| pedroalvarez | franred: That was my attempt to create a chunk for it | 14:21 |
| franred | ummm, ok, I need to create a stratum for it for horizon, because there are more django plugins/ packages needed for horizon | 14:23 |
| franred | so I will send the patch to create the stratum and the lorry soon | 14:23 |
| franred | pedroalvarez, ^^ | 14:23 |
| franred | pedroalvarez, also thanks for the chunk morphology :) | 14:23 |
| pedroalvarez | it was really straightforward | 14:24 |
| pedroalvarez | I expected it to be more complex | 14:24 |
| pedroalvarez | if horizon needs django + django plugins, makes sense to me to create a django stratum to put everything | 14:25 |
| ssam2 | yeah, a django stratum would be ace | 14:29 |
| Kinnison | django has a *lot* of optional dependencies. Getting the balance right will be hard but useful | 14:34 |
| * Kinnison likes django and would like to see it available for Baserock though | 14:34 | |
| CTtpollard | django stratum +1 | 14:35 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 14:37 | |
| ssam2 | yeah, the strata model will be a pain for Django | 14:38 |
| ssam2 | I guess most of the dependencies are probably small and quick to build though | 14:39 |
| Kinnison | At least until we have conditional behaviour | 14:39 |
| Kinnison | ssam2: it's things like the pgsql dependencies are only useful if you have postgres (and only buildable with it too) | 14:39 |
| ssam2 | ah, yes | 14:39 |
| Kinnison | sqlite we can obviously build always given cpython build-deps on it | 14:40 |
| Kinnison | but there's also mariadb | 14:40 |
| Kinnison | and a horde of others | 14:40 |
| ssam2 | might be better for django-pgsql to go in the stratum with each app that needs it, in that case | 14:41 |
| Kinnison | perhaps | 14:41 |
| ssam2 | until we can think of a better way | 14:41 |
| franred | aham, I will have a look **carefully** | 14:44 |
| *** franred [~franred@37.205.56.35] has quit [Quit: Leaving] | 14:47 | |
| pdar | I was looking at updating the wiki to inform people unpetrify-ref is for. Would http://wiki.baserock.org/Morph/morphology-files/ be the right place to add a sentance about it? | 14:54 |
| rdale | 'unpetrify-ref' has got to be the most obscure name for whatever it is it means | 15:00 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:01 | |
| bashrc | rdale: +1 | 15:02 |
| pdar | unpetrify isn't overly informative but ref seems relevant | 15:03 |
| radiofree | rdale: :) | 15:04 |
| mwilliams_ct | pdar: perhaps something should be added to http://wiki.baserock.org/contributing/ about standards for refs and "unpetrify-refs" | 15:04 |
| rdale | everyone else uses 'freeze' instead of 'petrify' afaik | 15:05 |
| Kinnison | the name 'unpetrify-ref' is hysterical raisins | 15:06 |
| tlsa | maybe 'frozen-ref' and 'thawed-ref' would be better | 15:21 |
| paulsher1ood | i think freeze is mainly a ruby term, not 'everyone' - and in that community freeze iirc means something else, not to do with refs? | 15:25 |
| paulsher1ood | http://wiki.dreamhost.com/Freezing_Gems | 15:25 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:28 | |
| rdale | interesting - i don't think i found 'freeze' more familiar than 'petrifiy' because of my ruby background. i need to go and find some other uses of 'freeze' as a metaphor | 15:28 |
| Kinnison | Really it should be SHA1 and landing-ref | 15:29 |
| Kinnison | and SHA1 should always be a SHA1 | 15:29 |
| Kinnison | and then perhaps we can move it out of the primary definitions into a side file | 15:29 |
| paulsher1ood | Kinnison: i've been experimenting with that side file idea. would you be averse to the SHA1 being the tree in all cases? is there some reason for it not to be? | 15:31 |
| paulsher1ood | (tree as opposed to commit... iirc there was some debate...) | 15:32 |
| Kinnison | You can't check if a tree SHA is anchored | 15:33 |
| Kinnison | so it's much less useful | 15:33 |
| Kinnison | I'd rather have the commit SHA, and a separate cache for the tree SHA | 15:33 |
| rdale | what is a 'side file'? | 15:34 |
| Kinnison | a file "on the side" i.e. not in the definitions you typically interact with, but still in the definitions repo | 15:34 |
| * paulsher1ood googles 'git anchor' but can't discover what Kinnison means | 15:35 | |
| Kinnison | the term 'anchor' relates to garbage collection | 15:36 |
| Kinnison | does that help? | 15:36 |
| paulsher1ood | i'm confused - maybe i'm misunderstanding the idea. assuming (in a world with side files) ref: is a branch/tag, and tree: is what that resolves to, how could a tree not be anchored? | 15:47 |
| Kinnison | My point is, it's easy to ask git "is this SHA1 anchored in this ref" | 15:48 |
| Kinnison | it's much harder to ask "is this tree anchored in this red" | 15:48 |
| rdale | what is 'red'? | 15:49 |
| Kinnison | ref | 15:49 |
| * Kinnison mistyped | 15:49 | |
| rdale | ah :) | 15:49 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 15:56 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 15:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:56 | |
| pdar | Another question regarding the same wiki page. Is the 'morphology' field for strata ever used? I've never encountered it and I couldnt find an instance of it in strata/* | 15:57 |
| pdar | of my definition | 15:58 |
| pdar | s | 15:58 |
| radiofree | is that the same as the morph field? | 16:00 |
| radiofree | documentation should probably be added for "morph" filed, i think the morphology field is obsolete now (i seem to remember it being used when the name of the morph file didn't match the name of the chunck) | 16:02 |
| radiofree | when morph files were in the git repos and not definitions | 16:02 |
| radiofree | e.g chunk linux might use morphology: linux-foo-bar-arch.morph | 16:02 |
| radiofree | though i may be completely wrong about that | 16:03 |
| Kinnison | naah, it was always morph: | 16:03 |
| pdar | hmm if its obselete I might remove that line then | 16:06 |
| radiofree | pdar: it's not obsolete, it should be "morph", but perhaps the documentation should be updated to reflect chunks-in-definitions | 16:07 |
| pdar | radiofree: ahh, "morph:" is used a whole bunch | 16:11 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:51 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:00 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:40 | |
| pedroalvarez | great, took to me 15 minutes to perform an on-hardware deployment using morph :) | 17:48 |
| pedroalvarez | I'm going to publish a document with instructions about how to do it | 17:49 |
| pedroalvarez | But before that I'll read it again, I'm sure I can improve it a bit | 17:49 |
| persia | On use of /etc/lsb-release in Baserock: I believe this file may have a version, but needs to be populated by the Baserock user, and that we probably don't want to have a default version upstream (because people won't remember to change it, whilst changing any number of sha1s). | 17:52 |
| pedroalvarez | that makes sense to me | 17:53 |
| persia | On the use of "landing-ref" to replace "unpetrify-ref": This assumes that every ref used is anchored, which to my knowledge is the only place this restriction is imposed in Baserock. Can we just drop it, and let users do whatever they want, anchoring or not anchoring as they find convenient (perhaps with a note that if they fail to anchor, and run `git gc`, they may lose the ref) | 17:54 |
| persia | I expect people will typically want to use branch refs during development, switching to sha1s when they publish: having two fields makes this confusing. | 17:55 |
| radiofree | it's a lot easier to see the branch/ref name when you're looking through morph files though | 17:56 |
| persia | In the case where someone wants to edit, they should create a new feature branch from the provided sha1, and land that in a place that depends on what they are doing (and may be entirely unrelated to the thoughts of the person who created the commit from which they are branching) | 17:56 |
| persia | radiofree: Yes, but why do you care? | 17:56 |
| radiofree | rather than some sha that you then have to translate into "oh it's using version 217 of systemd" | 17:57 |
| radiofree | persia: so you can quickly tell what version of something is being built? | 17:57 |
| persia | That trick happens to work for systemd, but not for many other things. | 17:57 |
| persia | As discussed many times previously, we need to put more effort into the documentation and usability of the tooling that currently does the translation from refs to versions. | 17:57 |
| radiofree | well only because we have a load of baserock/morph things still there | 17:57 |
| persia | Also because lots of upstreams don't organise their repos that way. | 17:58 |
| radiofree | generally for new things that have been added the unpetrify-ref with be something like "v3.3.9" (procps-ng) | 17:58 |
| persia | There is *an entirely different* tool that is supposed to provide the version numbers. | 17:58 |
| radiofree | qt5 for example | 17:58 |
| persia | And we really ought use that, rather than trying to assert that there is a meaningful relation between refs and versions in repositories controlled by people not us. | 17:58 |
| radiofree | i can take a look at that startum and see instantly that it's version 5.3.2 | 17:58 |
| radiofree | what a pain in the arse it would be to have to look up 05670f586ffe05425b7542a27fcca31bddf231aa | 17:59 |
| persia | Sure, but if you are interested in versions, why don't you use the tool already written to provide version number information? | 17:59 |
| radiofree | i'd prefer keeping stratum files human-readable rather than have to use yet another tool/command to get that info | 17:59 |
| radiofree | why on earth would i want to do that? | 18:00 |
| persia | I don't want the sha1s in the stratum files anyway :) | 18:00 |
| radiofree | "Oh i'm looking at this stratum file in vim, let me exit and run some other tool to find out what version of qt we're using" | 18:00 |
| jmacs | Note to self: adding a chunk to core causes a full rebuild | 18:00 |
| persia | jmacs: If you find that unpleasing, avoid adjusting build-essential :) | 18:00 |
| pedroalvarez | jmacs: at least you don't have to rebuild gcc | 18:01 |
| jmacs | True | 18:01 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:01 | |
| *** petefoth [~petefoth@host-92-25-64-58.as13285.net] has quit [Quit: petefoth] | 18:03 | |
| jmacs | Hmm, but if I put my sgdisk chunk into the more appropriate place, ceph-service.morph, it says its build dependency (util-linux) isn't defined. Surely everything depends on core? | 18:04 |
| pedroalvarez | no, not everything | 18:04 |
| persia | radiofree: Thinking about it, my desire to remove the refs from the stratum files entirely affects your described use case as much as my desire not to use two refs. | 18:04 |
| persia | What is the use case that means you care which version of of something is described at the time you are editing the stratum file? | 18:05 |
| radiofree | personally i'd rather you remove the sha than the branch name :) | 18:05 |
| persia | I want to remove all refs entirely. | 18:05 |
| pedroalvarez | jmacs: you can add an explicit build-depend entry in the stratum that you want to include sgdisk | 18:05 |
| jmacs | Tried that - I added a build-depends for the stratum (either strata/core.morph or strata/core/util-linux.morph, neither works) | 18:07 |
| pedroalvarez | then I don't expect it to work when adding it to core.morph. | 18:08 |
| pedroalvarez | :/ | 18:08 |
| jmacs | It is just because util-linux happens to be defined in core as well? | 18:08 |
| pedroalvarez | If you add sgdisk to core, and put util-linux as a build dependency should be (almost) the same as adding sgdisk in a different stratum depending on core | 18:10 |
| pedroalvarez | jmacs: you can try to add it to core, though. It will rebuld everything but starting from sgdisk, so you can see if that works | 18:10 |
| jmacs | Yep, I'm going to put it back in core and leave it to build overnight | 18:11 |
| persia | Adding things like this to non-core ought be less complicated. | 18:11 |
| persia | (to avoid the overnight-build effect) | 18:11 |
| pedroalvarez | jmacs: if that works I think you are doing something wrong when trying to add core.morph as a build-dependency | 18:15 |
| jmacs | Quite possibly. | 18:16 |
| pedroalvarez | as an example: this is how I'd add core as a dependency in the installer-utils stratum http://paste.baserock.org/otosuwesim | 18:19 |
| jmacs | Looks like what I was doing | 18:20 |
| pedroalvarez | Published: http://wiki.baserock.org/guides/deploy-to-hardware/ | 18:47 |
| pedroalvarez | I'll try to improve it tomorrow a bit more | 18:47 |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 18:51 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 18:51 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:51 | |
| persia | pedroalvarez: Your guide assumes Debian: is it possible to do this with only Baserock? | 19:10 |
| *** rdale [~quassel@97.Red-81-35-54.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 19:57 | |
| *** rdale [~quassel@77.Red-2-138-206.dynamicIP.rima-tde.net] has joined #baserock | 19:58 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:10 | |
| *** rdale_ [~quassel@147.Red-79-146-1.dynamicIP.rima-tde.net] has joined #baserock | 20:21 | |
| *** rdale [~quassel@77.Red-2-138-206.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:21 | |
| *** rdale [~quassel@206.red-80-26-163.adsl.dynamic.ccgg.telefonica.net] has joined #baserock | 20:23 | |
| *** rdale_ [~quassel@147.Red-79-146-1.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 20:23 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 20:25 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 20:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:25 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:25 | |
| *** rdale_ [~quassel@11.Red-80-39-246.dynamicIP.rima-tde.net] has joined #baserock | 20:28 | |
| *** rdale__ [~quassel@80.30.109.144] has joined #baserock | 20:30 | |
| *** rdale [~quassel@206.red-80-26-163.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 264 seconds] | 20:32 | |
| *** rdale_ [~quassel@11.Red-80-39-246.dynamicIP.rima-tde.net] has quit [Ping timeout: 245 seconds] | 20:33 | |
| *** rdale__ [~quassel@80.30.109.144] has quit [Ping timeout: 255 seconds] | 20:35 | |
| *** rdale [~quassel@30.Red-80-39-246.dynamicIP.rima-tde.net] has joined #baserock | 20:36 | |
| *** rdale [~quassel@30.Red-80-39-246.dynamicIP.rima-tde.net] has quit [Ping timeout: 265 seconds] | 20:41 | |
| *** rdale [~quassel@16.Red-88-21-208.staticIP.rima-tde.net] has joined #baserock | 20:46 | |
| *** rdale_ [~quassel@10.Red-80-39-246.dynamicIP.rima-tde.net] has joined #baserock | 20:48 | |
| *** rdale [~quassel@16.Red-88-21-208.staticIP.rima-tde.net] has quit [Ping timeout: 250 seconds] | 20:51 | |
| *** rdale [~quassel@102.red-80-26-167.adsl.dynamic.ccgg.telefonica.net] has joined #baserock | 20:51 | |
| *** rdale_ [~quassel@10.Red-80-39-246.dynamicIP.rima-tde.net] has quit [Ping timeout: 250 seconds] | 20:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
