[07:32] <DalekSec> apw: Any luck looking at the new cryptsetup?  If it helps, I did a merge for myself end of last month.
[07:33] <DalekSec> https://sigma.unit193.net/source/cryptsetup_1.7.1-0ubuntu1.dsc
=== dgadomski_ is now known as dgadomski
[08:59] <tjaalton> apw: do you have initramfs-tools in git somewhere? bug 1500751 needs fixing
[08:59] <ubot5> bug 1500751 in initramfs-tools (Ubuntu) "Cryptsetup Keyboard not working on Xubuntu 3.19.0-30" [High,In progress] https://launchpad.net/bugs/1500751
[09:08] <tjaalton> then again it's not out of proposed yet
[09:12] <tjaalton> should it still be blocked by https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1548120 ?
[09:12] <ubot5> Launchpad bug 1548120 in initramfs-tools (Ubuntu) "[xenial][initramfs-tools] support uppercase and lowercase uuids" [High,New]
[09:17] <apw> tjaalton, almost cirtainly not be blocked ... checking
[09:17] <tjaalton> it broke something for ntfs mounts
[09:18] <tjaalton> but that was not the reason for the tag
[09:18] <apw> tjaalton, oh poo ... ok ... so that needs fixing too
[09:18] <apw> tjaalton, do you have a fix in hand for your problem, if so if you email it to me now
[09:18] <tjaalton> I do
[09:18] <apw> tjaalton, i'll fix this uuid thing again, and apply yours at the same itme
[09:19] <tjaalton> https://launchpadlibrarian.net/223637474/debdiff-vivid
[09:19] <apw> (as yes it is in git)
[09:19] <apw> tjaalton, thanks ...
[09:19] <apw> grrr
[09:19] <tjaalton> this still works, sans changelog
[09:20] <tjaalton> yeah this fell through the cracks, and now vivid is eol. trusty would need this too, but it's also still in proposed waiting for testing
[09:20] <apw> ack
[11:14] <xnox> ah, i'm not the only one
[11:14] <xnox> bug 1500751 =)
[11:14] <ubot5> bug 1500751 in initramfs-tools (Ubuntu) "Cryptsetup Keyboard not working on Xubuntu 3.19.0-30" [High,In progress] https://launchpad.net/bugs/1500751
[11:16] <xnox> i have this optimus things, with nvidia & intel graphics. Is there a known good way to force intel graphics only, in plymouth and elsewhere?
[11:16] <xnox> my input is all weird with latest kernel -> plymouth is shown, yet i "type" at top left corner, and not into "plymouth" as if plymouth doesn't have focus.
[11:37] <apw> tjaalton, ok ... i've applied your fix and what i hope is the fix for the other issue, and uploaded to ppa:apw/ubuntu/initramfs-tools-test
[11:38] <apw> xnox, plymouth not having focus iirc is often when plymouth has rejected all the graphics displays as non-primary
[11:38] <apw> so it doesn't open the terminal, so the underlying vt reads and echos
[11:38] <xnox> ack.
[11:39] <xnox> apw, i'm suspecting the kernel/plymouth might have started to either use noveau instead of intel graphics, or noveaue graphics (with plymouth) got broken
[11:40] <apw> manjo, it seems your UUID fix is blowing up NTFS installs, i've uploaded a "only apply this to rfc4122 format uuids" fix to ppa:apw/ubuntu/initramfs-tools-test, could you verify that still fixes youpls.
[11:40] <xnox> i've blacklisted noveaue, purged noveaue xserver packages, booted without splash (to unlock the drive) and have desktop now (previously lightdm would work, unity/gnome-shell/plymouth crash/not-work)
[11:41] <apw> sounds like you are having fun, i don't know what wally thought switchable graphics was ever a good idea architecturally
[11:43] <tjaalton> xnox: is this a skylake laptop?
[11:43] <xnox> yes.
[11:43] <tjaalton> so you need that new initramfs-tools
[11:44] <apw> xnox, ahh that should be in ppa:apw/ubuntu/initramfs-tools-test
[11:44] <tjaalton> because otherwise initrd doesn't come with i915_bpo
[11:44] <apw> ubuntu2~rc1
[11:44] <tjaalton> oh I missed the backlog
[11:44] <tjaalton> so yeah
[11:44] <apw> tjaalton, oh i wasn't asking him to test it :)  i was just asking you and manjo :)
[11:45] <apw> if he can test too ... yay
[11:45] <apw> xnox, make sure you have an old kernel and initramfs :)
[11:45] <xnox> apw, i'm using a spare machine =) that seems to work.
[11:46] <apw> the initramfs-tools fixes you ?
[11:46] <xnox> apw, did i hear that right, that i shall dist-upgrade and everything will work.
[11:46] <xnox> apw, i've booted the laptop by hand, without splash and not shutting it down now =)
[11:46] <apw> without any risk of explosion, yes i definatly said that :)
[11:46] <tjaalton> it might also unbreak your nouveau
[11:46] <xnox> wheere can i get the magical ubuntu2~rc1?
[11:46] <apw> xnox, ahh that should be in ppa:apw/ubuntu/initramfs-tools-test
[11:46] <apw> ubuntu6~rc1
[11:48] <xnox> i ponder to just cowboy in the hooks/framebuffer thing
[11:48] <xnox> cause i don't want to enable that ppa, will forget about it.
[11:53] <xnox> apw, the copy_modules_dir of ubuntu/i915 is kosher.
[12:05] <apw> xnox, as long as it fixes you :)
[12:05] <apw> xnox, i tend to enable the ppa, instlal the pckage, and then remove it immediatly
[12:05] <apw> i always version before the archive in there
[12:57] <manjo> apw, sure will do today
[12:57] <apw> manjo, thanks ... hopefully that one will work for everyone and can actually go out
[12:57] <manjo> apw, thanks a ton .. will test do you have a bug number I can report back to ? 
[13:04] <apw> bug: #1553107
[13:04] <ubot5> bug 1553107 in initramfs-tools (Ubuntu) "initramfs-tools: UUID checks now fail for NTFS which has upper cases UUIDS" [Critical,In progress] https://launchpad.net/bugs/1553107
[13:04] <apw> manjo, ^
[13:05] <manjo> apw, awesome .. we are in a critsit with one of our friends today.. but I will definitely find time to test that for you and report back in that bug 
[14:00] <lamont> apw: (or anyone) in trusty and later, which, if any, filesystems still report 1-second granularity timestamps?
[14:03] <apw> lamont, hmmm, fat perhaps
[14:03] <apw> those kinds of places, not sure you'd keep dns things one one of those
[14:03] <apw> i'dbe slightly suspicious of samba mounts, and would suggest checking nfs
[14:03] <lamont> apw: let me reprhase that - places where even the most insane user/admin might put /etc
[14:03] <apw> but ... they should all just return 0 in that
[14:04] <apw> they should still return valid times in the calls which support ns numbers though right ?
[14:04] <apw> so ... do you care ?
[14:04] <lamont> fat is so broken in so many ways for that, making it not a consideration
[14:05] <lamont> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1553176
[14:05] <ubot5> Launchpad bug 1553176 in bind9 (Ubuntu) "BIND ignores nanoseconds field in timestamps, fails to load newer versions of zones on reload" [High,Confirmed]
[14:05] <apw> lamont, right but if you take them into account (the ns) tey should be valid and always 0 or something on older broken filesystems
[14:05] <lamont> and a related "maas does crazy things trying to work around 1-sec granularity" issue - I'm looking at "do I push to fix this in trusty, or not.
[14:06] <lamont> apw: true, making them either "still broken" or "fixed?"
[14:06] <lamont> s/?//
[14:06] <lamont> newly-broken being the one I really want to avoid
[14:06] <apw> well i think your contention that all sane underlying things would support <1s granularity
[14:07] <apw> i beleive if they are using something without, they already are broken, so makign it take ns into account won't make them any worse i odn't think
[14:07] <lamont> and no architecture where the patch in that bug would be bad?  (given that bind9 made it into xenial with that fix, it at least compiles, so nevermind that question
[14:07] <lamont> cogent argument.  thanks for the clarifying conversation
[14:08] <apw> do bear in mind just because the FS reports ns timestamps in its stat info
[14:08] <apw> that does not make the granulatity ns, it may well jump in multiple ms
[14:08] <apw> so i am not sure you can be confident of avoiding your issue if you keep updating the file at line speed
[14:09] <apw> lamont, ^
[14:09] <smb> line or light...
[14:09] <apw> all of the above :)  "very quickly" might be less than the fs granulairity regardless of the stat result maximum granularity
[14:10] <apw> though it would be easy enough for maas to stat the file, update it, stat it again, if the timestamps match, touch it again until its not
[14:10] <smb> yeah, true indeed
[14:10] <lamont> oh, that's fine
[14:10] <lamont> we take lots longer than that to acutally write the file
[14:10] <apw> and guarentee we never hit that issue
[14:10] <apw> or ... you could fix bind so when you ask it to reload, it does regardless of the timestamps
[14:11] <apw> because you know you asked it to
[14:11] <lamont> http://paste.ubuntu.com/15276110/ <-- from the headscratching yesterday finding the bug
[14:11] <apw> and it seems rude for it to say, naaa you are a tool the file is the same date i hate you
[14:11] <apw> all of the above :)  "very quickly" might be less than the fs granulairity regardless of the stat result maximum granularity
[14:11] <apw> damn you paste
[14:11] <smb> apw, nah you cannot make "tools" useful... :-P
[14:12] <apw> lamont, it is actually unreasonable for bind9 to be sent an _explicit_ reload and for it to say "nope i know better"
[14:12] <apw> why would you send it a reload if you didn't want it to like actually reload
[14:13] <lamont> if you send it a bunch of reloads for 1 zone, there's no reason it can't combine them into one load
[14:14] <lamont> it's specifically code that was added to help named installs with thousands of zones survive the admin saying "rndc reload"
[14:16] <lamont> the process goes: update zone file (atomically...), run rndc reload $ZONE, bind9 wakes up, processes zonefile, remembers when that happened
[14:16] <lamont> so there's definitely some lag between the zone getting written and bind9 serving new data
[14:17] <lamont> and yeah, milliseconds is fine
[14:18] <apw> lamont, so why is it not checking the inode and device numbers as well as the time
[14:18] <lamont> also, I'm fine with adding code down the road that says "while (timestamp hasn't changed) {write the *(^)*&*& file;}"
[14:19] <apw> as to make an atomic update you necesarily need to change the file, ie the inode number on the device
[14:19] <lamont> because we hate veryone
[14:19] <apw> if bind9 did that, we'd avoid this completely
[14:19] <lamont> true.  that will go in the bug report to upstream
[14:20] <lamont> but it's invasive enough of a change that I'd rather just go lalalalaalalala and ignore it for now
[14:22] <apw> surely the bit which adds ns check is the identicle bit we'd want to keep the inode number, but hey
[14:23] <smb> apw, though then bind9 has bigger issues right now than to worry about timestamps
[14:24] <smb> or rather not bind9 but poor tools trying to use its libraries... :-P
[14:30] <apw> heh
[15:00] <lamont> smb: adding back in the -export libs is inplan for this weekend (mgilbert is working on that, and worst case, I'll work on it early next week)
[15:00]  * lamont has a flight to kill time on monday evening
[15:00] <smb> lamont, Yeah, I know. And thanks for that.
[15:03] <smb> lamont, Just seriously felt like needing a shower after having been up to my throat in user-space code... ;)
[15:14] <apw> smb, :)
[15:26] <lamont> smb: heh
[16:52] <manjo> apw, initramfs tools is in your test PPA correct ? 
[16:53] <manjo> apw, https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools
[16:58] <manjo> apw, $ apt-cache policy initramfs-tools
[16:58] <manjo> initramfs-tools:
[16:58] <manjo>   Installed: 0.122ubuntu5~rc2
[16:58] <manjo>   Candidate: 0.122ubuntu5~rc2
[16:58] <manjo>   Version table:
[16:58] <manjo>  *** 0.122ubuntu5~rc2 100
[16:58] <manjo>         100 /var/lib/dpkg/status
[16:58] <manjo>      0.122ubuntu3 500
[16:58] <manjo>         500 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 Packages
[16:58] <manjo>      0.122ubuntu1~rc4 500
[16:58] <manjo>         500 http://ppa.launchpad.net/apw/initramfs-tools/ubuntu xenial/main arm64 Packages
[16:58] <manjo> apw, are you missing arm64 ? 
[16:59] <cristian_c> !paste
[16:59] <ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imgur.com/ !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[17:03] <manjo> apw, or is it the version in proposed ? 0.122ubuntu5 500
[17:03] <manjo>         500 http://ports.ubuntu.com/ubuntu-ports xenial-proposed/main arm64 Packages
[17:09] <manjo> apw, it is no clear to me that proposed have any changes for NTFS .. can you please tell me which PPA / archive the new initramfs tools is in ?
[17:22] <apw> manjo: i thpught i turned arm64 on on that ppa
[17:22] <apw> manjo: oh initramfs-tool-test, note the -test
[17:31] <manjo> apw, it is working .. I will update the bug 
[17:33] <manjo> apw, testing upper case now 
[17:37] <apw> manjo, great thanks
[17:37] <manjo> apw, wait .. upper case does not wrok
[17:39] <apw> hrm, what format is the thing, can you paste it for me
[17:39] <manjo> yes
[17:40] <manjo> I was going to update that bug ... but I can paste here
[17:40] <apw> ta
[17:40] <apw> do update the bug too pls
[17:43]  * apw drumbs his fingers
[17:43] <manjo> root=PARTUUID=7c5978e5-a56f-4c4c-a3f1-de1467d0b602 (lower case) works
[17:43] <manjo> root=PARTUUID=7C5978E5-A56F-4C4C-A3F1-DE1467D0B602 (upper case) does not work.
[17:44]  * manjo is sorry .. did not realize this would turn into such a cluster 
[17:45] <apw> manjo, meh, we'll get there, i was over zelous applying it to everything, and underzelous applying it to anything now it seems :)
[17:48] <apw> manjo, oh blech ... i see whats going on ... boo
[17:48] <manjo> thing do with the 5 digits / 
[17:48] <manjo> ? 
[17:54] <apw> manjo, no just not thinking when writing the code, i was losing the DEV when checking it ... so i've just uploaded a ~rc2 ... should be built in about 20m
[17:54] <manjo> ok sure I can test that 
[17:56] <manjo> apw, drinking and typing on Friday evening ... s**t happens 
[17:57] <apw> manjo, heh i did that this morning, so no excuses
[17:58] <manjo> apw, ☺ beer fixes sober coding errors .. works either way ..  
[17:58] <apw> heh i wish i was drinking, but i am not
[17:59] <manjo> apw, heh I hear ya .. I could use a strong drink right now ... s**t blowing up on my face all day
=== decoder_ is now known as decoder