Fedora-Cloud-35-20220131.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220130.0): ID: 1116436 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 31 January (Today)

Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 31th January (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or Matrix. The meeting is a public meeting, and open for everyone to attend. You can join us over: Matrix: https://matrix.to/#/#neuro:fedorapro

Re: Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0

i have installed the missing 32bit package, but then the compilation fails again with this error messages: $ dnf install graphite2-devel(x86-32) In function 'release', inlined from 'release' at ../modules/water/text/String.cpp:159:24, inlined from 'release' at ../modules/juce_core/text/ju

Re: Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0

Why?, your build flags are set for Windows compilation. /usr/bin/make -O -j2 V=1 VERBOSE=1 win32 CC=i686-w64-mingw32-gcc CXX=i686-w64-mingw32-g++ You should be compiling it in mock build. > i have installed the missing 32bit package, but then the compilation fails > again with this > error mess

Fedora-Cloud-34-20220131.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220130.0): ID: 1116574 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

ppc64le build failures in the mass rebuild

Hi, as there are still a number of ppc64le build failures from the mass rebuild, please make the FTBFS bugs block the "PPCTracker" so we know about them. Here is what we know so far - segfaulting ICE with "during RTL pass: final" or not being able to assemble the sources, those should be fixed in

Re: CVE-2021-4034: why is pkexec still a thing?

I vaguely remember we had a move off consolekit at some point: In 2016, I moved "luckybackup" away from "beesu" (which uses consolekit) to "pkexec" (from polkit). We still have "beesu" in Fedora. Should I switch back? ;) Seriously, while it's worthwhile to ponder which approach tu use or avoid

Re: Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0

a wine 32/64 bridge plugin should be built # build wine bridge 32bit - require mingw32 # build wine bridge 64bit - require mingw64 the problem is that I don't know how to build the program with mock build. ___ devel mailing list -- devel@lists.fedorapro

Re: CVE-2021-4034: why is pkexec still a thing?

On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@courier-mta.com) wrote: > Having said all of that: the suid bit itself is irrelevant. It is nothing > more than a convenient scapegoat to blame other bugs on. The same bug that's > exploitable in a suid binary will also be exploitable, exactly the same

Re: CVE-2021-4034: why is pkexec still a thing?

On Fr, 28.01.22 11:26, Adam Williamson (adamw...@fedoraproject.org) wrote: > On Fri, 2022-01-28 at 11:41 +0100, Lennart Poettering wrote: > > > > "pkexec" is a *short* program, it runs very little code with > > privileges actually. That makes it a *ton* better than the humungous > > code monster t

Re: CVE-2021-4034: why is pkexec still a thing?

Lennart Poettering writes: On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@courier-mta.com) wrote: > Having said all of that: the suid bit itself is irrelevant. It is nothing > more than a convenient scapegoat to blame other bugs on. The same bug that's > exploitable in a suid binary will also

Re: CVE-2021-4034: why is pkexec still a thing?

On Mo, 31.01.22 06:28, Sam Varshavchik (mr...@courier-mta.com) wrote: > > I vehemently disagree. The thing with setuid/setgid is that the > > invoked privileged process inherits a lot of implicit state and > > context that people aren't really aware of or fully > > understand. i.e. it's not just e

Re: ppc64le build failures in the mass rebuild

On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote: > Hi, > > as there are still a number of ppc64le build failures from the mass > rebuild, please make the FTBFS bugs block the "PPCTracker" so we know > about them. > > Here is what we know so far > - segfaulting ICE with "during RTL pass: final"

Re: ppc64le build failures in the mass rebuild

On Mon, 31 Jan 2022 12:04:08 + Sérgio Basto wrote: > On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote: > > Hi, > > > > as there are still a number of ppc64le build failures from the mass > > rebuild, please make the FTBFS bugs block the "PPCTracker" so we know > > about them. > > > > Here

Re: CVE-2021-4034: why is pkexec still a thing?

