| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 06:37 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 06:37 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:37 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 06:40 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:04 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:27 | |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 07:54 | |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:56 | |
| fay is now known as Guest72487 | 07:56 | |
| Guest72487 is now known as fay_ | 08:23 | |
| *** rdale [~quassel@169.Red-88-8-223.dynamicIP.rima-tde.net] has joined #baserock | 08:58 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:59 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: leaving] | 09:06 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
| mike is now known as Guest84456 | 09:06 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:16 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 265 seconds] | 09:22 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:22 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:23 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 09:28 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:44 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:54 | |
| Mode #baserock +v ssam2 by ChanServ | 09:54 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 09:54 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:54 | |
| * petefoth added a placeholder for the 'Rationalise upgrade functionality' story in http://wiki.baserock.org/stories-for-storyboard/ | 10:03 | |
| *** locallycompact [~lc@8.108.125.91.dyn.plus.net] has joined #baserock | 10:04 | |
| *** locallycompact [~lc@8.108.125.91.dyn.plus.net] has quit [Ping timeout: 252 seconds] | 10:52 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:04 | |
| bashrc | looks like https://git.baserock.org/git/delta/linux.git doesn't work. Certificate verification failed | 11:22 |
|---|---|---|
| rjek | Remove the s. | 11:22 |
| bashrc | I did | 11:22 |
| rjek | Without the s, there is no certificate verification to occur :) | 11:23 |
| bashrc | if it's inperable then it should probably be delisted | 11:23 |
| bashrc | s/inperable/inoperable | 11:23 |
| bashrc | as listed here http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/ | 11:24 |
| pedroalvarez | it's operable, but IIRC the certificate is self signed | 11:24 |
| pedroalvarez | the certificate of the trove | 11:24 |
| persia | bashrc: You may need to disable certificate checking in git, or add the certificate to the certificate list | 11:25 |
| bashrc | ok, however a git clone on it fails | 11:25 |
| * persia idly wonders if there should be a chunk with the baserock.org cert that is included in the development system | 11:25 | |
| bashrc | persia: I could, but really should users have to do that? | 11:25 |
| persia | bashrc: Which users? | 11:26 |
| bashrc | :) | 11:26 |
| persia | I think users of devel systems would have easier lives if we included a cert for baserock.org | 11:27 |
| persia | I think users of the baserock tooling are better served by using upstream ca-certificates from mozilla. | 11:27 |
| persia | I'm not excited enough to try to cause a baserock.org CA to be accepted by Mozilla. | 11:27 |
| bashrc | yes, it's not really tennable in 2014 to be asking people to be using insecure repos | 11:27 |
| persia | It isn't insecure. | 11:27 |
| persia | There just isn't a chain of trust. | 11:28 |
| bashrc | qed | 11:28 |
| persia | Personally speaking, I'd prefer to see more self-signed and peer-signed certificates, because I don't trust the practices of some of the organisations approved by Mozilla (and in at least two cases, know how to arrange them to issue certificates with information that does not match a legal entity) | 11:28 |
| persia | So from that perspective, maybe it is a bug in git that it just fails, rather than giving a useful opportunity to accept a certificate? | 11:29 |
| bashrc | I don't trust those practices either, but there isn't a better system in place at present | 11:29 |
| persia | Yep, but as a result, I don't know the best path for everyone :( | 11:30 |
| bashrc | it's not a bug in git, failing on inability to verify a certificate is pretty standard in a lot of software | 11:31 |
| bashrc | if baserock were to be used in any security critical environments only having http repos or downloads without checksums would be a problem | 11:46 |
| Zara_ | hi, I'm trying to update baserock to the newest version; I tried following the instructions in the 'upgrading a baserock installation' section, but the command I'm hoping to use (baserock-import) still isn't found, suggesting it hasn't updated. Do I need to run the command from somewhere specific? | 11:53 |
| ssam2 | do you mean the 'baserock-import' command? if so, no, it should be in /usr/bin | 11:55 |
| ssam2 | so you should be able to run it anywhere | 11:55 |
| Zara_ | sorry, that wasn't clear, I meant the morph upgrade command | 11:55 |
| persia | bashrc: Yes. The checksums are a known issue that we've talked about solving. For certificates, I think we need a plan. | 11:56 |
| bashrc | the easiest solution is just to adopt the conventional system until such time you can figure out some better arrangement | 11:57 |
| ssam2 | Zara_: ah, right. Yes, you have to run it inside the checkout of the branch you want to upgrade to | 11:58 |
| Zara_ | ssam2: ah, ok, I originally tried it in the import branch but I'm guessing I'd actually want the newest definitions branch? | 11:59 |
| ssam2 | for testing the import tool, the best branch to use right now is 'sam/update-import-tool' | 12:00 |
| ssam2 | (which it looks like I named incorrectly.) | 12:00 |
| ssam2 | if that branch had been reviewed and merged to master, then master would be the best branch to use | 12:00 |
| Zara_ | Ok | 12:00 |
| * petefoth has a task to review the tutorial in his todo list https://tree.taiga.io/project/baserock-tasks/us/51 | 12:02 | |
| Zara_ | could someone tell me the exact morph checkout command to use in this case (or point me to something which explains how they work)? | 12:09 |
| Zara_ | petefoth: I'll note what needs adding as I go along. :) | 12:11 |
| paulsher1ood | Zara_: better to use morhp branch? so 'morph branch baserock:baserock/definitions your-branch' should give you latest definitions in your-branch | 12:11 |
| Zara_ | paulsher1ood: I was trying to use checkout from within a testbranch, is the the same thing? | 12:12 |
| Zara_ | s/the/that | 12:12 |
| Zara_ | oh wait, his branch is *in* the definitions repo; I think that's what I was missing | 12:14 |
| franred | Zara_ no is not the same, morph checkout will checkout the branch on the server, morph branch will create a local branch with that name, AFAIK | 12:15 |
| paulsher1ood | morph branch baserock:baserock/definitions your-branch his-branch | 12:15 |
| paulsher1ood | will give you his-branch in your-branch... i hope that makes some sense | 12:15 |
| Zara_ | I'll try it out and see :) | 12:18 |
| bashrc | is there a way of updating baserock systems without having to create and flash an entire new image? | 12:22 |
| Zara_ | ah, seems to have worked; had to make a new testbranch since it acts weird if there's stuff already in the branch (or possibly if there's already a branch with that name) | 12:22 |
| DavePage | bashrc: I was under the impression that creating and flashing an entire new image was a feature, not a bug | 12:24 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 12:25 | |
| bashrc | DavePage: seems like a lot of work if you just want to make some minor bug fix | 12:27 |
| petefoth | bashrc: making a new system shouldn't take long (because cached build atrifacts), and you need to do it to check that your change hasn't broken anything | 12:28 |
| pedroalvarez | and you don't need to flash anything to upgrade your baserock system if it's using a btrfs filesystem | 12:30 |
| bashrc | I'm not familiar with btrfs. Does it have some image update feature? | 12:34 |
| pedroalvarez | the baserock upgrade process needs btrfs | 12:38 |
| paulsher1ood | s/upgrade/default upgrade/ | 12:38 |
| paulsher1ood | other processes are possible :) | 12:38 |
| pedroalvarez | yeah :) | 12:39 |
| Zara_ | I'm getting a 'deployment failed as system is not yet built' message. Suspect it's something to do with this instruction 'Make sure the 'morph' field below matches the system you are upgrading'; I'm not sure what that refers to. | 12:40 |
| Zara_ | (what the 'morph field' refers to | 12:40 |
| Zara_ | (my guess is the '(hostname)') | 12:41 |
| pedroalvarez | Zara_: so you want to upgrade your system, don't you? | 12:41 |
| Zara_ | yeah | 12:42 |
| pedroalvarez | to do that, you have to build the system using `morph build` and then deploy it as an upgrade to your running system | 12:42 |
| Zara_ | ah, ok, that should definitely go in the tutorial! :P | 12:42 |
| ssam2 | Zara: it'd be really cool if you could fix the 'how to upgrade your VM' guide to be more helpful to people who are relatively new to Baserock | 12:44 |
| ssam2 | after you've done the upgrade of course | 12:44 |
| Zara_ | yeah, I'll get on it :) | 12:45 |
| pedroalvarez | Zara_: regarding to the 'morph' field - It's the following line: | 12:47 |
| pedroalvarez | - morph: systems/devel-system-x86_64-generic.morph | 12:47 |
| pedroalvarez | so, if you want to upgrade your system to a system that is not a devel-system, you only have to change that field | 12:47 |
| Zara_ | oh, so that refers to the thing *above* it on the page-- I thought it was referring to something in the upgrade command! | 12:50 |
| Zara_ | so it's a field in the cluster morphology | 12:51 |
| Zara_ | I'll make a note to move that up | 12:51 |
| Zara_ | the build fails when it reaches setup.py | 12:52 |
| SotK | can you paste the full error in a pastebin somewhere? | 12:53 |
| pedroalvarez | I assume that is the setup.py of the baserock-import chunk | 12:54 |
| Zara_ | yeah | 12:54 |
| Zara_ | SotK: sure, do you have the url for the br pastebin handy? | 12:54 |
| SotK | http://paste.baserock.org/ | 12:55 |
| SotK | Zara_: ^ | 12:55 |
| Zara_ | http://paste.baserock.org/xuxedeqaji.vhdl | 12:55 |
| Zara_ | SotK: thanks :) | 12:56 |
| rjek | vhdl?! | 12:57 |
| Zara_ | I do not know the significance | 12:57 |
| rjek | VHSIC Hardware Description Language. It's a language for designing chips. | 12:58 |
| pedroalvarez | rjek: please, I know is not the best pastebin option, but it works fine for now | 12:58 |
| rjek | pedroalvarez: Can it be configured to default to plain text rather than randomly selecting a colour scheme that maximises unreadability? | 12:58 |
| pedroalvarez | rjek: probably | 12:59 |
| SotK | Zara_: that looks like a problem with the import tool stratum | 12:59 |
| Zara_ | SotK: yeah, seems like it, though I'm not sure if that means I tried to build the wrong thing | 12:59 |
| SotK | Zara_: nope, the stratum is wrong I think :) | 13:00 |
| SotK | the baserock-import chunk has no build-depends listed, so is probably being built before ansicolor has been built going off that error | 13:01 |
| Zara_ | SotK: (heh, I meant I might have tried to build an unfinished version or something and there's a working one lurking around elsewhere) | 13:01 |
| Zara_ | though I hope it's not me for a change :P | 13:01 |
| SotK | where are you building it from? | 13:03 |
| persia | bashrc: I'm not sure what you mean by "the conventional system". We do provide ca-certificates in the devel image, which works for any https URL signed by the CAs listed there. | 13:03 |
| Zara_ | SotK: I followed the instructions above, so it should be from my own branch containing the definitions from Sam's branch, sam/update-import-tool | 13:05 |
| Zara_ | the system itself was the x86_64 generic devel thing | 13:05 |
| SotK | the stratum does indeed look wrong in that to me | 13:09 |
| SotK | Zara_: try adding ansicolor (and the other chunks in the baserock-import stratum) to the build-depends field of the baserock-import chunk in that stratum | 13:10 |
| Zara_ | Ok, I'll give it a go :) | 13:11 |
| * SotK wonders why the 0.10.0 tag for pbr produces version 0.11.0.dev48.g49ff27c, and the 0.9.0 tag produces version 0.10.0 | 13:15 | |
| Zara_ | SotK: cool, that worked :) | 13:16 |
| SotK | Zara_: good :) | 13:16 |
| SotK | Zara_: maybe submit a patch to fix it since its broken in master too by the look of things? | 13:17 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:18 | |
| Zara_ | SotK: I think ssam2 said it hadn't been merged to master, yet, so hopefully he can catch it before that | 13:24 |
| Zara_ | (yay, build ends successfully!) | 13:24 |
| pedroalvarez | yeah, is not in master, otherwise mason would be failing | 13:26 |
| pedroalvarez | and is not: http://mason-x86-64.baserock.org/ | 13:26 |
| * SotK is confused | 13:32 | |
| SotK | http://paste.baserock.org/aqohiqenet.pl | 13:32 |
| SotK | perhaps mason built them in the right order first try? | 13:35 |
| Zara_ | hm, I did something wrong; I destroyed my baserock. | 13:39 |
| Zara_ | well, my devel system; luckily I have a copy | 13:39 |
| Zara_ | http://paste.baserock.org/ceqotuyuri.vhdl | 13:40 |
| SotK | ouch | 13:41 |
| * SotK has never seen that before | 13:41 | |
| * persia has had that happen, when running out of space on a btrfs volume | 13:41 | |
| persia | If one runs several sequential upgades without removing some results with system-version-manager, it is easy to fill the folume. | 13:42 |
| Zara_ | persia: how would I find out if that's what happened? | 13:44 |
| bashrc | persia: there was some mention of btrfs space issues in a meeting I was in this morning | 13:45 |
| persia | From the state you're in now, I think you'd have to mount the backing store from another system, and then use btrfs-tools to dig through. | 13:45 |
| persia | Do you have any unpushed git repos in that environment? | 13:45 |
| bashrc | couldn't there be some delete buffer, such that the disk never gets totally filled? | 13:45 |
| persia | bashrc: Depends on what one tells the system to do. Doesn't work if I try to deploy 6 2.5GB filesystems to a 10G backing store. | 13:46 |
| persia | That said, we should have better errors when we break things (and less catastrophic breakage), but when running everything as root, we don't have any reserved space protections. | 13:47 |
| bashrc | everything as root? | 13:48 |
| persia | Yes. Currently, morph expects to be run as root. | 13:49 |
| bashrc | ah... | 13:49 |
| Zara_ | when I logged into my copy system, I got a msg saying 'FACTORY login:[ 4.8566991] systemd-journald[90]: File /var/log/journal/[long key]/system.journal corrupted or uncleanly shut down, renaming and replacing. I'm not sure if that's to do with the update break, or if it's because I then had to force off the vm (it no longer recognised shut down or reboot) | 13:49 |
| persia | What is your "copy system"? | 13:50 |
| Zara_ | persia: when I was trying to update my devel system on friday, I managed to instead make a copy of it called 'newbr' | 13:50 |
| Zara_ | possibly it's not actually a copy and just is a generic devel system build | 13:51 |
| persia | Hard to say. | 13:51 |
| Zara_ | I haven't investigated that thoroughly yet; I'm just relieved I don't have to do everything from scratch | 13:51 |
| persia | If you have precious git repos there, I'd recommend trying to mount the disk image from another system. | 13:52 |
| persia | If you don't have precious data, I'd recommend starting over with a new devel VM. | 13:52 |
| Zara_ | persia: luckily, I haven't used baserock much yet, so it should be ok to start over-- is there a way to delete the broken factory system? | 13:53 |
| Zara_ | (without deleting the whole develvm and the other systems on it, since that'd save me a few mintues) | 13:53 |
| persia | Deleting "factory" isn't a good idea. | 13:54 |
| persia | And I only know how to delete other systems using `system-version-manager`, but that requires the ability to run commands. | 13:55 |
| Zara_ | I can run commands from my copy (just checked, it seems to be a copy after all) | 13:56 |
| persia | Try `system-version-manager --help` | 13:57 |
| persia | If you set the default to the running system, you can delete the othes (except "factory") | 13:57 |
| jjardon | Hi, ok to lorry libusb? http://fpaste.org/157616/80470861/ | 13:59 |
| paulsher1ood | 1 | 13:59 |
| paulsher1ood | +1 | 13:59 |
| Zara_ | persia: Ok, I've done that for now. :) | 14:01 |
| paulsher1ood | persia: deleting factory is fine now | 14:01 |
| paulsher1ood | so long as you have a working alternative running/default system | 14:01 |
| persia | Checking my mail log, it seems that morph a3c7fea2e1a7e10460d58d9fcbf8b395c0b17893 or newer is safe t use to upgrade systems without "factory" | 14:01 |
| franred | jjardon, looks ok to me +1 | 14:01 |
| persia | paulsher1ood: Teaches me to check my logs: I just should ask, as someone else is always faster :) | 14:02 |
| paulsher1ood | :-) | 14:02 |
| Zara_ | so, if I delete factory, will that let me clear the space without me needing to spend a long time learning to use lots of btrfs tools? (I'd like to reattempt the upgrade if possible) | 14:03 |
| jjardon | paulsher1ood: franred thanks, pushed | 14:03 |
| paulsher1ood | Zara_: yes, run system-version-manager remove factory | 14:04 |
| persia | Zara_: Yes, as long a ou have new enough morph | 14:04 |
| paulsher1ood | (which will only work after set-default to something else) | 14:04 |
| Zara_ | ok, let's find out (since if not, I'll need a new vm anyway! =D ) | 14:04 |
| Zara_ | ah, I get an error: 'ERROR: error accessing '/tmp/tmpEk4n_e/systems/factory/orig' | 14:05 |
| Zara_ | though it's gone from the list | 14:05 |
| Zara_ | ah, never mind, the copy seems to be incomplete; it's still saying 'morph not found' (I must have somehow affected it today as well). looks like it's time to start from scratch. | 14:18 |
| ssam2 | zara: good catch on the build failure of baserock-import | 14:20 |
| Zara_ | at least something useful came out of this! :) | 14:21 |
| ssam2 | I added manpage generation at the last minute which means that all the dependencies now need to be available at build-time | 14:21 |
| pedroalvarez | hm.. I wonder if systemd-timesyncd.service is the replacement of the ntp[d] service we had before | 15:10 |
| pedroalvarez | It's not working in my systems | 15:10 |
| pedroalvarez | because: ConditionVirtualization=no was not met (currently investigating) | 15:10 |
| pedroalvarez | looks like this unit is defined to not work in virtualized environments, so maybe I'm not looking to the right place | 15:12 |
| Kinnison | Virtualised machines usually have their clocks sync'd to their hosts | 15:13 |
| pedroalvarez | Kinnison: that's the reason of why my vm is 5 minutes ahead, thanks! | 15:14 |
| persia | Your host is 5 minutes ahead? | 15:14 |
| pedroalvarez | yup | 15:14 |
| Zara_ | hm, would it also be useful for me to add a wiki tutorial for installing baserock using the virtual machine manager gui? it's a bit fiddly and both times I've done it, it's taken me longer than it had to. | 15:25 |
| paulsher1ood | Zara_: using which virtual environment? | 15:26 |
| Zara_ | kvm, I think | 15:27 |
| Zara_ | the virtual machine enviroment help says libvirt | 15:27 |
| * Kinnison thinks Zara_ is using virt-manager | 15:28 | |
| Zara_ | yeah, it doesn't have to be kvm, but mine is (I think) | 15:28 |
| Zara_ | Kinnison: yeah | 15:28 |
| paulsher1ood | so http://wiki.baserock.org/guides/vm-setup/#index3h2 is not sufficient? (i only use virtualbox) | 15:28 |
| Zara_ | it didn't work for me when I tried it some months ago, which is why I ended up using the gui, though that might have been due to a mistake on my part | 15:29 |
| * SotK found that kvm guide unhelpful when he was first using Baserock, and someone (Kinnison perhaps) told me it was easier to just use the gui | 15:29 | |
| Kinnison | It's way easier to use virt-manager than to use kvm directly | 15:30 |
| SotK | Also, http://git.baserock.org/cgi-bin/cgit.cgi/delta/python-packages/lockfile.git/ is useless | 15:31 |
| radiofree | does virt manager make it easy to setup your network? | 15:31 |
| rjek | kvm is based on qemu by Fabrice Bellard, and thus has... a less than ideal command line interface. | 15:31 |
| radiofree | i'm still using /etc/qemu-ifup scripts... | 15:31 |
| rjek | (also see: ffmpeg) | 15:31 |
| Kinnison | virt-manager lets you control network setup yes | 15:31 |
| Kinnison | it's not massively capable, but you can do the simple stuff like bridge vs. nat vs. isolated | 15:31 |
| radiofree | hmm i'll have to look into that, the way i'm used to is -net nic,model=virtio and -net tap | 15:32 |
| radiofree | s/and/with | 15:32 |
| radiofree | then a script (/etc/qemu-ifup) which gets run automatically to do the brctl stuff | 15:33 |
| radiofree | it works well enough to allow you to quickly boot things from the command line, http://paste.fedoraproject.org/157658/18052822 is the script | 15:34 |
| franred | Sokt, looks like lockfile is now here --> https://github.com/openstack/pylockfile | 15:41 |
| franred | thanks by the way, I will fix it | 15:42 |
| SotK | franred: it is | 15:43 |
| SotK | franred: thanks | 15:43 |
| franred | http://paste.baserock.org/nizifilecu.diff | 15:45 |
| franred | SotK, ^^ | 15:45 |
| franred | and another nice soul for a quick review | 15:45 |
| SotK | hmm, actually, is it worth getting it from the repo on git.openstack.org? | 15:47 |
| franred | SotK, why not? | 15:48 |
| franred | it is the place where was moved | 15:48 |
| franred | http://git.baserock.org/cgi-bin/cgit.cgi/delta/python-packages/lockfile.git/tree/README | 15:49 |
| franred | SotK, ^^ | 15:49 |
| perryl | :q | 15:50 |
| perryl | ignore that... | 15:50 |
| SotK | franred: the readme in https://github.com/openstack/pylockfile links to https://git.openstack.org/openstack/pylockfile | 15:51 |
| SotK | they are the same repo though, so +1 whichever you pick | 15:51 |
| pedroalvarez | the HEAD commit of master of the git.baserock.org loickfile repo is not in the opesntack repo | 15:55 |
| paulsher1ood | how does that happen? | 15:55 |
| franred | because they change the repository and we haven't detected? SotK I've changed for this: http://paste.baserock.org/ukodihaxam.sql | 15:56 |
| SotK | paulsher1ood: they moved the repo to git.openstack.org (mirrored in a new repo on github) and added a commit to the old github removing everything and adding a note in the README explaining where it went | 15:56 |
| SotK | franred: +1 | 15:57 |
| SotK | paulsher1ood: (we were lorrying from the old github) | 15:57 |
| pedroalvarez | oh, I didn't realise that the commit was to remove everything | 15:57 |
| pedroalvarez | makes sense now to me: +1 franred | 15:58 |
| franred | pedroalvarez, SotK, thanks, it is pushed | 15:59 |
| SotK | thanks franred | 16:00 |
| franred | SotK, the odd thing is that I am building that repository in openstack sucessfully | 16:02 |
| franred | Im building it from 4eb27075e0523b6ed2027444fd42d83a6e9b14c5 master, which is the last commit before they move clean the repository :) | 16:02 |
| franred | s|move clean|move/clenan| | 16:03 |
| radiofree | jjardon: not sure if you're aware but we can use mainline libdrm now | 16:21 |
| radiofree | tegra stuff has been merged | 16:21 |
| SotK | does anyone happen to know exactly what the issue was that means that the python import-tool doesn't work for things which use pbr? | 16:31 |
| ssam2 | only Richard Ipsum | 16:31 |
| ssam2 | my guess is that it works in a fundamentally different way to 'pip' so the tool would need extra code to understand whatever format it uses | 16:32 |
| ssam2 | that code should be fairly easy to write, because pbr seems like it has quite a sane input format | 16:32 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:33 | |
| franred | not sure how difficult would be, but I know that pbr uses normally "requirements.txt" file to populate the install_requirements for setup_tools | 16:34 |
| SotK | I only ask because when I was trying to get Zuul installed in a hacked up way a few weeks ago I couldn't do anything due to an error similar to those linked in TODO.python | 16:34 |
| franred | SotK, I think Richard also added a link with the problem that he found on the interaction between pbr and setup_tools | 16:35 |
| SotK | I got around that by updating the version of pbr I was using | 16:35 |
| SotK | but maybe it wasn't the same problem | 16:35 |
| ssam2 | I don't know if he tried that | 16:35 |
| jjardon | radiofree: nice! All of it? (I see more patches in our branch than the ones applied in master) | 16:35 |
| SotK | the version we are using in baserock at the moment is pretty old I think | 16:35 |
| pedroalvarez | I remember that there was a way to check the kernel configuration of baserock system, but I forgot how to do t hat | 16:36 |
| radiofree | i'll give it a go | 16:37 |
| pedroalvarez | does anyone remember how to do that? | 16:37 |
| ssam2 | is it in configure-commands in /baserock/linux...xxx.meta ? | 16:38 |
| pedroalvarez | ssam2: yeah, but that doesn't include the ones that are included by default | 16:39 |
| paulsher1ood | pedroalvarez: there was a docker script i used, but iirc it got dropped | 16:39 |
| pedroalvarez | oh, looks like `cat /proc/config.gz |gunzip` is what I was looking for | 16:45 |
| Kinnison | zcat | 16:47 |
| Kinnison | zgrep exists too | 16:47 |
| pedroalvarez | nice! :) | 16:47 |
| pedroalvarez | this file is generated becaue IKCONFIG is enabled in the kernel | 16:47 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:13 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:25 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:32 | |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 17:36 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 17:40 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 17:40 | |
| radiofree | jjardon: words \o/ | 17:41 |
| radiofree | s/words/works | 17:41 |
| jjardon | radiofree: +1 | 17:41 |
| radiofree | patch "Use libdrm master" http://paste.fedoraproject.org/157713/80607461 | 17:46 |
| radiofree | tested on ARM | 17:46 |
| jjardon | radiofree: remove the "unpetrify-ref" and you have +2 | 17:47 |
| radiofree | is unpetrify-ref not a thing anymore? | 17:48 |
| Kinnison | I thought it still was | 17:48 |
| radiofree | it's a least useful for translating the sha to a branch | 17:48 |
| jjardon | radiofree: no if you are building from master, at least is what remember from a richard_maw review of one of my patches | 17:50 |
| franred | please leave the unpetrify-ref, it is useful to know where the sha1 comes from | 17:50 |
| radiofree | personally i'd prefer to leave it in, that sha could be from anywhere, it's a good indication of the branch | 17:50 |
| Kinnison | with an unpetrify-ref of 'master' it's a good hint that it may be unreproducible | 17:51 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:51 | |
| Kinnison | So it's useful information | 17:51 |
| pedroalvarez | indeed | 17:51 |
| ssam2 | radiofree: +1 if you keep the unpetrify-ref :) | 17:51 |
| pedroalvarez | ditto | 17:52 |
| radiofree | i'll test it in an x86 vm tomorrow first... you never know.... | 17:52 |
| pedroalvarez | radiofree: thanks for bearing that in mind :) | 17:53 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 17:56 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 17:57 | |
| jjardon | is there a doc somewhere that explain what is each parameter? So we can refer to it to explain what "unpetrify-ref" is for | 17:59 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 18:04 | |
| ssam2 | jjardon: lots of stuff is likely to change soon | 18:05 |
| ssam2 | but http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/README documents how things have been in the past | 18:06 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:06 | |
| jjardon | thanks! but unfortunately there is not mention to "unpetrify-ref" there ;) | 18:08 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:10 | |
| jjardon | what Sam mean about "lots of stuff is likely to change soon" ? | 18:10 |
| jjardon | any big changes comming? | 18:13 |
| *** Guest84456 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:24 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 18:26 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:00 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 19:41 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!