IRC logs for #baserock for Friday, 2014-12-19

*** zoli_ [~zoli_@linaro/zoli] has joined #baserock05:17
*** franred [~franred@213.37.90.178.dyn.user.ono.com] has joined #baserock06:40
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock07: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 #baserock07: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 #baserock08:55
*** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock08:58
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock09:07
Mode #baserock +v ssam2 by ChanServ09:07
*** zoli_ [~zoli_@linaro/zoli] has joined #baserock09:24
pedroalvarezpersia: yeah, it does assume Debian.  To do this only with Basserock I should have to be running baserock in my laptop09:57
pedroalvarezOr maybe just mention that the VM has to have a pre-vlanned interface and let the user fibgure out10:01
pedroalvarezI 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
pedroalvarezOr maybe it will and I'm wrong assuming that10:12
persiaI vaguely remember rumours of a USB install of Baserock.  Do you know if that exists?  Was it bootable USB?10:13
persiaBut 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
pedroalvarezpersia: 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 installer10:15
pedroalvarezMy 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 laptops10:16
persiaIndeed.  Enabling all the right bits for proper hardware support can be tricky.10:16
persiaSo, 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
pedroalvarezIf in my example I were deploying from a jetson, I could avoid the "Debian" bit10:18
pedroalvarezbut you have to flash the jetson before :P10:19
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock10:20
persiaAnd deal with the cross-architecture nature of things, unless you can find armv7lhf hardware with a reliable BMC :)10:27
pedroalvarezactually, it is possible to cross-deploy!10:30
pedroalvarezI'm going to try a deployment from it :)10:32
CTtpollardcould anyone point me in the direction of any documentation around the python importer tool?10:35
pedroalvarezCTtpollard: http://wiki.baserock.org/guides/import-tool-rubygems/10:36
petefothhttp://wiki.baserock.org/guides/import-tool-rubygems/10:36
persiaCTtpollard: Extra points for wiki gardening to make that more obviously python-related :)10:36
petefothbah! too slow for pedroalvarez 10:36
pedroalvarezoh, indeed, maybe the tutorial doesn't explain the python import10:37
CTtpollard:)10:37
CTtpollardI don't need it right now, just writing up a plan 10:38
CTtpollardon the same note, has a system including tox been created to anyones knowledge, the system I want to build uses venv's10:40
CTtpollardor is the use of venv's not in keeping with Naserock10:41
persiaI thought venvs were mostly used for development.  In production, wouldn't one populate the true environment?10:41
CTtpollard*Baserock10:41
CTtpollardpersia: Yes, but for a system still very much in development is having a venv more suited?10:45
CTtpollardthe 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 change10:45
KinnisonTo what end?10:46
ssam2fast construction of staging areas and artifacts10:46
KinnisonWell, to be fair, construction of staging areas and artifacts is not currently that slow10:48
* Kinnison thinks it'd help manage the size of caches more than improve speeds10:48
ssam2deployment is really slow10:48
Kinnisondeployment *has* to copy10:48
Kinnisonbecause it *has* to allow the configure extensions to make arbitrary changes10:48
Kinnisonif ostree hardlinks then you'll have the same corruption issues we had before we realised that10:49
* ssam2 tries to remember ostree works10:50
ssam2you're right, I think10:50
ssam2*remember how10:50
KinnisonWe had thoughts to improve deployment by removing one of the copy stages by use of a fuse or overlay fs10:50
Kinnisongiven 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 deployment10:51
ssam2would using overlayfs on top of a hardlink tree work ?10:52
ssam2i've never used it10:52
Kinnisonpresumably it would, but to be sure would need testing10:53
ssam2ok, cool10:53
KinnisonAlso, currently we build system artifacts by copying, again because system integrations can arbitrarily alter the filesystem10:53
Kinnisonso that'd be a candidate for speedups if you can get an overlayfs working10:54
KinnisonAll this was discussed quite some time ago, I think liw proposed a fuse FS approach back before overlayfs made it into the kerne10:54
Kinnison+l10:54
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds]11:08
jmacsI'm still having trouble getting my sgdisk morph out of core.morph. Here's my diff: http://paste.baserock.org/obimumawej11:09
jmacsStill says "chunk sgdisk references its dependency util-linux before it is defined"11:09
pedroalvarezjmacs: aaah! so it wasn't failing to compile11:10
jmacsNo11:10
Kinnisonjmacs: does it? (reference util-linux before util-linux in the list of chunks?)11:11
pedroalvarezjmacs: the util-linux dependecy is implicit when you add the core dependecy11:11
jmacsKinnison: util-linux isn't in ceph-service.morph; it's in core.morph11:11
Kinnisonthen remove the dependency from the chunk and ensure core.morph is in the build-depends for the ceph-service stratum11:12
Kinnisonchunk-level build-depends are intra-stratum, not inter-stratum11:13
Kinnisonyou've done the latter (adding core.morph as a build-dep) so just do the former and it should build11:13
Kinnison:_)11:13
jmacsOK, that appears to be happier11:14
Kinnisoncoolio11:14
*** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock11: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 par11: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_Boot11:49
paulsher1oodmauricemoss_: that's a private wiki11:50
radiofreemauricemoss_: for the most part it shouldn't matter11:50
paulsher1oodany chance you could make a video tutorial/demo if this?11:50
radiofreesince you can set the ROOT_DEVICE to be your btrfs partition, and the upgrade procress will move files around internally there11:50
radiofreewhat 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, subvolume11:50
mauricemoss_paulsher1ood, oh.. I can add it later to the baserock wiki? 11:51
radiofreeis 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.flags11:52
radiofreeand 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.html11:52
mauricemoss_yeah, it's build into a binary11:53
radiofreeah ok, so you can copy the kernel image with the new kernel args to the ext partition?11:53
mauricemoss_exactly11:54
radiofreecan you sign any kernel with that?11:54
mauricemoss_but currently I have to do it manually in chromeOS or on my machine11:54
mauricemoss_yep11:54
radiofreeso i think what you'll have to do is just build the zImage as normal in baserock11:54
mauricemoss_what do you mean? can you explain it more detailed?11:55
radiofreethen in your deployment stage, have system-version-manager sign that kernel (with the correct new subvolume name pased as a kernel arg)11:55
paulsher1oodmauricemoss_: 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
radiofreeand copy it over to the ext2 boot partition11:55
pedroalvarezradiofree: http://paste.baserock.org/ohaqoviser :/11:55
* paulsher1ood is grumpy again11:55
Kinnisonruhroh11:55
radiofreepedroalvarez: don't use that script!!11:55
pedroalvarezwhy11:55
pedroalvarezwhich one should I use11:55
radiofreebecause it's obselete, use the one i sent to the list (https://gitlab.com/jamesthomas/baserock-flashing-tools/)11:56
radiofreeyou'll need a few things in your baserock system that i'm preparing a stratum for now11:56
radiofreehowever i can message you the details on how to set them up manually if you want11:56
pedroalvarezradiofree: it may be obsolete but we are still using it in the wiki :(11:57
radiofreeyeah becaues the new one hasn't been approved yet11:57
pedroalvarezooi, why obsolete? 11:57
radiofreei'm working on it11:57
radiofreethe old one (everything on one partition) results in a "fingers crossed this update is going to work" scenario11:57
radiofreethe new way is to set BOOT_DEVICE=/dev/mmcblk0p1 and ROOT_DEVICE=/dev/mmcblk0p211:58
radiofreethen use the new script to create an ext boot partition, which boots into the btrfs one11:58
* paulsher1ood goes to see a moonshot server11:58
radiofreeflawless upgrades11:58
ssam2radiofree: 'not yet approved' - is it sat on the mailing list waiting for review?11:59
radiofreethere were comments i haven't got round to addressing yet11:59
ssam2ah OK11:59
pedroalvarezradiofree: then am I be able to upgrade my board after flashing with this script?11:59
pedroalvarezs/am I/will I/11:59
radiofreepedroalvarez: well in theory you can upgrade your board the old method11:59
radiofreein 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 file12:00
radiofreewith this new method upgrades work all the time12:00
radiofreei can prepare some instructions for you to try it out if you want12:01
pedroalvarezwhen you say "the old method" you mean that the new method is already merged and not compatible with this flashing script?12:01
radiofreethe 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/mmcbkl0p212:02
radiofrees/bkl/blk12:02
radiofreethere's also the added benefit we can use completely open tools to do the flashing now12:02
* pedroalvarez gives up12:05
radiofreei can show you how to do it if you want12:07
pedroalvarezradiofree: 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
radiofreepedroalvarez: morph upgrade and cycle.sh *might* work12:10
radiofreeyou've got... in my experience a 70/30 chance of it working12:11
radiofree70% success, but other people might disagree with that...12:11
pedroalvarezradiofree: hehe :) ok12:11
franred:)12:11
pedroalvarezthen I'll try that12:11
persiaCTtpollard: 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
CTtpollardpersia: I can see the point in not using tox then12:26
persiaOn 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
CTtpollardfor my my needs12:26
persiaCTtpollard: 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
persiaSo 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
CTtpollardpersia: yes I will have to do a lot of importing, especially *hopefully* of npm dependencies 12:29
CTtpollardalso if anybody knows anything around the package manager bower, that would be really helpful12:35
jmacsIs the output from 'morph build' logged anywhere?12:37
radiofreejmacs: /src/morph.log ?12:38
jmacsYep, cheers12: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 #baserock12: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 #baserock13:18
franreddo we prefer the repositories from github or openstack server when we lorry them? Im creating lorry files to lorry xstatic and xstatic-* packages for horizon13:24
persiagit.openstack.org13:24
franredpersia, ok13:24
persiaOr 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
franredfrom: https://github.com/stackforge/xstatic-angular and https://git.openstack.org/cgit/stackforge/xstatic-angular/ look the same for me13:25
persiaThe 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
franredI imagine that he creates first on gihub and then they got mirrored from openstack13:26
persiaThe 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
persiaThe existence of https://git.openstack.org/cgit/stackforge/xstatic-angular/commit/?id=7300bd88ba20368ef86c93428f78acac6f5d9c71 implies to me that the most recent commit went through OpenStack gerrit13:27
persiaActually, all commits except the initial import seem to have gone through OpenStack gerrit.13:28
franredcool, thanks persia :)13:29
persiaNote 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 directly13:30
persiahttps://github.com/angular/angular.j13:30
* persia is unhappy that xstatic-angular exists, and wishes that there was better coordination to land the pip-compatibility stuff upstream13:31
franredpersia, 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.113:31
persiaDoes 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
franredthere are some xstatic-* packages which horizon depends on - and I think they are just static compilation of these packages13:32
persiaThere 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
persiaGenerally 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
franredpersia, the reason is because they are dependencies for horizon and if they are not in the system horizon at compile time will complain13:34
franredI not sure if adding the real packages horizon will compile13:34
persiaYou 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
franredpersia, I think I read that they replace the real packages for this ones because the amount of dependencies13:35
persiaYeah.  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
persiaI think they do it because they want to use `pip install` to fulfill dependencies, rather than anything else.13:36
persiaBut anyway, if you must lorry xstatic-angular, I believe github is the mirror and openstack is the upstream.13:36
franredaham, so you will suggest to use the real packages for this and not use this dirty hack13:36
franredpersia, ^^ ?13:37
persiaI 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
persiaBut I'm an idealist, and you may not actually want to do that to achieve your personal goals :)13:39
persiaI 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
persiaAnd I'm not going to -1 it, because I'd rather get Horizon than do angular.js in the ideal manner.13:41
franredpersia, 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 packages13:41
persiaIf you have time to do that, I think that would be ideal :)13:42
franredlet'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 #baserock13: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 thingy14:10
pedroalvarezoopsie: http://paste.baserock.org/zemeyifiru14:17
persiaheh14:19
Kinnisondoh14:20
pedroalvarezso, it needs syslinux to become a pxe server14:21
Kinnisonsyslinux contains the files served over TFTP to the PXE client14:21
KinnisonCould you extract that from the system you're deploying?14:21
persiaSo it specifically needs to have syslinux for the target architecture, rather than the development architecture.14:21
pedroalvarezindeed, and if I'm deploying to (say) arm...14:22
KinnisonYou're not going to be using PXE14:22
Kinnisonsince PXE is an x86 thing14:22
radiofreeyou don't need syslinux for that14:22
*** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock14:22
Mode #baserock +v ssam2 by ChanServ14:22
persiaKinnison: What happened to the PXE interface that was added to u-boot a couple years ago?14:22
Kinnisonpersia: That may depend on uefi14:23
KinnisonConsider http://en.wikipedia.org/wiki/Preboot_Execution_Environment#Availability14:24
persiaAh, 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-making14:27
pedroalvarezhm..14:28
pedroalvarezI think this does a tftpboot parsing a pxlinux.conf14:28
persiaKinnison: The main issue is Tpwpp is longer than PXE, and fails to contain any vowels.14:32
KinnisonI tend to call it 'tftpboot'14:33
* pedroalvarez ponders adding a check for the '/usr/share/syslinux/pxelinux.0' file to pxeboot.check14:34
pedroalvarezAfter copying pxelinux.0 to the host, it's working14:39
pedroalvarezand here we go, installing on hardware :)14:41
persiaDirectly?  Deploying Baserock to hardware from Baserock on hardware?14:47
pedroalvarezfrom Baserock in a jetson which is baserock on hardware, yes14:47
jmacsI 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 it14:48
pedroalvarezjmacs: and it should14:48
Kinnisonjmacs: - mkdir -p "$DESTDIR/$PREFIX/bin"14:48
pedroalvarezah yes14:49
pedroalvarezimportant bit14:49
Kinnisonjmacs: - install -m 0755 -o root -g root sgdisk "$DESTDIR/$PREFIX/bin/"14:49
Kinnisonor similar14:49
persiahttp://sources.debian.net/src/gdisk/0.8.10-1/debian/rules/ suggests you may want to run 5 install commands14:50
persiaBut the last of these may be Debian-specific14:50
jmacsNone of those work. It looks like $DESTDIR is "/sgdisk.inst/"14:51
jmacsinstall: cannot create regular file '/sgdisk.inst//usr/bin': No such file or directory14:52
persiaYou may need a -D14:52
jmacs-D fixed it. Is /sgdisk.inst/usr/bin really the correct destination?14:54
Kinnisonsounds right14:54
KinnisonSince /CHUNKNAME.inst is the writable DESTDIR14:54
jmacsI thought it'd be going into /src/tmp/deploy/tmpbleugh/usr/bin - does that happen at deploy?14:55
Kinnisonremember that path is within the linux-user-chroot for the chunkbuild14:55
Kinnisonso it'll be /src/tmp/bleurghlyflsiufds/fds/fsd/fsa/CHUNKNAME.inst/...14:55
Kinnisonfrom the real root14:55
jmacsaha14: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 #baserock15:14
pedroalvarezI have done these changes to explain how to do a on-harware deployment using baserock on-hardware: http://paste.baserock.org/uxeliyavaq.diff15:22
jmacsStill 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
Kinnisonyeah the slash between destdir and prefix isn't really needed15:23
jmacsI'm getting an error while unpacking chunks now...15:25
jmacsERROR: [Errno 21] Is a directory: '/src/tmp/staging/tmpxWdklr/ceph-service-x86_64-generic.inst/usr/bin'15:25
jmacsWhile unpacking the sgdisk chunk15:25
pedroalvarezmaybe you need an slash at the end of the install command?15:26
KinnisonIf you're using install -D then you need the destination filename (or perhaps the trailing slash)15:26
Kinnisonhence I suggested a mkdir first15:26
*** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit []15:35
jmacsbuilt! Thanks Kinnison.15:36
KinnisonNo probs, sorry I wasn't clear enough earlier15:37
jmacsYou were, I just hadn't connected it to persia's advice15:39
paulsher1oodrdale: can you +1 the baserock-import tool, assuming you think it's somewhat useful?16:11
rdaleyes ok16:13
*** franred [~franred@213.37.90.178.dyn.user.ono.com] has quit [Quit: Leaving]16:20
ssam2thanks16:26
paulsher1oodme too, ssam2 - go ahead :)16:27
ssam2cool, thanks16:28
rdalei 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 yet16:29
ssam2argh16:30
ssam2do all the gems fail, or just certain ones?16:30
rdalerake-compiler 0.9.3 won't build with the version of ruby gems in ruby 1.916:31
ssam2right. :(16:31
ssam2not that many things need rake-compiler that I remember... it'd be worth checking if you can use an older version of it16:31
rdalebut if i go back to rake-compiler 0,8 it needs a gem called 'isolate' or something16:32
rdaleracc needs rake-compiler16:32
rdalei forget what needs racc16:32
ssam2should I update baserock-import to 764531201f99bf1d9c6dd451a212b741bfb6715e so we get the python importer as well ?16:33
rdalei think i would prefer to get the web app working with ruby 2.0, rather than go back to ruby 1.916:33
ssam2rdale: makes sense16:33
rdalei 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 python16:35
*** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock16: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 #baserock16: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
paulsher1oodanyone got any idea how to fix http://paste.baserock.org/osomuraxeb ?18:00
paulsher1oodjjardon, for example? 18:01
* paulsher1ood was just told by his better half to 'have fun', so is enjoying trying to build ostree18:01
radiofreeinstall e2p?18:02
jjardonpaulsher1ood: you need the package that provides the e2p.pc pkg-config file18:02
paulsher1oodwhat is it? i think it's something to do with e2fsprogs, which is already done18:02
jjardonlets see18:02
paulsher1oodgoogling e2p didn't help me much18:03
radiofreeext3ipods18:04
radiofreeLinux ext3fs with QoS extensions18:05
radiofreeactually18:05
radiofreee2fsprogs18:05
radiofreeso 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
paulsher1oodhttp://paste.baserock.org/itojuworev18:06
paulsher1oodwe already have e2fsprogs in tools, so i've got it as a build-depend. am thinking there may be some config i need to do18:06
jjardonyeah, should be part of e2fsprogs: http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/lib/e2p/e2p.pc.in18:07
radiofreemaybe you need to enable it in the config18:07
radiofreeit's in our version http://git.baserock.org/cgi-bin/cgit.cgi/delta/e2fsprogs.git/tree/lib/e2p?h=baserock/morph18:07
jjardonno configuration option in http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/tree/configure.in18:08
jjardonpaulsher1ood: Do this output something in a baserock system? pkg-config --list | grep e2p18:09
jjardonsorry pkg-config --list-all | grep e2p18:09
paulsher1oodnull18:09
paulsher1oodso i just add this to the config of e2fsprogs?18:10
radiofreeno18:10
radiofreetry -enable-elf-shlibs18:11
radiofree--enable-elf-shlibs18:11
paulsher1ood(as config in e2fsprogs) - same error18:15
jjardonmaybe 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 correctly18:16
radiofreeyeah change the ref to v1.42.1218:17
paulsher1oodi think it's already at that?18:18
* paulsher1ood tries18:18
paulsher1oodsame error building ostree, for efs2progrs built at v1.42.12 au naturel 18:21
paulsher1oods/efs2prgorgeergerfterghrts/e2fsprogs/18:21
paulsher1oodi guess this can wait... it's beer o'clock18:23
*** Kinnison_ [~dsilvers@gateway/shell/pepperfish/x-mfadslnrdwkbdash] has joined #baserock19: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 #baserock19:08
*** persia_ [quassel@2400:8900::f03c:91ff:feae:3452] has quit [Changing host]19:08
*** persia_ [quassel@ubuntu/member/persia] has joined #baserock19: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 #baserock19: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.14.0 by Marius Gedminas - find it at mg.pov.lt!