DalekSec | apw: Any luck looking at the new cryptsetup? If it helps, I did a merge for myself end of last month. | 07:32 |
---|---|---|
DalekSec | https://sigma.unit193.net/source/cryptsetup_1.7.1-0ubuntu1.dsc | 07:33 |
=== dgadomski_ is now known as dgadomski | ||
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 | 08:59 |
tjaalton | then again it's not out of proposed yet | 09:08 |
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:12 |
apw | tjaalton, almost cirtainly not be blocked ... checking | 09:17 |
tjaalton | it broke something for ntfs mounts | 09:17 |
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:18 |
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:19 |
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 | 09:20 |
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:14 |
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:16 |
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:37 |
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:38 |
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:39 |
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:40 |
apw | sounds like you are having fun, i don't know what wally thought switchable graphics was ever a good idea architecturally | 11:41 |
tjaalton | xnox: is this a skylake laptop? | 11:43 |
xnox | yes. | 11:43 |
tjaalton | so you need that new initramfs-tools | 11:43 |
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:44 |
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:45 |
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:46 |
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:48 |
xnox | apw, the copy_modules_dir of ubuntu/i915 is kosher. | 11:53 |
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:05 |
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 ? | 12:57 |
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:04 |
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 | 13:05 |
lamont | apw: (or anyone) in trusty and later, which, if any, filesystems still report 1-second granularity timestamps? | 14:00 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
lamont | it's specifically code that was added to help named installs with thousands of zones survive the admin saying "rndc reload" | 14:14 |
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:16 |
lamont | and yeah, milliseconds is fine | 14:17 |
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:18 |
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:19 |
lamont | but it's invasive enough of a change that I'd rather just go lalalalaalalala and ignore it for now | 14:20 |
apw | surely the bit which adds ns check is the identicle bit we'd want to keep the inode number, but hey | 14:22 |
smb | apw, though then bind9 has bigger issues right now than to worry about timestamps | 14:23 |
smb | or rather not bind9 but poor tools trying to use its libraries... :-P | 14:24 |
apw | heh | 14:30 |
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:00 |
smb | lamont, Just seriously felt like needing a shower after having been up to my throat in user-space code... ;) | 15:03 |
apw | smb, :) | 15:14 |
lamont | smb: heh | 15:26 |
manjo | apw, initramfs tools is in your test PPA correct ? | 16:52 |
manjo | apw, https://launchpad.net/~apw/+archive/ubuntu/initramfs-tools | 16:53 |
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:58 |
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. | 16:59 |
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:03 |
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:09 |
apw | manjo: i thpught i turned arm64 on on that ppa | 17:22 |
apw | manjo: oh initramfs-tool-test, note the -test | 17:22 |
manjo | apw, it is working .. I will update the bug | 17:31 |
manjo | apw, testing upper case now | 17:33 |
apw | manjo, great thanks | 17:37 |
manjo | apw, wait .. upper case does not wrok | 17:37 |
apw | hrm, what format is the thing, can you paste it for me | 17:39 |
manjo | yes | 17:39 |
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:40 |
* 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:43 |
* manjo is sorry .. did not realize this would turn into such a cluster | 17:44 | |
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:45 |
apw | manjo, oh blech ... i see whats going on ... boo | 17:48 |
manjo | thing do with the 5 digits / | 17:48 |
manjo | ? | 17:48 |
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:54 |
manjo | apw, drinking and typing on Friday evening ... s**t happens | 17:56 |
apw | manjo, heh i did that this morning, so no excuses | 17:57 |
manjo | apw, ☺ beer fixes sober coding errors .. works either way .. | 17:58 |
apw | heh i wish i was drinking, but i am not | 17:58 |
manjo | apw, heh I hear ya .. I could use a strong drink right now ... s**t blowing up on my face all day | 17:59 |
=== decoder_ is now known as decoder |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!