| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:17 | |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has joined #baserock | 06:40 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:22 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 07:24 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:24 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 07:59 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 08:41 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:55 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:58 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| Mode #baserock +v ssam2 by ChanServ | 09:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 09:24 | |
| pedroalvarez | persia: yeah, it does assume Debian. To do this only with Basserock I should have to be running baserock in my laptop | 09:57 |
|---|---|---|
| pedroalvarez | Or maybe just mention that the VM has to have a pre-vlanned interface and let the user fibgure out | 10:01 |
| pedroalvarez | I was going to test the 'spawn-vlan' mode of pxeboot.write, which creates a vlan interface in the VM, but I dobut it will work,. | 10:12 |
| pedroalvarez | Or maybe it will and I'm wrong assuming that | 10:12 |
| persia | I vaguely remember rumours of a USB install of Baserock. Do you know if that exists? Was it bootable USB? | 10:13 |
| persia | But if we don't have a reliable means of running Baserock on a laptop yet, then it is probably fine to assume Debian. | 10:14 |
| pedroalvarez | persia: I believe that deploying "clusters/installer-build-system-x86_64.morph" will generate a rawimage that you can dd to a USB to generate a bootable USB baserock installer | 10:15 |
| pedroalvarez | My previous attempt to do this in a laptop ended up in a kernel panic, I guess we have to enable hundreds of things in the kernel to support different laptops | 10:16 |
| persia | Indeed. Enabling all the right bits for proper hardware support can be tricky. | 10:16 |
| persia | So, while in an ideal world, the Baserock wiki would assume only Baserock, I don't think we can do that yet. | 10:17 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 10:18 | |
| pedroalvarez | If in my example I were deploying from a jetson, I could avoid the "Debian" bit | 10:18 |
| pedroalvarez | but you have to flash the jetson before :P | 10:19 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:20 | |
| persia | And deal with the cross-architecture nature of things, unless you can find armv7lhf hardware with a reliable BMC :) | 10:27 |
| pedroalvarez | actually, it is possible to cross-deploy! | 10:30 |
| pedroalvarez | I'm going to try a deployment from it :) | 10:32 |
| CTtpollard | could anyone point me in the direction of any documentation around the python importer tool? | 10:35 |
| pedroalvarez | CTtpollard: http://wiki.baserock.org/guides/import-tool-rubygems/ | 10:36 |
| petefoth | http://wiki.baserock.org/guides/import-tool-rubygems/ | 10:36 |
| persia | CTtpollard: Extra points for wiki gardening to make that more obviously python-related :) | 10:36 |
| petefoth | bah! too slow for pedroalvarez | 10:36 |
| pedroalvarez | oh, indeed, maybe the tutorial doesn't explain the python import | 10:37 |
| CTtpollard | :) | 10:37 |
| CTtpollard | I don't need it right now, just writing up a plan | 10:38 |
| CTtpollard | on the same note, has a system including tox been created to anyones knowledge, the system I want to build uses venv's | 10:40 |
| CTtpollard | or is the use of venv's not in keeping with Naserock | 10:41 |
| persia | I thought venvs were mostly used for development. In production, wouldn't one populate the true environment? | 10:41 |
| CTtpollard | *Baserock | 10:41 |
| CTtpollard | persia: Yes, but for a system still very much in development is having a venv more suited? | 10:45 |
| CTtpollard | the system being imported that is | 10:45 |
| * paulsher1ood is trying to persuade ssam2 to investigate bringing ostree into baserock in january... do we have any strong objections here ? this would be quite a big change | 10:45 | |
| Kinnison | To what end? | 10:46 |
| ssam2 | fast construction of staging areas and artifacts | 10:46 |
| Kinnison | Well, to be fair, construction of staging areas and artifacts is not currently that slow | 10:48 |
| * Kinnison thinks it'd help manage the size of caches more than improve speeds | 10:48 | |
| ssam2 | deployment is really slow | 10:48 |
| Kinnison | deployment *has* to copy | 10:48 |
| Kinnison | because it *has* to allow the configure extensions to make arbitrary changes | 10:48 |
| Kinnison | if ostree hardlinks then you'll have the same corruption issues we had before we realised that | 10:49 |
| * ssam2 tries to remember ostree works | 10:50 | |
| ssam2 | you're right, I think | 10:50 |
| ssam2 | *remember how | 10:50 |
| Kinnison | We had thoughts to improve deployment by removing one of the copy stages by use of a fuse or overlay fs | 10:50 |
| Kinnison | given modern kernels now have overlay support, perhaps it's time to look at that? | 10:51 |
| * Kinnison thinks ostree would be a good thing for managing the artifact cache, but it won't be a magical pill to speed up deployment | 10:51 | |
| ssam2 | would using overlayfs on top of a hardlink tree work ? | 10:52 |
| ssam2 | i've never used it | 10:52 |
| Kinnison | presumably it would, but to be sure would need testing | 10:53 |
| ssam2 | ok, cool | 10:53 |
| Kinnison | Also, currently we build system artifacts by copying, again because system integrations can arbitrarily alter the filesystem | 10:53 |
| Kinnison | so that'd be a candidate for speedups if you can get an overlayfs working | 10:54 |
| Kinnison | All this was discussed quite some time ago, I think liw proposed a fuse FS approach back before overlayfs made it into the kerne | 10:54 |
| Kinnison | +l | 10:54 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 11:08 | |
| jmacs | I'm still having trouble getting my sgdisk morph out of core.morph. Here's my diff: http://paste.baserock.org/obimumawej | 11:09 |
| jmacs | Still says "chunk sgdisk references its dependency util-linux before it is defined" | 11:09 |
| pedroalvarez | jmacs: aaah! so it wasn't failing to compile | 11:10 |
| jmacs | No | 11:10 |
| Kinnison | jmacs: does it? (reference util-linux before util-linux in the list of chunks?) | 11:11 |
| pedroalvarez | jmacs: the util-linux dependecy is implicit when you add the core dependecy | 11:11 |
| jmacs | Kinnison: util-linux isn't in ceph-service.morph; it's in core.morph | 11:11 |
| Kinnison | then remove the dependency from the chunk and ensure core.morph is in the build-depends for the ceph-service stratum | 11:12 |
| Kinnison | chunk-level build-depends are intra-stratum, not inter-stratum | 11:13 |
| Kinnison | you've done the latter (adding core.morph as a build-dep) so just do the former and it should build | 11:13 |
| Kinnison | :_) | 11:13 |
| jmacs | OK, that appears to be happier | 11:14 |
| Kinnison | coolio | 11:14 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:19 | |
| mauricemoss_ | hi, I'm wondering.. where is the right point to start integrating our chromebook in the baserock workflow? I booted from a USB HDD: Coreboot -> ChromiumOS Kernel partition (ext2) -> Baserock rootfs (btrfs) Unfortunately I don't see a possibility of using the normal Baserock structure http://fpaste.org/160590/18827081/ because the Kernel has to be signed with a special tool from Google (vbutil_kernel) together with a special par | 11:47 |
| mauricemoss_ | tition. Should I edit the deployment process to only deploy the rootfs or integrate vbutil_kernel as a lorry to do the Kernel signing in the deployment process? | 11:47 |
| mauricemoss_ | rough steps of what I did can be found here: https://admin.codethink.co.uk/wiki/index.php/Projects:CT189:Codethink_-_Bench/Chromebook#USB.2FSD_Boot | 11:49 |
| paulsher1ood | mauricemoss_: that's a private wiki | 11:50 |
| radiofree | mauricemoss_: for the most part it shouldn't matter | 11:50 |
| paulsher1ood | any chance you could make a video tutorial/demo if this? | 11:50 |
| radiofree | since you can set the ROOT_DEVICE to be your btrfs partition, and the upgrade procress will move files around internally there | 11:50 |
| radiofree | what you'll need to do, however, is change system-version-manager (part of tbdiff) to update the kernel args to point at the correct, new, subvolume | 11:50 |
| mauricemoss_ | paulsher1ood, oh.. I can add it later to the baserock wiki? | 11:51 |
| radiofree | is there some kind of boot menu file for the chrome bootloader? | 11:51 |
| mauricemoss_ | radiofree, nope it's the verified bootloader of google. you pass the kernel args with a file called kernel.flags | 11:52 |
| radiofree | and kernel.flags is on the ext2 partition? | 11:52 |
| mauricemoss_ | which vbutil_kernel then uses http://manpages.ubuntu.com/manpages/saucy/man1/vbutil_kernel.1.html | 11:52 |
| mauricemoss_ | yeah, it's build into a binary | 11:53 |
| radiofree | ah ok, so you can copy the kernel image with the new kernel args to the ext partition? | 11:53 |
| mauricemoss_ | exactly | 11:54 |
| radiofree | can you sign any kernel with that? | 11:54 |
| mauricemoss_ | but currently I have to do it manually in chromeOS or on my machine | 11:54 |
| mauricemoss_ | yep | 11:54 |
| radiofree | so i think what you'll have to do is just build the zImage as normal in baserock | 11:54 |
| mauricemoss_ | what do you mean? can you explain it more detailed? | 11:55 |
| radiofree | then in your deployment stage, have system-version-manager sign that kernel (with the correct new subvolume name pased as a kernel arg) | 11:55 |
| paulsher1ood | mauricemoss_: please feel free to update the baserock wiki with this info. but if i find any *secret* info in that, i'll be, er, *disappointed* | 11:55 |
| radiofree | and copy it over to the ext2 boot partition | 11:55 |
| pedroalvarez | radiofree: http://paste.baserock.org/ohaqoviser :/ | 11:55 |
| * paulsher1ood is grumpy again | 11:55 | |
| Kinnison | ruhroh | 11:55 |
| radiofree | pedroalvarez: don't use that script!! | 11:55 |
| pedroalvarez | why | 11:55 |
| pedroalvarez | which one should I use | 11:55 |
| radiofree | because it's obselete, use the one i sent to the list (https://gitlab.com/jamesthomas/baserock-flashing-tools/) | 11:56 |
| radiofree | you'll need a few things in your baserock system that i'm preparing a stratum for now | 11:56 |
| radiofree | however i can message you the details on how to set them up manually if you want | 11:56 |
| pedroalvarez | radiofree: it may be obsolete but we are still using it in the wiki :( | 11:57 |
| radiofree | yeah becaues the new one hasn't been approved yet | 11:57 |
| pedroalvarez | ooi, why obsolete? | 11:57 |
| radiofree | i'm working on it | 11:57 |
| radiofree | the old one (everything on one partition) results in a "fingers crossed this update is going to work" scenario | 11:57 |
| radiofree | the new way is to set BOOT_DEVICE=/dev/mmcblk0p1 and ROOT_DEVICE=/dev/mmcblk0p2 | 11:58 |
| radiofree | then use the new script to create an ext boot partition, which boots into the btrfs one | 11:58 |
| * paulsher1ood goes to see a moonshot server | 11:58 | |
| radiofree | flawless upgrades | 11:58 |
| ssam2 | radiofree: 'not yet approved' - is it sat on the mailing list waiting for review? | 11:59 |
| radiofree | there were comments i haven't got round to addressing yet | 11:59 |
| ssam2 | ah OK | 11:59 |
| pedroalvarez | radiofree: then am I be able to upgrade my board after flashing with this script? | 11:59 |
| pedroalvarez | s/am I/will I/ | 11:59 |
| radiofree | pedroalvarez: well in theory you can upgrade your board the old method | 11:59 |
| radiofree | in practice it's a bit hit-and-miss whether or not u-boot with the btrfs patches will be able to read the new extlinux.conf file | 12:00 |
| radiofree | with this new method upgrades work all the time | 12:00 |
| radiofree | i can prepare some instructions for you to try it out if you want | 12:01 |
| pedroalvarez | when you say "the old method" you mean that the new method is already merged and not compatible with this flashing script? | 12:01 |
| radiofree | the old method is not compatible with this script no, you'll have to redeploy your image with BOOT_DEVICE=/dev/mmcblk0p1 and ROOT_DEVICE=/dev/mmcbkl0p2 | 12:02 |
| radiofree | s/bkl/blk | 12:02 |
| radiofree | there's also the added benefit we can use completely open tools to do the flashing now | 12:02 |
| * pedroalvarez gives up | 12:05 | |
| radiofree | i can show you how to do it if you want | 12:07 |
| pedroalvarez | radiofree: just to dobule check that I've understood everything: If I try to upgrade the board flashed with the old script using 'morph upgrade' or 'cycle.sh' it wont work? | 12:10 |
| radiofree | pedroalvarez: morph upgrade and cycle.sh *might* work | 12:10 |
| radiofree | you've got... in my experience a 70/30 chance of it working | 12:11 |
| radiofree | 70% success, but other people might disagree with that... | 12:11 |
| pedroalvarez | radiofree: hehe :) ok | 12:11 |
| franred | :) | 12:11 |
| pedroalvarez | then I'll try that | 12:11 |
| persia | CTtpollard: I'd say so: if you do all the integration to make it work in a venv, you'll just have to do it all over again to not use a venv. | 12:24 |
| CTtpollard | persia: I can see the point in not using tox then | 12:26 |
| persia | On OSTree: there are some good ideas there, but I think the model morph is currently using is stronger (although it should be made faster). To the best of my knowledge, OSTree wants a reboot for each FS version it presents, or at least a full unmount/remount cycle (but I don't know the extent to which OSTree has been used in chroots) | 12:26 |
| CTtpollard | for my my needs | 12:26 |
| persia | CTtpollard: The advantage of Baserock is that it should be fairly quick to cause there to exist a system incorporating your latest changes. tox+venv provides that same functionality for a chroot. | 12:27 |
| persia | So it ought just be a matter of translating the tox/venv integration to definitions format. | 12:28 |
| persia | (although tox/venv stuff uses a lot of pip, often, making this a bit more of a rabbit hole) | 12:28 |
| CTtpollard | persia: yes I will have to do a lot of importing, especially *hopefully* of npm dependencies | 12:29 |
| CTtpollard | also if anybody knows anything around the package manager bower, that would be really helpful | 12:35 |
| jmacs | Is the output from 'morph build' logged anywhere? | 12:37 |
| radiofree | jmacs: /src/morph.log ? | 12:38 |
| jmacs | Yep, cheers | 12:38 |
| *** dabukalam [~quassel@ec2-54-69-244-150.us-west-2.compute.amazonaws.com] has quit [Quit: No Ping reply in 180 seconds.] | 12:45 | |
| *** dabukalam [~quassel@ec2-54-69-244-150.us-west-2.compute.amazonaws.com] has joined #baserock | 12:47 | |
| *** cosm [~Unknown@host-80-41-248-255.as13285.net] has quit [Ping timeout: 255 seconds] | 13:05 | |
| *** cosm [Unknown@gateway/vpn/mullvad/x-taupyptzbcbnmwro] has joined #baserock | 13:18 | |
| franred | do we prefer the repositories from github or openstack server when we lorry them? Im creating lorry files to lorry xstatic and xstatic-* packages for horizon | 13:24 |
| persia | git.openstack.org | 13:24 |
| franred | persia, ok | 13:24 |
| persia | Or rather, we prefer repositories from as far upstream as we can: in cases where OpenStack is upstream, we prefer git.openstack.org, in cases where OpenStack is mirroring, we prefer their source (which may be github) | 13:24 |
| franred | from: https://github.com/stackforge/xstatic-angular and https://git.openstack.org/cgit/stackforge/xstatic-angular/ look the same for me | 13:25 |
| persia | The rationale is that when one mirrors a git repository, the history of that repository can only be trusted as far as the last push, so the mirroring software may add spurious commits, remove commits, alter commits, etc. | 13:25 |
| franred | I imagine that he creates first on gihub and then they got mirrored from openstack | 13:26 |
| persia | The less mirroring that happens before lorry mirrors, the better, because that gives us more confidence in lorry's data, and any users of a lorry-populated mirror cannot trust any transactions beyond lorry except if they trust lorry (so we need to maximise trust of lorry). | 13:26 |
| persia | The existence of https://git.openstack.org/cgit/stackforge/xstatic-angular/commit/?id=7300bd88ba20368ef86c93428f78acac6f5d9c71 implies to me that the most recent commit went through OpenStack gerrit | 13:27 |
| persia | Actually, all commits except the initial import seem to have gone through OpenStack gerrit. | 13:28 |
| franred | cool, thanks persia :) | 13:29 |
| persia | Note that the code itself seems to just be a pip-compatible wrapper for Angular. If you don't need to process with pip, you might just want to use Angular.js 1.2.1 directly | 13:30 |
| persia | https://github.com/angular/angular.j | 13:30 |
| * persia is unhappy that xstatic-angular exists, and wishes that there was better coordination to land the pip-compatibility stuff upstream | 13:31 | |
| franred | persia, I know but these repos are dependencies for horizon: http://git.baserock.org/cgi-bin/cgit.cgi/delta/openstack/horizon.git/tree/requirements.txt?id=2014.2.1 | 13:31 |
| persia | Does horizon use pip in production? Can we not just use Angular directly? Is there some significant difference between Angular.js 1.2.1 and the wrapped version? | 13:32 |
| franred | there are some xstatic-* packages which horizon depends on - and I think they are just static compilation of these packages | 13:32 |
| persia | There may be reasons to propogate this particular dirty hack, but I'd like to know it was thought about before I reviewed a lorry for it :) | 13:33 |
| persia | Generally speaking, we strive for being as upstream as possible, and for avoiding importing compiled objects. I'm unsure of the right model here. | 13:34 |
| franred | persia, the reason is because they are dependencies for horizon and if they are not in the system horizon at compile time will complain | 13:34 |
| franred | I not sure if adding the real packages horizon will compile | 13:34 |
| persia | You might want to lorry the xstatic-* stuff, because it ought make your work faster if you need it, but I'd consider having lorried it a bug if it was committed upstream, and want to transition to raw integration of the real upstream. | 13:34 |
| franred | persia, I think I read that they replace the real packages for this ones because the amount of dependencies | 13:35 |
| persia | Yeah. Like I said, these packages shouldn't exist, and someone should have landed the setuptools stuff upstream so that one could `pip install angularjs` and get the static compilation of whatever version was on the pip mirror. | 13:35 |
| persia | I think they do it because they want to use `pip install` to fulfill dependencies, rather than anything else. | 13:36 |
| persia | But anyway, if you must lorry xstatic-angular, I believe github is the mirror and openstack is the upstream. | 13:36 |
| franred | aham, so you will suggest to use the real packages for this and not use this dirty hack | 13:36 |
| franred | persia, ^^ ? | 13:37 |
| persia | I think the right thing to do is to use the real packages, and preferably also to land the pip/setuptools integration stuff upstream so that the compiled blobs can be on pip mirrors. | 13:39 |
| persia | But I'm an idealist, and you may not actually want to do that to achieve your personal goals :) | 13:39 |
| persia | I suspect you can find two other people who will +1 a lorry from git.openstack.org for this, as it is a real repo, and the syntax isn't that fussy, and you claim it as a requirement for Horizon (and lots of folk want Horizon in baserock). | 13:40 |
| persia | And I'm not going to -1 it, because I'd rather get Horizon than do angular.js in the ideal manner. | 13:41 |
| franred | persia, I was wondering this when I've read about the static compilation, I can try to achive the goal without lorrying the repositories due they are git repos and after that look if I have time to achive the same goal with the real packages | 13:41 |
| persia | If you have time to do that, I think that would be ideal :) | 13:42 |
| franred | let's see what I can do ;) | 13:42 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 13:43 | |
| *** cosm [Unknown@gateway/vpn/mullvad/x-taupyptzbcbnmwro] has quit [Ping timeout: 250 seconds] | 13:46 | |
| *** cosm [~Unknown@host-80-41-248-255.as13285.net] has joined #baserock | 13:59 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 14:07 | |
| * pedroalvarez tries a hardware deployment from a jetson to avoid the macvtap thingy | 14:10 | |
| pedroalvarez | oopsie: http://paste.baserock.org/zemeyifiru | 14:17 |
| persia | heh | 14:19 |
| Kinnison | doh | 14:20 |
| pedroalvarez | so, it needs syslinux to become a pxe server | 14:21 |
| Kinnison | syslinux contains the files served over TFTP to the PXE client | 14:21 |
| Kinnison | Could you extract that from the system you're deploying? | 14:21 |
| persia | So it specifically needs to have syslinux for the target architecture, rather than the development architecture. | 14:21 |
| pedroalvarez | indeed, and if I'm deploying to (say) arm... | 14:22 |
| Kinnison | You're not going to be using PXE | 14:22 |
| Kinnison | since PXE is an x86 thing | 14:22 |
| radiofree | you don't need syslinux for that | 14:22 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:22 | |
| Mode #baserock +v ssam2 by ChanServ | 14:22 | |
| persia | Kinnison: What happened to the PXE interface that was added to u-boot a couple years ago? | 14:22 |
| Kinnison | persia: That may depend on uefi | 14:23 |
| Kinnison | Consider http://en.wikipedia.org/wiki/Preboot_Execution_Environment#Availability | 14:24 |
| persia | Ah, right. From that I think that it isn't appropriate to call the u-boot stuff "PXE", rather that there is a module for u-boot that can comprehend PXE-compatible instructions from the DHCP server to load images from a TFTP server and chainload them. | 14:26 |
| * Kinnison finds a lot of people saying 'PXE' when they mean TFTPboot (possibly with parsing a pxelinux.conf) | 14:27 | |
| * Kinnison finds this very sad-making | 14:27 | |
| pedroalvarez | hm.. | 14:28 |
| pedroalvarez | I think this does a tftpboot parsing a pxlinux.conf | 14:28 |
| persia | Kinnison: The main issue is Tpwpp is longer than PXE, and fails to contain any vowels. | 14:32 |
| Kinnison | I tend to call it 'tftpboot' | 14:33 |
| * pedroalvarez ponders adding a check for the '/usr/share/syslinux/pxelinux.0' file to pxeboot.check | 14:34 | |
| pedroalvarez | After copying pxelinux.0 to the host, it's working | 14:39 |
| pedroalvarez | and here we go, installing on hardware :) | 14:41 |
| persia | Directly? Deploying Baserock to hardware from Baserock on hardware? | 14:47 |
| pedroalvarez | from Baserock in a jetson which is baserock on hardware, yes | 14:47 |
| jmacs | I think I'm being thick but I can't figure this out - sgdisk doesn't have an install rule, just asks you to copy 'sgdisk' to /usr/bin - how do I get the proper directory in the staging area in install-commands? I thought cp sgdisk "$DESTDIR"/usr/bin would do it | 14:48 |
| pedroalvarez | jmacs: and it should | 14:48 |
| Kinnison | jmacs: - mkdir -p "$DESTDIR/$PREFIX/bin" | 14:48 |
| pedroalvarez | ah yes | 14:49 |
| pedroalvarez | important bit | 14:49 |
| Kinnison | jmacs: - install -m 0755 -o root -g root sgdisk "$DESTDIR/$PREFIX/bin/" | 14:49 |
| Kinnison | or similar | 14:49 |
| persia | http://sources.debian.net/src/gdisk/0.8.10-1/debian/rules/ suggests you may want to run 5 install commands | 14:50 |
| persia | But the last of these may be Debian-specific | 14:50 |
| jmacs | None of those work. It looks like $DESTDIR is "/sgdisk.inst/" | 14:51 |
| jmacs | install: cannot create regular file '/sgdisk.inst//usr/bin': No such file or directory | 14:52 |
| persia | You may need a -D | 14:52 |
| jmacs | -D fixed it. Is /sgdisk.inst/usr/bin really the correct destination? | 14:54 |
| Kinnison | sounds right | 14:54 |
| Kinnison | Since /CHUNKNAME.inst is the writable DESTDIR | 14:54 |
| jmacs | I thought it'd be going into /src/tmp/deploy/tmpbleugh/usr/bin - does that happen at deploy? | 14:55 |
| Kinnison | remember that path is within the linux-user-chroot for the chunkbuild | 14:55 |
| Kinnison | so it'll be /src/tmp/bleurghlyflsiufds/fds/fsd/fsa/CHUNKNAME.inst/... | 14:55 |
| Kinnison | from the real root | 14:55 |
| jmacs | aha | 14:56 |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has quit [Quit: Leaving] | 15:05 | |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has joined #baserock | 15:14 | |
| pedroalvarez | I have done these changes to explain how to do a on-harware deployment using baserock on-hardware: http://paste.baserock.org/uxeliyavaq.diff | 15:22 |
| jmacs | Still haven't got that install command right. There are other chunks - u-boot for example - which install to "$DESTDIR$PREFIX/bin/." | 15:23 |
| persia | +1 from me: extra points for "Doing the deployment from Baserock on hardware involves much less magic" | 15:23 |
| Kinnison | yeah the slash between destdir and prefix isn't really needed | 15:23 |
| jmacs | I'm getting an error while unpacking chunks now... | 15:25 |
| jmacs | ERROR: [Errno 21] Is a directory: '/src/tmp/staging/tmpxWdklr/ceph-service-x86_64-generic.inst/usr/bin' | 15:25 |
| jmacs | While unpacking the sgdisk chunk | 15:25 |
| pedroalvarez | maybe you need an slash at the end of the install command? | 15:26 |
| Kinnison | If you're using install -D then you need the destination filename (or perhaps the trailing slash) | 15:26 |
| Kinnison | hence I suggested a mkdir first | 15:26 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [] | 15:35 | |
| jmacs | built! Thanks Kinnison. | 15:36 |
| Kinnison | No probs, sorry I wasn't clear enough earlier | 15:37 |
| jmacs | You were, I just hadn't connected it to persia's advice | 15:39 |
| paulsher1ood | rdale: can you +1 the baserock-import tool, assuming you think it's somewhat useful? | 16:11 |
| rdale | yes ok | 16:13 |
| *** franred [~franred@213.37.90.178.dyn.user.ono.com] has quit [Quit: Leaving] | 16:20 | |
| ssam2 | thanks | 16:26 |
| paulsher1ood | me too, ssam2 - go ahead :) | 16:27 |
| ssam2 | cool, thanks | 16:28 |
| rdale | i was going to compose an email about my experiences with the import tool this afternoon because i thought i had pretty much was going to get one of our codething web apps ported. but i've got stuck, if i use ruby 2.0 the web app doesn't work, and if i try to use ruby 1.9 the gems don't build. that isn't an import tool problem though, but i haven't worked out what to do yet | 16:29 |
| ssam2 | argh | 16:30 |
| ssam2 | do all the gems fail, or just certain ones? | 16:30 |
| rdale | rake-compiler 0.9.3 won't build with the version of ruby gems in ruby 1.9 | 16:31 |
| ssam2 | right. :( | 16:31 |
| ssam2 | not that many things need rake-compiler that I remember... it'd be worth checking if you can use an older version of it | 16:31 |
| rdale | but if i go back to rake-compiler 0,8 it needs a gem called 'isolate' or something | 16:32 |
| rdale | racc needs rake-compiler | 16:32 |
| rdale | i forget what needs racc | 16:32 |
| ssam2 | should I update baserock-import to 764531201f99bf1d9c6dd451a212b741bfb6715e so we get the python importer as well ? | 16:33 |
| rdale | i think i would prefer to get the web app working with ruby 2.0, rather than go back to ruby 1.9 | 16:33 |
| ssam2 | rdale: makes sense | 16:33 |
| rdale | i don't think we have existing users of the import-tool who would not want to risk us updating, and so i would keep updating it while we dogfood it in ruby and python | 16:35 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:35 | |
| *** cosm [~Unknown@host-80-41-248-255.as13285.net] has quit [Ping timeout: 245 seconds] | 16:36 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 16:43 | |
| *** cosm [~Unknown@host-78-148-113-50.as13285.net] has joined #baserock | 16:51 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:53 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:55 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:59 | |
| paulsher1ood | anyone got any idea how to fix http://paste.baserock.org/osomuraxeb ? | 18:00 |
| paulsher1ood | jjardon, for example? | 18:01 |
| * paulsher1ood was just told by his better half to 'have fun', so is enjoying trying to build ostree | 18:01 | |
| radiofree | install e2p? | 18:02 |
| jjardon | paulsher1ood: you need the package that provides the e2p.pc pkg-config file | 18:02 |
| paulsher1ood | what is it? i think it's something to do with e2fsprogs, which is already done | 18:02 |
| jjardon | lets see | 18:02 |
| paulsher1ood | googling e2p didn't help me much | 18:03 |
| radiofree | ext3ipods | 18:04 |
| radiofree | Linux ext3fs with QoS extensions | 18:05 |
| radiofree | actually | 18:05 |
| radiofree | e2fsprogs | 18:05 |
| radiofree | so http://git.baserock.org/cgi-bin/cgit.cgi/delta/e2fsprogs.git/ | 18:05 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 18:05 | |
| paulsher1ood | http://paste.baserock.org/itojuworev | 18:06 |
| paulsher1ood | we already have e2fsprogs in tools, so i've got it as a build-depend. am thinking there may be some config i need to do | 18:06 |
| jjardon | yeah, should be part of e2fsprogs: http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/e2p/e2p.pc.in | 18:07 |
| radiofree | maybe you need to enable it in the config | 18:07 |
| radiofree | it's in our version http://git.baserock.org/cgi-bin/cgit.cgi/delta/e2fsprogs.git/tree/lib/e2p?h=baserock/morph | 18:07 |
| jjardon | no configuration option in http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/configure.in | 18:08 |
| jjardon | paulsher1ood: Do this output something in a baserock system? pkg-config --list | grep e2p | 18:09 |
| jjardon | sorry pkg-config --list-all | grep e2p | 18:09 |
| paulsher1ood | null | 18:09 |
| paulsher1ood | so i just add this to the config of e2fsprogs? | 18:10 |
| radiofree | no | 18:10 |
| radiofree | try -enable-elf-shlibs | 18:11 |
| radiofree | --enable-elf-shlibs | 18:11 |
| paulsher1ood | (as config in e2fsprogs) - same error | 18:15 |
| jjardon | maybe the problem is in the morph file. Can you try to compile it without any morph file at all? and see if e2p.pc is generated correctly | 18:16 |
| radiofree | yeah change the ref to v1.42.12 | 18:17 |
| paulsher1ood | i think it's already at that? | 18:18 |
| * paulsher1ood tries | 18:18 | |
| paulsher1ood | same error building ostree, for efs2progrs built at v1.42.12 au naturel | 18:21 |
| paulsher1ood | s/efs2prgorgeergerfterghrts/e2fsprogs/ | 18:21 |
| paulsher1ood | i guess this can wait... it's beer o'clock | 18:23 |
| *** Kinnison_ [~dsilvers@gateway/shell/pepperfish/x-mfadslnrdwkbdash] has joined #baserock | 19:07 | |
| *** persia_ [quassel@ubuntu/member/persia] has quit [Ping timeout: 244 seconds] | 19:08 | |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-iumivulvebvqfovj] has quit [Ping timeout: 244 seconds] | 19:08 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has joined #baserock | 19:08 | |
| *** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host] | 19:08 | |
| *** persia_ [quassel@ubuntu/member/persia] has joined #baserock | 19:08 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 19:12 | |
| *** cosm [~Unknown@host-78-148-113-50.as13285.net] has quit [Ping timeout: 256 seconds] | 19:38 | |
| *** cosm [~Unknown@host-78-148-235-178.as13285.net] has joined #baserock | 19:51 | |
| *** rdale [~quassel@102.red-80-26-167.adsl.dynamic.ccgg.telefonica.net] has quit [Ping timeout: 256 seconds] | 23:57 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!