No missing expected images.
Passed openQA tests: 1/1 (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 devel-le...@lists.fedorap
Hi,
Thanks a lot for this change. 00:00 is always confusing to deal with.
Jirka
On Thu, 2020-02-20 at 14:04 -0500, Mohan Boddu wrote:
> Hi all,
>
> It has been brought to our attention that release freezes starting at
> 00:00 UTC has been confusing for a lot of people. So, we decided to
> chang
Hi everybody,
I don't have any use for rubygem-simple-rss, therefore I orphaned it. It
is up2date in Rawhide ATM.
Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Cod
A new 1.0.0 version of the ezstream packages changed a license
from "GPLv2 and BSD and MIT" to "GPLv2 and MIT".
-- Petr
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to dev
as I have no use for it.
If you need it, I've prepared the update, but it needs more work due to Bundler:
https://src.fedoraproject.org/rpms/rubygem-cocoon/pull-request/1
Regards,
--
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
dev
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Failed openQA tests: 2/8 (x86_64)
New failures (same test not failed in Fedora-IoT-33-20200219.0):
ID: 524998 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/524998
ID: 524999 Te
Petr,
thank you for the introduction and for your and your team's work on
Modularity for last several years.
DNF and Modularity are under one roof now. We believe we have sufficient
knowledge to continue the work you have started and that we'll put fresh
energy in the project and hopefully ta
Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200221.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
Is this a known issue?
/var/tmp/rpm-tmp.WMn6E3: line 53: 2113660 Segmentation fault (core
dumped) /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG"
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTA
Hi,
before I write the proposal itself I just want to stress the fact that
it isn’t my intention to change the current packaging workflow and
definitely not the user experience. Also if you have C or Python
packages it would not affect your work at all (I’m not familiar with all
interpreted l
On 2/21/20 9:57 AM, Martin Sehnoutka wrote:
Every time there is a new release it would automatically synchronize our
own Fedora-specific registry, which would in turn be accessible in
buildroot.
One thing that comes to my mind with this proposal is that we still need
some way to vet licenses.
Le vendredi 21 février 2020 à 15:57 +0100, Martin Sehnoutka a écrit :
> Hi,
Hi,
> Go went even further in this case and it is
> common
> to bundle all the dependencies as a source code directly in the
> upstream
> repository. See this repo as an example:
> https://github.com/containers/libpod/
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Failed openQA tests: 2/8 (x86_64)
New failures (same test not failed in Fedora-IoT-32-20200220.0):
ID: 525182 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/525182
ID: 525183 Te
On Fri, 21 Feb 2020 at 09:58, Martin Sehnoutka wrote:
>
> Hi,
>
> before I write the proposal itself I just want to stress the fact that
> it isn’t my intention to change the current packaging workflow and
> definitely not the user experience. Also if you have C or Python
> packages it would not a
On Fri, Feb 21, 2020 at 3:58 PM Martin Sehnoutka wrote:
>
> Hi,
Hi!
I think several of your assumptions are not necessarily correct, which
might lead to wrong conclusions.
My responses are inline below.
> before I write the proposal itself I just want to stress the fact that
> it isn’t my inten
OLD: Fedora-32-20200220.n.0
NEW: Fedora-32-20200221.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 6
Dropped packages:0
Upgraded packages: 57
Downgraded packages: 0
Size of added packages: 2.35 MiB
Size of dropped packages:0 B
Size of
I will soon build a new version of coin-or-Ipopt (3.13.0) in F32+ as
part of fixing several FTBFS problems with coin-or packages during the
mass rebuild. I will rebuild its dependent packages, namely:
coin-or-Bonmin
coin-or-Couenne (also fixing a FTBFS)
coin-or-OS (also fixing a FTBFS)
Also, pol
No missing expected images.
Failed openQA tests: 78/171 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-32-20200220.n.0):
ID: 525006 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/525006
ID: 525008 Test: x86_64 Server-dvd-iso i
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
# CPE Weekly: 2020-02-21
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build
On Fri, 2020-02-21 at 14:09 -0500, Ben Cotton wrote:
>
> 3. python-blivet — https://bugzilla.redhat.com/show_bug.cgi?id=1798792
> — ASSIGNED
> blivet.errors.DeviceTreeError: failed to add slave root00p2 of device root00
>
> Using SCSI, IDE, or SATA software RAID created by the installer in a
> vi
A week later than I intended, here's the start of the weekly Fedora 32
blocker status mails!
Action summary
=
Accepted blockers
-
1. dnf-plugins-extras — Cannot upgrade to Fedora 32: Modules blocking
the upgrade path — NEW
ACTION: dnf team to implement module reset wor
Hello everybody!
As you can read from the subject my name is Jochen Breuer and I'm one of
the lucky people that is being payed for working on open source. I'm a
remote employee of SUSE Germany and I'm working on the SUSE Manager team.
My squad is taking care of Salt for SUSE Manager, Uyuni (the up
On Fri, Feb 21, 2020 at 9:34 AM Jerry James wrote:
> I will soon build a new version of coin-or-Ipopt (3.13.0) in F32+ as
> part of fixing several FTBFS problems with coin-or packages during the
> mass rebuild. I will rebuild its dependent packages, namely:
>
> coin-or-Bonmin
> coin-or-Couenne (a
On Fri, Feb 21, 2020 at 3:48 PM Jochen Breuer wrote:
>
> Hello everybody!
>
> As you can read from the subject my name is Jochen Breuer and I'm one of the
> lucky people that is being payed for working on open source. I'm a remote
> employee of SUSE Germany and I'm working on the SUSE Manager te
Hi everybody,
The update to fluidsynth 2.1.0 from a few days ago bumped the SONAME
of the library as mentioned in $SUBJECT (maintainer in CC).
The following packages depend on that library:
- fluidsynth-dssi (rebuilt)
- gstreamer1-plugins-bad-free, -fluidsynth subpackage (not rebuilt,
maintainer
Ben Cotton wrote:
> 1. dnf-plugins-extras — Cannot upgrade to Fedora 32: Modules blocking
> the upgrade path — NEW
> ACTION: dnf team to implement module reset workaround
>
> 2. PackageKit — Cannot upgrade to Fedora 32: Modules blocking the
> upgrade path — NEW
> ACTION: PackageKit maintainers to
Thanks for the ideas, Fabio and Jan.
On Wed, Feb 19, 2020 at 7:28 AM Jan Grulich wrote:
> can you try to run with QT_DEBUG_PLUGINS=1 and attach here the output? Does
> uninstalling QGnomePlatform package make any difference? Can you be more
> specific about where exactly you are trying to change
Hi,
could a proven maintainer have a look at
https://src.fedoraproject.org/rpms/mpich/pull-request/2?
It causes a FTBFS in espressomd, gromacs and now coin-or-Ipopt on rawhide
(see https://bugzilla.redhat.com/show_bug.cgi?id=1803964 for details)
The above PR is open for a week and I have pinged t
On Friday, February 21, 2020 2:31:14 AM MST jkone...@redhat.com wrote:
> Hi,
>
> Thanks a lot for this change. 00:00 is always confusing to deal with.
>
> Jirka
>
> On Thu, 2020-02-20 at 14:04 -0500, Mohan Boddu wrote:
>
> > Hi all,
> >
> > It has been brought to our attention that release fre
- Original Message -
> From: "Jochen Breuer"
> To: devel@lists.fedoraproject.org
> Sent: Friday, February 21, 2020 9:46:46 PM
> Subject: Self Introduction: Jochen Breuer
> Hello everybody!
> As you can read from the subject my name is Jochen Breuer and I'm one of the
> lucky people that
On Fri, 21 Feb 2020 at 16:49, Fabio Valentini wrote:
>
> Hi everybody,
>
> The update to fluidsynth 2.1.0 from a few days ago bumped the SONAME
> of the library as mentioned in $SUBJECT (maintainer in CC).
>
The email title is somewhat misleading. This was mentioned in this
list a few days back.
Hi all,
While working on getting Fedora Jam a bit more modernized for F33 (the
backgrounds and themes haven't been touched since 2013!), I found that
my predecessor (Brendan Jones) still has fedora-jam-kde-theme and
fedora-jam-backgrounds. I think it's safe to say that since he
abandoned Jam
On Fri, Feb 21, 2020 at 7:28 PM John M. Harris Jr wrote:
>
> On Friday, February 21, 2020 2:31:14 AM MST jkone...@redhat.com wrote:
> > Hi,
> >
> > Thanks a lot for this change. 00:00 is always confusing to deal with.
> >
> > Jirka
> >
> > On Thu, 2020-02-20 at 14:04 -0500, Mohan Boddu wrote:
> >
On Friday, February 21, 2020 9:03:26 PM MST Neal Gompa wrote:
> On Fri, Feb 21, 2020 at 7:28 PM John M. Harris Jr
> wrote:
> >
> >
> > On Friday, February 21, 2020 2:31:14 AM MST jkone...@redhat.com wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > Thanks a lot for this change. 00:00 is always confusi
On 2/21/20 9:32 PM, John M. Harris Jr wrote:
That's simply not true. UTC is midnight UTC. That is not difficult to
grasp. I certainly understand the mappings, which is why this is even more
confusing. Why was 1400 chosen?
Midnight of which day? Maybe it doesn't confuse you, but it confuse
On 22. 02. 20 1:28, John M. Harris Jr wrote:
I really must disagree.
In my opinion, once you simply disagree with literally everything, your feedback
no longer gives any significant meaning for the people who receive it. I know
that it is very frustrating when everybody around you seem not to
On Friday, February 21, 2020 10:52:27 PM MST Miro Hrončok wrote:
> On 22. 02. 20 1:28, John M. Harris Jr wrote:
>
> > I really must disagree.
>
>
> In my opinion, once you simply disagree with literally everything, your
> feedback no longer gives any significant meaning for the people who
> rec
37 matches
Mail list logo
