When using Fedora's containers, LTO appears to be broken. I'm not sure
who to report this to, the container builder or gcc.
$ podman run --pull=always --rm -it registry.fedoraproject.org/fedora:rawhide
# dnf install -y gcc
# echo 'int main(void) { int class=0; return class; }' > sanitycheck.c
#
On Wed, Sep 9, 2020 at 2:50 PM Petr Pisar wrote:
> I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it
> is to be use with Stream, why don't we call it EPEL 8 Stream? I think the
> meaning of the repository would be easier to understand.
Agreed. Using the "Stream"
https://fedorapeople.org/groups/389ds/ci/nightly/2020/09/17/report-389-ds-base-1.4.4.4-20200916gitf9638bb.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
https://github.com/389ds/389-ds-base/
All developers, and any other interested individuals, should make sure
to "watch" this repo. We moved off of Pagure and onto github, but the
Pagure subscribers were not migrated. So if you want to keep an eye on
what's happening make sure to watch this
At the EPEL Steering Committee last week, we had an extensive discussion of
this proposal, specifically focused on how to handle the dist macro. I
believe these are the possible choices.
* keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using
https://github.com/389ds/389-ds-base/pull/4328
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On Wed, 2020-09-16 at 19:17 -0500, Michael Catanzaro wrote:
> On Wed, Sep 16, 2020 at 10:55 pm, majid hussain
> wrote:
> > hi,
> >
> > i'm no dev but
> >
> > i'm blind would functional include being accessible to orca the
> > screen reader?
> >
> > after all to a blind person like me having
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-09-17 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2020-09-17 09:00 PDT US/Pacific
2020-09-17
Hello All,
We had an issue today as some people were unable to push to dist-git
f31 branches, it was caused by setting a wrong date in pdc. It has
been fixed now and people can push to f31 branches.
More info at https://pagure.io/fedora-infrastructure/issue/9325
Sorry for the trouble that this
Hello All,
We had an issue today as some people were unable to push to dist-git
f31 branches, it was caused by setting a wrong date in pdc. It has
been fixed now and people can push to f31 branches.
More info at https://pagure.io/fedora-infrastructure/issue/9325
Sorry for the trouble that this
No missing expected images.
Failed openQA tests: 1/16 (x86_64)
New failures (same test not failed in Fedora-IoT-33-20200916.0):
ID: 668703 Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/668703
Soft failed openQA tests: 1/16 (x86_64)
Eric Sandeen wrote:
> Block > page size is a different problem vs what is described in this
> thread.
Well, the thread is about block size ≠ page size, of which that is one of
the two cases to handle.
Though of course, if (as is the case for xfs), mkfs does not produce large
block sizes by
On Wed, Sep 16, 2020 at 10:55 pm, majid hussain
wrote:
hi,
i'm no dev but
i'm blind would functional include being accessible to orca the
screen reader?
after all to a blind person like me having an accessible setup
experience is a requirement?
or after I install the system, I would be
Gary Buhrmaster wrote:
> Some people download once, and install once. For
> those, it is pay me now, or pay me later, and it may
> be a wash, time wise, depending on your download
> speeds, but it is also just a one time thing in any
> case. Some people download once, and install lots
> of times
No missing expected images.
Failed openQA tests: 1/16 (x86_64)
New failures (same test not failed in Fedora-IoT-34-20200916.0):
ID: 668687 Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/668687
Soft failed openQA tests: 1/16 (x86_64)
hi,
i'm no dev but
i'm blind would functional include being accessible to orca the screen
reader?
after all to a blind person like me having an accessible setup
experience is a requirement?
or after I install the system, I would be in the dark?
Majid
On 15/09/2020 15:29, Kamil Paral
Hello,
I was doing some binary analysis of files in F33 and have run across something
odd.
readelf -s /usr/sbin/auditd | grep GLIBC
produces a lot of output like:
182: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 (3)
184: 0 FUNCGLOBAL
Welcome!
FWIW I'm probably older and yes - I used to use RCS (and sccs, cvs,
perforce, svn) and I still use ESR's SRC package (which is based on
RCS) on a daily basis:
https://www.emacswiki.org/emacs/VersionControlAlways
FAQ http://www.catb.org/~esr/src/FAQ.html
resources
https://bugzilla.redhat.com/show_bug.cgi?id=1879741
Pedro Sampaio changed:
What|Removed |Added
Blocks||1857388
--
You are receiving this
https://bugzilla.redhat.com/show_bug.cgi?id=1879741
Bug ID: 1879741
Summary: CVE-2014-10402 perl-dbi: Incomplete fix for
CVE-2014-10401
Product: Security Response
Hardware: All
OS: Linux
Status: NEW
https://bugzilla.redhat.com/show_bug.cgi?id=1879713
Latest upstream release: 1.15
Current version/release in rawhide: 1.14-2.fc33
URL: http://search.cpan.org/dist/Astro-FITS-CFITSIO/
Please consult the package updates policy before you issue an update to a
stable branch:
https://bugzilla.redhat.com/show_bug.cgi?id=1879713
Bug ID: 1879713
Summary: perl-Astro-FITS-CFITSIO-1.15 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Astro-FITS-CFITSIO
Keywords:
compat-openssl10 has just been retired. FTBFS bugs have just been filed against:
dmg2img
gnome-vfs2
gq
httperf
libwvstreams
netty-tcnative
samdump2
skipfish
snownews
sslscan
stud
telepathy-salut
ucommon
validns
vtun
They will need to be updated to use modern openssl, or retired. The dependency
On 9/16/20 3:18 PM, Eugene Syromiatnikov wrote:
On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote:
At the time we tied the fs blocksize to the
page size, because it was unlikely that a user would mkfs a fs on one arch
and move it over to another arch.
But one doesn't need "another
On Wed, Sep 16, 2020 at 03:04:45PM -0400, Josef Bacik wrote:
> At the time we tied the fs blocksize to the
> page size, because it was unlikely that a user would mkfs a fs on one arch
> and move it over to another arch.
But one doesn't need "another arch" for page size to change; many
Ok, I'll just do the first layer and let the process work. I'll send an
announcement to devel outside this thread.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure
On 9/14/20 3:31 AM, Daniel Pocock wrote:
Given the plans to make btrfs the default, I'll share some of my own
recent experiences, hopefully this can make it easier for the next person
One issue I've come across is that a btrfs filesystem can only be used
on hosts with the same page size as
https://bugzilla.redhat.com/show_bug.cgi?id=1879600
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #3 from
https://bugzilla.redhat.com/show_bug.cgi?id=1879217
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
On Wed, 2020-09-16 at 18:26 +, Gwyn Ciesla wrote:
> I don't mind doing so. Just for the first layer of dependencies? Does someone
> have the deeper tree handy?
I only have part of it from the gnome-vfs2 side:
$ repoquery --releasever=33 --whatrequires gnome-vfs2
girl-0:10.0.0-10.fc33.x86_64
On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote:
>
> On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote:
> ...snip...
> >
> > When a maintainer is done with their package in playground, they must
> > untag all builds of it out of epel-playground. We do not want
> > epel-playground
On Wed, Sep 16, 2020 at 2:15 PM Daniel P. Berrangé wrote:
>
> On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> > I'm annoyed in general that we still have problems like this, and I'm
> > even more annoyed that I basically have no way to even test or deal
> > with these things. We
I don't mind doing so. Just for the first layer of dependencies? Does someone
have the deeper tree handy?
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
On Wed, 2020-09-16 at 12:41 -0500, Michael Catanzaro wrote:
> On Wed, Sep 16, 2020 at 1:37 pm, Simo Sorce wrote:
> > note that one of the dependencies is gnome-vfs2, itself a dependency
> > for libgnome, which is a dependency for another dozen packages.
> >
> > All of them will likely go away
On Wed, Sep 16, 2020 at 02:09:42PM -0400, Neal Gompa wrote:
> I'm annoyed in general that we still have problems like this, and I'm
> even more annoyed that I basically have no way to even test or deal
> with these things. We *still* do not have packager test machines, so I
> can't even figure out
On Wed, Sep 16, 2020 at 2:05 PM Tom Seewald wrote:
>
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler > wrote:
> >
> > I hate to break it to you, but this problem is not just in
> > filesystems, it's in basically everything in the kernel. And we've had
> > variations of problems like this for
> On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler wrote:
>
> I hate to break it to you, but this problem is not just in
> filesystems, it's in basically everything in the kernel. And we've had
> variations of problems like this for years (endianness, page size,
> pointer size, single bit vs
Due to outstanding unresolved blockers, there is no release candidate
for Fedora 33 Beta yet. I am cancelling tomorrow's Go/No-Go meeting.
Please update the Release Readiness wiki page[1] with your team's
readiness if appropriate.
The Fedora 33 Beta Go/No-Go meeting[3] will be held at 1700 UTC on
Due to outstanding unresolved blockers, there is no release candidate
for Fedora 33 Beta yet. I am cancelling tomorrow's Go/No-Go meeting.
Please update the Release Readiness wiki page[1] with your team's
readiness if appropriate.
The Fedora 33 Beta Go/No-Go meeting[3] will be held at 1700 UTC on
https://bugzilla.redhat.com/show_bug.cgi?id=1879600
--- Comment #1 from Fedora Update System ---
FEDORA-2020-89167ec17c has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-89167ec17c
--
You are receiving this mail because:
You are on the CC list
On Wed, Sep 16, 2020 at 1:37 pm, Simo Sorce wrote:
note that one of the dependencies is gnome-vfs2, itself a dependency
for libgnome, which is a dependency for another dozen packages.
All of them will likely go away because gnome-vfs2 is unlikely to be
changed.
I looked over the dependency
note that one of the dependencies is gnome-vfs2, itself a dependency
for libgnome, which is a dependency for another dozen packages.
All of them will likely go away because gnome-vfs2 is unlikely to be
changed.
Simo.
On Wed, 2020-09-16 at 12:56 -0400, Simo Sorce wrote:
> Do we need a more
https://bugzilla.redhat.com/show_bug.cgi?id=1879600
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=1879600
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
Doc Type|---
Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-16/fesco.2020-09-16-14.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-16/fesco.2020-09-16-14.00.txt
Log:
Do we need a more involved plan than filing bugs for those packages and
let them drop if they do not react ?
I mean they are using very old dependencies, there are probably many
other ways in which they are broken at this point.
Simo.
On Wed, 2020-09-16 at 16:37 +, Gwyn Ciesla via devel
On Wed, 2020-09-16 at 12:12 +, rawh...@fedoraproject.org wrote:
> Announcing the creation of a new nightly release validation test event
> for Fedora 33 Branched 20200916.n.0. Please help run some tests for this
> nightly compose if you have time. For more information on nightly
I'm the compat-openssl10 owner. I've updated kqoauth-qt5 and sipp, but the rest
are more involved. We need a plan for each package to be patched, updated to a
version supporting modern openssl, or retired.
--
Gwyn Ciesla
she/her/hers
in your
On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote:
...snip...
>
> When a maintainer is done with their package in playground, they must
> untag all builds of it out of epel-playground. We do not want
> epel-playground cluttered with old test packages. Done means either
> the package
On Wed, 2020-09-16 at 14:58 +0200, Miro Hrončok wrote:
> On 16. 09. 20 14:29, Simo Sorce wrote:
> > Indeed compat-openssl10 really should go.
> > If there are still packages depending on it they should be ported or
> > dropped at this point.
> > Openssl1.0.2 is unmaintained upstream and only
Hi team,
please, check two PRs about cleaning up after the pagure to github
migration:
https://github.com/389ds/389-ds-base/pull/4321
https://github.com/389ds/389-ds-base/pull/4320
For the second PR, you can check how the README.md will look like here:
On 9/16/20 10:22 AM, Benjamin Block wrote:
> On Wed, Sep 16, 2020 at 09:31:50AM -0500, Eric Sandeen wrote:
...
>> Sub-page block support in filesystems is not a wild, esoteric, unexpected
>> feature.
>>
>
> These kinds of problems are not really that rare across different
> Filesystems.
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1879600
Bug ID: 1879600
Summary: perl-DB_File-1.854 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-DB_File
Keywords: FutureFeature, Triaged
Good Morning Everyone,
Since September 5th, we have been emailing daily the following users to notify
that the email they have set in FAS does not correspond to a valid bugzilla
account.
This is a requirement for Fedora packagers.
Does someone know how to contact these people?
ekulik is main
On Wed, Sep 16, 2020 at 09:31:50AM -0500, Eric Sandeen wrote:
> On 9/15/20 7:29 PM, Neal Gompa wrote:
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler wrote:
> >>
> >> Daniel Pocock wrote:
> >>> One issue I've come across is that a btrfs filesystem can only be used
> >>> on hosts with the same
The following Fedora EPEL 6 Security updates need testing:
Age URL
10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-972f57ea6d
drupal7-7.72-1.el6
7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b425525e83
mbedtls-2.7.17-1.el6
1
On Wed, Sep 16, 2020 at 10:32 AM Eric Sandeen wrote:
>
> On 9/15/20 7:29 PM, Neal Gompa wrote:
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler wrote:
> >>
> >> Daniel Pocock wrote:
> >>> One issue I've come across is that a btrfs filesystem can only be used
> >>> on hosts with the same page
The following Fedora EPEL 7 Security updates need testing:
Age URL
763 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d
condor-8.6.11-1.el7
503 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b
bubblewrap-0.3.3-2.el7
12
On 9/15/20 7:29 PM, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler wrote:
>>
>> Daniel Pocock wrote:
>>> One issue I've come across is that a btrfs filesystem can only be used
>>> on hosts with the same page size as the host that created the filesystem
>>
>> Ewww! That alone
On Thu, Sep 10, 2020 at 6:05 PM Robbie Harwood wrote:
>
> Ondrej Mosnacek writes:
>
> > James Cassell wrote:
> >> Ben Cotton wrote:
> >>
> >>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >>>
> >>> == Summary ==
> >>> Remove support for SELinux runtime
No missing expected images.
Failed openQA tests: 6/170 (x86_64)
New failures (same test not failed in Fedora-33-20200915.n.0):
ID: 668282 Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/668282
ID: 668330 Test: x86_64 universal
Since the new mock-core-configs are in Fedora stable, it allowed us to enable
fedora-eln- [1] buildroots in Fedora Copr. Feel free to try them.
Note that Fedora ELN repositories aren't mirrored at this moment, and thus
we can face some weird repo/package downloading issues (as e.g. discussed
On 16. 09. 20 14:29, Simo Sorce wrote:
Indeed compat-openssl10 really should go.
If there are still packages depending on it they should be ported or
dropped at this point.
Openssl1.0.2 is unmaintained upstream and only critical security fixes
are done in RHEL. But the team that handles them
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-IoT-34-20200913.0):
ID: 668221 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL:
OLD: Fedora-33-20200915.n.0
NEW: Fedora-33-20200916.n.0
= SUMMARY =
Added images:0
Dropped images: 1
Added packages: 0
Dropped packages:1
Upgraded packages: 3
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:56.08 MiB
Size
On Wed, 2020-09-16 at 12:28 +0200, Tomas Mraz wrote:
> On Tue, 2020-09-15 at 19:33 +0200, Miro Hrončok wrote:
> > On 15. 09. 20 19:26, Tomas Mraz wrote:
> > > What is more important? Consistency between those two compat
> > > packages
> > > or strictly following the naming rules for the new
Announcing the creation of a new nightly release validation test event
for Fedora 33 Branched 20200916.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
https://bugzilla.redhat.com/show_bug.cgi?id=1879289
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
No missing expected images.
Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 21/181 (x86_64)
New failures (same test not failed in Fedora-Rawhide-20200915.n.1):
ID:
https://bugzilla.redhat.com/show_bug.cgi?id=1879289
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=1879217
--- Comment #1 from Fedora Update System ---
FEDORA-2020-1360b0ae9a has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1360b0ae9a
--
You are receiving this mail because:
You are on the CC list
No missing expected images.
Passed openQA tests: 7/7 (x86_64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
https://bugzilla.redhat.com/show_bug.cgi?id=1879217
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
On Tue, 2020-09-15 at 19:33 +0200, Miro Hrončok wrote:
> On 15. 09. 20 19:26, Tomas Mraz wrote:
> > What is more important? Consistency between those two compat
> > packages
> > or strictly following the naming rules for the new package?
>
> Why not both? I.e. renaming compat-openssl10 to
OLD: Fedora-Rawhide-20200915.n.1
NEW: Fedora-Rawhide-20200916.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 3
Dropped packages:4
Upgraded packages: 198
Downgraded packages: 0
Size of added packages: 200.41 KiB
Size of dropped packages
Hello,
I'm working on packaging NetPyNE[1] for NeuroFedora next, a tool used
for simulation and analysis of neuroscientific computational models
using the NEURON simulator. It's first dependency is the python-bokeh
web-visualisation library[2]. Would someone like to swap reviews please?
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-32-20200915.0):
ID: 667701 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
- Original Message -
> From: "Andy Mender"
> To: "Development discussions related to Fedora"
>
> Sent: Tuesday, September 15, 2020 10:38:20 PM
> Subject: Re: Giving away two of my package
>
> On Tue, 15 Sep 2020 at 12:04, Charalampos Stratakis < cstra...@redhat.com >
> wrote:
>
>
>
No missing expected images.
Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-IoT-33-20200914.0):
ID: 667624 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL:
Announcing the creation of a new nightly release validation test event
for Fedora-IoT 33 RC 20200916.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1879217
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
On 16. 09. 20 9:55, Peter Robinson wrote:
On Wed, Sep 16, 2020 at 8:11 AM Miro Hrončok wrote:
On 16. 09. 20 2:20, Neal Gompa wrote:
Something that Mageia and openSUSE do sometimes is just not ship a
-devel package if the library is only there for runtime backwards
compatibility. That's
On Wed, Sep 16, 2020 at 8:11 AM Miro Hrončok wrote:
>
> On 16. 09. 20 2:20, Neal Gompa wrote:
> > Something that Mageia and openSUSE do sometimes is just not ship a
> > -devel package if the library is only there for runtime backwards
> > compatibility. That's something we could do for openssl1.0
On 16. 09. 20 2:20, Neal Gompa wrote:
Something that Mageia and openSUSE do sometimes is just not ship a
-devel package if the library is only there for runtime backwards
compatibility. That's something we could do for openssl1.0 and
eventually openssl1.1.
IIRC Tomas attempted to do this twice
Hello,
I'm pleased to announce that there's a new Mock release:
https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.6
This release backported the '--addrepo' option and the automatic SRPM URL
downloading feature from the --chain mode into the --rebuild mode. There
are
85 matches
Mail list logo