Lennart Poettering writes: On Mo, 31.01.22 06:28, Sam Varshavchik (mr...@courier-mta.com) wrote: > > I vehemently disagree. The thing with setuid/setgid is that the > > invoked privileged process inherits a lot of implicit state and > > context that people aren't really aware of or fully > > un

Re: Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0

> the problem is that I don't know how to build the program with mock build. Try fedpkg mockbuild or mock -r fedora-36-x86_64 /path/to/carla.srpm ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@li

Re: Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0

> Try > > fedpkg mockbuild > > or > > mock -r fedora-36-x86_64 /path/to/carla.srpm Add your user name to the mock group sudo usermod -a -G mock myusername ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel

the meaning of pkgconfig's Libs fields

Hi, various .pc files that we ship contain a lot of stuff in the Libs and Libs.private field don't make much sense to me. I started looking at the documentation, and the documentation is very scarce, and what is there doesn't seem to have been thought out at all. I'm writing my observations and qu

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

Hi, Le 19/01/2022 à 11:53, Jakub Jelinek a écrit : That error means that there is difference in the target attribute or #pragma GCC target between the caller of the always_inline function and the always_inline function which prevents the inlining (and always_inline requires to be inlined). I'd

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

On Mon, 31 Jan 2022 14:53:08 +0100 Remi Collet wrote: > Hi, > > Le 19/01/2022 à 11:53, Jakub Jelinek a écrit : > > That error means that there is difference in the target attribute or > > #pragma > > GCC target between the caller of the always_inline function and the > > always_inline function

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

Tracked as https://bugzilla.redhat.com/show_bug.cgi?id=2048565 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/proje

Re: the meaning of pkgconfig's Libs fields

Dne 31. 01. 22 v 14:09 Zbigniew Jędrzejewski-Szmek napsal(a): Hi, various .pc files that we ship contain a lot of stuff in the Libs and Libs.private field don't make much sense to me. I started looking at the documentation, and the documentation is very scarce, and what is there doesn't seem to

Re: ppc64le build failures in the mass rebuild

On Mon, 2022-01-31 at 13:36 +0100, Dan Horák wrote: > On Mon, 31 Jan 2022 12:04:08 + > Sérgio Basto wrote: > > > On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote: > > > Hi, > > > > > > as there are still a number of ppc64le build failures from the mass > > > rebuild, please make the FTBFS

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

I just saw this today, btrfs+LUKS, Micron MTFDHBA256TDV. May not have been five minutes, but it was a long time, and DNF consumed an entire CPU during that time. On Sat, Jan 29, 2022 at 3:39 PM Chris Murphy wrote: > On Sat, Jan 29, 2022 at 4:12 AM Vitaly Zaitsev via devel > wrote: > > > > On 24

Re: CVE-2021-4034: why is pkexec still a thing?

