sarnoldwwalker: 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
wwalkergood point01:41
=== JanC is now known as Guest9817
=== JanC_ is now known as JanC
eagles0513875|2hi 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|2hi 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
ikoniait's a bare metal manager to manage interactions of tools/systems to do around build/provisioning08:56
=== amoralej|off is now known as amoralej
=== Thumpxr_ is now known as Thumpxr
fricklerjamespage: we need oslo.privsep 1.13.1 for newton please, see https://review.openstack.org/#/c/406504/ , this is blocking chef integration testing currently11:06
jamespagecoreycb, zul: ^^11:06
fricklerjamespage: 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.311:09
jamespagefrickler, not yet and avoiding .4 on upstream advice :-)11:17
jamespagefrickler, my window for getting that done pre-christmas is rapidly diminishing11:18
jamespagefrickler, https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/164985611:22
ubottuLaunchpad bug 1649856 in ceph (Ubuntu Zesty) "[SRU] ceph 10.2.5" [Undecided,New]11:22
jamespageI'll try get PPA builds up today11:22
fricklerjamespage: great, thx. if you ping me once they are built, I can give them a spin on my test cluster11:30
=== aruns is now known as Guest70478
jamespagefrickler, they will appear here https://launchpad.net/~openstack-ubuntu-testing/+archive/ubuntu/ceph-sru/+packages11:44
jamespagetakes some time11:44
=== amoralej is now known as amoralej|lunch
DirtyCajunso... in apache... Why would a .conf file without an ssl cert pick up the cert from another .conf ?13:07
lordievaderDepends on how the value is set I suppose, if it is set as a global...13:08
DirtyCajunsee 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 cert13:09
lordievaderWithout seeing any configuration I cannot really help.13:10
coreycbfrickler, I've uploaded a new version of python-oslo.privsep with that fix to the yakkety review queue13:37
coreycbjamespage, 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-updates13:41
cyphermoxsmoser: 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
cyphermoxoh, scratch that, I think I see what the issue is13:51
=== amoralej|lunch is now known as amoralej
smosercyphermox, what was ait ?14:22
cyphermoxmy sponsored upload of os-prober missing a depends on grub-common. I suspect grub-common isn't typically on these images14:23
=== giraffe is now known as Guest59158
fricklercoreycb: thanks, can you tag it for xenial uca, too, or will that happen automatically?14:57
coreycbfrickler, it's tagged for newton uca, which is xenial14:58
cyphermoxhow does one import a new upstream in the git imports?15:10
cyphermoxnacc: rbasak: smoser: ^15:10
smosercyphermox, a new upstream ?15:11
cyphermoxupstream tarball15:11
cyphermoxis it straight g15:11
smoseryou upload to ubuntu and then the importer pulls it.15:11
cyphermoxwell, say I wanted to use that branch as a base for new uploads15:11
smoserare you speaking locally ?15:11
rbasakInteresting question.15:11
rbasakI don't think we've considered that use case.15:12
rbasakThe 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
rbasakWe don't have any tooling that will do that for you, I don't think.15:13
rbasakBut you could use uscan for example and then "git add -Af" or similar.15:13
cyphermoxalright, I think I can fudge around it and I'll write up doc for that use case15:13
rbasakOr gbp tooling.15:13
cyphermoxwe'll use gbp and convince it to do the right thing15:13
rbasakI'm not sure we have worked out how to feed the importer the upload tags properly yet.15:13
rbasakSo is it worth doing it this way right now?15:14
rbasakWe need to talk to the Launchpad team about this.15:14
rbasakOr you can give your upload tag to nacc, smoser or to me. And we can push it.15:14
rbasakBut that has to be before anyone attempts to run the importer against lpusip.15:14
rbasakOr more specifically, before someone does an importer run to push to lpusip.15:15
nacccyphermox: 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 in15:24
naccrbasak: sorry about the icingaweb2 bug, will fix15:24
cyphermoxmy interest is not so much in the upload itself (presumably we can upload and go import again)15:46
cyphermoxbut the whole process for doing a new upstream release seems broken15:47
cyphermoxor 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 ancestry15:47
nacccyphermox: ah i see what you mean15:47
cyphermox(I know because I did some of the obvious dance to try to make it work)15:47
nacccyphermox: right, we don't have an upstream branch, but we do use upstream tags15:48
cyphermoxI have the commands here and I'll document what I did15:48
nacccyphermox: we actually use gbp import-orig in the importer to do that15:48
nacccyphermox: sounds good, we probably can abstract out our 'see if this is a new upstream' code to be a standalone command15:48
cyphermoxoh, I suppose I should have used a different master branch too, doh15:48
cyphermoxso what do you use instead of an upstream branch to keep just the pristine source without debian/?15:49
nacccyphermox: so we have an upstream branch we throw away, as all upstreams are reachable via tags15:50
nacccyphermox: our use case was purely smoser's which was being able to use pristine-tar to recreate the orig tarball15:50
naccso 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
cyphermoxthat doesn't help cuttin new upstream releases though15:51
naccright, it's a different use case :)15:51
nacccyphermox: can you file a bug?15:51
cyphermoxI will, just trying to grab enough documentation on how close we are to this working before I do15:51
nacccyphermox: 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
nacccyphermox: thanks!15:52
cyphermoxnacc: AFAIK all that is missing is some ancestry links, because I was very close to having the right commands15:57
nacccyphermox: ah ok, between the upstream tags? (which is basicaly what keeping the branch would get you)15:57
nacccyphermox: we *could* keep the branch, it was just that rbasak iirc, had a reason not to15:57
cyphermoxprobably that15:57
cyphermoxor because gbp or git aren't finding  the upstream/2.0.0 tag behind the original upload of 2.0.0 in ubuntu/zesty-devel15:58
cyphermox(looking at juju-core, to be precise)15:58
cyphermoxnow I have a reproducer.15:59
naccalways good :)15:59
cyphermoxwhere should I file a bug?15:59
nacchttps://bugs.launchpad.net/usd-importer please15:59
cyphermoxzug zug16:00
=== pavlushka is now known as The_Doctorman
=== The_Doctorman is now known as pavlushka
rbasaknacc, cyphermox: I tend not to use tags unless they're supposed to be a thing that moves.16:03
rbasaknacc, cyphermox: I tend not to use *branches* unless they're supposed to be a thing that moves.16:03
rbasakAnd import artifacts generally don't move, so they're all tags.16:03
naccrbasak: right, but it he case of gbp, it has some presumptions i think16:04
rbasakWhat parenting do the upstream tags end up with?16:04
nacccyphermox: 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 correct16:04
naccrbasak: they *seem* to be correct (it just ends up being the sequence in which we see new upstreams)16:05
naccrbasak: but i'm not sure what correct would be for cyphermox's case16:05
rbasakI suppose that's OK. I don't like the implication that they have a defined ordering though.16:05
naccrbasak: right, but using gbp import-orig doens't allow for any flexibility there16:06
rbasakFor 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
naccso either we don't import upstreams or we right yet another tool, or we leave it :)16:06
rbasakgbp assumes that the packager is supplying correct upstream version ordering information, using import-orig or by pulling from an upstream git repo.16:06
rbasakThe importer doesn't have that luxury.16:06
rbasakI think the solution is a uscan wrapper tool.16:07
rbasakOr something to provide richer history if the packager wants to provide that.16:08
rbasakMerging in the upstream branch would work too!16:08
nacc*if* we had the upstream branch16:08
rbasakIf we don't, then a uscan/uupdate wrapper is the only option, right?16:09
naccand do you mean 'upstream' in the gbp sense or upstream VCS sense16:09
naccno, i mean, we explicitly don't pust the upstream branch from gbp right now16:09
rbasakI meant upstream VCS sense, but I think they're equivalent.16:09
cyphermoxhttps://bugs.launchpad.net/usd-importer/+bug/1649940 for your hacking pleasure.16:09
ubottuLaunchpad bug 1649940 in usd-importer "can't prepare new upstream releases using gbp" [Undecided,New]16:09
naccthey have different histories (gbp import-orig does nto provide a rich history afaict)16:10
cyphermoxwell, something really simple is missing from the look of things16:10
cyphermoxbut I don't know enough about git internals to know what16:10
naccright, so this goes back to we don't *really* use gbp int he importer16:14
naccwe do, just to pull orig tarballs in16:14
naccso that smoser can work offline, but we don't necessarily maintain state in a way that gbp understands16:14
cyphermoxwell, it's close enough tbf16:14
cyphermoxie. git checkout -b upstream upstream/<previous version>   work well to get back an upstream branch16:15
naccright, that makes sense16:15
naccyeah, i think the other thing we don't do currently is merge upstream in16:15
naccit's a standalone history of just upstream objects16:15
cyphermox right16:15
naccthat's probably what is most fundamentally broken for your use case :)16:16
cyphermoxwell you could fudge that by adding the right bits, presumably?16:16
naccright, but we'd have to reimport probably, too16:16
cyphermoxie. the upload itself is a merge of upstream and debian pieces16:16
naccand we'd need to figure out what is supposed to be there16:16
cyphermoxotherwise 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
cyphermoxmy opinion is until you have an equivalent to bzr merge-upstream you can't really claim it to be UDD16:18
cyphermoxcutting 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
cyphermoxI was just tryin16:19
naccright, the claims of 'being udd' were never actually made :)16:19
naccbut yeah -- i also think we have a separate discussion to figure out, potentially, as even if this could be made to work16:19
naccthe only thing the importer sees outside of launchpad is 'upload' tags16:20
cyphermoxtrying 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 time16:20
cyphermoxnacc: it worked in bzr, so it's definitely possible16:20
nacccyphermox: oh i'm not saying it's not possible16:20
nacccyphermox: i'm saying we may not have covered this use-case :)16:20
cyphermoxAFAICT it's just a matter of doing the right grafting of the right bits in the right places ;)16:20
cyphermoxright right16:21
nacclots of "right" which tends to be easy to get "wrong" :)16:21
cyphermoxofc that grafting operation might be quite complex ;)16:21
cyphermoxso far so good, I like the process16:21
cyphermoxit was very close to working.16:21
rbasakI think we have the structure correct. We just need a tool that takes an upstream tarball into that structure.16:22
rbasakAnd we need to make some decisions as to what form such an import should take, since the importer will accept anything.16:22
cyphermoxand merge that upstream structure into the ubuntu branches16:22
rbasakYes. That's a job to do locally. The importer will accept the parent it's given.16:23
naccright, i think this is a subcase of our generic "how to add an external upstream" discussion last week16:23
naccand how to find objects in it, of course16:23
naccpresuming that could be made to work, you'd get rich history via merges (with a new 'upstream parent' parent)16:24
rbasakI 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
naccrbasak: true16:24
rbasakIt's the halfway cause of upstream-release-tarball but Ubuntu-side-in-git that we need tooling for.16:24
rbasakhalfway case16:24
=== iberezovskiy is now known as iberezovskiy|off
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 mask nomodify notrap noquery, and i'm wondering which one applies here?18:47
xibalba_also the would make me thing it only allows one ip, but it appears many can connect to it18:47
sarnoldxibalba_: if you start fiddling with those lines it'd be best to understand this doc completely http://support.ntp.org/bin/view/Support/AccessRestrictions18:57
xibalba_yeh no changes yet ust trying to understand this better18:57
xibalba_ill go through that doc now18:57
sarnoldgood good :)18:58
sarnoldit all made sense to me once, for one afternoon, hehe18: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 how19:09
=== amoralej is now known as amoralej|off
sarnoldfiltering 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!