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
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://bugzilla.redhat.com/show_bug.cgi?id=1643855
Petr Pisar changed:
What|Removed |Added
Status|ON_QA |CLOSED
CC|
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
https://bugzilla.redhat.com/show_bug.cgi?id=1522685
Petr Pisar changed:
What|Removed |Added
Status|NEW |CLOSED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1894364
Bug ID: 1894364
Summary: perl-CPANPLUS-Dist-Fedora-0.4.2 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-CPANPLUS-Dist-Fedora
Keywords:
https://bugzilla.redhat.com/show_bug.cgi?id=1889622
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1821881
Jitka Plesnikova changed:
What|Removed |Added
Version|31 |32
--
You are receiving this
https://bugzilla.redhat.com/show_bug.cgi?id=1379554
Jitka Plesnikova changed:
What|Removed |Added
Version|31 |32
--
You are receiving this
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:
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.redhat.com/show_bug.cgi?id=1883530
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #8 from
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
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
The following Fedora EPEL 8 Security updates need testing:
Age URL
10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4f4de3554d
fastd-21-1.el8
7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5f50399d2e
chromium-86.0.4240.111-1.el8
4
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
https://bugzilla.redhat.com/show_bug.cgi?id=1878018
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1875827
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1893759
--- Comment #6 from Fedora Update System ---
FEDORA-2020-bd4e52879a has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1893923
--- Comment #4 from Fedora Update System ---
FEDORA-2020-39d5c8fd1e has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1893759
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #5 from
https://bugzilla.redhat.com/show_bug.cgi?id=1893923
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #3 from
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
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
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
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
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.
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.Â
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
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 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
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
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
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,
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 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
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
___
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
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 --
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
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
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
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
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
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 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
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
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
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
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,
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:
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
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/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
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
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:
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/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
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:
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
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
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
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
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
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 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
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
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
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 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
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
>
https://bugzilla.redhat.com/show_bug.cgi?id=1283764
--- Comment #26 from Harald Reindl ---
i see that on any machine running postfix and mailgrpah a few minutes after
each and every reboot, that's why it's so annyoing when you filter fopr
warning/fail/error over a whole cluster
--
You are
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
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.
>
>
Thanks for the notice. I am rsyncing /pub/epel/8/ to
/pub/archive/epel/8.2.2020-11-04/ for people who need longer compatibility.
On Wed, 4 Nov 2020 at 00:36, Thomas Stephen Lee wrote:
> Hi,
>
> RHEL 8.3 got released.
>
> ---
> Lee
> ___
> epel-devel
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 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
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:
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
81 matches
Mail list logo
