| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 00:12 | |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:20 | |
| fay is now known as Guest48475 | 00:20 | |
| *** cosm [~Unknown@host-80-41-248-255.as13285.net] has joined #baserock | 00:35 | |
| radiofree | persia: i don't think baserock has to worry about that for now | 00:43 |
|---|---|---|
| radiofree | despite the blurb it's not that good at keeping up with upstream | 00:43 |
| radiofree | it's more important to upgrade our gcc then it is to upgrade python? | 00:43 |
| ratmice | fwiw gcc's libstdc++ pretty printers appear to have been updated to work with python3 :) | 02:02 |
| *** Guest48475 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 258 seconds] | 02:43 | |
| *** Guest48475 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:44 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 06:58 | |
| *** zoli_ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Changing host] | 06:58 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 06:58 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:12 | |
| mike is now known as Guest8462 | 07:12 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:01 | |
| *** rdale [~quassel@197.Red-2-137-105.dynamicIP.rima-tde.net] has joined #baserock | 08:14 | |
| persia | radiofree: My thought is that we ought upgrade things in a sensible way when they are upgraded. That not enough things are upgraded is also worthy of attention :) Newer gcc would be lovely. | 08:17 |
| *** Guest48475 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 08:19 | |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:26 | |
| fay is now known as Guest43272 | 08:26 | |
| Guest43272 is now known as fay_ | 08:26 | |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:01 | |
| pedroalvarez | I wanted to look at upgrading gcc but I didn't have time | 09:02 |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:06 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:07 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:11 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:28 | |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:52 | |
| *** benbrown_ [~benbrown@access.ducie-dc1.codethink.co.uk] has joined #baserock | 10:01 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:07 | |
| Mode #baserock +v ssam2 by ChanServ | 10:07 | |
| rdale | if i deploy a kvm image onto my host machine from a baserock guest kvm, is it possible to upgrade that image subsequently? | 10:10 |
| rdale | or do i need to delete it, and then redeploy? | 10:10 |
| Kinnison | If you can reach the one image from the other (e.g. by ssh0 then upgrades by ssh+rsync should be possible | 10:10 |
| persia | You ought be able to do so. | 10:10 |
| rdale | ah, so i need to have both kvm vms running in order to do an upgrade | 10:11 |
| SotK | yes | 10:11 |
| persia | Well, you'll need a development environment that can reach the target. | 10:12 |
| persia | If the target is a development environment, you can upgrade it internally. | 10:12 |
| persia | Similarly, if you have a development environment somewhere else entirely, with ssh access to the target VM, you can upgrade it. | 10:13 |
| rdale | both source and target kvm vms are development environments | 10:13 |
| persia | Then you can upgrade the target from the target, if you like. | 10:13 |
| persia | (cycle.sh is designed for this use case) | 10:13 |
| rdale | the cycle.sh script docs seem to imply that you can have multiple boot images inside the same kvm machine | 10:14 |
| persia | This is also the case. system-version-manager selects between them. | 10:14 |
| persia | When one "upgrades", one is really adding a new system and adjusting the default boot system. | 10:15 |
| rdale | are there docs on system-version-manager - is that a baserock thing? | 10:15 |
| persia | It is a baserock thing. The only docs I've seen are those from `system-version-manager --help` | 10:15 |
| persia | Strangely, `system-version-manager help` is unhelpful | 10:16 |
| rdale | :( | 10:16 |
| pedroalvarez | it's really tiny and intuitive.. but yeah, I think that because I wrote it :) | 10:17 |
| rdale | so i have a system 'factory' running which is my devel system. i would like a target system called 'web-devel' which is the one i'm developing and would like to use cycle.sh to flip from one to the other with reboots | 10:18 |
| persia | OK. Upgrade your system with your new target. Reboot. | 10:19 |
| persia | Then use system-version-manager to un-upgrade, remove the target, and upgrade into a new target. | 10:19 |
| rdale | and then i get a boot menu with both new and old systems? | 10:19 |
| pedroalvarez | yes, but with a timeout to boot the default one | 10:20 |
| persia | I never saw a boot menu, but I don't use KVM on my laptop for this, so this might be me. | 10:20 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:20 | |
| rdale | i've never seen a kvm boot menu | 10:20 |
| SotK | you only get it once you've done an upgrade | 10:21 |
| jjardon | paulsherwood: I'd try and replace python2 for python3 in core | 10:22 |
| persia | And only if you use the console and look at it. | 10:22 |
| persia | jjardon: That would break morph | 10:22 |
| jjardon | persia: I'm not building morph in my systems | 10:23 |
| jjardon | You can put python2 in the morph stratum | 10:23 |
| persia | heh, good point. | 10:23 |
| persia | I suppose we have already reached the point where we have to consider dual-installs of python :) | 10:24 |
| paulsherwood | jjardon: are you serious? i can try that | 10:24 |
| paulsherwood | this would be quite an invasive change, though (rebuild from core) | 10:25 |
| jjardon | If you can build core and foundation with python3, no need to have 2 versions of python there, I think | 10:26 |
| pedroalvarez | paulsherwood: I thought we didn't care about invasive changes anymore :) | 10:26 |
| persia | I thought the advantage of Baserock was that one could try invasive changes easily | 10:27 |
| paulsherwood | heh | 10:27 |
| jjardon | Can't agree more ;) | 10:28 |
| paulsherwood | if we go this route, would the default chunk be called 'python' or 'python3' ? and presumably invoking 'python' on command line would start python433? | 10:28 |
| paulsherwood | s/433/3/ ? | 10:28 |
| jjardon | Oy | 10:28 |
| jmacs | Am I right in saying that if I add "KERNEL_ARGS=net.ifnames=0" to the end of my morph deploy command, it should be used as a argument? | 10:29 |
| jjardon | Ups, sorry. Python3 I'd say | 10:29 |
| pedroalvarez | jmacs: that's almos true | 10:30 |
| jmacs | Almost? | 10:30 |
| pedroalvarez | jmacs: I'd put that inside the cluster morphology rather than appending it to the command line | 10:30 |
| persia | I think the chunk should be called 'python3', but I think we ought have *something else* that decides whether `python` calls `python2` or `python3` | 10:30 |
| jmacs | pedroalvarez: What would the format be then? "KERNEL_ARGS: net.ifnames=0" ? | 10:30 |
| pedroalvarez | jmacs: yes, I believe that there are some examples in definitions.git | 10:31 |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 10:31 | |
| jmacs | Also, should what I originally wrote work? If not we need to change the documentation. | 10:31 |
| persia | I think it should | 10:31 |
| pedroalvarez | jmacs: if you want it to use it in your command line, you have to put <deploy-key>.KERNEL_ARGS=net.ifnames=0 | 10:32 |
| pedroalvarez | s/it// | 10:32 |
| jmacs | What's a deploy-key? | 10:33 |
| pedroalvarez | Not sure if deploy-key is the name, but let me explain what it is | 10:33 |
| jjardon | IIRC, There is a PEP about that | 10:34 |
| jjardon | Yes: https://www.python.org/dev/peps/pep-0394/ | 10:34 |
| pedroalvarez | jmacs: http://paste.baserock.org/kapasaqera as you can see in this example, OPENSTACK_PASSWORD is not defined in the cluster morphology, and is added when calling morph deploy | 10:35 |
| paulsherwood | persia: what would be the 'something else' ? | 10:35 |
| pedroalvarez | jmacs: In this case "openstack-image" is the "deploy-key" | 10:35 |
| jmacs | pedroalvarez: OK, I'll bear that in mind. Is it documented anywhere? All I can find on the wiki is some stuff in old-tutorials/ | 10:36 |
| persia | paulsherwood: I think it would be another chunk, that just created the /usr/bin/python symlink | 10:36 |
| pedroalvarez | jmacs: this example was here: http://wiki.baserock.org/devel-with/ | 10:36 |
| paulsherwood | persia: hmmm. so if we have a system where by default that chunk is python => python3, and then i add morph-utils to it... morph requires python => python2 ... and chaos ensues? | 10:38 |
| persia | Chunks that depend on specific versions of python shouldn't expect /usr/bin/python to be a particular version. If they do, this is a bug. | 10:39 |
| persia | Either the code needs to be safe to run under either python2 or python3, or it needs to declare which it wants in the interpreter entry. | 10:40 |
| jjardon | paulsherwood Its recommended to have python==python2 if python2 is in the system: https://www.python.org/dev/peps/pep-0394/ | 10:45 |
| * persia suspects that at the time that PEP was written, lots of software still assumed /usr/bin/python was python2 | 10:46 | |
| paulsherwood | i think that is still the case | 10:47 |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:51 | |
| robtaylor | yeah, i run arch on my laptop and it has python==python3, when ever building something new I have to be careful | 10:54 |
| persia | Because so many of the larger distros have Python3 for /usr/bin/python, I think the set of things that needs python2 is not as large as when PEP 394 was written, but this may not include a number of non-desktop and non-server applications. | 10:56 |
| *** Guest8462 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 11:01 | |
| *** fay [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:02 | |
| fay is now known as Guest78070 | 11:02 | |
| * paulsherwood doesn't know how to frab so that morph would get python2, in a system with python3 as default python | 11:03 | |
| robtaylor | paulsherwood: #!/bin/env python2 rather than #!/bin/env python | 11:04 |
| paulsherwood | robtaylor: you man patch morph/*.py ? | 11:04 |
| *** fay_ [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 11:05 | |
| persia | Shouldn't be *.py: aren't most of them nonexecutable libraries? | 11:05 |
| robtaylor | paulsherwood: well, any files that have #! | 11:05 |
| paulsherwood | none of them at this point | 11:05 |
| robtaylor | paulsherwood: a quick look says morph, source-stats, and the scripts in scripts | 11:06 |
| Kinnison | the write and configuration extensions likely need tweaking too | 11:06 |
| robtaylor | paulsherwood: *.py are your nonexecutable libraries, as persia said. | 11:06 |
| robtaylor | Kinnison: yup | 11:06 |
| robtaylor | (using git grep python) | 11:07 |
| * robtaylor also notes that they were using #!/usr/bin/python which he always understood to be bad form =) | 11:08 | |
| Kinnison | git grep "^#\!.*python" | 11:09 |
| Kinnison | robtaylor: poor form for portable stuff. For a platform where you're in complete control it hardly seems an issue :-) | 11:09 |
| Kinnison | However, they all need fixing | 11:09 |
| robtaylor | Kinnison: true. That aim has only changed recently, i understand =) | 11:09 |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 11:10 | |
| * persia remembers writing innumerable patches to change "usr/bin/env python" to "usr/bin/python" in the past when embedding portable code into a fixed system | 11:13 | |
| persia | (the issue being that the portable code might pick up some random version of python someone installed, which would be a bad thing for a system library to do) | 11:13 |
| persia | s/library/utility/ | 11:14 |
| *** Guest8462 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:16 | |
| *** mauricemoss_ [~simonh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 11:24 | |
| radiofree | How big is the minimal system? | 11:29 |
| ssam2 | a couple of hundred MB I think | 11:32 |
| ssam2 | but I think it can be shrunk more quite easily | 11:33 |
| tiagogomes | hi baserockers, any special reason why the vbox vm setup page (http://wiki.baserock.org/guides/vm-setup/) uses both bridge and host-only network connectivity? With bridge you get both inside/outside access. I tended to use in the past host-only to access the VM from my host, and NAT to give external access to the vm. Other option is only use NAT and setup port forwarding to ssh the VM in a specific port | 11:33 |
| ssam2 | we don't strip it, for example | 11:33 |
| petefoth_ | tiagogomes: I *may* have changed that when trying to set up a VBox VM in Mac OS. If I recall, it didn't work without a host-only adapter | 11:34 |
| tiagogomes | also gunzip seems to be missing the "-d" option for "Using Ubuntu or Debian with KVM" instructions | 11:34 |
| persia | tiagogomes: I always use host networking with NAT, because I'm rarely in an environment where bridge actually works reliably. | 11:35 |
| paulsherwood | radiofree: 321.7M unstripped :/ | 11:35 |
| paulsherwood | (x86_64) | 11:35 |
| tiagogomes | petefoth it is working for me, but you need to change the adapter type from the default. Intel PRO/1000 T Server works for me | 11:35 |
| persia | paulsherwood: To be fair, that isn't only unstripped, but also includes all the artifacts generated by the sources, so lots of extra stuff that may not be so useful in the delivered system. | 11:36 |
| petefoth_ | tiagogomes: feel free to modify that page :) | 11:36 |
| ssam2 | paulsherwood: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/remove-gcc.configure?h=baserock/sam/chef-from-git shrinks it my 200MB, according to my former self | 11:36 |
| ssam2 | *by | 11:36 |
| tiagogomes | persia yep, and host-only + NAT seems a bit more secure | 11:37 |
| ssam2 | (forgets why richard maw is implicated in that comment) | 11:37 |
| ssam2 | s/forgets/I forget/ | 11:37 |
| persia | tiagogomes: Feel free to document it as an alternative, or use it yourself. Some folk don't like it because it means extra fussing on the host. | 11:37 |
| pedroalvarez | radiofree, paulsherwood< IIRC the minimal system can be reduced if we do a finer splitting on gcc merging this patch: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/commit/?h=baserock/pedroalvarez/finer-splitting-gcc&id=80f23407c109b22e2c877a1114abac5b3a33918f | 11:45 |
| paulsherwood | pedroalvarez: +1, then! :) | 11:57 |
| pedroalvarez | hahah note, it's a quite invasive change :P | 11:57 |
| tiagogomes | it'd be also worth mention that /etc/network/interfaces is not configured to automatically dhcp the eth1 interface | 11:58 |
| pedroalvarez | /etc/network/interfaces is not used anymore with new systemd | 11:59 |
| *** Guest78070 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 12:01 | |
| tiagogomes | pedroalvarez with systemd 204 adding configuration for eth1 made it to get in a ip address on boot | 12:01 |
| persia | tiagogomes: Ah, you want systemd > 217. | 12:03 |
| pedroalvarez | s/>/</? | 12:04 |
| pedroalvarez | s/>/>=/? | 12:04 |
| tiagogomes | persia, I don't know how old is my baserock VM. I download the one that is on the wiki. /etc/os-release could show more information | 12:06 |
| persia | tiagogomes: That should probably get updated, and it is unfortunate it was released during the transition. | 12:06 |
| persia | Once you have network, use cycle.sh to upgrade to the new one. | 12:07 |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 12:07 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 240 seconds] | 12:09 | |
| *** Guest78070 [~fay@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:23 | |
| Guest78070 is now known as fay_ | 12:24 | |
| CTtpollard | once gerrit is in place, would GerritBot be put in place for this channel, or would it be considered to much noise? | 12:27 |
| CTtpollard | s/to/too | 12:29 |
| ssam2 | I think I'd find it annoying | 12:33 |
| ssam2 | we could always run it in a separate #baserock-commits channel though | 12:33 |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 12:34 | |
| CTtpollard | that would be my issue, I've found it useful in certain openstack channels, but it's highly variable on channel & commit traffic | 12:34 |
| persia | Given the speed of patches arriving to the mailing list, I think it wouldn't be disruptive. | 12:36 |
| persia | But if we have automation submitting candidate patches, I think I'd prefer not to see that in-channel. | 12:37 |
| CTtpollard | yes, maybe some thinking toward what is and isn't broadcasted is needed | 12:38 |
| CTtpollard | the config of GerritBot looks quite customisable, for instance you can set it to only broadcast merges to master, or patch sets etc | 12:42 |
| petefoth_ | another vote her for not having GerritBot broadcasting in this channel | 12:43 |
| petefoth_ | s/her/here/ | 12:43 |
| pedroalvarez | can it be configurable to be more or less chatty? | 12:53 |
| CTtpollard | pedroalvarez: this is what I'm referring: https://github.com/openstack-infra/gerritbot/blob/master/doc/source/installation.rst | 12:54 |
| persia | petefoth_: In the absence of such broadcasting, would you prefer automated mail to baserock-dev? In the absence of either, how do you anticipate we will become aware of new/updated patchsets? | 12:59 |
| petefoth_ | persia: either automated mail, with a subject line that makes it easy to filter, and/ or a separate irc channel as sggested by ssam2. My objection to having it here is a: that not everyone here is interested in code changes, and it is not easy to filter out in irc and b: if it becomes, 'high-traffic' * it could swampt the channel. (*Unlikely, but you never know) | 13:02 |
| persia | If we have enough patches for it to be high-traffic, I'll agree with you. | 13:03 |
| persia | But I don't like automated mail, because it clogs my mail system, and is pointlessly verbose when a single line will do. | 13:03 |
| pedroalvarez | CTtpollard: and it looks configurable | 13:03 |
| ssam2 | I prefer polling for new patch sets when I have capacity to review them, rather than being interrupted in the middle of conversations by a bot .. | 13:03 |
| persia | And I have prior experience with watching separated channels not work at all. | 13:03 |
| persia | I have seen many fruitful conversations helped by such bots. For example, one does something and pushes. Someone else glances at it, and replies to you on IRC, etc. | 13:04 |
| persia | But I agree that if there is sufficient volume to interrupt or distract, it can be bad. Gerritbot doesn't tend to be that chatty, in my experience, but others may have had different experiences. | 13:05 |
| ssam2 | that sounds like it encouranges people to do reviews outside the review tool, which doesn't seem good | 13:05 |
| ssam2 | encourages | 13:06 |
| CTtpollard | ssam2: what exactly is the review tool, just the mailing list? | 13:07 |
| persia | I suppose it depends on the point of the review tool. Generally speaking, I don't care about the details of why something got redone, rather just that it was redone. | 13:07 |
| ssam2 | tpollard: currently, but we should be switching to Gerrit | 13:07 |
| CTtpollard | so if the bot provides a url straight to the patch where you could comment and vote, surely that's a good thing? | 13:08 |
| ssam2 | it could be helpful in some situations | 13:09 |
| CTtpollard | one of the reasons I've brought this is up is I'm currently on a channel where a lot of the changes take place in US timezone, so having the backscroll of changes the following day is useful to me | 13:09 |
| ssam2 | does Gerrit lack a useful change log? I figured that the 'Open changesets' page would be good enough | 13:09 |
| ssam2 | but I haven't used Gerrit much. If the only way to get a useful change feed is to run a bot in IRC, then that's a good argument in favour of doing so | 13:09 |
| petefoth_ | Ibelieve that's the point (one of the points) of Gerrit - you can go into a view with a list of the stuff you are interested in | 13:11 |
| petefoth_ | If you need a feed, why not do RSS/Atom so those who are interetsed can subscrive, and those who aren't don't get their irc interrupted? | 13:12 |
| CTtpollard | a way for users who don't want a bot could be /ignore , but that is far from ideal | 13:12 |
| straycat | put the bot in another channel, people who care can join that | 13:42 |
| straycat | in my experience bots annoy people here | 13:43 |
| straycat | also why am i here | 13:43 |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [] | 13:43 | |
| paulsherwood | ? | 13:44 |
| persia | I believe the above to be evidence of straycat becoming slightly better at being on holiday. | 13:47 |
| paulsherwood | :) | 13:54 |
| * paulsherwood wonders what causes the setup of links for /usr/bin/python* | 13:56 | |
| Kinnison | cpython's install target IIRC | 14:01 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 14:01 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:03 | |
| paulsherwood | i can't see that in the morph file.... http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/core/cpython.morph | 14:08 |
| Kinnison | I mean, *cpython*'s install target, not the morphology commands | 14:10 |
| Kinnison | i.e. it'll be part of the makefiles | 14:10 |
| paulsherwood | ah | 14:10 |
| paulsherwood | so the behaviour i've noticed is when trying python3 as default, it doesn't seem to link python-config by default | 14:11 |
| paulsherwood | causing gobject-introspection to report 'checking for headers required to compile python extensions... ./configure: line 14520: /usr/bin/python-config: No such file or directory' | 14:12 |
| * paulsherwood is thinking he's the wrong person to be digging this hole | 14:12 | |
| persia | If you don't understand it, and are willing to admit it, and have the time to collect feedback from others, you're the perfect person. If other conditions apply, perhaps not. | 14:13 |
| paulsherwood | i think i already demonstrated 1 and 2 :) | 14:14 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 14:15 | |
| paulsherwood | i tried setting up the link myself, adn got a bit further... http://paste.baserock.org/rapujivoho | 14:15 |
| persia | That looks to me like the headers are different in some way, but I don't know enough about python headers to suggest and good way to deal with 2/3 issues. | 14:17 |
| robtaylor | paulsherwood: i'd crib how arch does it https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gobject-introspection | 14:17 |
| robtaylor | (and this trick will work other places that assume python 2) | 14:18 |
| robtaylor | though its pretty fugly (sed -i '1s|#!/usr/bin/env python$|&2|' giscanner/*.py) | 14:19 |
| persia | Waugh! | 14:19 |
| robtaylor | the results of that sed should really just be send upstream | 14:19 |
| persia | Yes. | 14:20 |
| persia | Or some sort of sixish thing done | 14:20 |
| robtaylor | upstream would be good, i'm sure colin will take a patch for that | 14:20 |
| robtaylor | sixish? | 14:20 |
| persia | From what I understand, things that work with python2 and python3 are sixish, and much of them use the python library six. | 14:23 |
| persia | https://pypi.python.org/pypi/six | 14:24 |
| paulsherwood | this defeats the possibility of moving python2 to morph-utils, i believe? | 14:25 |
| paulsherwood | jjardon: do you have some reason to believe it's possible to build gobject-introspection with python3? | 14:25 |
| robtaylor | paulsherwood: yes, you'd need both python3 and python2 on a system using g-i | 14:25 |
| robtaylor | paulsherwood: its coding to fix it - the API changed | 14:26 |
| robtaylor | (and i presume noones volunteered to do that yet) | 14:26 |
| jjardon | paulsherwood: oh yeah, gobject-introspection has not been ported to python3 | 14:26 |
| robtaylor | paulsherwood: the api changes were the cause of those errors you got , btw :) | 14:27 |
| paulsherwood | ok. on that basis i stand by the patch series i already sent :) | 14:27 |
| robtaylor | paulsherwood: sounds good =) | 14:27 |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 14:28 | |
| *** Zara [~zarazaime@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 272 seconds] | 14:39 | |
| *** Zara [~zarazaime@access.ducie-dc1.codethink.co.uk] has joined #baserock | 14:40 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 14:48 | |
| Krin | so if I'm pushing a change to the lorries, the change has a +1, (is it one or two of those I need?) with notes for a change that I need to do at merge. I'v performed said change, is it a simple re-base of the current working branch followed by switching to master and then merge in my branch? ...yes I'm still scared of blowing things up with git | 14:57 |
| Kinnison | Krin: if you're worried, punt the changed branch to the git server and ask someone here to double-check it via http://git.baserock.org/ | 14:57 |
| Kinnison | Krin: better safe than sorry with that configuration | 14:58 |
| SotK | you need +2 (so two +1s or one +2) before merging :) | 14:58 |
| SotK | and that is what I do when merging, yes (`git merge my/feature/branch --no-ff` - using --no-ff so that I get a merge commit) | 14:59 |
| Krin | does anyone have time to quickly review the small .lorry addition? with the patch e-mail labelled "[PATCH] Lorrying in zookeeper project" | 15:00 |
| persia | Note that when "fixing something at merge time", one is expected to cause the commit that introduced the thing to be fixed to be modified to contain the fix. | 15:09 |
| *** petefoth_ [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: petefoth_] | 15:10 | |
| *** petefoth [~petefoth@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 15:10 | |
| CTtpollard | persia: as in git amend? | 15:15 |
| persia | I think that is the easiest way. The other is to insert a commit between two others, and interactively rebase, squashing the commits. | 15:16 |
| persia | Note that if one chooses git amend, one still needs to rebase, but can (usually) do so non-interactively. | 15:16 |
| * Krin blinks, reads the above and goes on a google hunt to find out how to do any of that rather than simply have anoher commit afterwards showing the changes | 15:22 | |
| persia | Krin: The way I do it is as follows: | 15:25 |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 15:25 | |
| persia | 1) `git fetch` to update the database to match upstream | 15:26 |
| persia | 2) `git rebase master` to reparent my patchset on current master | 15:26 |
| persia | 3) `git log --oneline master..` to get a short list of all my patches and new shortshas. | 15:26 |
| persia | 4) `git checkout <sha>` for one of the patches | 15:27 |
| persia | 5) fix stuff | 15:27 |
| persia | 6) `git commit --amend` to update my changes. | 15:27 |
| persia | 7) `git checkout mybranch` to get back to the branch | 15:27 |
| persia | At this point, git complains I'm leaving an orphan commit, and tells me the SHA | 15:27 |
| persia | 8) `git rebase -i <<SHA>>` where <<SHA>> is the one git provided while complaining | 15:28 |
| persia | I then drop the old version of the commit from my patchset to be rebased. | 15:28 |
| persia | The alternative is to not use --amend in step 6, and then use squash when rebasing in step 8. | 15:28 |
| radiofree | why not just commit the change, use git rebase -i and move that commit + squash | 15:44 |
| radiofree | or git rebase -i, edit the commit in question, then rebase --continue | 15:45 |
| persia | Mostly because that's more magic that my grimoire contains :) | 15:46 |
| Krin | i have no idea if what i just did worked... wait i have to cherry pick now? | 15:46 |
| persia | Why are you cherrypicking? | 15:46 |
| Krin | i followed your instructions and it informed me "you are now cherrypicking" | 15:47 |
| Krin | or at least i think i followed your instructions... i really hate git sometimes | 15:47 |
| persia | Nothing in my instructions should have been a cherrypick, and now I'm confused, because I'm not sure how you got that message. | 15:56 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 16:00 | |
| Krin | well franred helped me fix it, and i'm still baffled with what may have caused the cherry picking. but i'm going to back away slowly from it now as it's working... | 16:03 |
| persia | heh | 16:04 |
| * Krin has a very bad relationship with git and swears blind that other people entering the same commands as him has vastly different results. the logical part of his mind denies this | 16:05 | |
| paulsherwood | SotK: is there a working Mason thing we can play with? | 16:06 |
| *** mdunford [~marcdunfo@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:12 | |
| pedroalvarez | paulsherwood: not sure, but I think that there is a working one, and is linked to gerrit: http://testgerrit.baserock.org:8080/#/q/status:open | 16:13 |
| pedroalvarez | so if you send a patch for review, mason tests it | 16:14 |
| paulsherwood | is that open to all-comers? | 16:16 |
| pedroalvarez | not 100% sure, but I believe that everybody can get an account in gerrit, and send patches for review | 16:17 |
| pedroalvarez | maybe they changed the configuration, but it should be open | 16:17 |
| franred | the testgerrit is not in production yet, AFAIK, it is just for testing | 16:18 |
| pedroalvarez | indeed, so please, don't use it yet until Sam or Adam say that we can | 16:19 |
| pedroalvarez | i wonder if it will test on various architectures | 16:20 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 16:23 | |
| paulsherwood | pedroalvarez: only one way to find out :) | 16:28 |
| * paulsherwood is failing to log in, though | 16:29 | |
| pedroalvarez | I don't know how would you know how many architectures is testing, though | 16:29 |
| pedroalvarez | and... it is deploying to openstack to test that the new system can build as well, and I don't think we can do that with arm | 16:32 |
| persia | Just needs ARM compute nodes in the OpenStack :) | 16:34 |
| pedroalvarez | I wonder how the different architecutres available would appear in nova | 16:36 |
| persia | I don't know. http://trystack.org/ had something working for a while, but it is facebook-only login, so I didn't explore that much. Last I heard, there were no more ARM nodes available, but I may be out of date. | 16:38 |
| pedroalvarez | I tested that one, but only the x86. | 16:39 |
| pedroalvarez | It looked to me as 2 different clouds | 16:39 |
| persia | Hrm. I've seen various specs for nova to have multiple backends or different resource pools for different hypervisors. I don't know the implementation status of them currently. | 16:40 |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:52 | |
| *** bashrc [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 17:53 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 256 seconds] | 18:05 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:10 | |
| *** Guest8462 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:21 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 18:36 | |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has joined #baserock | 18:46 | |
| *** straycat [~straycat@vortis.xen.tardis.ed.ac.uk] has quit [] | 18:48 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 20:33 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 20:36 | |
| *** rdale [~quassel@197.Red-2-137-105.dynamicIP.rima-tde.net] has quit [Ping timeout: 265 seconds] | 20:58 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has quit [Ping timeout: 245 seconds] | 21:02 | |
| *** jmacs [~jimmacart@access.ducie-dc1.codethink.co.uk] has joined #baserock | 21:02 | |
| *** rdale [~quassel@167.Red-83-35-194.dynamicIP.rima-tde.net] has joined #baserock | 21:06 | |
| *** rdale_ [~quassel@223.Red-79-157-221.dynamicIP.rima-tde.net] has joined #baserock | 21:31 | |
| *** rdale [~quassel@167.Red-83-35-194.dynamicIP.rima-tde.net] has quit [Read error: Connection reset by peer] | 21:31 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 21:33 | |
| genii is now known as ChristmasPresent | 21:35 | |
| *** rdale [~quassel@79.Red-79-145-105.dynamicIP.rima-tde.net] has joined #baserock | 21:35 | |
| ChristmasPresent is now known as genii | 21:38 | |
| *** rdale_ [~quassel@223.Red-79-157-221.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] | 21:38 | |
| genii is now known as ChristmasPresent | 21:55 | |
| ChristmasPresent is now known as genii | 21:56 | |
| genii is now known as ChristmasPresent | 22:10 | |
| ChristmasPresent is now known as genii | 22:11 | |
| genii is now known as ChristmasPresent | 23:47 | |
| ChristmasPresent is now known as genii | 23:48 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!