On Mon, Oct 07, 2019 at 04:39:22PM +0200, David Kaufmann wrote:
> Although I have to re-symlink SOURCES everytime I work on a different
> package I can use all of rpmbuild, mock, fedpkg,… from the same source
> folder.
You can also use a wrapper script that can be called in dist-git working
copie
On Tue, Oct 8, 2019 at 12:06 AM Kevin Kofler wrote:
>
> Matthew Miller wrote:
> > A key goal of the modularity project is to allow some of the cases to be
> > better addressed by allowing packagers to think in terms of upstream
> > changes which affect user experience separate from the Fedora rele
On 10/8/19 8:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 07, 2019 at 04:34:28PM -0400, Scott Talbert wrote:
On Mon, 7 Oct 2019, Richard Shaw wrote:
I am in the midst of updating the freecad package in two major ways:
Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving fr
Dne 07. 10. 19 v 16:26 Zbigniew Jędrzejewski-Szmek napsal(a):
> On Mon, Oct 07, 2019 at 03:15:02PM +0100, Ankur Sinha wrote:
>> Out of curiosity, what workflow do existing package maintainers user
>> while packaging new software? Is it `fedpkg` based with a folder for the
>> spec to work in? (I st
On 10/7/19 10:23 PM, Richard Shaw wrote:
I am in the midst of updating the freecad package in two major ways:
Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from
Python 2 to 3)
and
Coin3 -> Coin4 (Which requires several other packages move to Coin4)
I have been working with th
On Mon, Oct 07, 2019 at 04:34:28PM -0400, Scott Talbert wrote:
> On Mon, 7 Oct 2019, Richard Shaw wrote:
>
> >I am in the midst of updating the freecad package in two major ways:
> >Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from Python
> >2 to 3)
> >and
> >Coin3 -> Coin4 (Wh
Chris Murphy wrote:
> How to fix it?
d) Revert the complete BootLoaderSpecByDefault change, including reverting
grubby and the kernel.spec snippets to the F29 versions, and verify that
this fixes the issue.
This would really be the right way to deal with changes causing regressions.
It is unfo
Dear all,
You are kindly invited to the meeting:
Modularity Team (weekly) on 2019-10-08 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
Release criterion
https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Xen_DomU
Bug since Fedora 30 also affects Fedora 31 and has been proposed as a
Fedora 31 blocker bug
https://bugzilla.redhat.com/show_bug.cgi?id=1703700
The gist of this bug is that Bootloaderspec by default broke X
Matthew Miller wrote:
> Without modularity, RPM doesn't offer a good way to choose between
> different versions of the same thing. One can squash version numbers into
> the name, which covers some use cases, but also becomes unwieldy and loses
> the _idea_ that these things are different branches o
- Original Message -
> From: "Matthew Miller"
> To: "Development discussions related to Fedora"
>
> Sent: Monday, October 7, 2019 4:31:18 PM
> Subject: Re: Modularity and the system-upgrade path
>
> On Mon, Oct 07, 2019 at 03:20:21PM -0400, Alexander Scheel wrote:
> > > And where is the
Matthew Miller wrote:
> A key goal of the modularity project is to allow some of the cases to be
> better addressed by allowing packagers to think in terms of upstream
> changes which affect user experience separate from the Fedora release
> cycle. The default stream for a package shouldn't be upda
On Mon, Oct 07, 2019 20:40:07 +0200, Aleksandra Fedorova wrote:
> Hi,
>
>
>
> I think we are talking about different things.
>
> It all depends on which question the doc is trying to answer.
So, there are two different documents with two different target
audiences.
- The first is this:
https:
On Mon, Oct 07, 2019 20:40:07 +0200, Aleksandra Fedorova wrote:
> Hi,
>
> I think we are talking about different things.
>
> It all depends on which question the doc is trying to answer.
>
> You are talking about "How do I contribute a package to Fedora". Then
> I agree, the doc should cover mai
On 07. 10. 19 22:31, Matthew Miller wrote:
- Any size reduction in modular RPMs can be made to urisine RPMs.
Maybe. But what if it reduces functionality? Modularity allows there to be a
reduced version or a full version which can be swapped in.
In reality what we see is the reduced version i
On Mon, Oct 7, 2019 at 1:47 PM Matthew Miller
wrote:
> On Sat, Oct 05, 2019 at 01:34:36PM +0200, Aleksandra Fedorova wrote:
> > Thus I think we should consider alternatives and how we can migrate
> > from a Fedora specific app, to some simple and easy to maintain
> > tooling.
>
> I'm all for it.
On Mon, 7 Oct 2019, Richard Shaw wrote:
I am in the midst of updating the freecad package in two major ways:
Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from Python
2 to 3)
and
Coin3 -> Coin4 (Which requires several other packages move to Coin4)
I have been working with the
On Mon, Oct 07, 2019 at 08:13:17PM +0200, Fabio Valentini wrote:
> To quote you from the other ongoing thread: "The default stream for a
> package shouldn't be updated in disruptive ways in shipped releases"
> If that's the case, then what *is* the benefit of abandoning the
> non-modular version of
On Mon, Oct 07, 2019 at 03:20:21PM -0400, Alexander Scheel wrote:
> > And where is the software for those containers coming from? Some
> > container registry like Docker Hub? One of the main points of
> > Modularity is to provide a trusted source of software to install into
> > containers.
> I neve
I am in the midst of updating the freecad package in two major ways:
Qt4 -> Qt5 (via PySide -> PySide2, which also facilitates moving from
Python 2 to 3)
and
Coin3 -> Coin4 (Which requires several other packages move to Coin4)
I have been working with the Coin2/3, SoQt, & SIMVoleon maintainer Ral
On 04/10/2019 21:31, Miro Hrončok wrote:
On 04. 10. 19 16:57, Stephen Gallagher wrote:
Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.
1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Se
Hi all.
This mail is sent as foreseen by the `Non-responsive maintainer policy`
(https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/).
If you know Dave or how to contact him, please forward this mail.
Open rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=1759
On Mon, Oct 07, 2019 at 02:59:37PM -0400, Stephen Gallagher wrote:
> On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce wrote:
> >
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue wi
On Mon, 2019-10-07 at 14:59 -0400, Stephen Gallagher wrote:
> On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce wrote:
> >
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue with thi
- Original Message -
> From: "Stephen Gallagher"
> To: "Development discussions related to Fedora"
>
> Sent: Monday, October 7, 2019 2:59:37 PM
> Subject: Re: Modularity and the system-upgrade path
>
> On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce wrote:
> >
> > I have to ask,
> > given
On Mon, Oct 7, 2019 at 11:33 AM Jaroslav Mracek wrote:
>
> I would like to open discussions more widely, because we are talking about
> future of software distribution and discussing only particular issue is not
> an approach how to delivery solid and stable architecture.
>
> What issues I have
On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce wrote:
>
> I have to ask,
> given containers are so popular and can deal with any dependency
> without conflicting with system installed binaries, should we really
> continue with this very complicated modular design ?
>
> Shouldn't we go back to have defa
I have to ask,
given containers are so popular and can deal with any dependency
without conflicting with system installed binaries, should we really
continue with this very complicated modular design ?
Shouldn't we go back to have default packages and then defer to
"containers" for applications (a
Hi,
On Mon, Oct 7, 2019 at 7:53 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Oct 07, 2019 at 05:38:51PM +0200, Aleksandra Fedorova wrote:
> > On Mon, Oct 7, 2019 at 5:21 PM Michael Catanzaro
> > wrote:
> > >
> > > On Mon, Oct 7, 2019 at 3:11 pm, Ankur Sinha
> > > wrote:
> > > > So I guess
On Mon, Oct 7, 2019 at 8:02 PM Matthew Miller wrote:
>
> On Fri, Oct 04, 2019 at 09:31:55PM +0200, Miro Hrončok wrote:
> > Wouldn't it be easier if the "default stream" would just behave like
> > a regular package?
>
> Part of the "hybrid modularity" proposal was that the default stream could
> _l
On Fri, Oct 04, 2019 at 09:31:55PM +0200, Miro Hrončok wrote:
> Wouldn't it be easier if the "default stream" would just behave like
> a regular package?
Part of the "hybrid modularity" proposal was that the default stream could
_literally_ be tagged into the base repo as non-modular. That has a l
On Sat, Oct 05, 2019 at 02:35:59AM +0200, Kevin Kofler wrote:
> There are many possible reasons for shipping the same upstream release
> across different Fedora releases:
[...snip good list of reasons...]
> That said, I am not a fan of the Updates Policy as written because it is
> written in th
On Mon, Oct 07, 2019 at 05:38:51PM +0200, Aleksandra Fedorova wrote:
> On Mon, Oct 7, 2019 at 5:21 PM Michael Catanzaro wrote:
> >
> > On Mon, Oct 7, 2019 at 3:11 pm, Ankur Sinha
> > wrote:
> > > So I guess I am arguing that while the "new package for existing
> > > maintainers" remain at the `fe
On 07. 10. 19 17:41, Zbigniew Jędrzejewski-Szmek wrote:
Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-07/fesco.2019-10-07-15.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-07/fesco.2019-10-07-15.00.txt
Log:
https://meetbot.fedoraproject
On Sat, Oct 05, 2019 at 01:34:36PM +0200, Aleksandra Fedorova wrote:
> Thus I think we should consider alternatives and how we can migrate
> from a Fedora specific app, to some simple and easy to maintain
> tooling.
I'm all for it. The OpenStack meeting approach seems an improvement over
"back to
Hi,
what's the grand plan for delivering rust packages in F32?
My understanding was that in F31 it wasn't possible to build rust
packages, but it seems to work in rawhide now. I built rust-zram-generator
without issue [1].
I have a rust-generator module, but if it is not necessary, I'd prefer
to
No missing expected images.
Failed openQA tests: 7/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191006.n.1):
ID: 464337 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/464337
ID: 464341 Test: x86_64 Server-dvd-iso inst
OLD: Fedora-31-20191006.n.1
NEW: Fedora-31-20191007.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 6
Dropped packages:0
Upgraded packages: 44
Downgraded packages: 1
Size of added packages: 56.99 MiB
Size of dropped packages:0 B
Size of
Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-07/fesco.2019-10-07-15.00.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-07/fesco.2019-10-07-15.00.txt
Log:
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-10-07/fesco.2019-10-07-15.00.lo
On Mon, Oct 7, 2019 at 5:21 PM Michael Catanzaro wrote:
>
> On Mon, Oct 7, 2019 at 3:11 pm, Ankur Sinha
> wrote:
> > So I guess I am arguing that while the "new package for existing
> > maintainers" remain at the `fedpkg` level of doing things, the "join
> > the
> > package collection maintainer"
I would like to open discussions more widely, because we are talking about
future of software distribution and discussing only particular issue is not
an approach how to delivery solid and stable architecture.
What issues I have in mind?
1. Fedora system upgrade (libgit2, axa, bat)
2. Adding new
Hi,
On Mon, Oct 7, 2019 at 4:12 PM Ankur Sinha wrote:
>
> On Mon, Oct 07, 2019 12:56:51 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Oct 07, 2019 at 12:13:34PM +0100, Ankur Sinha wrote:
> > > On Mon, Oct 07, 2019 12:16:28 +0200, Vít Ondruch wrote:
> > > > If you would like to have rpmbui
On Mon, Oct 7, 2019 at 3:11 pm, Ankur Sinha
wrote:
So I guess I am arguing that while the "new package for existing
maintainers" remain at the `fedpkg` level of doing things, the "join
the
package collection maintainer" page for newbies, who should not be
assumed to have prior knowledge about
On Mon, 7 Oct 2019 at 15:30, Jindrich Novy wrote:
[..]
> BTW mc.
>> Also I do not understand why FC31 release comity ignored my objection to
>> push mc 4.8.23 to fc31 since it core dumps sometimes few times per hour of
>> active use.
>>
>
> You commented on the F29 update (not F31) here:
> https:
On Mon, Oct 7, 2019 at 9:58 AM Peter Pentchev wrote:
> Hmmm, maybe I'm not thinking straight today, but what happens when you
> cross the streams? Correct me if I'm wrong in the following scenario:
You're wrong :)
> Release N:
> - foo: available streams: 1.0, 2.0, default: 2.0
> - bar: depe
Announcing the creation of a new nightly release validation test event
for Fedora 31 Branched 20191007.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
On Mon, Oct 7, 2019 at 4:15 PM Ankur Sinha wrote:
>
> Out of curiosity, what workflow do existing package maintainers user
> while packaging new software? Is it `fedpkg` based with a folder for the
> spec to work in? (I still use rpmbuild + mock/koji-scratch builds).
>
> --
> Thanks,
> Regards,
>
https://bugzilla.redhat.com/show_bug.cgi?id=1759044
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from F
On Mon, Oct 7, 2019 at 3:21 PM Tomasz Kłoczko
wrote:
> On Mon, 7 Oct 2019 at 13:28, Jindrich Novy wrote:
>
>> Hi Tomasz,
>>
>> > On top of removing perl-generators which add for mc proper perl modules
>> dependencies for
>> > patchfs
>>
>> Can you please elaborate on the above? patchfs works for
On Mon, Oct 07, 2019 at 03:15:02PM +0100, Ankur Sinha wrote:
> Out of curiosity, what workflow do existing package maintainers user
> while packaging new software? Is it `fedpkg` based with a folder for the
> spec to work in? (I still use rpmbuild + mock/koji-scratch builds).
I'm only a packager s
On Mon, Oct 07, 2019 at 03:15:02PM +0100, Ankur Sinha wrote:
> Out of curiosity, what workflow do existing package maintainers user
> while packaging new software? Is it `fedpkg` based with a folder for the
> spec to work in? (I still use rpmbuild + mock/koji-scratch builds).
I do:
mkcd foo (bas
Out of curiosity, what workflow do existing package maintainers user
while packaging new software? Is it `fedpkg` based with a folder for the
spec to work in? (I still use rpmbuild + mock/koji-scratch builds).
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.
On Mon, Oct 07, 2019 12:56:51 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Oct 07, 2019 at 12:13:34PM +0100, Ankur Sinha wrote:
> > On Mon, Oct 07, 2019 12:16:28 +0200, Vít Ondruch wrote:
> > > If you would like to have rpmbuild mentioned in the docs, then mock
> > > should be
> > > mention
OLD: Fedora-Rawhide-20191006.n.1
NEW: Fedora-Rawhide-20191007.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 26
Downgraded packages: 1
Size of added packages: 0 B
Size of dropped packages:0 B
Size
No missing expected images.
Compose FAILS proposed Rawhide gating check!
1 of 45 required tests failed, 2 results missing
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
On Fri, Oct 04, 2019 at 10:57:39AM -0400, Stephen Gallagher wrote:
[snip]
> * The state `dep_enabled` would be set whenever a stream becomes
> enabled because some other module stream depended on it. This state
> must be entered only if the previous state was `default` or
> `available`. (We don't w
I think we've already discussed and documented [1] this — although we
haven't discussed module dependencies back then.
A) If user selects a default (or doesn't do any selection), default is
followed.
B) If user selects a specific stream, that stream is followed.
So, basically, respecting user cho
On Mon, 7 Oct 2019 at 13:28, Jindrich Novy wrote:
> Hi Tomasz,
>
> > On top of removing perl-generators which add for mc proper perl modules
> dependencies for
> > patchfs
>
> Can you please elaborate on the above? patchfs works for me despite
> missing perl-generators? This is not raised by me b
On Mon, Oct 07, 2019 at 12:13:34PM +0100, Ankur Sinha wrote:
> On Mon, Oct 07, 2019 12:16:28 +0200, Vít Ondruch wrote:
> > If you would like to have rpmbuild mentioned in the docs, then mock should
> > be
> > mentioned as well.
>
> mock is mentioned in the "Create an hello world rpm" doc:
> http
Sorry guys
that I am disconnected last month. I had some problems with health
and now I am overbusy in work. I hoped that someone else could
continue on that meanwhile what I started.
As I pointed, you can continue with move of other packages using
the copr build anyway. But I understand that's n
Hello,
Vit has been rewritten from scratch in Python and released as version 2.
As part of this re-write, it also changed license to from GPLv3 to MIT.
https://github.com/scottkosty/vit
This does not affect any other packages. I'm building the new version
for F30+ now.
--
Thanks,
Regards,
Ank
On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon wrote:
> So I've been wondering a little bit how we could solve this and I've been
> wondering if we couldn't leverage the PR workflow for this.
> Imagine:
> - You request a new repo to be created
> - The new repo is automatically created from your
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2019-10-07 15:00 UTC'
Links to all issues to be
On Mon, 7 Oct 2019 at 12:04, wrote:
> Notification time stamped 2019-10-07 11:04:36 UTC
>
> From c0792d465daa3db808d63086a1524e786b213fe2 Mon Sep 17 00:00:00 2001
> From: Jindrich Novy
> Date: Oct 07 2019 11:04:05 +
> Subject: - just keep perl-interpreter BR because of man2hlp,
>
> it is a
On Mon, Oct 07, 2019 12:16:28 +0200, Vít Ondruch wrote:
> If you would like to have rpmbuild mentioned in the docs, then mock should be
> mentioned as well.
mock is mentioned in the "Create an hello world rpm" doc:
https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/
But, "mak
On Mon, Oct 07, 2019 at 12:54:56PM +0200, Vít Ondruch wrote:
>
> Dne 07. 10. 19 v 12:00 Pierre-Yves Chibon napsal(a):
> > On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
> >> Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
> >>> On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon
>
Dne 07. 10. 19 v 12:00 Pierre-Yves Chibon napsal(a):
> On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
>> Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
>>> On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon
>>> wrote:
On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrot
If you would like to have rpmbuild mentioned in the docs, then mock
should be mentioned as well. Or both can be omitted for simplicity. But
definitely, we should not suggest plain rpmbuild IMO.
Vít
Dne 07. 10. 19 v 11:32 Ankur Sinha napsal(a):
> Hi,
>
> I was looking at this quick-docs page[1]
On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote:
>
> Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a):
> > On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon
> > wrote:
> >> On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
> >>
> >> Thanks for your words, I appreciate the s
On 07. 10. 19 10:05, Miroslav Suchý wrote:
Dne 04. 10. 19 v 21:31 Miro Hrončok napsal(a):
1. (drastic for modular maintainers)
We keep miantaining the default versions of things as ursine packages. We only
modularize alternate versions.
This will improve current situation. And it will resolv
* Matthew Miller:
> On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
>> > ○ Every changes to dist-git is done via pull-requests
>> Erm, no thank you. Pull requests are a terrible workflow.
>
> It's definitely the winning workflow in the open source world today,
> particularly f
On 06. 10. 19 23:52, Kevin Fenzi wrote:
On Sun, Oct 06, 2019 at 09:00:18PM +0200, Miro Hrončok wrote:
It says: package python3-3.7.4-5.fc31.armv7hl is excluded
I don't know why would it be. How do i debug why it gets excluded?
Only python36 and python38 was excluded, not python37.
...and I du
Hi,
I was looking at this quick-docs page[1] which is mentioned in the "New
package process for existing contributors" page[2]. It now does not use
rpmbuild---it uses `fedpkg` and dist-git.
This is also linked to the "Join the package maintainers page"[3].
Is this now the suggested way---and is
Dne 04. 10. 19 v 21:31 Miro Hrončok napsal(a):
1. (drastic for modular maintainers)
We keep miantaining the default versions of things as ursine packages. We only
modularize alternate versions.
This will improve current situation. And it will resolve upgrades from F30->F31.
However, I fail t
On 10/4/19 3:17 PM, Björn Persson wrote:
Panu Matilainen wrote:
On 10/2/19 8:33 PM, Matthew Miller wrote:
On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote:
○ Every changes to dist-git is done via pull-requests
Erm, no thank you. Pull requests are a terrible workflow.
It's
On Sun, Oct 06, 2019 at 03:11:28PM +0200, Fabio Valentini wrote:
>On Sun, Oct 6, 2019, 15:07 Miro Hrončok <[1]mhron...@redhat.com> wrote:
>
> Couple of my updates have e-mailed me $subj. Is it something to worry
> about?
>
>I got this too for a lot of my updates, just a few hour
On Sun, 06 Oct 2019 18:03:16 -0500
Michael Catanzaro wrote:
> On Sun, Oct 6, 2019 at 4:14 pm, Orion Poplawski
> wrote:
> > Is there any way to check if this was due to an OOM condition?
>
> In my experience, that error is always the OOM killer.
yup, and either we need the builders to get more
Hi all,
This week is GNOME 3.34.1 release. I'm collecting builds in f31-gnome
side tag and going to submit everything in a single megaupdate to Bodhi
later this week. Please use 'fedpkg build --target f31-gnome' if you are
helping with builds.
Tonight also starts the F31 Final Freeze, which mak
78 matches
Mail list logo
