Bug#1078421: mwclient upstream status
As one of the current mwclient maintainers: we have merged a patch to remove the expectation of the writeapi flag - https://github.com/mwclient/mwclient/pull/345 - and intend to do a 0.11.0 mwclient release today (which will also contain a whole bunch of other changes, so for stable releases you will likely just want to backport that patch). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net
Bug#1007022: podman: starting rootless container fails with: can't get final child's PID from pipe: EOF
Just reporting I found the same problem on Fedora 36. Filed here: https://bugzilla.redhat.com/show_bug.cgi?id=2066527 . -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
Bug#930759: mokutil(1) refers to non-existent "--enroll-validation"
On Fri, 2021-07-02 at 21:02 +0200, Julian Andres Klode wrote: > On Thu, Apr 08, 2021 at 02:20:36PM -0700, Adam Williamson wrote: > > Well, upstream has fixed s/enroll/enable/ . But it has not added any > > useful explanation of what this does, nor why it prompts for a password > > It enables validation in shim, as the manual page says - it's the > opposite of disable-validation. > > > and what that password does. > > It's hardly mokutil's job to explain mokmanager's inner workings, > but as I'm surely aware you know, any action needs to be confirmed > at boot by a password - or specific characters thereof (sigh). I didn't actually know that, no. I was completely confused until someone explained this to me on IRC. > > It's a very specific tool to control MokManager that's not really > suitable for end users, but for distro developers building integration > so I think both things are kind of non-issues. However, it is actually necessary for end users in at least one specific case: developer edition Dell laptops (which are quite popular among Linux users). These ship with Secure Boot enabled at the firmware level, but disabled at the MOK level. Running this command is exactly what you have to do to actually enable Secure Boot properly on those laptops. See https://bodhi.fedoraproject.org/updates/FEDORA-2021-cab258a413#comment-1978725 for me being completely confused about that command. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
Bug#930759: mokutil(1) refers to non-existent "--enroll-validation"
Well, upstream has fixed s/enroll/enable/ . But it has not added any useful explanation of what this does, nor why it prompts for a password and what that password does. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net
Bug#975003: mount refuses to mount cifs from fstab with Unknown mount option "symfollow"
I think this has been reported and fixed in util-linux: https://github.com/karelzak/util-linux/issues/1193 Updating Fedora to the util-linux with that fix backported seems to fix the issue for me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
Bug#495269: GPL code linked against OpenSSL in KVirc
Package: kvirc Version: 2:3.4.0-1+b1 As per http://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html , Debian considers it a conflict for GPL code to link against OpenSSL without an exception in the GPL app's license. KVirc is a GPL app, and it is - according to http://packages.debian.org/sid/kvirc - linked against openssl. It's listed as requiring: libssl0.9.8 (>= 0.9.8f-5) KVIrc's license has a special exception covering an issue with Qt/Win32, but no exception for OpenSSL. I suspect the exception for Qt is erroneously causing your lint thingy not to flag up the issue for KVirc. I have mentioned this issue to the KVirc developers and this is their position: if you send to the mailing list a paragraph that should be added to the license and people acknowledge that, I can add it feel no problems about it it's just that I don't really want to read about all this stuff :D I'll gain interest in it only when someone really comes and complains loudly :D I honestly don't really care a lot about this kind of massively theoretical licensing issue, but I know the legal eagles of debian-legal do, and I am taking advantage of this fact to dump all the effort required to sort this out onto you, poor Debian maintainer. You will then do all the work and I can swoop in and claim the benefit in a couple of weeks, having spent the intervening period drinking beer and eating ice cream. You poor schmuck. -- adamw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419597: MP2 patents
There seems to have been at least some discussion in the past about patents that cover MP2 as well as MP3. The most useful discussion is here, relating to MPC (an encoder that originated as an implementation of MP2): http://www.hydrogenaudio.org/forums/index.php?showtopic=10072&st=0&; It contains reference to at least one specific patent that was considered by at least some people to cover MP2, US patent 5,214,678 - go to http://patft.uspto.gov/netahtml/PTO/srchnum.htm and enter that number. The patent is currently owned by Sisvel, whose page is at http://www.audiompeg.com/website/homepage.htm . They only seem to be asserting it in relation to MP3 - "The US patents licensed by Audio MPEG and the Non-US patents licensed by Sisvel S.p.A. relate to digital audio compression and among others are relevant for MP3 players, MPEG 2 compliant set-top boxes and satellite receivers, DVD players with MP3 capabilities, computers, PDAs, sound boards for computers, software for encoding and/or decoding audio signals, and in general any technology conforming to the ISO/IEC 11172-3 or ISO/IEC 13818-3 Standards (MPEG 1 and 2, Layer I, II, and III)." I'm not sure if this means they don't think it applies to MP2, or if they just don't care about MP2. It would be good for someone appropriately qualified to make a determination about whether this patent affects twolame. The same question regarding twolame's patent status recently arose in Mandriva and I thought it'd be best to work together to determine the status. I will mail the twolame maintainers for their opinion. -- adamw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