Dne 27. 01. 22 v 0:18 Adam Williamson napsal(a): BTW, bonus follow-up to this: as part of researching the background of polkit, I noticed that we never actually entirely got done moving off usermode:( There are still over a dozen packages in the distro that require it: Moving off to where? FY

Re: ppc64le build failures in the mass rebuild

My spec for cantera currently has an "excludearch" for ppc64le since the rawhide builds were failing - should I drop this allow for the releng tools to automatically find and rebuild it? Thanks 31 Jan 2022 16:47:07 Sérgio Basto : > On Mon, 2022-01-31 at 13:36 +0100, Dan Horák wrote: >> On Mon,

Re: CVE-2021-4034: why is pkexec still a thing?

On Mo, 31.01.22 07:46, Sam Varshavchik (mr...@courier-mta.com) wrote: > > > Stuff that's "added all the time" won't be used in existing code base, and > > > will be immaterial. None of the stuff from semi-recent history > > > (containers, > > > CPU affinities, etc…) appears to have much effect on

Re: RFE: CMake AutoRequires?

Fabio Valentini wrote: > Sure, but is this doable? CMakeLists.txt files are very complex and > border on a Turing-complete language. Technically, CMake *is* a Turing-complete language – if and only if you use recursive functions. > Does cmake support passing in "-D foo" options and returning a l

Re: CVE-2021-4034: why is pkexec still a thing?

Lennart Poettering wrote: > The IPC message is the *full* vulnerable surface, and that's as minimal as > it can get. And that's great. But that message can actually open a whole new vulnerability, compared to a monolithic program running completely as root. E.g., I have seen several D-Bus-activa

Re: CVE-2021-4034: why is pkexec still a thing?

On 1/31/22 05:36, Lennart Poettering wrote: > On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@courier-mta.com) wrote: > >> Having said all of that: the suid bit itself is irrelevant. It is nothing >> more than a convenient scapegoat to blame other bugs on. The same bug that's >> exploitable in a sui

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Ben Cotton wrote: > The current mingw32 and mingw64 cross-toolchains provided by Fedora > target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio > 15 & Windows 10, the default and recommended runtime is UCRT. See also > [https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

For the record: https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt states: > MSVCRT […] Works out of the box on every Microsoft Windows versions. This is not entirely true. MSVCRT.DLL was introduced in Windows 95 OSR 2. The original Windows 95, with or without the only service pack released

Re: ppc64le build failures in the mass rebuild

On Mon, 2022-01-31 at 15:06 +, Mark E. Fuller wrote: > My spec for cantera currently has an "excludearch" for ppc64le since > the rawhide builds were failing - should I drop this allow for the > releng tools to automatically find and rebuild it? I'm not from releng team , I don't know if relen

Re: the meaning of pkgconfig's Libs fields

Zbigniew Jędrzejewski-Szmek wrote: > 3. We autogenerate a dependency on /usr/bin/pkg-config for -devel. > Logic is reversed here: the -devel package **provides** something > that it consumed by pkg-config. Dependencies are from a consumer to > the providing entity. The idea there is that packages

Orphaning some packages (w3c-markup-validator fallout)

Hello, I recently gave ownership of w3c-markup-validator to Sérgio Basto which reminded me that there are a handful of perl packages that I probably created/took a hand in as part of that. I haven't touched them in as long as w3c-markup-validator so probably should also orphan them as well. Ther

Re: ppc64le build failures in the mass rebuild

On Mon, Jan 31, 2022 at 02:46:09PM +, Sérgio Basto wrote: > On Mon, 2022-01-31 at 13:36 +0100, Dan Horák wrote: > > On Mon, 31 Jan 2022 12:04:08 + > > Sérgio Basto wrote: > > > > > On Mon, 2022-01-31 at 11:12 +0100, Dan Horák wrote: > > > > Hi, > > > > > > > > as there are still a number

Re: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?

On 31/01/2022 15:47, Kevin P. Fleming wrote: DNF consumed an entire CPU during that time. https://bugzilla.redhat.com/show_bug.cgi?id=2048168 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.o

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

On Mon, Jan 31, 2022 at 05:17:29PM +0100, Kevin Kofler via devel wrote: > > But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version > numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the > box, UCRT is not. Is it really a good default to depend on a run

Re: CVE-2021-4034: why is pkexec still a thing?

On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote: > On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@courier-mta.com) wrote: > > Having said all of that: the suid bit itself is irrelevant. It is nothing > > more than a convenient scapegoat to blame other bugs on. The same bug > > th

Re: Intent to orphan gnu-efi

On 25 Jan 2022 13:17, Robbie Harwood wrote: > Hello, we plan to orphan gnu-efi shortly after I finish fixing the > FTBFS. There do not appear to be any consumers: > > # dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel} > --source > Last metadata expiration check: 0:05:32 ago

Re: the meaning of pkgconfig's Libs fields

