| sarnold | wwalker: well, there's a good chance the init daemon won't even pass it along to the services. but it seemed worth suggesting :) | 00:00 |
|---|---|---|
| wwalker | good point | 01:41 |
| === JanC is now known as Guest9817 | ||
| === JanC_ is now known as JanC | ||
| eagles0513875|2 | hi all can someone help me understand what exactly is MaaS please is it a hypervisor of some sort that allows one to run vm's on top of it? | 04:48 |
| === iberezovskiy|off is now known as iberezovskiy | ||
| eagles0513875|2 | hi all can someone help me understand what exactly is MaaS please is it a hypervisor of some sort that allows one to run vm's on top of it? | 08:43 |
| ikonia | no | 08:56 |
| ikonia | it's a bare metal manager to manage interactions of tools/systems to do around build/provisioning | 08:56 |
| === amoralej|off is now known as amoralej | ||
| === Thumpxr_ is now known as Thumpxr | ||
| frickler | jamespage: we need oslo.privsep 1.13.1 for newton please, see https://review.openstack.org/#/c/406504/ , this is blocking chef integration testing currently | 11:06 |
| jamespage | coreycb, zul: ^^ | 11:06 |
| frickler | jamespage: thx, also, do you have a ceph-10.2.5 build yet? I'm hoping that this will finally fix all issues we have with 10.2.3 | 11:09 |
| jamespage | frickler, not yet and avoiding .4 on upstream advice :-) | 11:17 |
| jamespage | frickler, my window for getting that done pre-christmas is rapidly diminishing | 11:18 |
| jamespage | frickler, https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1649856 | 11:22 |
| ubottu | Launchpad bug 1649856 in ceph (Ubuntu Zesty) "[SRU] ceph 10.2.5" [Undecided,New] | 11:22 |
| jamespage | I'll try get PPA builds up today | 11:22 |
| frickler | jamespage: great, thx. if you ping me once they are built, I can give them a spin on my test cluster | 11:30 |
| === aruns is now known as Guest70478 | ||
| jamespage | frickler, they will appear here https://launchpad.net/~openstack-ubuntu-testing/+archive/ubuntu/ceph-sru/+packages | 11:44 |
| jamespage | takes some time | 11:44 |
| === amoralej is now known as amoralej|lunch | ||
| DirtyCajun | so... in apache... Why would a .conf file without an ssl cert pick up the cert from another .conf ? | 13:07 |
| lordievader | Depends on how the value is set I suppose, if it is set as a global... | 13:08 |
| DirtyCajun | see thats the thing. its defined explicitly in foo.conf in sites. bar.conf does not have it. If both are enabled... and you browse to bar it uses foo cert. if you disable foo then bar does not use the cert | 13:09 |
| lordievader | Without seeing any configuration I cannot really help. | 13:10 |
| coreycb | frickler, I've uploaded a new version of python-oslo.privsep with that fix to the yakkety review queue | 13:37 |
| coreycb | jamespage, can you promote the following when you get a moment please? cinder 1:2015.1.4-0ubuntu1.1 and python-glanceclient 1:0.15.0-0ubuntu1~cloud1 are ready to promote to kilo-updates, and liberty-proposed is ready to promote to liberty-updates | 13:41 |
| cyphermox | smoser: not sure if it's directly related to the cloud-init upload that happened recently, but I have some issues with running cloud-init to build up an autopkgtest image: http://paste.ubuntu.com/23628778/ | 13:50 |
| cyphermox | oh, scratch that, I think I see what the issue is | 13:51 |
| === amoralej|lunch is now known as amoralej | ||
| smoser | cyphermox, what was ait ? | 14:22 |
| smoser | s/ait/it/ | 14:22 |
| cyphermox | my sponsored upload of os-prober missing a depends on grub-common. I suspect grub-common isn't typically on these images | 14:23 |
| === giraffe is now known as Guest59158 | ||
| frickler | coreycb: thanks, can you tag it for xenial uca, too, or will that happen automatically? | 14:57 |
| coreycb | frickler, it's tagged for newton uca, which is xenial | 14:58 |
| cyphermox | how does one import a new upstream in the git imports? | 15:10 |
| cyphermox | nacc: rbasak: smoser: ^ | 15:10 |
| smoser | cyphermox, a new upstream ? | 15:11 |
| cyphermox | upstream tarball | 15:11 |
| cyphermox | is it straight g | 15:11 |
| smoser | you upload to ubuntu and then the importer pulls it. | 15:11 |
| cyphermox | gbp? | 15:11 |
| cyphermox | well, say I wanted to use that branch as a base for new uploads | 15:11 |
| smoser | are you speaking locally ? | 15:11 |
| rbasak | Interesting question. | 15:11 |
| smoser | yeah. | 15:11 |
| rbasak | I don't think we've considered that use case. | 15:12 |
| rbasak | The importer doesn't particularly care what you do, as long as you end up with a commit whose tree matches your subsequent upload (currently patches-unapplied). | 15:12 |
| rbasak | We don't have any tooling that will do that for you, I don't think. | 15:13 |
| rbasak | But you could use uscan for example and then "git add -Af" or similar. | 15:13 |
| cyphermox | alright, I think I can fudge around it and I'll write up doc for that use case | 15:13 |
| rbasak | Or gbp tooling. | 15:13 |
| cyphermox | right | 15:13 |
| cyphermox | we'll use gbp and convince it to do the right thing | 15:13 |
| rbasak | I'm not sure we have worked out how to feed the importer the upload tags properly yet. | 15:13 |
| rbasak | So is it worth doing it this way right now? | 15:14 |
| rbasak | We need to talk to the Launchpad team about this. | 15:14 |
| rbasak | Or you can give your upload tag to nacc, smoser or to me. And we can push it. | 15:14 |
| rbasak | But that has to be before anyone attempts to run the importer against lpusip. | 15:14 |
| rbasak | Or more specifically, before someone does an importer run to push to lpusip. | 15:15 |
| nacc | cyphermox: in my case (php), i've done a uupdate, which creates a new working directory, git added those contents in place of the current working tree, and committed that as a new version to publish. as rbasak suggests, you would then need a way to feed the upload tag in | 15:24 |
| nacc | rbasak: sorry about the icingaweb2 bug, will fix | 15:24 |
| cyphermox | my interest is not so much in the upload itself (presumably we can upload and go import again) | 15:46 |
| cyphermox | but the whole process for doing a new upstream release seems broken | 15:47 |
| cyphermox | or at least, you can't use gbp, because you have no upstream branch and no master, and if you fudge it, you likely still don't have the right ancestry | 15:47 |
| nacc | cyphermox: ah i see what you mean | 15:47 |
| cyphermox | (I know because I did some of the obvious dance to try to make it work) | 15:47 |
| nacc | cyphermox: right, we don't have an upstream branch, but we do use upstream tags | 15:48 |
| cyphermox | I have the commands here and I'll document what I did | 15:48 |
| nacc | cyphermox: we actually use gbp import-orig in the importer to do that | 15:48 |
| nacc | cyphermox: sounds good, we probably can abstract out our 'see if this is a new upstream' code to be a standalone command | 15:48 |
| cyphermox | oh, I suppose I should have used a different master branch too, doh | 15:48 |
| cyphermox | so what do you use instead of an upstream branch to keep just the pristine source without debian/? | 15:49 |
| nacc | cyphermox: so we have an upstream branch we throw away, as all upstreams are reachable via tags | 15:50 |
| nacc | cyphermox: our use case was purely smoser's which was being able to use pristine-tar to recreate the orig tarball | 15:50 |
| nacc | so he could build locally after a clone w/o talking to launchpad at all (as we also have a the historical DSC files) | 15:50 |
| cyphermox | that doesn't help cuttin new upstream releases though | 15:51 |
| nacc | right, it's a different use case :) | 15:51 |
| nacc | cyphermox: can you file a bug? | 15:51 |
| cyphermox | yeah | 15:51 |
| cyphermox | I will, just trying to grab enough documentation on how close we are to this working before I do | 15:51 |
| nacc | cyphermox: all of the workflow use cases are 'new' in some sense -- we cover some by chance, but others, like this one, may require more changes :) | 15:52 |
| nacc | cyphermox: thanks! | 15:52 |
| cyphermox | nacc: AFAIK all that is missing is some ancestry links, because I was very close to having the right commands | 15:57 |
| nacc | cyphermox: ah ok, between the upstream tags? (which is basicaly what keeping the branch would get you) | 15:57 |
| nacc | cyphermox: we *could* keep the branch, it was just that rbasak iirc, had a reason not to | 15:57 |
| cyphermox | probably that | 15:57 |
| cyphermox | or because gbp or git aren't finding the upstream/2.0.0 tag behind the original upload of 2.0.0 in ubuntu/zesty-devel | 15:58 |
| cyphermox | (looking at juju-core, to be precise) | 15:58 |
| cyphermox | now I have a reproducer. | 15:59 |
| nacc | always good :) | 15:59 |
| cyphermox | where should I file a bug? | 15:59 |
| nacc | https://bugs.launchpad.net/usd-importer please | 15:59 |
| cyphermox | zug zug | 16:00 |
| === pavlushka is now known as The_Doctorman | ||
| === The_Doctorman is now known as pavlushka | ||
| rbasak | nacc, cyphermox: I tend not to use tags unless they're supposed to be a thing that moves. | 16:03 |
| rbasak | nacc, cyphermox: I tend not to use *branches* unless they're supposed to be a thing that moves. | 16:03 |
| rbasak | And import artifacts generally don't move, so they're all tags. | 16:03 |
| nacc | rbasak: right, but it he case of gbp, it has some presumptions i think | 16:04 |
| rbasak | What parenting do the upstream tags end up with? | 16:04 |
| nacc | cyphermox: i'd need to see the workflow int he bug, as it does seem like the tag has history correctly, so it might just be a tooling issue to get that correct | 16:04 |
| nacc | rbasak: they *seem* to be correct (it just ends up being the sequence in which we see new upstreams) | 16:05 |
| nacc | rbasak: but i'm not sure what correct would be for cyphermox's case | 16:05 |
| rbasak | I suppose that's OK. I don't like the implication that they have a defined ordering though. | 16:05 |
| nacc | rbasak: right, but using gbp import-orig doens't allow for any flexibility there | 16:06 |
| rbasak | For example, although a packager shouldn't do it, bumping epoch could allow the upstream version to go backwards. I'm not sure what would happen then. | 16:06 |
| nacc | so either we don't import upstreams or we right yet another tool, or we leave it :) | 16:06 |
| nacc | *wrtie | 16:06 |
| nacc | gah | 16:06 |
| rbasak | gbp assumes that the packager is supplying correct upstream version ordering information, using import-orig or by pulling from an upstream git repo. | 16:06 |
| rbasak | The importer doesn't have that luxury. | 16:06 |
| rbasak | I think the solution is a uscan wrapper tool. | 16:07 |
| rbasak | Or something to provide richer history if the packager wants to provide that. | 16:08 |
| rbasak | Merging in the upstream branch would work too! | 16:08 |
| nacc | *if* we had the upstream branch | 16:08 |
| rbasak | If we don't, then a uscan/uupdate wrapper is the only option, right? | 16:09 |
| nacc | and do you mean 'upstream' in the gbp sense or upstream VCS sense | 16:09 |
| nacc | no, i mean, we explicitly don't pust the upstream branch from gbp right now | 16:09 |
| rbasak | I meant upstream VCS sense, but I think they're equivalent. | 16:09 |
| cyphermox | https://bugs.launchpad.net/usd-importer/+bug/1649940 for your hacking pleasure. | 16:09 |
| ubottu | Launchpad bug 1649940 in usd-importer "can't prepare new upstream releases using gbp" [Undecided,New] | 16:09 |
| nacc | they have different histories (gbp import-orig does nto provide a rich history afaict) | 16:10 |
| cyphermox | well, something really simple is missing from the look of things | 16:10 |
| cyphermox | but I don't know enough about git internals to know what | 16:10 |
| nacc | right, so this goes back to we don't *really* use gbp int he importer | 16:14 |
| nacc | we do, just to pull orig tarballs in | 16:14 |
| nacc | so that smoser can work offline, but we don't necessarily maintain state in a way that gbp understands | 16:14 |
| cyphermox | well, it's close enough tbf | 16:14 |
| cyphermox | ie. git checkout -b upstream upstream/<previous version> work well to get back an upstream branch | 16:15 |
| nacc | right, that makes sense | 16:15 |
| nacc | yeah, i think the other thing we don't do currently is merge upstream in | 16:15 |
| nacc | it's a standalone history of just upstream objects | 16:15 |
| cyphermox | right | 16:15 |
| nacc | that's probably what is most fundamentally broken for your use case :) | 16:16 |
| cyphermox | well you could fudge that by adding the right bits, presumably? | 16:16 |
| nacc | right, but we'd have to reimport probably, too | 16:16 |
| cyphermox | ie. the upload itself is a merge of upstream and debian pieces | 16:16 |
| nacc | and we'd need to figure out what is supposed to be there | 16:16 |
| cyphermox | otherwise making a tool that DTRT wrt flipping the right bits so that an upstream branch can be attached or copied into the debian branch would work. | 16:17 |
| nacc | yeah | 16:18 |
| cyphermox | my opinion is until you have an equivalent to bzr merge-upstream you can't really claim it to be UDD | 16:18 |
| cyphermox | cutting new upstream releases is a very import use case.. now whether or not we use gbp for it is not that important (at least, not to me) | 16:19 |
| cyphermox | I was just tryin | 16:19 |
| nacc | right, the claims of 'being udd' were never actually made :) | 16:19 |
| cyphermox | ugh | 16:19 |
| nacc | but yeah -- i also think we have a separate discussion to figure out, potentially, as even if this could be made to work | 16:19 |
| nacc | the only thing the importer sees outside of launchpad is 'upload' tags | 16:20 |
| cyphermox | trying to find a way to make it so the juju team can cut new releases based on the right things (basically, what is in the archive) without having to recreate branches every time | 16:20 |
| cyphermox | nacc: it worked in bzr, so it's definitely possible | 16:20 |
| nacc | cyphermox: oh i'm not saying it's not possible | 16:20 |
| nacc | cyphermox: i'm saying we may not have covered this use-case :) | 16:20 |
| cyphermox | AFAICT it's just a matter of doing the right grafting of the right bits in the right places ;) | 16:20 |
| cyphermox | right right | 16:21 |
| nacc | lots of "right" which tends to be easy to get "wrong" :) | 16:21 |
| cyphermox | ofc that grafting operation might be quite complex ;) | 16:21 |
| nacc | heh | 16:21 |
| cyphermox | so far so good, I like the process | 16:21 |
| cyphermox | it was very close to working. | 16:21 |
| rbasak | I think we have the structure correct. We just need a tool that takes an upstream tarball into that structure. | 16:22 |
| rbasak | And we need to make some decisions as to what form such an import should take, since the importer will accept anything. | 16:22 |
| cyphermox | and merge that upstream structure into the ubuntu branches | 16:22 |
| rbasak | Yes. That's a job to do locally. The importer will accept the parent it's given. | 16:23 |
| nacc | right, i think this is a subcase of our generic "how to add an external upstream" discussion last week | 16:23 |
| nacc | and how to find objects in it, of course | 16:23 |
| nacc | presuming that could be made to work, you'd get rich history via merges (with a new 'upstream parent' parent) | 16:24 |
| rbasak | I think we already have this solved (with no effort) when it's an upstream git branch you're pulling in. Just merge it, and it'll work. | 16:24 |
| nacc | rbasak: true | 16:24 |
| rbasak | It's the halfway cause of upstream-release-tarball but Ubuntu-side-in-git that we need tooling for. | 16:24 |
| rbasak | halfway case | 16:24 |
| === iberezovskiy is now known as iberezovskiy|off | ||
| xibalba_ | a | 18:46 |
| xibalba_ | hey guys i'm looking at my ntp.conf and i see the default line, restrict default kod nomodify notrap nopeer noquery, but then there is an additional restrict line restrict 192.168.0.0 mask 255.255.255.255 nomodify notrap noquery, and i'm wondering which one applies here? | 18:47 |
| xibalba_ | also the 255.255.255.255 would make me thing it only allows one ip, but it appears many can connect to it | 18:47 |
| sarnold | xibalba_: if you start fiddling with those lines it'd be best to understand this doc completely http://support.ntp.org/bin/view/Support/AccessRestrictions | 18:57 |
| xibalba_ | yeh no changes yet ust trying to understand this better | 18:57 |
| xibalba_ | ill go through that doc now | 18:57 |
| sarnold | good good :) | 18:58 |
| sarnold | it all made sense to me once, for one afternoon, hehe | 18:59 |
| xibalba_ | though im stepping back a moment, i think somewhere/somehow there is an acl in my network. did a tcpdump on the ntpd side and never saw an incoming packet from this particular how | 19:09 |
| === amoralej is now known as amoralej|off | ||
| sarnold | filtering unexpected ntp at the borders seems like a useful thing to do, yes :) | 19:12 |
| xibalba_ | no borders, this is all internal :) | 19:19 |
| === Guest34309 is now known as IO | ||
| === IO is now known as IdleOne | ||
| === petevg is now known as petevg_afk | ||
| === RezaA is now known as xibalba_ | ||
| === GMR-Master is now known as teranet | ||
| === EvilAngel is now known as Guest89785 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!