=== joed_ is now known as RogueOmega7
RogueOmega7anyone here wanna bs about ubuntu / unity convergence?01:20
cpaelzeradd "ipv6.address: none" in the edit "lxc network edit lxdbr0" gives you07:17
Laneybdmurray: see man autopkgtest, could be lots of things09:14
=== jamespag` is now known as jamespage
pete-woodscan anyone with more debian-packaging-fu than me understand what's wrong in this autopkgtest log? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2362/zesty/amd64/u/unity8/20170113_095859_4ba42@/log.gz10:39
Mirvpete-woods: you need to ask for retrying the tests with all-proposed=1 until Qt 5.7.1 transition is over (which is currently waiting for archive admin action)11:25
Mirvpete-woods: ...retried both11:26
=== _salem is now known as salem_
=== marcusto_ is now known as marcustomlinson
pete-woodsMirv: thanks! hopefully that works11:55
=== hikiko is now known as hikiko|ln
coreycbdoko, i have a fix for cinder (well kombu) re: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161216-updates-python2712-trusty.html13:53
coreycbdoko, i'm not sure how best to provide it to you though13:56
coreycbdoko, it might fix up glance too13:56
coreycbdoko, here's the debdiff: http://paste.ubuntu.com/23792290/14:00
=== davmor2_ is now known as davmor2
dokocoreycb: does it work with the old python 2.7 as well?14:11
dokoif yes, then maybe SRU it?14:12
coreycbdoko, good question, I'll try it out14:13
tjaaltonmdeslaur: hi, sudo needs a merge.. 1.8.16 is buggy with freeipa/sssd, fixed in .17 (#1607666). do you have plans to merge 1.8.19 for zesty?14:47
mdeslaurtjaalton: 1.8.19 has a syslog regression I believe14:48
mdeslaurwe need 1.8.19p114:48
mdeslaurtjaalton: looks like mvo touched it last, would have to ask him what his plans are14:49
barrystgraber: we're seeing some new regressions on ubuntu-image promotion in zesty on armhf.  are you aware of or can think of any changes that might have broken devmapper?  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/u/ubuntu-image/20170111_171929_431b1@/log.gz14:49
mvotjaalton: take it if you have the time14:50
tjaaltonwe'll see :)14:56
smosernacc, do we expect to get upstream tags on usd imported things now ?14:56
tjaaltonmight just fix that bug so that sru is possible14:56
=== scottt is now known as Guest72306
smosernacc, and, when you're about... is there a way to do a clean import even if the thing has already been imported?15:03
smoserthis seems to work...but wondering if there was a more direct way15:04
smoser usd import -v --director=cloud-utils --lp-user=smoser --lp-owner=NONE cloud-utils15:04
rbasaksmoser: I discussed that with nacc yesterday. He's being doing what you did. I have a branch I've added --no-fetch to, but it's not ready yet.15:21
smoserrbasak, for this specific need, i just deleted the branch :)15:26
smoseron lpusp15:26
smoseri know i shoudlnt do that generally, but i think it was fine here and i wanted the newly imported thing with tags and such.15:26
rbasakddstreet: can you help me with reviewing bug 1642903 please? I haven't yet figured out what the specification of udev_event_apply_format is supposed to be :-/15:28
ubottubug 1642903 in systemd (Ubuntu Trusty) "introduce disk/by-id (model_serial) symlinks for NVMe drives" [Wishlist,Fix committed] https://launchpad.net/bugs/164290315:28
rbasakAnd trying to follow string manipulation in raw C makes my head hurt :-(15:29
rbasakSo reverse engineering its intention is difficult.15:29
rbasakI understand that SUBST_* seems to match udev rule syntax roughly.15:30
rbasakI mean bug 1647485, sorry.15:31
ubottubug 1647485 in systemd (Ubuntu Zesty) "NVMe symlinks broken by devices with spaces in model or serial strings" [High,Confirmed] https://launchpad.net/bugs/164748515:31
sladenrbasak: doesn't appear to be any C involved in that at all.  Just adding some udev rules (https://launchpad.net/bugs/1642903)15:32
ubottuLaunchpad bug 1642903 in systemd (Ubuntu Trusty) "introduce disk/by-id (model_serial) symlinks for NVMe drives" [Wishlist,Fix committed]15:32
rbasaksladen: sorry, wrong bug. I meant bug 164748515:32
ubottubug 1647485 in systemd (Ubuntu Zesty) "NVMe symlinks broken by devices with spaces in model or serial strings" [High,Confirmed] https://launchpad.net/bugs/164748515:32
coreycbdoko, kombu tested and uploaded to trusty review queue15:40
rbasakddstreet: never mind. I think I've figured it out.15:47
ddstreetrbasak sorry, just saw this, let me know if i can help15:51
ddstreetand yeah, that udev tangle is not easy to follow15:52
=== karstensrage_ is now known as karstensrage
sladenddstreet: reading that patch, I [think] it is possible to reach the end of  udev_event_apply_format() with an uninitialised sbuf[]16:04
ddstreetsladen sbuf should only ever be used if replace_ws is true16:04
ddstreetwhere are you seeing a problem?16:05
sladenddstreet: https://git.launchpad.net/~ddstreet/+git/systemd/tree/src/udev/udev-event.c?id=a135967a#n21616:05
sladenddstreet: followed by eg.  https://git.launchpad.net/~ddstreet/+git/systemd/tree/src/udev/udev-event.c?id=a135967a#n22816:05
sladenddstreet: meaning that the for(;;) loop is would be exited with nothing written into sbuf16:05
rbasakI'm still on udev-rules.c. Not dived deep into the changes in udev_event_apply_format yet.16:06
sladenddstreet: then finally  https://git.launchpad.net/~ddstreet/+git/systemd/tree/src/udev/udev-event.c?id=a135967a#n41016:06
ddstreetsladen those break; commands don't break out of the for loop, they break out of the switch statement16:10
ddstreetis that what you're talking about?16:10
sladenddstreet: correct16:10
=== hikiko|ln is now known as hikiko
ddstreetsladen i'm not quite following where the bug happens?16:12
ddstreetline 216, s = &sbuf, then it enters the switch(), then eventually exits the switch(), and restores s after replacing whitespace...16:13
ddstreetthe switch ends at line 39916:13
ddstreetthe if statement at line 402 is outside, after, the switch16:14
ddstreetsladen is there something i'm missing?16:14
sladenddstreet: minimal example is  char sbuf[UTIL_PATH_SIZE]; s = &sbuf; switch(SUBST_RESULT) { case SUBST_RESULT: if (event->program_result == NULL) break; tmplen = util_replace_whitespace(sbuf, s, MIN(tmplen, l));16:17
naccsmoser: right, we don't (can't in the current algorithm) go back and add history (e.g., upstream data) for already imported stuff16:26
naccsmoser: that could be a reasonable feature, but the alternative, presuming no one is yet using your repository, is to delete and re-import16:27
ddstreetsladen that util_replace_whitespace is called with length 016:27
ddstreetas tmplen will be 0 if sbuf isn't used16:27
smosernacc, so i did that16:28
smoserwhy is there only one upstream/16:28
Henning_I am planning to file an "upgrade-software-version" bug for xkeyboard-config and maybe freetype. But I am confused. xkeyboard-config has the string ubuntu1 at the end of the version string. So it's not automatically imported until DebianImportFreeze. So if I want to get the version bumped to the version that's in debian sid/unstable I have to file a bug with the tag "upgrade-software-version", probably at least two or three we16:28
naccsmoser: which src package?16:29
naccsmoser: wait you deleted a branch or a repository?16:29
smoseri deleted the lusd-import and then re-imported16:29
smoserat least i thought i9 did.16:30
naccsmoser: hrm, the newest objects in the repo are just 3 tags16:30
smoseryeah, that is confusing16:31
smoseri think i try again16:31
naccsmoser: seems reasonable16:31
smoserso i'm going to 'delete repository' at https://code.launchpad.net/~usd-import-team/ubuntu/+source/cloud-utils/+git/cloud-utils16:31
smoserright ?16:31
smosernacc, hm... why do we not default to patches-applied?16:32
smoserthat was going to be my next question, "where are my patches-applied" branches16:33
smoserthen i see that it doesnt have them by default. i suspect due to possible failure of applying due to lack of a tool ?16:33
sladenddstreet: where is 'l' (saved to '_l') initialised?16:33
naccsmoser: see the git commits16:34
rbasaksladen: "l = size;"16:34
naccsmoser: disabled becasue it doesn't always work (for certain src packages) and the importer can't fail (yet)16:34
naccsmoser: you can pass --patches-applied16:34
ddstreetsladen line 13116:34
ddstreetsladen but if replace_ws, then l is set to UTIL_PATH_SIZE which is the size of sbuf16:35
smosernacc, yeah, but that wont be "sticky"16:35
rbasakThis code is horrible :-(16:35
ddstreetthen tmplen is UTIL_PATH_SIZE - l, so if the switch statement doesn't do anything tmplen is 0 and nothing is copied16:36
smoserrbasak, you're in a friend-making mood :)16:36
naccsmoser: that is true, but nothing is 'sticky' in the importer (there's no config stored in the repository)16:36
rbasakIt might as well be in assembly!16:36
ddstreetrbasak i agree16:36
smosernacc, and thats fine... i'm just saying that i can do it , you're right, but then as the importer goes on i dont have it.16:37
rbasakddstreet: yeah, not your fault :)16:37
smoserso its not terribly helpfu.16:37
smoseri wonder if we could --patches-applied=attempt16:37
smoserand that be the default16:37
naccsmoser: this is mostly temporary while we wait for debian to tell me what policy they want for dgit16:38
smoserand if it failed, then warn and skip16:38
rbasaksmoser: I hope that eventually --patches-applied will not break and be the default.16:38
naccsmoser: for the cases where it fails16:38
rbasaksmoser: so in the meantime, it's just a feature flag awaiting feature specification finialization really.16:38
naccsmoser: because we have to do something withe branch pointers16:38
rbasakddstreet: I think I'd have preferred you to have modified the destination in-place instead of temporarily redirecting everything else.16:42
rbasakThough then I suppose that util_replace_whitespace couldn't be called directly. Hmm.16:42
* sladen just reading util_replace_whitespace()16:44
ddstreetand util_replace_whitespace strips leading/trailing whitespace16:44
ddstreethmm i supppose util_replace_whitespace could operate on the same memory as src and dest...16:46
ddstreetbut that's a bit more clever than is safe for this code i think16:46
sladenddstreet: I (think) this code (probably) works.  It has taken 45 minutes to understand the implications of the patch.  The UTIL_PATH_SIZE - UTIL_PATH_SIZE == 0 step is quite fragile if another patch gets added later.  There may well be a much simpler way to implement it.16:49
rbasakThe entire switch statement should be in its own ******* function :-/16:50
ddstreetrbasak +100016:50
smosernacc, so you're saying you would not want --patches-applied right now if it always worked ?16:50
sladenddstreet: if it's purely a post-processing step, it should be possible to do it all at the end, with (probably) no additional variables being added before16:50
smoseras in you're not sure if the implementation is right here ?16:50
rbasaksladen: I appreciate your additional review. Thanks.16:50
ddstreetsladen i'm not sure how it's fragile, it calculates the amount of chars added16:50
ddstreetsladen what *really* should be done is for strpcpy() to return the number of chars copied, not the new length remaining!16:51
ddstreetstrpcpy is a function that udev didn't need to re-invent16:52
ddstreetbut i digress.  my patch was done with minimal changes to the existing code in udev, which is why it looks weird.16:52
ddstreetudev's existing code is already weird.16:52
sladenddstreet: bool replace_whitespace, could probably be const to aid readability, and then could be referenced directly, which would be easier than the 'replws' abbreviation16:52
naccsmoser: the implementation is correct. The need for the flag is temporary16:52
naccsmoser: hopefully16:53
rbasakddstreet: to be fair, you could have refactored it in your upstream patchset.16:53
ddstreetsladen it's not possible to do all at the end, because only the variable substitution whitespace should be removed - not any whitespace that was already in the string16:53
ddstreet(that isn't my requirement, see the pull req for details)16:53
ddstreetrbasak fixing strpcpy? it's used all over udev16:54
rbasakddstreet: the redirection around the switch statement is pretty hacky and fragile. Better to pull the switch into a separate function. Then you can give the switch statement different pointers.16:54
smosernacc, http://paste.ubuntu.com/23793031/16:54
rbasakddstreet: that would also ensure that nothing in the switch statement can reach out to other variables in the scope of udev_event_apply_format that might impact the redirection.16:55
smoserthat is what i'm suggesting, that way we get it imported for everything that *does* work, and for stuff that doesnt we warn rather htan fail16:55
ddstreetrbasak yeah but i think a separate func is gonna need a lot of params passed in16:55
naccsmoser: that will break those packages where it doesn't work16:55
naccsmoser: in a way that is not fixable later16:55
smoseri dont follow16:55
rbasakddstreet: perhaps, but I have to review each of those parameters individually for unintended interactions this way anyway.16:55
smoserit will just not create those commits16:56
smoserwhich is what you're doing now16:56
naccno, it will break the historical import algorithm16:56
naccfor that series16:56
rbasakddstreet: to check the redirection for correctness, I have to know what other variables the contents of the switch reaches out to.16:56
smoserhow is that different than not doing it?16:56
ddstreetrbasak sure i can create a new patch to pull that function out, but the upstream bug is already closed16:57
naccsmoser: yes.16:57
rbasakddstreet: understood. This is a passing comment really. I haven't come to a conclusion with my SRU hat yet.16:57
naccsmoser: because if it's not done, i can go back and 'catch-up' the applied branches16:57
naccsmoser: if history is *wrong*, I can't.16:57
ddstreetrbasak yep, i understand, i'll see what i can do upstream to pull the function out16:58
smoseri'm missing something. if the patch application fails, you dont create the history, so its just as if you ran without patches-applied16:59
smoserare you just saying that the commit_patches_applied has side affects ?16:59
smosernacc, ? what would be un-correctable ?17:05
smoseri think you're suggesting that you could potentially import incorrect state and succeed. i'm not sure. if thats the concern then you can never be sure that running of tools provided the same code they did a decade ago.17:08
smoserie, samba's failure.  although, as i understand it , that was a fialure to apply the patch, and thus my suggestion would just go on.17:09
=== scottt is now known as Guest19740
rbasakddstreet: I think you should use sizeof(x)/sizeof(x[0]) instead of UTIL_PATH_SIZE, etc. Again, maybe not important for this SRU.17:20
naccsmoser: i don't understand what you mean by 'commit_patches_applied has side effects'? it creates/moves branch pointers17:23
ddstreetrbasak yeah i thought of that, but was concerned if sbuf is changed from stack array to a * the sizeof would silently break17:23
smosernacc, it does that only if it succeeds to apply a patch17:24
rbasakOTOH, if the size of sbuf is changed, then we'll silently break.17:24
naccsmoser: no, i'm saying that if make patch-application non-fatal by default, which (you by default are doing), then historical patches-applied imports will 'succeed' but will not be imported anywhere (potentially)17:24
rbasakIMHO, I'd expect someone changing a variable's type to check how something is used.17:24
rbasakMore so than the the length of an array.17:24
naccsmoser: i think you misunderstand what your new 'commit_patches_applied' does17:25
naccsmoser: it loops over the patches applying each17:25
naccsmoser: that can fail anywhere in the queue17:25
smosernacc, right. so yeah,j it has side affects.17:26
smoserwe'd have to revert the branch17:26
smoserwhich honestly woudl not be that hard17:26
smoserjust take the head before attempt and then reset it on fail17:26
smoserright ?17:26
naccwhat do you do with the *next* one?17:26
naccthis is not some trivial problem :)17:26
smoseri dont know. i understand your point.17:30
naccsmoser: as in, fine, you fail to apply patches, so you leave the current pointer at the prior17:31
naccbut then FF branches get messy17:31
naccand you're dropping state without tagging or anything else17:31
smoserFF ?17:31
smoserright, then the next version tries and succeeds17:31
naccand determining its 'parents' are where we're currently undecided17:31
naccand that decision is policy, so rather than fake it, i'm avoding the choice17:32
smoserit really doesnt matter all that much.17:32
naccat some point, when we swtich the default for patched-applied, i'll switch the algorithm to also do historical applied-patches imports separate from unapplied17:32
smoseryou do lose some history in taht you dont have those in the middle, but it is history that could not be created.17:32
smoserand woudlnt be used anyway17:33
smoserbecause people are only really going to use the tip for applied branches17:33
smoserwell.. that might not be the case, but missing a historic commit doenst matter that much17:33
naccit breaks some of our assertions17:34
naccthat every publish in launchpad is imported, e.g.17:34
naccsmoser: i agree there are solutions out there for this problem. But they all imply a policy, which once done, needs to become stable and supported.17:36
=== JanC is now known as Guest43962
=== JanC_ is now known as JanC
naccsmoser: if what you are asserting is true, then i would suggest a *better* choice is a usd sub-command (perhaps a checkout) which takes a series (+pocket?) and checks out the latest publish in that series (+pocket?) and applies the patches to it.17:42
naccsmoser: the patches-applied state is always deriviable and if users don't care about history, let's not provide history17:42
naccsmoser: but for dgit, they *do* care about history, and so we have to do the right thing in the importer17:42
smosernah. thats not what i was saying17:43
rbasakddstreet: how feasible would it be to add a test case for this particular bug?17:43
smosereven in dgit17:43
smoserthey're only really primarily interested in the tip17:43
smoserits for development, to make changes.17:43
smoserif a historical point was unable to be created, that is what it is.17:43
smosersame as if there was no download available for a thing in launchpad or something17:43
smoserits less than perfect for sure and obnoxious, and i'd probably complain about it later17:44
naccnote that a failure to find a download in launchpad is fatal to the importer17:47
smoserright. the difference i see is only in that the next import would possibly succeed and then go stopmping on the history.17:47
smoserin my suggested solution17:48
ddstreetrbasak i can do that, there's a big test case perl script built into systemd/udev that's run on compile, i'll add some test cases17:48
smosernacc, if i wanted to pull in a new upstraeam release17:48
smoserwhen working with this branch... ie, to upload.17:48
smoserwhat would you do to do that ?17:49
smoserie, i'm on ubuntu-devel17:49
smoserand i want a new upstream tarball17:49
naccsmoser: does uupdate/uscan work?17:49
naccnote this might be the same question as the bug cyphermox filed :)17:49
naccsmoser: LP: #164994017:50
ubottuLaunchpad bug 1649940 in usd-importer "can't prepare new upstream releases using gbp" [Medium,New] https://launchpad.net/bugs/164994017:50
naccthat's one 'answer', in that we don't actually use the upstream data we have17:51
naccsmoser: but if you have uupdate/uscan working, what i would suggest (and it's gross) is to do a uupdate/uscan, and then overwrite the working tree to be exactly what is in the new upstream17:51
smosernacc, yeah, that is basically what i was asking17:55
naccsmoser: i think this is where we hit the bodge that is you asking for imported orig tarballs :)17:56
naccsmoser: in that, we don't really import them -- they exist, but are off to the side17:56
smosernacc, so... this is what actually brought me here..17:56
smoseri was tying to use the lpusp branch to do development on cloud-utils now17:57
smosermy plan is to leave upstream in bzr for now17:57
smoserand do the usd for working with git17:57
smoserbut then wanted to upll in a new 0.30 that is really the same as what was in ubuntu due to the applied patches17:57
smoserbut i wanted git to tell me that17:57
smoserand so i wanted to diff against lpusip/applied/0.27-0ubuntu917:58
smoserto see that that was the case17:58
naccand that didn't exist17:59
smoserso that is a non-dgit use of the applied branches18:01
naccbut my prior point of a catch-up mode for the applied branches would have solved your problem18:01
naccsmoser: i can probably get that coded up today, honestly -- we'll need it anyways at some point, probably18:02
naccthat allows us to continue using the current importer for now and then we can catchup all the repos at some point, change the default on the flag, and then restart the importer with patches-applied?18:03
smosersure. one other thing you coulddo....18:04
smoserso, i'm concerned that reality will be that we never get to the point that we have these applied branches18:05
smoserbecause discussion or whatever policy will drag on and on18:05
smoserfor now we could do as i suggested, and then correctly reset the branch to the last good state.18:06
smoserand then add a commit "APPLIED_PATCHES_FAILED"18:06
smoserand then if that was ever seen, dont go on.18:06
naccLP: #164983218:08
ubottuLaunchpad bug 1649832 in usd-importer "Problems in applied patches imports cause import failures which are not ignored" [Wishlist,Confirmed] https://launchpad.net/bugs/164983218:08
naccsmoser: --^18:08
barrystgraber: re-ping19:35
smoseris eatmydata broken ?20:21
smoser$ grep LD_LIBRARY_PATH /usr/bin/eatmydata20:21
smoser   LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata20:21
smoser   export LD_LIBRARY_PATH LD_PRELOAD20:21
smoser$ ls -l /usr/lib/libeatmydata20:21
smoserls: cannot access '/usr/lib/libeatmydata': No such file or directory20:21
stgraberbarry: hey there, sorry, in South Africa this week so not the most compatible timezone20:59
stgraberbarry: so that's running inside a LXC container and is attempting to mknod /dev/mapper/control. If the container is unprivileged, then that sure won't be allowed by the kernel. If the kernel is privileged, then it'd depend on the lxc.cgroup.devices configuration.21:00
stgraberbarry: I'm not aware of any change we made that would explain a change in behavior there, so a change in the adt container configuration seems more likely to be. Or something was at /dev/mapper/control before which has since disappeared and triggers the mknod?21:01
barrystgraber: is that something that changed recently?  i'm fairly positive that worked original in ubuntu-image dated 10-oct21:01
barrystgraber: yeah, *something* has changed, just not sure what.  do you know, does autopkgtest.u.c run priv'd or unpriv'd containers?21:02
stgraberbarry: I don't know about our adt test environment's config. We haven't changed anything on our side that'd explain that. mknod has always failed in unprivileged containers and always succeeded or failed in privileged containers based on lxc.cgroup.devices config21:03
stgraberbarry: no idea21:03
stgraberbarry: and unfortunately autopkgtest doesn't log what it used to create the lxd container (like it does for nova)21:04
barrystgraber: let me poke around in the apt source and see if i can find something, otherwise i'll email ubuntu-devel@ and see if anybody else has an idea.  thanks, this is starting to narrow it down21:05
stgraberbarry: note that devmapper itself isn't namespaced, so if the adt container is allowed to interact with it, you may well conflict with another container and run into surprises21:13
barrystgraber: i wonder if the apt infra used to run priv'd containers and now runs unpriv'd containers?21:14
=== salem_ is now known as _salem
barrystgraber: that's good to know.  maybe the right answer is to skip the mount test if `dmsetup ls` fails.  i should at least set isolation-machine restriction in d/tests/control for that test21:16
barrythat might do it in a more principled way21:16
stgraberbarry: I know that the lxc adt backend was using privileged containers with barely any security restriction applied to the container. I suspect the lxd adt backend attempts to be somewhat more secure and may run unprivileged.21:16
cjwatsonIt certainly can run unprivilege.21:17
cjwatsonI forget whether it does in production.21:17
barrycjwatson: maybe Laney knows if he's still online21:17
stgraberbarry: yeah and if you set isolation-machine for that test, then adt will just skip it for you when running on lxc/lxd21:17
cjwatsonBut it's what adt-build-lxd(1) and adt-virt-lxd(1) will set up unless you muck about.21:17
barrystgraber: given that devmapper isn't namespaced, that's probably the right thing to do anyway, even if it doesn't explain what's changed21:18
barrycjwatson: ack21:19
barryok, testing and if it works, yay!  but i may still send the email cause i'm still curious21:19
barrycjwatson, stgraber: oh, but isolation-machine will prevent the test from running on amd64 too, so then i'm not so sure what the use of the test is ;/21:20
cjwatsonYeah, dunno, my use of lxd is (a) openssh autopkgtests and (b) Launchpad/OLS stuff at the moment :-)21:21
stgraberbarry: no it won't21:26
* stgraber triple checks21:26
stgraberbarry: right, isolation-machine is satisfied by VMs21:27
stgraberbarry: we set it for the lxc/lxd/lxcfs/... packages and we do see our tests running on everything but armhf and s390x21:27
barrystgraber: then a test that kpartx's and mounts the partitions in a built image is never going to be *safely* tested on current apt infra.  would you agree?21:28
stgraberbarry: ? I'm saying that if you set isolation-machine, your test will run on amd64, i386 and ppc64el21:29
barrystgraber: oh, yes, i see what you're saying.21:30
barrystgraber: unfortunately, i usually use schroot for local tests because qemu and until recently lxd wasn't working locally for me.  qemu still doesn't for some reason (a crash in kvm.c iirc)21:31
xnoxbarry, there is isolation-vm and isolation-container too i think21:49
xnoxto be more specific than just "machine"21:50
barryxnox: isolation-container yes, that's to isolate services and tcp ports.  isolation-machine looks to be more appropriate for kernel interactions (e.g. devmapper).  no isolation-vm restriction that i can see21:51
naccsmoser: still around?23:58

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