[00:41] <hallyn> pitti: mbiebl_: so i think i've got a bug in yakkety's deb-systemd-helper:  when libvirt-bin.service is renamed t libvirtd.service as part of packaging update, it fails on the new code that calls systemctl preset bc of a onexisting file
[00:41] <hallyn> is that bc the service unit file was renamed but the preset not yet?
=== juliank_ is now known as juliank
[01:49] <hallyn> but i dunno what exactly it means that does not exist:
[01:49] <hallyn> http://paste.ubuntu.com/16270773/
=== JanC is now known as Guest97342
=== JanC_ is now known as JanC
[03:05] <Umeaboy> Hi!
[03:05] <Umeaboy> In 15.10 I can't find nouveau-kms.conf in /etc/modprobe.d/
[03:06] <Umeaboy> I want to run this command, but I'm thinking of changing the name of the conf-file to blacklist.conf: echo options nouveau modeset=0 | sudo tee -a /etc/modprobe.d/nouveau-kms.conf
[03:06] <Umeaboy> Would that be correct?
[05:13] <hallyn> yay, seem to have working upgrades
[05:16] <hallyn> urg, so /etc/init.d/* are considered conffiles?  they can't be removed?
[08:21] <alkisg> Hi, apt complains that this repository of mine [http://ts.sch.gr/repo/dists/stable/InRelease] is signed using a weak key.
[08:21] <alkisg> I read in https://wiki.debian.org/Teams/Apt/Sha1Removal that sha1 is obsolete.
[08:21] <alkisg> But my repository also has sha256... Reprepro doesn't yet support sha512, is the solution to just completely remove sha1?
[09:10] <alkisg> Hmm it looks like my DSA key won't do, and I'll need a new, RSA one...?
[09:14] <cjwatson> alkisg: The problem isn't the checksums in the file, but that the entire file is signed using a SHA-1 digest.  Pass --digest-algo SHA512 to gpg
[09:15] <cjwatson> alkisg: Works with DSA too, although switching to RSA is generally a good idea
[09:15] <alkisg> cjwatson: thanks, looking how to tell reprepro to pass options to gpg...
[09:15] <cjwatson> I don't know that part, although at absolute worst you could give it a wrapper
[11:55] <Umeaboy> Hi!
[11:56] <Umeaboy> I just installed makemkv in 15.10 and I got no errors with that.
[11:56] <Umeaboy> I get this error when it tries to read a perfectly scratch free DVD disc: DEBUG: Code 101019396 at o#cQLC'ojTv?,F~6kN:29396092
[11:56] <Umeaboy> DEBUG: Code 101019396 at o#cQLC'ojTv?,F~6kN:29393930
[11:57] <Umeaboy> ILLEGAL REQUEST:MEDIA REGION CODE IS MISMATCHED TO LOGICAL UNIT REGION'
[11:57] <Umeaboy> at offset '1048576'
[11:57] <Umeaboy> How can I solve that?
[11:57] <Umeaboy> I have checked that there's no smudge on the lens.
[11:59] <Umeaboy> It seems like my drive has a RPC protection.
[17:14] <alkisg> cjwatson: I couldn't make it work with my DSA-1024 key, but I was able to do it with a new RSA-1024 key. My last test was with plain `gpg --clearsign some.text`, without repositories involved; gpg wouldn't produce a SHA256 or SHA512 signature for my DSA-1024 key.
[17:14] <alkisg> *a new RSA-4096 key, sorry
[17:39] <juliank> alkisg: DSA1 keys only support 160 bit hashes, so they cannot support the larger SHA2 variants (without truncation)
[17:40] <juliank> (JFTR)
[17:41] <juliank> The correct step is to roll out a new RSA key like you generated, sign it with the old DSA key, and tell your users to switch to the new key in a message signed with the old one (or package, if you ship key in a package)
[17:53] <alkisg> juliank: thank you for verifying this, I will indeed ship a new key with a package.
[19:51] <cjwatson> juliank: It is possible with truncation, but certainly using a stronger key is better.
[19:52] <juliank> cjwatson: I heard that,  but I'm not really sure if GPG supports that
[19:53] <juliank> Maybe it's a different algo setting than the normal SHA256 and stuff
[19:53] <cjwatson> juliank: We had it working for an old Ubuntu key at one point, which is why I confidently claimed it worked :-)
[19:54] <cjwatson> I guess I might have missed something.  It wouldn't have been with current apt.
[21:06] <psusi> ummm... why does it appear that uds.ubuntu.com has not been updated since last year?
[23:07] <TJ-> with unity desktop which component handles ssh key passphrases? I've just found that using a remote SSH session the pass-phrase for the keyring is bring prompted for in the remote PC's desktop, preventing the SSH session from doing a 'git clone <host-entry-in-.ssh/config>:<path>' but can't tell what to report the bug against
[23:09] <mdeslaur> TJ-: try unsetting SSH_AUTH_SOCK in the remote session
[23:11] <TJ-> mdeslaur: ooo, thanks, I was just looking in the 'env' for something like that
[23:11] <TJ-> mdeslaur: thank you, that did it. is that a 'bugette' in the ssh env setup?
[23:12] <mdeslaur> I'm not sure why it's being set in your remote session
[23:24] <TJ-> me neither; I'll investigate. It's a relative new clean 16.04 install with Unity I've not done any tinkering yet
[23:29] <TJ-> there's a weird bug with gnome-screensaver and pam-yubico interaction too preventing unlocking a locked GUI session; when using challenge-response the system-wide challenge file cannot be accessed because g-s runs as $USER but any login/sudo etc causes the file to be owned by root with only u+rw. there's a fix upstream so might need to SRU that