=== _salem is now known as salem_
=== salem_ is now known as _salem
[05:26] <cpaelzer> good morning
=== JanC_ is now known as JanC
[06:08] <pitti> Good morning
[06:14] <tsimonq2> o/ pitti, verification-done on bug 1575460 as of 1 min ago :)
[06:14] <ubottu> bug 1575460 in lubuntu-meta (Ubuntu Xenial) "Intel video driver not installed by default on Lubuntu 16.04 fresh install" [Undecided,Fix committed] https://launchpad.net/bugs/1575460
[06:15] <tsimonq2> pitti: how are you? :)
[06:16] <pitti> a bit tired, but quite fine, thanks! how about yourself?
[06:16] <tsimonq2> great :)
[07:29] <ginggs> Logan: hi, please send your fix-isnan.patch for leocad to Debian bug #818819
[07:29] <ubottu> Debian bug 818819 in leocad "leocad: FTBFS with libc 2.23: 'isnan' was not declared in this scope" [Serious,Open] http://bugs.debian.org/818819
[08:01] <Markus23> Dear FOSS developers! Please fully fill out our survey at http://elektra.limequery.org/625192 and a donation will go to FOSS projects. The survey is carefully crafted and helps research! Thank you! If you have any questions you can ask me.
[08:57] <mwhudson> can someone explain to me how to use livecd-rootfs?
[08:57] <mwhudson> or point me to some documentation
[09:03] <pitti> ogra perhaps ^ ?
[09:09] <mwhudson> pitti: hi :-)
[09:10] <mwhudson> pitti: steve and i were talking about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799 a little today
[09:10] <ubottu> Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged]
[09:11] <mwhudson> pitti: given that snapcraft failure you posted was with snapd 2.0.2, it seems that this is some problem that's caused by, or maybe revealed by, some change in yakkety, not snapd
[09:11] <mwhudson> pitti: obvious candidate would be systemd, i think?
[09:14] <pitti> mwhudson: yes, it's certainly a change in some underlying thing (kernel/systemd/util-linux/whatever)
[09:15] <mwhudson> pitti: do you have any ideas on how to figure out what?
[09:16] <mwhudson> i was idly wondering if you could reproduce it by booting a yakkety vm and just installing and uninstalling a snap in a loop
[09:17] <pitti> mwhudson: I don't know what snapd is trying to do there, but the bug reproduces perfectly locally, so it should be quite simple to look what exactly fails there
[09:17] <pitti> quite obviously it's setting up some loop device, and apparently that fails
[09:17] <mwhudson> yeah
[09:18] <mwhudson> i don't really see how that could fail though...
[09:20] <pitti> well, watch it live and see what happens :)
[09:20] <pitti> there's only so much you can learn from that tiny log
[09:30] <mwhudson> is it as bad as snapd just not working at all in yakkety?
[09:30] <mwhudson> i guess i can find that out easily enough
[09:31] <pitti> mwhudson: y-proposed only, 2.0.2 in yakkety still works
[09:32] <pitti> (well, the tests pass, so I guess it works well enough)
[09:32] <mwhudson> pitti: not all the time, according to that snapcraft failure
[09:32] <mwhudson> but yeah true, not completely broken
[09:33] <pitti> actually, 2.0.2 started to fail now as well,  for a different reason
[09:33] <mwhudson> oh good
[09:34] <pitti> it last succeeded on June 9 (2.0.2)
[09:34] <mwhudson> wait no, the other thing
[09:34] <pitti> ... value *exec.Error = &exec.Error{Name:"hello-world.echo", Err:(*errors.errorString)(0xc82000e670)} ("exec: \"hello-world.echo\": executable file not found in $PATH")
[09:37] <pitti> maybe hello-world changed in the store?
[09:40] <mwhudson> sounds like a great test, in that case
[09:40] <mwhudson> pitti: it's passed on xenial reasonably recently though
[09:42] <mwhudson> oh no, not that recently
[09:43]  * pitti runs locally on x and y
[09:43] <mwhudson> heh yep looks like the hello-word snap no longer provides hello-world.echo
[09:43] <ogra> mwhudson, it is really badly documented ...  livecd-rootfs is onlöy a bunch of config files for live-build
[09:44] <mwhudson> ogra: well i guess i'm glad that i didn't miss the docs then...
[09:44] <pitti> mwhudson: xenial has 2.0.10 already (breaking the SRU rules), so that also introduces some jitter
[09:44] <mwhudson> ogra: i notice that some of the config has hard-coded paths in /usr
[09:45] <ogra> mwhudson, this and https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html and http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/files might be the best hints you can get
[09:45] <mwhudson> ogra: so i guess if someone tells me to "use lp:livecd-rootfs" i check it out, dpkg-buildpackage & dpkg -i, then run lb config $whatever?
[09:45] <tsdgeos> anyone knows who do i have to "complain" because compiz-core-dbgsym in yakkety ddbs is too old?
[09:45] <ogra> mwhudson, it isnt that easy, but essentially, yes ... (you need to have the right ENV setup and to mimic the builds proper you need to have a stack of chroots
[09:46] <ogra> )
[09:46] <mwhudson> ogra: to be less mysterious, i'm trying to follow http://people.canonical.com/~mtrudel/console-conf/README
[09:46] <ogra> see the links above, they should explain it
[09:46] <mwhudson> which i think covers the ENV part
[09:46] <mwhudson> ok, /me reads
[09:47] <ogra> from rootstock specifically http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch
[09:47] <mwhudson> i don't think i've used live-build since 2011 or so, almost long enough
[09:47] <ogra> it s awful and painful ...
[09:48] <mwhudson> and shell
[09:48] <mwhudson> that's about the limit of my memories
[09:48] <pitti> mwhudson: ah, 2.0.10 dropped that HelloWorld test
[09:48] <mwhudson> pitti: oh ok
[09:49] <ogra> mwhudson, well, livecd-rootfs used to be a single shell script ... despite being spaghetti code it was a million times easier to maintain and use
[09:50] <mwhudson> ubuntu-image will save us all
[09:50] <mwhudson> right?
[09:50] <ogra> hah
[09:51] <ogra> (for now i'd be happy if ubuntu-image saved just snappy :P )
[09:57] <mwhudson> ogra: http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch is fairly terrifying
[09:57] <ogra> lol, sorry :)
[09:58] <ogra> it describes the build process pretty well though ... :)
[09:59] <mwhudson> ogra: why does it run lb inside the chroot? isolation?
[10:01] <ogra> it comes from a time before lxd :) ... but yes, clean build env ... and you dont really want to taint your PC with build scripts
[10:01] <ogra> effectively it mimics a live builder
[10:01] <ogra> (it is just doing the same as the launchpad live builders did by that time)
[10:02] <mwhudson> fair enough
[10:09] <cjwatson> and still do, because we want to run lb in a chroot of the appropriate Ubuntu series rather than whatever the host's base system is
[10:11] <ogra> cjwatson, good to know ... i really didnt look anymore since the switch to launchpad buildd
[10:16] <mwhudson> uh why the heck would lb build fail with 'E: Unable to locate package zsync'
[10:17] <ogra> sounds like a missing dependency
[10:17] <mwhudson> or missing universe?
[10:18] <ogra> oh, right, not in main
[10:19] <ogra> given that we run all our images through it on cdimage, someone should probably MIR it eventually :)
[10:19] <mwhudson> um i seem to have created a precise chroot somehow
[10:20] <mwhudson> seems unlikely to be what i wanted...
[10:20] <ogra> did you set the right env vars ?
[10:20] <mwhudson> i ran PROJECT=ubuntu-core SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image SUITE=xenial ARCH=amd64 lb config
[10:21] <mwhudson> which looks plausible to me...
[10:21] <mwhudson> oh
[10:21] <mwhudson> but i put the sudo on the wrong side of the env :(
[10:21] <ogra> EXTRA_PPAS="snappy-dev/image snappy-dev/edge" ... but yeah, the rest looks ok
[10:22]  * mwhudson swigs more beer
[10:22] <ogra> if you buuild core you definitely need universe btw
=== jamesh_ is now known as jamesh
[10:25] <mwhudson> nope still deboostrapping precise
[10:29] <ogra> did you properly link the /usr/share/livecd-rootfs/live-build/auto scripts `
[10:29] <ogra> ?
[10:34] <mwhudson> ogra: no, just figured that out myself
[10:34] <ogra> :)
[10:36] <mwhudson> ok that looks better
[10:37] <mwhudson> deboostrap is still running with --components=main,restricted but we'll see if that matters in the long run
[10:37] <ogra> we fixed a lot of the universe deps on our way to xenial ... but i'm not sure everything is gone ... the images definitely still have universe enabled
[10:47] <mwhudson> well that looks moderately successful
[10:47] <mwhudson> still exited with status 1 mind
[10:50] <ogra> heh
[10:50] <ogra> did it spit out two snaps ?
[10:51] <mwhudson> 99zz-check-uid-gid.chroot had a sad it seems
[10:51] <mwhudson> ogra: i don't think so, where would they be?
[10:51] <ogra> in $PWD
[10:51] <mwhudson> then no
[10:51] <ogra> then it didnt finish
[10:52] <mwhudson> ogra: http://paste.ubuntu.com/19262524/
[10:53] <ogra> paste the error ... todays xenial builds definitekly worked on the buildds... 99zz-check-uid-gid.chroot usually indicates that a system user was added
[10:53] <ogra> hmm, the uuidd group was added by something
[10:54] <mwhudson> the uuidd package, i assume
=== hikiko is now known as hikiko|ln
[10:55] <ogra> well, i dont get how you get it there ... it isnt like the seed changed in xenial
[10:58] <mwhudson> pulled in by lupin-casper apparently
[10:58] <ogra> uh
[10:58] <ogra> nothing you want really
[10:59] <ogra> you still use PROJECT=ubuntu-core SUBPROJECT=system-image ?
[10:59] <mwhudson> ys
[10:59] <ogra> that shouldnt pull in such stuff ... weird
[10:59] <mwhudson> it's only excluded for "ubuntu-server|ubuntu-touch|ubuntu-touch-custom)" apparently
[10:59] <ogra> well, and for all images that dont use an initrd or kernel at all :)
[11:00] <ogra> like all system-image ones should
[11:00] <mwhudson> i see
[11:00] <ogra> (we build a kernel snap during the ubuntu-core build, but thats a separate hack, not using live-build mechanisms )
[11:02] <ogra> try adding IMAGEFORMAT="plain"
[11:02] <ogra> and PREINSTALLED="true"
[11:03] <ogra> (wild guess though)
[11:08] <mwhudson> ok one more try and then bed :)
[11:14] <flexiondotorg> rbasak, I've seen you comments on my mate-hud sponsoring package.
[11:15] <flexiondotorg> I've corrected the license.
[11:16] <flexiondotorg> I've updated to adhere to Debian Python Policy.
[11:17] <flexiondotorg> I can make the package quilt too. But so far all the Ubuntu MATE specific packages in the Ubuntu archive are native.
[11:17] <flexiondotorg> So, is this simply a case of splitting the debian packaging from the source?
[11:20] <mwhudson> i have a snap!
[11:23] <ogra> yay
[11:23] <ogra> you shoudl have two :)
[11:23] <ogra> a kernel and an os snap
[11:23] <mwhudson> it's not finished yet :)
[11:23] <ogra> ah
[11:24] <mwhudson> although i have livecd.ubuntu-core.os.snap  ubuntu-core_16.04+20160713.23-17_amd64.snap
[11:24] <mwhudson>  so far
[11:24] <ogra> right, it creates a clean new chroot and in there creates a kernel snap
[11:24] <mwhudson> ah ok
[11:24] <ogra> so that takes a bit
[11:24] <mwhudson> yeah, it's getting kernel packages now, which seems consistent with making a kernel snap
[11:24] <ogra> yup
[11:25] <mwhudson> for next time is there an easy way to make it use the same proxy apt is configured to use?
[11:25] <ogra> shzould be done soon then ... it just installs them, creates an initrd and calls snapcraft snap
[11:25] <ogra> you can use MIRROR= and point to a local packageproxy
[11:25] <ogra> iirc
[11:26] <ogra> (see rootstock :) )
[11:26]  * ogra notes it is late at your place :)
[11:27] <ogra> (by the snap version :) )
[11:27] <rbasak> flexiondotorg: if you think the package should definitely be native, I'm happy for you to make that case. As long as it makes sense and wasn't a mistake.
[11:28] <flexiondotorg> OK. I'll push the changes and update the bug in a bit :-)
[11:28] <rbasak> flexiondotorg: I'd expect it to be quilt format though, because that more easily allows Debian/Ubuntu to patch on top of upstream releases if necessary. For the existing Ubuntu MATE specific packages, do "upstreams" exist?
[11:29] <rbasak> flexiondotorg: in this case, for example, what if Fedora wanted MATE with HUD support or something? It doesn't feel distro-specific to me.
[11:29] <flexiondotorg> rbasak, Those MATE packages in Debian and Ubuntu are all quilt.
[11:29] <flexiondotorg> Those specific to Ubuntu MATE, and only in the Ubuntu archive, are currently all native.
[11:29] <rbasak> flexiondotorg: note that debian/patches/ exists in the version I reviewed, which AFAIK doesn't make sense for a native package.
[11:30] <flexiondotorg> mate-hud can only work on Ubuntu.
[11:30] <flexiondotorg> Not other distro I've checked carries the required libraries.
[11:30] <rbasak> OK, but that's because of missing dependencies, which isn't fundamental.
[11:31] <flexiondotorg> rbasak, I'll drop debian/patches it is leftover from my skeleton.
[11:31] <rbasak> As an exmaple, unity, unity8 and mir are all non-native packages.
[11:31] <mwhudson> ogra: heh yes indeed
[11:31]  * mwhudson zzz
[11:31] <flexiondotorg> rbasak, So I am perfectly happy to make it non-native.
[11:31] <rbasak> OTOH, dpkg is native because it would make no sense for dpkg to be a separate upstream to Debian.
[11:31] <rbasak> flexiondotorg: I don't want you to break consistency just because of one reviewers opinion.
[11:31] <flexiondotorg> I can split the packaging from the "upstream".
[11:32] <rbasak> So sorry, I'm not sure what my opinion is. If you have a good reason, perhaps document in the bug and we'll leave it to the archive admins to decide?
[11:32] <flexiondotorg> rbasak, Things are the way they are because that was how the very first Ubuntu MATE packages were introduced.
[11:32] <flexiondotorg> I quite happy to do "the right thing" :-)
[11:33] <flexiondotorg> I'll make it non-native.
[11:33] <rbasak> flexiondotorg: would you mind asking on the ubuntu-devel ML or something? I'd appreciate other opinions, and then the thread will be archived and you can have consistency. That's "the right thing", IMHO. Or if you wish, I'm happy to upload and leave it to the archive admins on NEW review if you wish, since it appears to be debateable.
[11:34] <flexiondotorg> rbasak, I will make it non-native. It does seem the sensible choice and no effort.
[11:35] <rbasak> flexiondotorg: OK, thanks.
=== hikiko|ln is now known as hikiko
[12:14] <flexiondotorg> rbasak, I've update the open posting of the bug and added a comment - https://bugs.launchpad.net/ubuntu/+bug/1602270
[12:14] <ubottu> Launchpad bug 1602270 in Ubuntu "[needs-packaging] mate-hud" [Wishlist,New]
[12:14] <flexiondotorg> Rebuilt and tested.
[12:51] <rbasak> flexiondotorg: thanks. I reviewed from your .dsc before. Should I be using your git repo on bitbucket now? When I reviewed, there was no postinst. On bitbucket, there is a postinst that calls glib-compile-schemas. Should this not use a dpkg trigger? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587661 suggests that a suitable trigger is available. Finally, for an upload, I'll need an orig tarball
[12:51] <ubottu> Debian bug 587661 in glib2.0 "should install glib-compile-schemas in libglib2.0-bin" [Wishlist,Fixed]
[12:51] <rbasak> from somewhere. Should I just be using uscan?
[13:12] <flexiondotorg> rbasak, I update the .dsc link in the opening post too :-)
[13:13] <flexiondotorg> So if the dget of that .dsc is OK. Then drop the ~yakkety1.2 suffix and upload please.
[13:13] <flexiondotorg> rbasak, https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+files/mate-hud_16.10.0-1~yakkety1.2.dsc
=== _salem is now known as salem_
[14:13] <rbasak> pitti: I have the known mysql-5.7 dep8 failure on ppc64el holding up proposed migration again. Can we override it to treat as "always failed"?
[14:14] <pitti> rbasak: yep, bumped the hint'
[14:27] <rbasak> Thanks!
[14:31] <tseliot> pitti: you rejected u-d-c in xenial because it's not yet in yakkety. The truth is u-d-c in yakkety keeps failing because of this: The following packages have unmet dependencies:  sbuild-build-depends-ubuntu-drivers-common-dummy : Depends: python3-aptdaemon.pkcompat but it is not going to be installed
[14:31] <tseliot> https://launchpadlibrarian.net/272774340/buildlog_ubuntu-yakkety-amd64.ubuntu-drivers-common_1%3A0.4.19_BUILDING.txt.gz
[15:07] <arges> cking: bug 1599219 1599221 1599259 did these get fixed in yakkety?
[15:07] <ubottu> bug 1599219 in spl-linux (Ubuntu Xenial) "SRU: spl-linux: xenial: apply fix Fix do_div() types in condvar:timeout" [Medium,In progress] https://launchpad.net/bugs/1599219
[15:07] <arges> well the first two relaly
[15:10] <cking> arges, 1599219 says it's been fixed in spl 0.6.5.7 (in Yakkety),  1599221 says it's in yakkety and needed to be backported, so if spl 0.6.5.7-0ubuntu4 is released then yes
[15:11] <arges> cking: ok i'll fixup those tasks in the bug, it makes review a bit easier for me than having to parse through version numbers and released versions etc
[15:38] <slangasek> cking: is stress-ng autopkgtest failing on armhf because the tests are broken, or because the kernel is broken? :)
[15:39] <cking> slangasek, got a link to that so I can figure it out?
[15:40]  * cking found it, just a sec
[15:40] <slangasek> cking: http://autopkgtest.ubuntu.com/packages/s/stress-ng/yakkety/armhf/
[15:40] <slangasek> k
[15:44] <cking> slangasek, looks like the semantics on arm are different from x86 when it comes write prot on the text segment, which is not what I expected, but why this didn't happen previously I don't know as I'm sure that's passed before
[15:45] <slangasek> :)
[15:47] <cking> hrm, it passed on the dragonboard too when I tested it, most bizzare
[15:49] <slangasek> dragonboard being an arm64 host kernel, I imagine?
[15:58] <smoser> hey. in a container, i'm seeing -.mount fail occasionally
[15:58] <smoser> what seems odd is that it ever succeeds.
[15:59] <smoser> as when it fails, systemctl status -- -.mount
[15:59] <smoser> shows:
[15:59] <smoser> ExecMount=/bin/mount /dev/disk/by-label/cloudimg-rootfs / -t ext4
[16:21] <jderose> tyhicks: so in terms of getting the ecryptfs-utils fixes into 16.04.1, will a new upstream 112 release be made or will 111-0ubuntu1 just be patched?
=== JanC is now known as Guest81961
=== JanC_ is now known as JanC
[16:52] <tyhicks> jderose: 111-0ubuntu1 will be patched
[16:52] <tyhicks> jderose: they'll go through the security pocket and I'll release them by tomorrow
[16:52] <jderose> tyhicks: do you have patched yet, or would be helpful for me to attach an updated patch to lp:1597154
[16:53] <jderose> er, have a patch yet...
[16:53] <tyhicks> jderose: I have debdiffs prepared but haven't tested
[16:53] <tyhicks> jderose: I'll upload them to the ubuntu-security-proposed ppa shortly and point you there so you can test
[16:53] <jderose> tyhicks: awesome, thanks. yeah, i'll help test them as so as there are builds
[17:02] <cking> slangasek, yep, arm64 dragonboard it works fine, so I wonder what the kernel is on that arm64 test environment is
[17:12] <tyhicks> jderose: wily and xenial updates are building in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
[17:13] <slangasek> cking: autopkgtest [23:32:03]: testbed running kernel: Linux 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:13:13 UTC 2016
[17:14] <cking> slangasek, ok, I'll get access to a box later tonight or tomorrow and figure out what the root cause is
[17:14] <cking> ta
[17:15] <slangasek> cking: of course, that doesn't tell you if it's an arm64 or armhf host
[17:15] <jderose> tyhicks: thanks!
[17:15] <slangasek> (and I don't recall which it is)
[17:15] <cking> no probs, I can dig into it from now
=== PaulW2U_ is now known as PaulW2U
[17:18] <tyhicks> jderose: thanks for offering to test! (note that I haven't staretd my testing of those security updates just yet)
[17:19] <jderose> tyhicks: no problem, System76 is always happy to help with testing :)
[17:19] <tyhicks>  \o/
[18:18] <semiosis> slangasek: whats the next step for my merge request?  i haven't seen Odd_Bloke around in a couple days to ask about the localhost thing.  thoughts?
[18:19] <semiosis> https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
[19:06] <smoser> slangasek, or someone else systemd boot knowledgable.. care to read bug https://bugs.launchpad.net/juju-core/+bug/1602192 .
[19:06] <ubottu> Launchpad bug 1602192 in juju-core "deploy 30 nodes on lxd, machines never leave pending" [Critical,In progress]
[19:06] <smoser> my last two comments i think are the crux of the issue.
[19:07] <smoser> i ping you by name because other people i know that could answer this are typically europe time zone
[19:07] <smoser> (pitti and xnox )
[19:36] <slangasek> smoser: the job output notes that this is from systemd-fstab-generator.  Does /etc/fstab have different contents on the successful vs. failed containers?
[19:37] <smoser> no
[19:37] <slangasek> semiosis: we do really need the input from the cloud team regarding correctness of the hostname resolution change (and whether to make it in both places or neither).  If Odd_Bloke is unavailable, perhaps rcj or gaughen can help
[19:37] <slangasek> smoser: ok. what are the contents there?
[19:38] <smoser> # cat /etc/fstab
[19:38] <smoser> LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
[19:38] <slangasek> alright
[19:38] <slangasek> so has udev/systemd failed to resolve that label to a device?
[19:39] <slangasek> (is /dev/disk/by-label/cloudimg-rootfs present?)
[19:39] <smoser> never in a container.
[19:39] <smoser> no udev
[19:40] <smoser> so that is strictly wrong. but in most cases (probably > 90% of the time) something addresses that.
[19:41] <semiosis> slangasek: fwiw, as far as correctness goes, Odd_Bloke already had me change from installing libnss-myhostname (as was done in pre-xenial vagrant boxes) to using this cloud-init method.
[19:42] <semiosis> slangasek: you also had concerns about the virtualbox packages not being in main.  if that's a blocker for you, what direction would you suggest taking?  i'd be happy to start down that path
[19:42] <semiosis> ...if necessary
[19:58] <slangasek> semiosis: I've been talking with gaughen already about a path forward on virtualbox.  We can probably land this change and deal with the MIR for virtualbox later, provided we agree that's the direction to go
[19:59] <semiosis> slangasek: that sounds great to me.  thanks for your time.  let me know if there's anything else I can do to help move things forward.
[20:09] <jderose> tyhicks: finished testing ecryptfs-utils packages from https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages everything seem solid, no issues found. i tested both ecryptfs-setup-swap and ecryptfs-utils.postinst
[20:13] <gaughen> slangasek, semiosis I'm reading the scrollback
[20:18] <tyhicks> jderose: thank you for reporting back :)
[20:19] <tyhicks> jderose: did you only test on GPT partitioned devices that were affected by the bug?
[20:19] <jderose> tyhicks: thus far yes. still need to check for regressions on non-GPT partitioned drives
[20:19] <jderose> we'll keep testing though
[20:20] <tyhicks> jderose: ok - I'll be testing that situation, as well
[20:21] <tyhicks> jderose: I just wanted to make sure I understood what testing you've already done
[20:25] <jderose> tyhicks: ah, gotcha. on a UEFI system with an NVMe drive and an oem install, i first tested that ecryptfs-setup-swap correctly worked when going through oem-firstrun and choosing encrypted home directory. then i unset bit 63 and ran `sudo apt-get install --reinstall ecryptfs-utils` to make sure ecryptfs-utils.postinst would correctly re-set bit 63. both worked fine.
[21:07] <jderose> tyhicks: okay, i finished tested on an non-NVMe SSD, in both UEFI (GPT partitioning) and BIOS (msdos partitioning)... no issues found, everything seems shiny.
[21:08] <tyhicks> jderose: thanks again :)
[21:08] <jderose> also, i made sure that the new ecryptfs-utils.postinst script would re-set bit 63 okay even when on a standard SSD (non-NVMe)
[21:08] <jderose> np :)
[21:13] <jderose> tyhicks: oh, i've only been testing xenial so far, haven't tested wily at all. need help testing wily?
[21:13] <tyhicks> jderose: no, I can handle wily
[21:15] <jderose> tyhicks: cool, thanks!
[22:55] <nacc> mdeslaur: ping re: python-django 1.8.7-1ubuntu2; i'm trying to merge to yakkety, and it seems like our xenial CVE fix ended upnot being the one taken upstream (the patch's commit sha doesn't match anything on github or anonscm and there's no dep3 url in the patch)
[22:56] <nacc> mdeslaur: the merge is fine, in that upstream has the right CVE fix, just wanted to bring to your attention, in case xenial needs a corrected fix
=== salem_ is now known as _salem