Fwd: conditional require (RPM dependency solving puzzle)
by przemek klosowski
>>>>>
>>>>> rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
>>>>> kicad-doc < 1:6.0.1-4.fc35
>>>> ...
>>>>
>>>> When I add the '--best --allowerasing' flags, then I get the
>>>> desired result:
>>>>
>>>> # dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
>>>> Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022
>>>> 05:06:19 PM EST.
>>>> Dependencies resolved.
>>>> ============================================================================================
>>>>
>>>> Package Architecture Version Repository
>>>> Size
>>>> ============================================================================================
>>>>
>>>> Upgrading:
>>>> kicad x86_64 1:6.0.1-4.fc35
>>>> @commandline 90 M
>>>> Removing dependent packages:
>>>> kicad-doc noarch 1:5.1.12-1.fc35
>>>> @updates 111 M
Thanks to Steven, Stephen and Miro for finding this solution. Still,
having to add flags and deleting the existing doc package is not
completely gruntling---it works, but it's not automatic and, for the
future, I am curious if there's another way.
Sorry for flogging this fine stallion, but I believe that 'dnf update
kicad kicad-doc' would have worked (I did check that updating kicad-doc
followed by updating kicad works). Isn't there some combination of
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages
instead of deleting kicad-doc?
2 years, 1 month
CVE-2021-4034: why is pkexec still a thing?
by Adam Williamson
Hi folks!
For anyone who hasn't seen it yet - there's quite a kerfuffle today
about a major security issue in polkit:
https://arstechnica.com/information-technology/2022/01/a-bug-lurking-for-...
turns out that ever since it was invented, `pkexec` has had a bug
allowing for local root privilege escalation. Which is...bad.
The issue and some of the comments around it prompted me to wonder -
why is `pkexec` still a thing? Particularly, why is it still a thing we
are shipping by default in just about every Fedora install?
My best recollection is that pkexec was kinda a kludge to allow us to
get rid of consolehelper: some apps weren't getting rewritten to the
Right Way of doing things under policykit, they still just wanted to
have the entire app run as root, and pkexec was a way to make that
happen.
But that was then, and this is now. Does anything in Workstation use
pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
hope!) nothing in Server uses it. I don't think any of our
documentation recommends its use for interactive execution of things as
root (these days we tend to just specify `sudo` for that and assume the
install has an admin user).
Should we just split it out of the polkit package into a subpackage and
stop shipping the subpackage on those editions/spins at least? If
there's anything in other desktops still using it, it can grow a
dependency on the subpackage...
Am I forgetting some other reason we still need it?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years, 1 month
Announcing LLVM Snapshot Packages for Fedora Linux
by Konrad Kleine
Dear Fedora packagers, developers and users,
we have some good news for you:
We are beginning to build nightly snapshot packages of LLVM for the latest
versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list
of
architectures.
You can grab them here:
https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/
Feel free to enable the copr repository with
$ dnf copr enable @fedora-llvm-team/llvm-snapshots
and then install the i.e. latest clang with
$ dnf install clang
Beware, that a snapshot release of LLVM is probably more unstable than a
regular release! If you run into a problem, I would kindly ask you to wait
and try it again with the next snapshot.
We hope you enjoy this peek into the next version of LLVM that you can now
try without too much hassle and without compiling it every day on your own.
Regards,
Konrad Kleine
Senior Software Engineer, Platform Tools
Red Hat <https://www.redhat.com>
kkleine(a)redhat.com
M: +49(0)151/21000244
D87A 77F4 2A58 C72D 12A7 203B C0A0 2C32 BCB7 3099
<https://www.redhat.com>
2 years, 1 month
search among all spec files
by Germano Massullo
Good day. I have to search gcc-toolset among all Fedora packages specs
files, in order to read some example of usage.
Is that possible? For example cloning the whole git repository.
Best regards
2 years, 1 month
Odd annobin output during mock build?
by Richard Shaw
I just did a local mock build of the latest version of OpenImageIO which
was just released and saw this on every cpp line:
annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp:
Warning: -D_GLIBCXX_ASSERTIONS not defined
Is this harmless?
Thanks,
Richard
2 years, 1 month
Retire openCOLLADA?
by Richard Shaw
It seems to fail with gcc 12 due to uninitialized variables. That's easy
enough to work around but the last release was in 2018 and the only
consumer in Fedora in Blender.
Maybe it's time to retire it?
I would hate that as it's actually my first package...
Thanks,
Richard
2 years, 1 month