https://bugzilla.redhat.com/show_bug.cgi?id=1793146
--- Comment #3 from Fedora Update System ---
FEDORA-2020-d2b004c685 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d2b004c685
--
You are receiving this mail because:
You are on the CC list f
https://bugzilla.redhat.com/show_bug.cgi?id=1793146
--- Comment #2 from Fedora Update System ---
FEDORA-2020-ebb35aefc3 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ebb35aefc3
--
You are receiving this mail because:
You are on the CC list f
https://bugzilla.redhat.com/show_bug.cgi?id=1793146
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1793146
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|jples...@redha
On Mon, Jan 20, 2020 at 05:20:08PM +0100, Nils Philippsen wrote:
> On Mon, 2020-01-13 at 10:34 +0100, Petr Pisar wrote:
> > (2) The new values must be larger than all historical values (across
> > all historical Fedora releases). That assures than a new build won't
> > become obsoleted because of a
On Mon, Jan 20, 2020 at 5:58 PM Matthew Garrett wrote:
>
> I've been thinking about ways to solve this for a while, and I'm coming
> to the conclusion that the best plan is probably to just ship pre-built
> initramfs images. I can think of three main reasons to want to use
> system-specific images
On Mon, Jan 20, 2020 at 03:53:51PM +0100, Vít Ondruch wrote:
> Because this is blocking merge of the side tag [1], I am going to build
> them again.
Thanks - if there's still a problem after both tags are merged
then I'll build them again afterwards.
Rich.
--
Richard Jones, Virtualization Group
On Sat, Jan 18, 2020 at 08:53:59PM -0800, Kevin Fenzi wrote:
> On Sat, Jan 18, 2020 at 11:32:30PM +0100, Fabio Valentini wrote:
> ...snip...
> >
> > Sounds interesting!
> > Koji might suffer from the database dump cron job ... though I'm not
> > sure at which time of day it's supposed to run.
>
>
Dear all,
You are kindly invited to the meeting:
Modularity Team (weekly) on 2020-01-21 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting of the Modularity Team.
More information available at: [Modularity Team
Docs](https://docs.pagure.o
Looks like python-userpath exists already, albeit for rawhide only.
I'd like to review pipx (this will be my first review). If you could in
turn review mopidy-mpd, that would be greatly appreciated.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1792086
_
On 1/20/20 7:57 PM, Matthew Garrett wrote:
>
> I've been thinking about ways to solve this for a while, and I'm coming
> to the conclusion that the best plan is probably to just ship pre-built
> initramfs images. I can think of three main reasons to want to use
> system-specific images:
For
On Mon, Jan 20, 2020, at 7:57 PM, Matthew Garrett wrote:
> I've been thinking about ways to solve this for a while, and I'm coming
> to the conclusion that the best plan is probably to just ship pre-built
> initramfs images.
rpm-ostree[1] (used for Fedora CoreOS and Silverblue and IoT among o
Measured boot involves generating cryptographic measurements of boot
components and configuration and using that to either control access to
a local secret (in the case of sealing secrets to a TPM) or proving to
another device (eg, a remote server or a local phone) what was booted.
We're shippi
In keeping with FESCo's approval[1] of a keepalive requirement, the
following Spins and Labs are marked for retirement in Fedora 32 unless
the maintainer replies to the keepalive request or a new maintainer
steps up.
1. Jam Audio[2] (keepalive[3])
2. Scientific[4] (keepalive[5])
[1] https://pagur
On Mon, Jan 20, 2020 at 4:24 AM Adam Williamson
wrote:
>
> On Sun, 2020-01-12 at 15:02 -0700, Chris Murphy wrote:
> > Do you have any tests to compare plain squashfs xz with zstd? The nested
> > ext4 stuff is really pointless now because Fedora hasn't used 'dd' +
> > resizing the ext4 file system
On Fri, 17 Jan 2020 at 04:33, Nicolas Mailhot via devel
wrote:
>
> Le jeudi 16 janvier 2020 à 22:24 -0500, Neal Gompa a écrit :
>
> Hi Neal,
>
> > I've also said that I don't think we can handle it as our
> > infrastructure currently stands. Our build system tooling has
> > suffered from a decade
On Mon, 20 Jan 2020 at 03:59, Panu Matilainen wrote:
>
> On 1/17/20 3:03 PM, Stephen John Smoogen wrote:
> > On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote:
> >>
> >> Once upon a time, Nico Kadel-Garcia said:
> >>> Is there any software or service that currently uses Berkeley DB that
> >>> cann
On Wed, Jan 15, 2020 at 04:28:56PM +0200, Panu Matilainen wrote:
On 1/15/20 3:33 PM, Vít Ondruch wrote:
Dne 15. 01. 20 v 13:33 Panu Matilainen napsal(a):
On 1/15/20 2:13 PM, Miroslav Suchý wrote:
Dne 13. 01. 20 v 14:05 Vít Ondruch napsal(a):
%changelog
%include changelog
+1
As I pointe
On Mon, Jan 13, 2020 at 08:19:36AM -0600, Richard Shaw wrote:
Just catching up on this thread...
How about an incremental step? (I don't know how difficult it would be to
implement however)...
What about separating the change log to a separate file in dist-git?
Something like the traditional "C
https://fedoraproject.org/wiki/Changes/Haskell_Stackage_LTS_14
== Summary ==
Haskell libraries and packages will be updated from Stackage LTS 13 to
the new versions in Stackage LTS 14.
== Owner ==
* Name: [[User:Petersen| Jens Petersen]]
* Email:
* Name: [[Haskell_SIG| Haskell SIG]]
* Email:
=
https://fedoraproject.org/wiki/Changes/Python3-rdiff-backup
== Summary ==
rdiff-backup is a python based backup tool. While development stopped
for many years, it's now resumed upstream and a python3 port has been
(almost) completed. Unfortunately, the python2 and python3 versions
will not interop
Hey Petr!
On Mon, 2020-01-13 at 10:34 +0100, Petr Pisar wrote:
> (2) The new values must be larger than all historical values (across
> all historical Fedora releases). That assures than a new build won't
> become obsoleted because of a decreased release.
can you clarify what you mean with "histo
=
#fedora-meeting-1: FESCO (2020-01-20)
=
Meeting started by dcantrell at 15:00:03 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-01-20/fesco.2020-01-20-15.00.log.html
.
Meetin
Because this is blocking merge of the side tag [1], I am going to build
them again.
Vít
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2020-223644200d
Dne 20. 01. 20 v 11:55 Vít Ondruch napsal(a):
> There happened mid air collision between OCaml rebuilds and Ruby
> rebuilds unfortunately.
* Florian Weimer:
> I'm disabling annobin temporarily so that the GCC 10 transition in the
> buildroot will hopefully be a bit smoother than usual. Packages built
> during the temporary change will hopefully be rebuilt during the mass
> rebuild.
This redhat-rpm-config change is complete and anno
Hi all,
My name is Javier and I am Spaniard. I have been using Linux for more than 15
years (10 at a professional level). I have worked mainly as a System Engineer
and Database (Oracle/MySQL) Engineer for many years in a few IT companies in
Spain and the US.
I am contributing fedora since 2017
https://bugzilla.redhat.com/show_bug.cgi?id=1792997
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On Sun, Jan 19, 2020 at 4:42 PM Bohdan Khomutskyi
wrote:
> Hello,
>
> Thanks everyone for posting feedback.
> More benchmarking results are available at
> https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS,
> including the 'plain' SquashFS filesystem.
> After performing the tests, I
Neal Gompa wrote:
> * building containers, ISOs, disk images
+1 (at least installable live ISOs).
> using kiwi and/or appliance-tools+livecd-tools/lorax
I vote for livecd-creator from livecd-tools, it is the easiest to use
(and in particular, livecd-creator accepts kickstarts from livemedia-cre
Miroslav Suchý wrote:
> * We removed outdated chroots, which allowed us to reclaim terabytes of
> disk space. At the same time, we give you the option to keep those old
> repos if you want them.
> http://frostyx.cz/posts/copr-removing-outdated-chroots
For what it's worth, I never got the promised
On Sun, 2020-01-12 at 15:02 -0700, Chris Murphy wrote:
> Do you have any tests to compare plain squashfs xz with zstd? The nested
> ext4 stuff is really pointless now because Fedora hasn't used 'dd' +
> resizing the ext4 file system as an installation method in a long time
> (going back to Fedora 1
There happened mid air collision between OCaml rebuilds and Ruby
rebuilds unfortunately. At least the following packages were build
against old Ruby and will need rebuild again:
nbdkit
libguestfs
hivex
Will you build them in f32-build-side-17977 side tag? Should I build
them again or will you
I'm disabling annobin temporarily so that the GCC 10 transition in the
buildroot will hopefully be a bit smoother than usual. Packages built
during the temporary change will hopefully be rebuilt during the mass
rebuild.
Thanks,
Florian
___
devel mailing
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If
On 06. 01. 20 23:41, Peter Jones wrote:
On Mon, Jan 06, 2020 at 02:48:22PM -0500, Robbie Harwood wrote:
If you don't have the time to make a new build once every year, you
shouldn't be a packager, full stop.
I think that's a fair point, but not at all the issue here. I
specifically want not
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
Dear maintainers.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching
(2020-02-03).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
The packages in
On 1/17/20 3:03 PM, Stephen John Smoogen wrote:
On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote:
Once upon a time, Nico Kadel-Garcia said:
Is there any software or service that currently uses Berkeley DB that
cannot reasonably be discarded and rebuilt from scratch for new
versions of that so
On Mon, Jan 20, 2020 at 09:37:32AM +0100, Bohdan Khomutskyi wrote:
> Chris,
>
> Thanks for your feedback and comments, it's very valuable to me.
>
> In my previous message, I mentioned that CPU is *underutilized* during
> installation. I haven't investigated further why, but I suspect it's due to
On Sun, Jan 05, 2020 at 10:08:07AM -0700, Chris Murphy wrote:
> In my testing, xz does provide better compression ratios, well suited
> for seldom used images like archives. But it really makes the
> installation experience worse by soaking the CPU, times thousands of
> installations (openQA tests
Chris,
Thanks for your feedback and comments, it's very valuable to me.
In my previous message, I mentioned that CPU is *underutilized* during
installation. I haven't investigated further why, but I suspect it's due to
the inefficiency caused by the usage of the *loop* device and/or
inefficiency
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
42 matches
Mail list logo