Zbigniew Jędrzejewski-Szmek writes: > 1. pc(5) talks about "package", as if one would want to link to a >whole "package" instead one of the specific library files provided >by a package. Thankfully most .pc files only list one "-l" in Libs. >(Counterexamples: tbbmalloc_proxy.pc says '

Re: CVE-2021-4034: why is pkexec still a thing?

po 31. 1. 2022 v 13:49 odesílatel Sam Varshavchik napsal: > And in both cases, the issue is the nature of the actual bug in the > exploitable program, and not anything else. Suid is just a scapegoat. I mean, this exact vulnerability is a counterexample. The input to pkexec is approximately (inv

Re: CVE-2021-4034: why is pkexec still a thing?

Hello, po 31. 1. 2022 v 18:13 odesílatel Steve Grubb napsal: > On Monday, January 31, 2022 5:36:24 AM EST Lennart Poettering wrote: > > On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@courier-mta.com) wrote: > > > > I vehemently disagree. The thing with setuid/setgid is that the > > invoked privile

Re: Intent to orphan gnu-efi

Al Stone writes: > I may be interested in picking this up. I've been doing some UEFI > dev work on Fedora. Let me take a look at the package and let you > know in a day or two or three. Anything I should watch out for if > I do decide to pick this up? Thanks for your interest! However, the p

Re: gcc-12.0.0-0.4.fc36 in rawhide

So, going over FTBFS bugs I've seen against bunch of my packages since the mass rebuild, there is bunch of "undefined reference to `std::type_info::operator==(std::type_info const&) const'" returned by ld, affecting only armv7hl arch. The affected packages are: mozjs68, mozjs78, mozjs91. I've tried

Re: the meaning of pkgconfig's Libs fields

On Mon, Jan 31, 2022 at 05:20:39PM +0100, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > 3. We autogenerate a dependency on /usr/bin/pkg-config for -devel. > > Logic is reversed here: the -devel package **provides** something > > that it consumed by pkg-config. Dependencies

Re: the meaning of pkgconfig's Libs fields

On Mon, Jan 31, 2022 at 03:39:20PM +0100, Vít Ondruch wrote: > > Dne 31. 01. 22 v 14:09 Zbigniew Jędrzejewski-Szmek napsal(a): > >Hi, > > > >various .pc files that we ship contain a lot of stuff in the Libs and > >Libs.private field don't make much sense to me. I started looking at > >the document

Re: Intent to orphan gnu-efi

On 31 Jan 2022 13:20, Robbie Harwood wrote: > Al Stone writes: > > > I may be interested in picking this up. I've been doing some UEFI > > dev work on Fedora. Let me take a look at the package and let you > > know in a day or two or three. Anything I should watch out for if > > I do decide to

Re: CVE-2021-4034: why is pkexec still a thing?

On Mon, 2022-01-31 at 10:19 +, Michael J Gruber wrote: > I vaguely remember we had a move off consolekit at some point: In 2016, I > moved "luckybackup" away from "beesu" (which uses consolekit) to "pkexec" > (from polkit). > > We still have "beesu" in Fedora. Should I switch back? ;) No. T

Re: CVE-2021-4034: why is pkexec still a thing?

On Mon, 2022-01-31 at 16:00 +0100, Miroslav Suchý wrote: > Dne 27. 01. 22 v 0:18 Adam Williamson napsal(a): > > BTW, bonus follow-up to this: as part of researching the background of > > polkit, I noticed that we never actually entirely got done moving off > > usermode:( There are still over a doz

Re: the meaning of pkgconfig's Libs fields

Zbigniew Jędrzejewski-Szmek wrote: > Well, that is the reverse of how we do things in general. If I want to > look for libraries using pkg-config, I install pkg-config. If I want > to look for libraries using 'gcc test.c -lfoo', then I install gcc. > > What we have now is like saying that .h files

Re: the meaning of pkgconfig's Libs fields

Robbie Harwood wrote: > k5crypto and com_err are internal libraries used across the different > interfaces krb5 provides - they're not intended for external > consumption, and upstream doesn't support their direct use by other > applications. Then they belong in Libs.private, not Libs. > So you'r

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

Tomasz Torcz wrote: >On Mon, Jan 31, 2022 at 05:17:29PM +0100, Kevin Kofler via devel wrote: >> >> But yes, for Windows releases ≥ 95 OSR 2 and < 10 (and no, Windows version >> numbers are not anywhere near monotonic ;-) ), MSVCRT is included out of the >> box, UCRT is not. Is it really a good

