ScottK^^^ is just rejected so it doesn't get inadvertently accepted before I get my testing questions answered.03:27
ScottKAnd an FFe reviewed.03:51
Laneyblerg, need to remember to pass --source to queue08:33
=== seb128_ is now known as seb128
apw^ bug fix only update to ensure thermald runs correctly in the face of sysfs bits being late to the party08:50
rbasakcjwatson: reuploaded bcache-tools. Thanks for the review.09:18
cjwatsonrbasak: ta09:20
cjwatsonzul: Um I just noticed that python-nova.flex contains no useful files.  Please can you run packages through sbuild before uploading them?09:24
apw^ fix for vbox VMs failing to reach lightdm10:23
mlankhorstoh for the love of god..10:41
mlankhorsthttps://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1374131 seems that it needs libgl1-mesa-dri installed10:42
ubot2Launchpad bug 1374131 in mesa (Ubuntu) "qtcreator-plugin autopkgtest fails on AMD64 mesa mesa_10.3.0" [Critical,Confirmed]10:42
ogra_can someone approve phablet-tools and ubuntu-touch-meta ?11:11
ogra_(i thought there is a bot that does it)11:12
ogra_Laney, i assume you justified with the right people that it is ok to add another font to the seed (while we are just trying to only drop bits to make space)11:12
cjwatson10:57 -queuebot:#ubuntu-release- Unapproved: accepted phablet-tools [sync] (utopic-proposed) [1.1+14.10.20140929-0ubuntu1]11:12
Laneyogra_: are you telling me off?11:13
ogra_missed that11:13
cjwatsonAnd I'm not sure how ubuntu-touch-meta can possibly be accepted given that 1.187 is already in the archive.11:13
ogra_Laney, no, i was wondering if you talked to pmcgowan and slangasek ... who work on shrinking the image :)11:13
ogra_why didnt i see it on -cahnges then11:14
cjwatsonPlease use "pull-lp-source ubuntu-touch-meta" as your starting point for uploads11:14
LaneyI didn't justify with anybody, go ahead and revert if you want. Seems like a valid enough request to me.11:14
cjwatsonogra_: anyway, https://lists.ubuntu.com/archives/utopic-changes/2014-September/010878.html11:15
ogra_Laney, right, to me too ... we can still remove it if someone complains ... that was simply the reason why i didnt merge it yet11:15
ogra_cjwatson, yeah, i see it now11:15
LaneyNobody even responded to the request at all11:15
cjwatson... but it makes ubuntu-touch/i386 uninstallable apparently11:15
cjwatson libqt5gui5-gles : Conflicts: libqt5gui5 but 5.3.0+dfsg-2ubuntu6 is to be installed11:17
cjwatson libqt5quick5-gles : Conflicts: libqt5quick5 but 5.3.0-3ubuntu12 is to be installed11:17
cjwatsonbecause signon-apparmor-extension needs to be built against -gles on !armhf, I think?11:18
ogra_oh, fun11:18
cjwatsonoh, no, it's the sdk-libs changes11:18
ogra_so that needs arch specific differentiation i guess11:20
cjwatsonyup, will sort it out11:20
cjwatsonogra_: does http://paste.ubuntu.com/8454630/ look right in terms of the package organisation?11:21
ogra_cjwatson, it does, are these two enough ?11:22
cjwatsonthe others there don't have -gles variants11:22
cjwatsonLaney: it would be nice if you could have merged your branch into trunk when you noticed the divergence, rather than merging trunk into your branch and then pushing that over the top of trunk11:23
cjwatsonproduces confusing bzr log :-/11:23
Laneymmm, apols, can overwrite if you like?11:24
cjwatsonif you could then now might be a good time, yeah11:24
Laneycjwatson: try that11:29
cjwatsonLaney: thanks11:31
cjwatsonogra_: committed, if you want to redo a 1.188 upload with a fresh seed update11:31
=== agateau_ is now known as agateau
mlankhorstcjwatson: hey I've fixed the dependency issue of mesa, shall I re-upload?12:23
cjwatsonmlankhorst: I know nothing about this beyond people having asked me about it the other day and me redirecting them12:26
cjwatsonDo what seems appropriate :)12:26
mlankhorstI've found the root cause at least12:27
mlankhorstit being that it was working by pure chance before. :P12:28
mlankhorst DISPLAY=:0 glxinfo12:31
mlankhorstname of display: :012:31
mlankhorstError: couldn't find RGB GLX visual or fbconfig12:31
mlankhorstdidn't mean to copy paste12:31
LaneyIt'd be nice if someone could review gnome-desktop3 - it's a small transition that we want to do quickly13:49
cjwatsoninfinity,slangasek: openssl and grub2 reviews from unapproved would be lovely when you're around.14:15
ogra_that package name could need a few more "s" in it :P14:20
jamespage^^ that keystone upload does a variety of good things and should unblock all of the pending oslo.* packages stuck in proposed on failing autopkgtests14:37
mlankhorstsame for mesa, i promise it won't break qtbase-opensource-src this time. :D14:40
Laneyis it possible to get the signer of a queue item?15:01
LaneyDon't see anything on package_upload15:01
ScottKFor mesa it's not the known stuff I worry about.15:04
jamespagethanks cjwatson15:09
=== bladernr_30kFeet is now known as bladernr_
=== Guest13468 is now known as balloons_
Riddellanyone know what's wrong with okular? it seems the main blocker to KDE SC 4.14.1 bits getting in the archive but I can't see a failure in jenkins http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html15:32
rbasakRiddell: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-okular/lastBuild/? shows as failed to me.15:34
LaneyThat's faily15:34
Riddellah hah, I was looking at the "log" file15:37
Riddellthanks Laney15:37
Laneyit's in there, you just have to look harder15:38
Laney'testsuite' has its output before 'acc'15:38
Riddellah yes, still getting my head around this autopkgtest stuff15:40
zul^^^ the nova-compute-flex makes it installable and fixes races with cgmanager15:51
infinitycjwatson: I assume you're using the word "review" very loosely in the openssl case.16:29
infinitycjwatson: "Yes, your rainbow tables all look correct, I re-calculated them on a napkin."16:29
cjwatsoninfinity: right :)  that took me roughly a day of resolving merges on two monitors16:32
cjwatsoninfinity: I ended up importing the current package state into git temporarily so that I could cherry-pick the requested series from upstream and then compare that against the rolled-up patch I'd been given to make sure I'd resolved conflicts correctly ...16:32
infinitycjwatson: Well, not matching theirs doesn't imply you're the one that did it wrong. :P16:33
infinitycjwatson: But if both ended up the same, that has some implication that you're both equally smart or equally unlucky.16:34
infinitycjwatson: So, yeah, more of a verbal review, then.  Did yours, indeed, match theirs in the end?16:34
infinitycjwatson: And this is building with full testsuite goodness and no obvious regressions?16:35
cjwatsonclose enough.  there were a few bits where they'd pulled unnecessary bits of other patches, and I went with my own resolution.  I'd made one or two mistakes which I found that way and corrected.16:35
infinitycjwatson: And, how can we test the POWER8 stuff (can I build it on a P7 host, and run a testsuite on P8 and watch for bogons?)16:35
cjwatsonI built on amd64/powerpc/ppc64el and the test suites passed16:35
cjwatsonI trust that the last is true but don't have one to test on :)16:36
infinitySure, but building on ppc64el probably means POWER7, which would skip any P8-optimised bits.16:36
infinitySo, how can we test on P8?  I think we should, since that's the whole point of the upload.16:36
cjwatsonFair question.  I think: build source package on p7, rsync built tree to p8, run 'make test'16:38
cjwatsonDo I have access to one I've forgotten about?16:38
infinitycjwatson: Kay.  That sounds reasonable.  Want to spin up a test tree on kelsey, and I'll do the second bit when I find a host to slap a chroot on?16:39
infinitycjwatson: You might have access to a few, though what state any of them are in is the more interesting question.16:39
cjwatsoninfinity: OK, (re-)building on kelsey0116:41
=== seelaman is now known as IS_hr_bot
=== IS_hr_bot is now known as seelaman
cjwatsoninfinity: kelsey01:~cjwatson/openssl-1.0.1f/17:03
infinitycjwatson: Ta.17:04
dobeyuploads to seeded packages are ok now as long as they don't break feature/ui/string freeze, right?17:07
cjwatsonYes, they're just held for manual review17:12
cjwatsoninfinity: I take it it passed?17:19
infinitycjwatson: Nah, I was on a call with our fearless leader.17:56
cjwatsoninfinity: Oh.  Somebody accepted it.17:59
infinityOh.  Indeed somebody did.18:00
infinityI wonder how they "reviewed" it.18:00
infinityAnyone want to confess to accepting that openssl upload? :P18:00
infinitycjwatson: I guess no one's fessing up.  I'll test it anyway in a bit.18:11
infinity(I wish someone had finished that queue auditing feature...)18:11
bdmurraycjwatson: slangasek ran change-override for aptdaemon but there is no information about that here - https://launchpad.net/ubuntu/trusty/amd64/aptdaemon. Any ideas?18:14
cjwatsonbdmurray: That's where it would've appeared18:14
cjwatsonSo need to know what he did18:14
cjwatson(Assuming he did a binary override in the correct suite including that architecture ...)18:15
infinitybdmurray: Ran change-override to what end?18:15
bdmurrayinfinity: to fully phased the update18:15
bdmurray18:09 <slangasek> $ change-override -z 100 -s  trusty-updates aptdaemon18:15
infinityLooks fully phased to me.18:15
cjwatsonThen that worked fine18:15
cjwatsonphase 100 shows empty in that column18:16
infinityEmpty... What Colin said.18:16
infinitySmall UI bug that could be filed, perhaps.18:16
infinityEr, of course, that should have been -S aptdaemon, to phase all the binaries from the source.18:18
infinityOh, I say that, but python3-aptdaemon also looks phased.18:18
infinitySo maybe slangasek did them individually.18:18
infinityslangasek: ^?18:18
bdmurrayI understand that empty means 100%, the timing is particularly confusing18:19
bdmurray17:08:15 ... 0% of users18:19
bdmurray17:08:14 ... empty18:20
slangasekinfinity: I mistakenly did it without -S the first time around, then went back and used -S on a second pass when bdmurray called my attention back to it18:20
infinitybdmurray: That's the date it was deleted/superseded, not the date it was set to 0%18:20
infinityslangasek: Ahh, kay.18:20
infinitybdmurray: The history output is a bit confusing in that regard, I agree.18:20
slangasekcjwatson, infinity: I accepted the openssl upload, as cjwatson highlighted both of us and infinity did not tell me he was claiming it :)18:22
infinityslangasek: Oh.  Backscroll had me waffling about unreviewability and that it should be tested first.18:22
slangasekinfinity: yep; didn't see that until now18:22
slangasekso, well, feel free to continue testing18:23
infinityslangasek: But I assume you pored over all the assembly and recalculated the rainbow tables by hand, so we're good. ;)18:23
slangasekI'll say that's what I did, sure18:23
infinitybdmurray: Hrm.  Is it an lpapi bug or sru-review bug that it seems to pick up the wrong diff for a package that's been uploaded, rejected, and reuploaded with the same version?18:28
bdmurrayinfinity: which package?18:29
infinitybdmurray: flash-kernel, it's picking the debdiff from rejected.18:30
bdmurrayinfinity: it uses the debdiff in launchpad so - https://launchpadlibrarian.net/186070966/flash-kernel_3.0~rc.4ubuntu49.3_3.0~rc.4ubuntu49.4.diff.gz18:31
infinitybdmurray: But that's not the diff I'm getting.18:31
infinitybdmurray: Does it cache locally?18:31
bdmurrayinfinity: nope, I'll take a look18:31
infinitybdmurray: ... And now I do get that diff.  WTF?18:33
infinitybdmurray: Does it fall back to other queues if unapproved doesn't have a diff yet, maybe?18:33
bdmurrayinfinity: no, but there is a --queue option18:35
infinitybdmurray: Which I wasn't uding, since it defaults to unapproved.18:35
=== balloons_ is now known as balloons
=== balloons is now known as Guest63150
=== Guest63150 is now known as balloons_
=== jhenke_ is now known as jhenke
=== balloons_ is now known as balloons
hallynhi, bugs 1374622, 1374617 and 1374612 fix the inability to migrate VMs from p->t.  The latter two require FFE for u.  The second is a new package with only 4 pxe roms.20:56
ubot2bug 1374622 in libvirt (Ubuntu Trusty) "Support migration from 12.04" [High,New] https://launchpad.net/bugs/137462220:56
ubot2bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,New] https://launchpad.net/bugs/137461720:56
ubot2bug 1374612 in qemu (Ubuntu Trusty) "[FFE] add pc-1.0-precise machine type" [High,New] https://launchpad.net/bugs/137461220:56
infinityhallyn: How is this meant to work to the user without excessive documentation?21:02
infinityhallyn: If their old machines were pc-1.0, starting them on trusty won't magically use pc-1.0-precise, I assume.  Will it fail to boot gracefully with an error telling them what to do?21:02
infinityhallyn: And once it's migrated, does it become "pc-1.0" again and use the new ipxe ROMs, or are they stuck as pc-1.0-precise forever?21:04
infinityI'm a bit fuzzy on how this works.21:04
hallyninfinity: once they've migrated to trusty, it'll be called pc-1.0-precise21:05
hallynthen they can edit the machine type to be something newer if they like21:06
infinityCan't that be handled transparently, then?21:06
hallynbut yes, the switch to pc-1.0-precise wont' be automatic.  they have to set a libvirt flag21:06
hallynwhich part21:06
infinityWell, with any luck, all of it.21:06
infinitySo, AIUI, we need to go from precise/1.0 to trusty/1.0-precise to trusty/1.0, cause you stop in the middle, you're still using ipxe-precise, which we don't want to keep forever, yes?21:07
hallynno.  because pc-1.0 means two different things.  so we are introducing pc-1.0-precise to refer to one of them, and using the libvirt flag to tell libvirt which to use21:07
infinitys/cause you/cause if you/21:07
hallynit's ok to use pc-1.0-precise at least as long as precise is supported21:08
hallynand realistically we'll probably never get rid of it.21:08
infinitySo, I guess I have two questions.  1) if we can move from trusty/1.0-precise to trusty/1.0, why can't we move from precise/1.0 to trusty/1.0, and 2) can we make either step more automatic?21:08
hallynjust as the default machine type in trusty is now caled 'pc-i440fx-trusty21:08
hallyn1) is false.  ou'd move to something newer ,not to 1.021:09
hallyn2) we can't make it more automatic bc there is no way to tell which pc-1.0 they are sending us.21:09
infinityErr, whatever, ignore my terminology.21:09
infinityBut you can move from trusty/1.0-precise to trusty/pc-i440fx-trusty then, right?21:09
hallynwhile it is shut down, yes21:09
infinityWhat happens when I try to migrate precise to trusty today?21:10
hallynone of the proposed packages is to make pc-1.0-precise the default in precise to cut down on the amount by which this happens now21:10
hallynit simply fails21:10
infinityIs it a detectable failure?21:11
infinityOr completely nonsensical?21:11
hallynnot complete nonsensical.  it's detectable if yo uknow what to look for21:11
infinityOkay, so if it's detectable, it's automatable.21:12
hallynit'll complain about memory segments not being the same or somesuch21:12
hallynat what level though.  some ppl are doing qemu migration by hand.  there yo ubasically get no feedback at the source site, other than that the vm kept running instead of stopping21:12
hallynsome are using libvirt.  we coudl indeed try to fix it automatically there, but it would not be simple.  the destination would have to detect it, then tell the source to restart21:13
hallynthe ipxe-precise package would be needed regardless,21:13
hallynfor qemu users really it can't be automaticed more tha nit is - you specify the target machine type with 'qemu -M pc-1.0-precise', jsuts as you would otherwise do 'qemu -M pc-1.0'.  you have to specify it regardless.21:15
infinityhallyn: Right, not disputing the need for the new package, just thinking that we can do better than "oh, yeah, that failed because you need to read obscure doc X".21:15
infinityhallyn: For qemu, it could still be trapped, I'd think.  If -M pc-1.0 runs into the memory segment consistency issue, can we not do some checksums, compare to our other ipxe on disk, go "oh, no, we need that one", and reboot with that machine type?21:16
hallynwe have discussed making the fallback to the pc-1.0-precise the default;  that would throw users who were using 'pc-1.0' in trusty (which some would say would be their own fault, but i think that's not quite true)21:16
infinityhallyn: Thus eliminating the need for people or tools to specify -precise at all, we just twiddle it.21:16
hallynrharper: ^ got a job for you :)21:17
rharperhallyn: sup21:17
hallyninfinity: it may be possible21:17
hallyni'm not sure we can restart at that level21:17
hallynsure we can always re-exec ourselves :)21:17
infinityIt's all just a userspace program, you can restart at any level.21:17
infinityYou just need some cleverness.21:17
hallyndo we want cleverness in an sru?21:17
infinityI'd rather cleverness than something that technically fixes the issue but is hard to discover.21:18
hallynso yeah, it should be possible.  detect an old vga size paired with pc-1.0, then re-exec ourselves with "-M pc-1.0-precise"21:18
infinityAt worst, I'd like it to be able to detect the issue and print "you probably want -M pc-1.0-precise", but once we've gone that far trapping it, a bit more clever to JDTRT might be the best option.21:18
rharperhallyn: if I'm reading backscroll right, neither qemu nor libvirt are the right place to "detect" which type to be used21:18
hallynthen what is?21:19
infinityqemu seems like the ideal lowest common denominator.21:19
infinityIt's the only one that knows something's broken.21:19
hallynif we *could* have qemu just re-exec itself, then libvirt wouldn't need to do anything21:19
rharperat the end of the day, folks without a higher level management tool which makes migration and machine type decisions (versus taking hte defaults which is what both do) it's going to be trouble getting it "right"21:19
hallyninfinity: so to be clear the machine type as such is not passed from source to destination21:20
rharpernot sure I follow the re-exec -- when migration fails you retain the original qemu -- and IIUC folks don't want to actually have to reboot/restart their qemu VM21:20
hallynrharper: re-exec the destination21:20
hallynand somehow signal the source to restart :)21:20
rharperno one is reexecting in the qemu case21:20
rharperlibvirt *could* but that's just a guess21:20
rharperand what if migration fails for some other reason21:20
hallynqemu could do it itself.21:20
rharperno way to know that it should do that21:20
infinityWhat if it fails for "some other reason'?21:21
infinityI don't care about some other reason.21:21
infinityI'm specifically curious about "pc-1.0" failing due to this specific issue.21:21
hallyndetect that vgasize is that of pc-1.0-precise while m-t is pc-1.0.  D oit only in that case21:21
rharperhow long do you want and how many times do we want qemu to keep rexecing itself ?21:21
hallyninfinity: but i still don't know how we could tell the source qemu to re-start migration21:21
infinityWhich should be entirely solvable by detecting the situation and swithcing to pc-1.0-precise.21:21
rharperthis all seems crazy hacky21:21
hallynrharper: agreed, but the goal of something easier ofr the user to discover is laudible21:22
rharperscan some part of the incoming migration data, some how track these parts in some state (or write it out) so it can recall what happened the last N times we re-exec'ed ourselves ?21:22
hallynrharper: yup, write out what we've read so far, re-exec ourselves with -m pc-1.0-precise;  if we're already exec'd with that we just fail21:23
infinityhallyn: So, the problem here is that qemu itself is also doing the migration?  This isn't fed to it by some higher level tool?  (I'm mostly ignorant to how this works).21:23
rharperthat sounds like a really bad idea w.r.t keep state, how to handle if the file is still around, or if it contains bogus data, or ...21:23
hallyninfinity: right, the two qemu processes do it with a'migrate' API21:23
hallynrharper: it works for upstart :)21:23
infinityAnd who triggers the migration?  Source or destination?21:23
rharperqemu can't migrate itself -- it always requires a third party to initiate migration21:23
hallynboth :)21:23
hallyndestination is started with "-incoming tcp:"21:24
hallynsource is told "migrate tcp:a.b.c.d:5555"21:24
rharpermanagement application ( most likely libvirt ) is issued a migration command to the source (with the destination URL);21:24
rharperand mgmt app does as hallyn describes under the covers;21:25
infinityOkay, but once it's started, the destination knows the source, as it has an open TCP connection to it.21:25
hallynand qemu does the migration :P21:25
infinitySo, no need to save temp files or other ugliness.21:25
rharperwe can't modify the migration protocol21:25
infinityYou detect the bad memory segment, and restart the source migration.21:25
rharpersource doesn't retain any state w.r.t migration succeeding or failing, the mgmt application can/could21:26
hallyninfinity: if we make that kind of change, supporting/backporting future CVEs until 2019 is gonna hurt21:26
infinityBleh.  Maybe.21:26
infinityI just see limited value in non-discoverable ways to work around bugs.21:26
hallynwell lemme put it another way - i don't believe any 'ordinary user' is going to migrate vms from P->T21:26
infinityAnd "we documented it somewhere, really" isn't discoverable.21:27
hallynwe saw limited value in supporting this at all, but ablight needed it enough that he wrote the patches himself to fix it.  his own site is done entirely with thie rown mgmt toold21:27
rharperhonestly, the easiest fix I'd say for 99% of folks is to shutdown your Precise VM, modify the machine type to pc-1.0-precise21:27
rharperand then we're all good21:27
rharperor offline migration to trusty21:27
hallynagreed.  this is mainly for ppl who have tons of customers not willing to shut down21:27
infinityrharper: sure, but those people need to be told to do that.21:27
hallynbut we can't predict how they're using this.  if they're using netcat to a qemu monitor socket they won't see any info we try to hand them21:28
infinityAnyhow, I'm not saying magic is a blocker for this, I'm just examining if there are better ways.21:28
rharperindeed;  I don't think there is an easy package-specific place to do this...21:28
hallynso right now what happens is - they try to migrate, it fails.  the question is, is there any better way - other than release notes and/or a lp bug - to let them know that hey they can re-try it like this21:29
infinityI'm more concerned about if this will come up again between 14.04 and 16.04, etc.21:29
hallynthat shouldn't, that's why we have the pc-i440fx-trusty machine type21:29
hallynso we can do magic21:29
infinityhallyn: Release Notes are useless to communicate to users on release day, they're even worse after.21:29
hallynwe could do magic if we didn't care about 14.04 pc-1.0 users21:29
infinityhallyn: So, a special trusty machine type is a start, but I assume this still implies we might need 14.04 ROMs in 16.04?21:30
infinityhallyn: So, better magic for the users, same mess for us? :)21:30
rharperdocumenting on wiki and socializing the document21:30
rharperthat's not the best, but better than nothing21:30
hallyninfinity: we will need old roms, yes.  fixing that is not up to us, but up to the qemu folks.  they believe it's up to distros to work that out.21:31
infinityI wonder if/how this affects non-BIOS arches.21:31
infinityOVMF, SLOF, etc.21:31
hallynegads, for that matter, we never got qemu-slof ot compile for utopic21:31
hallyn("that reminds me")21:31
infinityhallyn: Err, never got it to compile?21:32
infinityhallyn: Is it currently sad?21:32
infinitybinutils segv.  Exciting.21:33
infinityI can look at that in a bit.21:33
hallyninfinity: now the roms have to change their size to the next o(log n) or something before it matters that they changed, which odesn 'thappen much.  otherwise new roms are fine during migration.21:33
hallynbut when thta does happen, then we need to package the old roms and direct qemu to them.21:33
hallynon the bright side, we can do that automatically21:33
hallyn(for the user, not for us)21:33
infinityThis all sounds a whole like some serious design flaws. ;)21:34
rharperfwiw I do believe this is something that QEMU should address upstream, but it's not an easy thing to do21:34
infinityAlright, so I'm not happy about, but can accept "manual migration, icky forward-ported ROMs, and socializing docs", but I'd really like better answers.21:35
infinityThe docs part goes away for 14.04->16.04, so that's a plus, but the rest still looks sketchy.21:35
rharperthe idea of a OS or VM being bound to a machine, is very much like real hardware ... and part of real hardware (and virtual) is the BIOS/Firmware/Blob -- that ought to be something we can encapsulate (if users desire)21:36
rharperand possibly included in the payload of the VM.21:36
infinityrharper: Effectively, save the firmware blobs that the VM was started with as an nvram blob that gets reused and passed around?21:36
infinityThat has the disadvantage that it's then hard to upgrade the firmware.21:36
infinityBut I guess this is a case where having and eating cake might just be really hard.21:37
infinityOr impossible.21:37
rharperinfinity: I think it can be worked out -- the nvram stuff already has a "writable" drive that needs to be kept with the the VM21:39
rharperno reason that we couldn't keep/load/write roms for BIOS as well -- but we need to think carefully about how to handle the permissions needed to host these VMs that can care and update their own BIOS21:40
rharperwith something like qcow2 (or other metadata drive files) one could even mark out hidden partitions to hold this... but it's seriously like a qemu 3.0 sort of feature as it will cut across all of QEMU21:40
hallynrharper: did you mention recently that you were talking about just that with qemu upstream?  What sort of venue was that, i.e. email/irc, and is there a log?21:41
infinityrharper: Yeah, that sounds rather complex and whacky.21:41
rharperhallyn: not upstream, with alex21:41
rharperhallyn: I probably have the log21:41
hallynrharper: oh, ok, i thought you had told alex you'd been talking with upstream about something like that.  nm then21:48
hallyninfinity: so really, the libvirt patch could be tweaked so that if /etc/libivrt/qemu.conf does not have 'assume_incoming_qemukvm = 1' and machine type is pc-1.0, it spits a warning out "if migration fails, try setting that"21:56
ari-tczewdo we still use subscribing to ~ubuntu-release for FFe reviews?21:58
infinityari-tczew: Yeah.  It does hurt to poke people on IRC too, though.22:00
infinitycjwatson: Want to lob a grub2-signed at the queue too, or should I do that?22:01
cjwatsoninfinity: I was going to do that, yeah.22:02
cjwatsoninfinity: ^-22:38
infinitycjwatson: Ta.22:40
xnoxinfinity: Laney: poke re:FFe Bug #137236723:44
ubot2bug 1372367 in btrfs-tools (Ubuntu Utopic) "FFe Upgrade btrfs-tools to 3.16" [Undecided,New] https://launchpad.net/bugs/137236723:44

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!