Hi,
in order to prevent backward compatibility libsepol and libsemanage used had few
symbols defined twice and used symbol versioning for them. But when LTO was
enabled these symbols were completely dropped during compilation, see
https://github.com/SELinuxProject/selinux/issues/245
In order to f
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-32-20201103.0):
ID: 714969 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
On 10/26/20 5:20 PM, Ben Cotton wrote:
**Check software that requires or depends on 'mariadb' or 'galera' package for
incompatibilities
This shouldn't be an issue in general, as vast majority
of the software requires client library, provided by "mariadb-connector-c"
package, which won't change.
Hi Kevin,
Thanks for the good tip - I've created a pull request:
https://src.fedoraproject.org/rpms/gr-iio/pull-request/1
Cheers,
Isaac
‐‐‐ Original Message ‐‐‐
On Tuesday, 3. November 2020 17:38, Kevin Fenzi wrote:
> On Mon, Nov 02, 2020 at 10:19:32PM +, Isaac True wrote:
>
> >
On Tue, Nov 03, 2020 at 05:47:28PM +0100, Dominique Martinet wrote:
> Marek Marczykowski-Górecki wrote on Tue, Nov 03, 2020:
> > Do you know if some parts of the above already exist? I know Debian has
> > automatic checks for latest upstream versions, but I haven't seen it in
> > Fedora.
>
> Fedor
On Tuesday, 03 November 2020 at 17:36, Marek Marczykowski-Górecki wrote:
[...]
> But by looking at few random items there, it seems the fix is
> available in a subsequent upstream release and what is missing is just
> bumping the package version in Fedora.
"Just bumping" may not always be trivial,
On Wed, Nov 4, 2020 at 8:48 AM Petr Lautrbach wrote:
> As none of packages which require either libsepol or libsemanage use dropped
> symbols and in order not to break build root during soname bumps I've added
> temporary
> subpackages with original library versions - libsepol-compat with
> lib
On 11/4/20 3:41 PM, Gary Buhrmaster wrote:
On Wed, Nov 4, 2020 at 8:48 AM Petr Lautrbach wrote:
As none of packages which require either libsepol or libsemanage use dropped
symbols and in order not to break build root during soname bumps I've added
temporary
subpackages with original library
Thank you Orion!
This was the decisive bit of missing information.
The bookkeeping issue is now gone, but it did mean that I had to add a
fair bit of reworking for my original package to get all the paths
relinked properly. One of my mpi-dependent libraries seems to be
getting installed OK,
On Tue, Nov 3, 2020 at 11:39 AM Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> wrote:
> On Tue, Nov 03, 2020 at 10:02:24AM +, P J P wrote:
> > * Right, Fedora package CVEs and relevant bugs are filed by Red Hat
> Product security team.
> >
> > * CVEs/bugs are fixed in the upstre
I dont think creating 5 bugs per CVE is a correct statement here. We create one
bug per product per CVE.
So if fedora is affected with a node.js, we create one fedora tracker per CVE.
The tracker should block the CVE bug, so it should be easy to find. Also you
can search for bugs with SecurityT
On Wed, Nov 04, 2020 at 03:48:28PM +0100, Miro Hrončok wrote:
> On 11/4/20 3:41 PM, Gary Buhrmaster wrote:
> > On Wed, Nov 4, 2020 at 8:48 AM Petr Lautrbach wrote:
> >
> > > As none of packages which require either libsepol or libsemanage use
> > > dropped
> > > symbols and in order not to break
Does anyone know when this is likely to be available in COPR build roots?
My R package is still failing with a segfault (I resubmitted just now, all
excited, but it looks like it's still using 2.35.1-11 ...).
On Tue, 3 Nov 2020 at 17:17, Miro Hrončok wrote:
> On 11/3/20 6:08 PM, Jeff Law wrote:
On Wed, Nov 4, 2020 at 9:10 AM Huzaifa Sidhpurwala wrote:
>
> I dont think creating 5 bugs per CVE is a correct statement here. We create
> one bug per product per CVE.
>
> So if fedora is affected with a node.js, we create one fedora tracker per
> CVE. The tracker should block the CVE bug, so i
Stephen Gallagher wrote:
> Generally, whenever Node.js issues a security release, they do so for
> multiple issues simultaneously. When Product Security then goes and creates
> Bugzilla tickets, they create many (sometimes up to five bugs per CVE). It
> becomes nearly impossible to keep up with the
Hello,
my name is Davide Caratti, I'm a networking developer working for Red
Hat; I've been playing sometimes with Fedora, mostly as a contributor
for the 'wpa_supplicant'[1] package. I'm also doing some contribution
for the Linux kernel, mostly in the networking area.
Currently, I'm involved in
Il 02/11/20 23:19, Isaac True ha scritto:
> Hello all,
>
> I'm hoping to become the maintainer of an orphaned package (gr-iio,
> GNU Radio blocks for Analog Devices platforms) but I need some
> sponsorship to become a package maintainer. The releng team
> recommended that I send a message on thi
On Wed, 4 Nov 2020 at 18:10, Davide Caratti wrote:
>
> Hello,
>
> my name is Davide Caratti, I'm a networking developer working for Red
> Hat; I've been playing sometimes with Fedora, mostly as a contributor
> for the 'wpa_supplicant'[1] package. I'm also doing some contribution
> for the Linux ke
Announcing the creation of a new nightly release validation test event
for Fedora 34 Rawhide 20201103.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test
https://fedoraproject.org/wiki/Changes/Stratis_2.2.0
Stratis 2.2.0 now places Stratis filesystem symlinks in /dev/stratis,
rather than /stratis. Stratis creates and maintains the symlinks by
means of udev rules, rather than directly via stratisd as previously.
The /stratis directory is neither cre
https://fedoraproject.org/wiki/Changes/ModularGnomeKeyring
== Summary ==
The monolithic daemon provided by GNOME Keyring will be split into
dedicated sub-daemons, so that they can be consistently managed by
systemd.
== Owner ==
* Name: [[User:ueno|Daiki Ueno]]
* Email: du...@redhat.com
* Name: [[
https://fedoraproject.org/wiki/Changes/RemoveNSCD
== Summary ==
This proposal intends to replace the ''nscd'' cache for named services
with ''systemd-resolved'' for the `hosts` database and the ''sssd''
daemon for everything else.
== Owner ==
* Name: [[User:submachine| Arjun Shankar]]
* Email: ar
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
= Phase 1: Analysis =
For this change, we wi
On Wed, Nov 4, 2020 at 1:12 pm, Ben Cotton wrote:
Despite its original goal to be the central cryptographic service on
desktop, the scope of GNOME Keyring has been gradually reduced over
years. Notable examples are
[https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
in 2015, [h
Is the expectation to explicitly BR: make?
Or would pulling in autotools/automake/cmake suffice?
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of C
Hello,
My name is Patrick with Fedora pseudo: patux.
I am a Fedora Ambassador since 2015 and an enthusiast for Fedora and Red Hat
GNU/Linux for 22 years.
Now I would like to contribute as a packager, too. I’m not a developer. My
backgrounds are system, infrastructure and databases administra
On 04/11/2020 18:12, Ben Cotton wrote:
= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the bu
On 04/11/2020 19:06, Tom Hughes via devel wrote:
On 04/11/2020 18:12, Ben Cotton wrote:
= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding al
On 04/11/2020 20:01, Patrick Vavrina wrote:
> Hello,
>
> My name is Patrick with Fedora pseudo: patux.
>
> I am a Fedora Ambassador since 2015 and an enthusiast for Fedora and Red Hat
> GNU/Linux for 22 years.
>
> Now I would like to contribute as a packager, too. I’m not a developer. My
>
On Wed, Nov 4, 2020 at 7:52 PM Richard Shaw wrote:
>
> Is the expectation to explicitly BR: make?
>
> Or would pulling in autotools/automake/cmake suffice?
My general approach is that if I call it, or call things in my package
that directly call it, I buildrequire it.
If you do that, you don't h
On Wed, Nov 4, 2020 at 7:16 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
>
> == Summary ==
> This change will remove make from the default buildroot in Koji and mock.
Huge +1 here, by the way.
P
___
devel m
On Wed, Nov 4, 2020 at 2:10 PM Tom Hughes via devel
wrote:
>
> On 04/11/2020 19:06, Tom Hughes via devel wrote:
> > On 04/11/2020 18:12, Ben Cotton wrote:
> >
> >> = Phase 1: Analysis =
> >> For this change, we will start by creating a list of all packages that
> >> have a build-time depen
On Wed, Nov 4, 2020 at 6:50 PM Richard Shaw wrote:
>
> Is the expectation to explicitly BR: make?
>
> Or would pulling in autotools/automake/cmake suffice?
The cmake package currently requires make. I do
not believe the auto packages requires make,
so you would need to add make explicitly there.
On 04/11/2020 19:14, Neal Gompa wrote:
When did this happen? CMake should not be requiring Make at runtime,
especially now that the CMake macros let you trivially use either Make
or Ninja.
No idea, but "rpm -q --requires cmake" says it does.
And I only sue %cmake macros which is turn invoke c
On Wed, Nov 4, 2020 at 7:15 PM Neal Gompa wrote:
> When did this happen? CMake should not be requiring Make at runtime,
> especially now that the CMake macros let you trivially use either Make
> or Ninja.
rhbz#1862014
___
devel mailing list -- devel@li
On Wed, Nov 4, 2020 at 2:20 PM Gary Buhrmaster
wrote:
>
> On Wed, Nov 4, 2020 at 7:15 PM Neal Gompa wrote:
>
> > When did this happen? CMake should not be requiring Make at runtime,
> > especially now that the CMake macros let you trivially use either Make
> > or Ninja.
>
> rhbz#1862014
That sho
On 11/4/20 1:50 PM, Richard Shaw wrote:
Is the expectation to explicitly BR: make?
Yes, this is the expectation. I think this is the safest way to handle
this.
-Tom
Or would pulling in autotools/automake/cmake suffice?
Thanks,
Richard
___
dev
On 11/4/20 2:10 PM, Tom Hughes via devel wrote:
On 04/11/2020 19:06, Tom Hughes via devel wrote:
On 04/11/2020 18:12, Ben Cotton wrote:
= Phase 1: Analysis =
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done
From: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
"The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make."
Seems like using a canon to swat flies. It seems to widely distribute
pain without clearly
On 04/11/2020 19:46, Tom Stellard wrote:
On 11/4/20 2:10 PM, Tom Hughes via devel wrote:
Also I'm suspicious about the quality of that list because it
includes packages of mine that only use make via cmake and which
do BR cmake which in turn requires make.
For the purposes of this proposal, y
On 11/4/20 3:22 PM, Tom Hughes wrote:
On 04/11/2020 19:46, Tom Stellard wrote:
On 11/4/20 2:10 PM, Tom Hughes via devel wrote:
Also I'm suspicious about the quality of that list because it
includes packages of mine that only use make via cmake and which
do BR cmake which in turn requires make.
On 04/11/2020 20:31, Tom Stellard wrote:
On 11/4/20 3:22 PM, Tom Hughes wrote:
On 04/11/2020 19:46, Tom Stellard wrote:
On 11/4/20 2:10 PM, Tom Hughes via devel wrote:
Also I'm suspicious about the quality of that list because it
includes packages of mine that only use make via cmake and whic
On 11/4/20 3:34 PM, Tom Hughes wrote:
On 04/11/2020 20:31, Tom Stellard wrote:
On 11/4/20 3:22 PM, Tom Hughes wrote:
On 04/11/2020 19:46, Tom Stellard wrote:
On 11/4/20 2:10 PM, Tom Hughes via devel wrote:
Also I'm suspicious about the quality of that list because it
includes packages of min
On Wed, Nov 4, 2020 at 3:43 PM Tom Stellard wrote:
>
> On 11/4/20 3:34 PM, Tom Hughes wrote:
> > On 04/11/2020 20:31, Tom Stellard wrote:
> >> On 11/4/20 3:22 PM, Tom Hughes wrote:
> >>> On 04/11/2020 19:46, Tom Stellard wrote:
> On 11/4/20 2:10 PM, Tom Hughes via devel wrote:
>
> >
On Wed, Nov 04, 2020 at 12:43:13PM -0800, Tom Stellard wrote:
> > > No, in that case gcc needs to Require: gas, because it is a run-time
> > > dependency of that package.
> > >
> > > CMake will still work if make is not installed. Packages that use
> > > cmake + Ninja should require those packag
On Wed, Nov 4, 2020 at 3:47 PM Jakub Jelinek wrote:
>
> On Wed, Nov 04, 2020 at 12:43:13PM -0800, Tom Stellard wrote:
> > > > No, in that case gcc needs to Require: gas, because it is a run-time
> > > > dependency of that package.
> > > >
> > > > CMake will still work if make is not installed. P
On Wed, Nov 04, 2020 at 03:51:40PM -0500, Neal Gompa wrote:
> > Well, gcc really should have either weak or strong dependency on make too
> > given that -flto is now used everywhere.
>
> The goal of this change seems to include removal of Make as a
> dependency for the LTO wrapper used by GCC.
Th
On 11/4/20 3:57 PM, Jakub Jelinek wrote:
On Wed, Nov 04, 2020 at 03:51:40PM -0500, Neal Gompa wrote:
Well, gcc really should have either weak or strong dependency on make too
given that -flto is now used everywhere.
The goal of this change seems to include removal of Make as a
dependency for t
Missing expected images:
Xfce raw-xz armhfp
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 10/181 (x86_64), 16/117 (aarch64)
New failures (same test not failed in Fedora-Rawhide-20201102.n.0):
ID: 715447 Test: x86_64 Workstation-live-iso deskt
On Wed, Nov 04, 2020 at 01:06:03PM -0800, Tom Stellard wrote:
> On 11/4/20 3:57 PM, Jakub Jelinek wrote:
> > On Wed, Nov 04, 2020 at 03:51:40PM -0500, Neal Gompa wrote:
> > > > Well, gcc really should have either weak or strong dependency on make
> > > > too
> > > > given that -flto is now used ev
On 11/4/20 2:06 PM, Tom Stellard wrote:
> On 11/4/20 3:57 PM, Jakub Jelinek wrote:
>> On Wed, Nov 04, 2020 at 03:51:40PM -0500, Neal Gompa wrote:
Well, gcc really should have either weak or strong dependency on
make too
given that -flto is now used everywhere.
>>>
>>> The goal of th
On Wed, Oct 28, 2020 at 3:15 PM Neal Gompa wrote:
>
(snip)
>
> I think we're looking at having a pkgdb3 web service if we move
> forward with GitLab, simply because there's no way to actually
> *implement* everything we need in GitLab itself.
So ... to me, this does not sound like a good trade-
On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton wrote:
(snip)
> == Contingency Plan ==
>
> Modules will provide the functional version of MariaDB 10.4, available to all
> users.
>
> * Contingency mechanism: Fedora Modules for 10.4 available
> * Contingency deadline: already in place
> * Blocks relea
On 11/4/20 7:12 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
I fully support this.
Next one: info ;)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
__
On Wed, Nov 4, 2020 at 1:15 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
>
> == Summary ==
> This change will remove make from the default buildroot in Koji and mock.
> == Feedback ==
> * Removing make from the Buildroot without rebuilding the package
On 11/4/20 10:13 PM, Nico Kadel-Garcia wrote:
On Wed, Nov 4, 2020 at 1:15 PM Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Feedback ==
* Removing make from the B
Michael Catanzaro writes:
> On Wed, Nov 4, 2020 at 1:12 pm, Ben Cotton wrote:
>> Despite its original goal to be the central cryptographic service on
>> desktop, the scope of GNOME Keyring has been gradually reduced over
>> years. Notable examples are
>> [https://bugzilla.gnome.org/show_bug.cgi?
As part of the XorgUtilityDeaggregation [1], I'm planning to retire these
three. They're currently part of xorg-x11-xkb-utils-extras, a subpackage of
xorg-x11-xkb-utils (which provides setxkbmap and xkbcomp).
setxkbmap and xkbcomp will be split into their own packages and both will
Obsolete: xorg-
Il 05/11/20 00:05, Fabio Valentini ha scritto:
>
> Honestly, I'm very worried that just after finally getting back ~all
> the features that were "lost" when shutting down pkgdb2 and migrating
> to pagure+dist-git, we'll have a major setback *again* when moving to
> GitLab, with no clear plan whethe
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-33-20201104.0):
ID: 715998 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
On Wed, Nov 04, 2020 at 07:15:47PM +, Gary Buhrmaster wrote:
> On Wed, Nov 4, 2020 at 6:50 PM Richard Shaw wrote:
> >
> > Is the expectation to explicitly BR: make?
> >
> > Or would pulling in autotools/automake/cmake suffice?
>
> The cmake package currently requires make.
That's because cma
61 matches
Mail list logo