How to handle a few files moving from one package to another?

When updating from KiCad 5 to KiCad 6, a few files have moved from the kicad-doc package to the main kicad package. If someone has KiCad 5 and its documentation package installed, and then tries to just upgrade the main package to KiCad 6 (without also updating the docs), they get an error mes

conditional require

During recent major version update, some files were moved from -doc to , and as a result updates of fail due to a file conflict. Manual update of -doc resolves this, of course. A simple solution would be to declare that Required: package-doc >= 6.0.0 but that would force the install of the

Re: conditional require

You just asked the same question that I did. :-) I think the Obsoletes line is correct. Once I get a ruling on that from the experts, I'll add it to the package. Steve On 1/31/22 03:58 PM, przemek klosowski via devel wrote: During recent major version update, some files were moved fr

Re: conditional require

On 31. 01. 22 21:58, przemek klosowski via devel wrote: During recent major version update, some files were moved from -doc to , and as a result updates of fail due to a file conflict. Manual update of -doc resolves this, of course. A simple solution would be to declare that Required: packa

Re: conditional require

In similar situations I've used something like Conflicts: package-doc < 6.0.0 On Mon, 2022-01-31 at 16:01 -0500, Steven A. Falco wrote: > You just asked the same question that I did. :-) > > I think the Obsoletes line is correct. Once I get a ruling on that > from the experts, I'll add it to th

Re: conditional require

Thanks all! I'll use the Conflicts approach. Steve On 1/31/22 04:06 PM, Ken Gaillot wrote: In similar situations I've used something like Conflicts: package-doc < 6.0.0 On Mon, 2022-01-31 at 16:01 -0500, Steven A. Falco wrote: You just asked the same question that I did. :-) I thin

Re: the meaning of pkgconfig's Libs fields

* Robbie Harwood: > Zbigniew Jędrzejewski-Szmek writes: > >> 1. pc(5) talks about "package", as if one would want to link to a >>whole "package" instead one of the specific library files provided >>by a package. Thankfully most .pc files only list one "-l" in Libs. >>(Counterexamples:

Re: How to handle a few files moving from one package to another?

On Mon, Jan 31, 2022 at 3:45 PM Steven A. Falco wrote: > > When updating from KiCad 5 to KiCad 6, a few files have moved from the > kicad-doc package to the main kicad package. > > If someone has KiCad 5 and its documentation package installed, and then > tries to just upgrade the main package t

Re: How to handle a few files moving from one package to another?

On 1/31/22 04:44 PM, Stephen Gallagher wrote: On Mon, Jan 31, 2022 at 3:45 PM Steven A. Falco wrote: When updating from KiCad 5 to KiCad 6, a few files have moved from the kicad-doc package to the main kicad package. If someone has KiCad 5 and its documentation package installed, and then tr

Re: conditional require

On 1/31/22 04:04 PM, Miro Hrončok wrote: On 31. 01. 22 21:58, przemek klosowski via devel wrote: During recent major version update, some files were moved from -doc to , and as a result updates of fail due to a file conflict. Manual update of -doc resolves this, of course. A simple solution

Weirdness with clang and stdatomic.h on Rawhide

Hey all, I’m troubleshooting an issue and came up with this sample program: https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, on Rawhide, won’t compile that program, while on Fedora 35 it does. The reason why is that on Rawhide, stdatomic.h exists under /usr/include

Re: conditional require

On 1/31/22 05:08 PM, Steven A. Falco wrote: On 1/31/22 04:04 PM, Miro Hrončok wrote: On 31. 01. 22 21:58, przemek klosowski via devel wrote: During recent major version update, some files were moved from -doc to , and as a result updates of fail due to a file conflict. Manual update of -doc

Re: CVE-2021-4034: why is pkexec still a thing?

Demi Marie Obenour writes: What would break if sudo was replaced by an IPC service that ran sudo as if it was setuid root, without it actually being setuid root? I imagine the hardest part would be TTY handling, as not being able to Ctrl-C a command launched by sudo is a rather poor user experie

Re: conditional require

On 31. 01. 22 23:51, Steven A. Falco wrote: On 1/31/22 05:08 PM, Steven A. Falco wrote: On 1/31/22 04:04 PM, Miro Hrončok wrote: On 31. 01. 22 21:58, przemek klosowski via devel wrote: During recent major version update, some files were moved from -doc to , and as a result updates of fail due

Re: CVE-2021-4034: why is pkexec still a thing?

Lennart Poettering writes: See the discussion around seccomp and NNP. i.e. a new kernel facility was added precisely to ensure that seccomp cannot be used to run code that is intended to be run privileged – under security policies in control by an unprivileged user. i.e. if you can take certain

Re: gcc-12.0.0-0.4.fc36 in rawhide

> * Jakub Jelinek: > > > I think Kevin has posted a GDB patch for the crash: > > [PATCH] Fix GDB internal error by using text (instead of data) section > offset > > > The bug was exposed by the loss of the .data sectio

search among all spec files

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 ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: search among all spec files

On Tue, Feb 01, 2022 at 01:03:22AM +0100, Germano Massullo wrote: > 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. Well, each package is it's own git repo, the

Re: search among all spec files

On 01. 02. 22 1:03, Germano Massullo wrote: 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. This tarball contains all Rawhide spec files, updated I believe dail

Re: search among all spec files

Check https://src.fedoraproject.org/lookaside/, specifically https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz. This covers Rawhide only, of course. On Mon, Jan 31, 2022, at 7:03 PM, Germano Massullo wrote: > Good day. I have to search gcc-toolset among all Fedora packages specs >

Schedule for Tuesday's FESCo Meeting (2022-02-01)

Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 18:00UTC in #fedora-meeting on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2022-02-01 18:00 UTC' Links to all issues to be d

Re: CVE-2021-4034: why is pkexec still a thing?

Hello Mirek, This is the most constructive reply I've seen in this thread. On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote: > > But doesn't satisfy our security requirements. If the kernel dbus project > > had been successful, then Linux would have had a rock solid basis to > > al

Re: search among all spec files

On Tue, 2022-02-01 at 01:03 +0100, Germano Massullo wrote: > 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. > also you got sourcegraph https://sourcegraph.c

Re: CVE-2021-4034: why is pkexec still a thing?

On Mon, Jan 31, 2022 at 5:24 PM Steve Grubb wrote: > > Hello Mirek, > > This is the most constructive reply I've seen in this thread. > > On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote: > > > But doesn't satisfy our security requirements. If the kernel dbus project > > > had been

Re: CVE-2021-4034: why is pkexec still a thing?

On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb wrote: > > Hello Mirek, > > This is the most constructive reply I've seen in this thread. > > On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote: > > > But doesn't satisfy our security requirements. If the kernel dbus project > > > had been

Re: CVE-2021-4034: why is pkexec still a thing?

On 1/31/22 21:15, Neal Gompa wrote: > On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb wrote: >> >> Hello Mirek, >> >> This is the most constructive reply I've seen in this thread. >> >> On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote: But doesn't satisfy our security requirements.

Re: CVE-2021-4034: why is pkexec still a thing?

Dne 31. 01. 22 v 20:39 Adam Williamson napsal(a): but very soon I discovered that documentation of PolicyKit is nearly non-existent. At least, it is not sufficient to do the migration. After reading the code I found that it is likely missing functionality of consolehelper. I had a discussion w