Hi,
I've submitted a new font package for review [1], but I have 0
experience with fonts (I need it to unbundle it from [2]), and I found
the documentation about font packages a little bit outdated. It's a
pretty simple font (OFL, single family with a couple of styles), but
it would be great if
Hi all,
FMN (https://apps.fedoraproject.org/notifications) is currently one of the
main blocking point for dropping fedmsg in favour of fedora-messaging.
FMN is quite important to the community and the composition of Fedora
because it gives emails and notifications on commits, composes, builds
Am Di., 25. Feb. 2020 um 20:37 Uhr schrieb Matthew Miller
:
> > Whereas with 12h clocks, I think midnight is 12:00 PM, and noon is 12:00
> > AM? Which is still confusing me after having known about it for decades.
>
> It's the opposite, which furthers your point. :)
That does not seem to be very
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
https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/26/report-389-ds-base-1.4.3.3-20200226gitea4fa54.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On 2/25/20 3:12 PM, Ankur Sinha wrote:
Basically, packages do not pass review merely because they use good
licenses.
Note that I just said that I thought it was the primary purpose, not the
only purpose.
___
devel mailing list --
On Tue, 2020-02-25 at 16:11 +0100, Kevin Kofler wrote:
> Fabio Valentini wrote:
> > The recent update from cantor 19.08 to cantor 12.12 in both fedora 32
> > and rawhide bumped the SONAME of a shared library as mention in
> > $SUBJECT (maintainers in CC).
> >
> > At least LabPlot still needs to
https://pagure.io/389-ds-base/pull-request/50913
—
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
https://bugzilla.redhat.com/show_bug.cgi?id=1807263
--- Comment #1 from Upstream Release Monitoring
---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/Getopt/Getopt-Long-Descriptive-0.105.tar.gz
to
On 25/2/20 20:54, Richard W.M. Jones wrote:
> On Mon, Feb 24, 2020 at 10:07:15PM -0800, Luya Tshimbalanga wrote:
>> Hello team,
>>
>> It looks like spammers use closed bug report for their ads as seen
>> in this one:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1644013
>>
>> Can someone
https://bugzilla.redhat.com/show_bug.cgi?id=1807263
Bug ID: 1807263
Summary: perl-Getopt-Long-Descriptive-0.105 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Getopt-Long-Descriptive
Keywords:
On Tue, Feb 25, 2020 at 5:05 PM Troy Dawson wrote:
...
> While I agree that we should be very careful with this, I do not
> believe it should be completely off the table.
> I believe it should be permissible with the EPEL Steering Council's
> blessing, but not otherwise.
> Case in point is
On Tue, Feb 25, 2020 at 1:16 PM Stephen Gallagher wrote:
>
> On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller
> wrote:
> >
> > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> > > Consider:
> > >
> > > 1. foo rpm that is in the RHEL baseos. It's not in any module.
> > > Can epel
* Richard Shaw:
> While API/ABI breaking changes within a release is discouraged, it's
> still might be the right thing to do.
libffi within a Fedora release? That seems rather ... involved because
Python depends on it.
I don't think we'll need ABI changes for CET support, and we plan to
port
No missing expected images.
Failed openQA tests: 25/160 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-32-20200224.n.0):
ID: 527306 Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/527306
ID: 527316 Test: x86_64
On Tue, 25 Feb 2020 at 12:55, Antonio Trande wrote:
>
> Hi all.
>
> Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
> package since today.
Actually, it's orphaned *and retired*. This is not insurmountable for
anyone who wishes to take over, but one does not necessarily imply
On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > So these are the results of our current investigations, we are very much
> > eager
> > to get your feedback on them and even more eager if you have ideas on how to
>
On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller wrote:
>
> On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> > Consider:
> >
> > 1. foo rpm that is in the RHEL baseos. It's not in any module.
> > Can epel make a foo (non default) module that overrides it?
> >
This is safe from a
On Tue, Feb 25, 2020 at 12:22:10PM -0800, Michel Alexandre Salim wrote:
> > On February 25, 2020 3:38 AM Richard W.M. Jones wrote:
> >
> >
> > In the previous mass build LWT FTBFS because the tests failed on POWER
> > and s/390 (https://bugzilla.redhat.com/1792780). There is also a new
> >
On Tuesday, 25 February 2020 17.35.04 WET Miro Hrončok wrote:
> Not yet. See also https://github.com/rpm-software-management/rpm/issues/1061
Thank you. It is nice to know that this is being worked (even if as a thought
experiment). :-)
Manually working with this is not difficult but it is
https://bugzilla.redhat.com/show_bug.cgi?id=1655461
--- Comment #9 from Upstream Release Monitoring
---
The following Sources of the specfile are not valid URLs so we cannot
automatically build the new version for you. Please use URLs in your Source
declarations if possible.
-
https://bugzilla.redhat.com/show_bug.cgi?id=1655461
Upstream Release Monitoring
changed:
What|Removed |Added
Summary|w3c-markup-validator-20.1.2
On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> Consider:
>
> 1. foo rpm that is in the RHEL baseos. It's not in any module.
> Can epel make a foo (non default) module that overrides it?
>
> 2. foo rpm that is in a RHEL default module.
> Can epel make a foo (non default) module
On Tue, Feb 18, 2020 at 05:09:04PM +0100, Petr Pisar wrote:
> So the bottom line is: Prefixed streams should provide a bullet proof
> mitigation. Until DNF gains the ability to obsolete a stream, there will be
> slight risk of creeping out-dated EPEL content into the installation.
A prefix also
> On February 25, 2020 3:38 AM Richard W.M. Jones wrote:
>
>
> In the previous mass build LWT FTBFS because the tests failed on POWER
> and s/390 (https://bugzilla.redhat.com/1792780). There is also a new
> version of LWT (https://bugzilla.redhat.com/1755859). The new version
> is noted as
No missing expected images.
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 18/160 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-Rawhide-20200224.n.0):
ID: 527154 Test: x86_64 Server-dvd-iso modularity_tests
URL:
On Tue, Feb 25, 2020 14:41:34 -0500, Matthew Miller wrote:
> On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > > One thing that comes to my mind with this proposal is that we still need
> > > some way to vet licenses. Today, this is done via the package review
> > > process, and in
Il 24/02/20 23:04, Ben Cotton ha scritto:
> In the weekly Fedora program update that I publish on
> communityblog.fedoraproject.org, I have started to include a count of the
> open package review requests. As of this moment, there are ~1300 open review
> requests. Some of these were opened in
On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> So these are the results of our current investigations, we are very much eager
> to get your feedback on them and even more eager if you have ideas on how to
> approach/solve some of the challenges mentioned here.
This all
Thanks for the answer.
I make a comment in the bug.
El mar., 25 feb. 2020 a las 16:42, Scott Talbert ()
escribió:
> On Tue, 25 Feb 2020, Eduard Lucena wrote:
>
> > Hello team,
> >
> > I'm writing this here, because I don't know of any other place, so if
> there
> > is another place to report
Hello,
We're drafting a submission to CNS*2020[1] about NeuroFedora. Would
anyone know if there's a way to formally cite RPM?
Google Scholar gives me this document by Mark Ewing and Eric Troan[2]
from 1996. Should one keep citing this, or does someone know a newer
publication that we should use?
On Tue, 25 Feb 2020, Eduard Lucena wrote:
Hello team,
I'm writing this here, because I don't know of any other place, so if there
is another place to report it, I'll listen to go there.
I'm trying to install the package: python3-i3ipc
$ sudo dnf info python3-i3ipc
Last metadata expiration
On Mon, Feb 24, 2020 at 10:35:08AM +, Ankur Sinha wrote:
> > One thing that comes to my mind with this proposal is that we still need
> > some way to vet licenses. Today, this is done via the package review
> > process, and in my mind is the primary purpose of package review. If we
> > started
On Sat, Feb 22, 2020 at 11:06:30AM +0100, Fabio Valentini wrote:
> I assume 00:00 UTC was confusing for people used to the AM/PM (12h) time
> format instead of the 24h format.
>
> For people used to 24h clocks, it's completely obvious that 00:00 is the
> beginning of the day, and 24:00 is the end
On Mon, Feb 24, 2020 at 05:04:26PM -0500, Ben Cotton wrote:
> The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly
> excludes review request bugs. Having a large number of open, ancient review
> requests isn't exactly harmful, but it's not very helpful either.
>
> Before I
Hello there
Here are the logs for today's meeting.
HTML Logs:
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.log.html
HTML Minutes:
https://meetbot.fedoraproject.org/fedora-neuro/2020-02-25/neurofedora.2020-02-25-16.00.html
Minutes in plain text are
https://pagure.io/389-ds-base/pull-request/50911
--
389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200225.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
Hello. I have updated the python27 package to use the bundled wheels of pip and
setuptools, so we can update setuptools in rawhide to a version that no longer
works with Python 2.
Unfortunately, that changes the license from "Python" to this beast:
Python and MIT and ASL 2.0 and BSD and ISC
Hello team,
I'm writing this here, because I don't know of any other place, so if there
is another place to report it, I'll listen to go there.
I'm trying to install the package: python3-i3ipc
$ sudo dnf info python3-i3ipc
Last metadata expiration check: 0:02:42 ago on Tue 25 Feb 2020 02:18:22
On Tue, 25 Feb 2020 at 17:07, Michal Schorm wrote:
> Hello,
>
> Will anybody be able to explain to me the current state of the
> containers & containerization in Fedora, please?
>
Hi Michal,
As you mention in the points below the current state of building containers
in Fedora needs a lot of
Dear all,
You are kindly invited to the meeting:
EPEL Steering Co on 2020-02-26 from 18:00:00 to 19:00:00 GMT
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the
following:
#meetingname EPEL
#topic
Den tis 25 feb. 2020 kl 16:10 skrev Christophe de Dinechin <
dinec...@redhat.com>:
> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does
Hi all.
Antimony (https://src.fedoraproject.org/rpms/antimony) is an orphan
package since today.
Feel free to take it.
--
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/
signature.asc
On 25. 02. 20 18:23, José Abílio Matos wrote:
AFAIU the automatic generated dependencies take care of the first step. Is
there any way, automatic or not, to generate the equivalent of
pip install "Nikola[extras]"?
Not yet. See also https://github.com/rpm-software-management/rpm/issues/1061
--
Hi,
my case study is nikola (a static pages generator).
I am using the automatically generated dependencies but that only covers the
Requires part of the spec file.
My question is if there are any tools that people use, working from the setup
file, to generate the addition fields like
On Tue, Feb 25, 2020 at 9:57 AM Anthony Green wrote:
> Hello -- I'm the current Fedora maintainer for libffi, as well as the
> upstream author/maintainer. I'm looking for help with libffi
> packaging. Specifically, we need to roll out a new ABI-breaking
> release (required for ARM64 and Intel
On 25. 02. 20 15:27, Fabio Valentini wrote:
Side note: I've been meaning to propose dropping Epoch because of this
"we don't care about upgrade path anymore", but I've not gotten around
to do that yet
Unfortunately, that breaks rawhide users.
--
Miro Hrončok
--
Phone: +420777974800
IRC:
Add me as co-maintainer, please.
I'm using libffi as dependency for a couple of packages.
On 25/02/20 16:56, Anthony Green wrote:
> Hello -- I'm the current Fedora maintainer for libffi, as well as the
> upstream author/maintainer. I'm looking for help with libffi
> packaging. Specifically, we
On 25. 02. 20 9:50, Pierre-Yves Chibon wrote:
Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).
I don't consider
Hi all,
Please see the latest AAA FAS replacement project update below:
AAA: FAS replacement project update 2/25/20
The month of February was a very busy month for the CPE AAA team and
community contributors working on this initiative. Great progress was made
in the development phase of the
Hidden from sight of any mortal man, I've found 'Fedora Container SIG'
with as little information as possible [1], although they state, they have
notes from 2019 DevConf meetup [2], but locked [3].
Atleast I found first place of discussion! [4]
... if you can say that about bunch of threads with
Hello,
Will anybody be able to explain to me the current state of the
containers & containerization in Fedora, please?
I have some questions, but the more I searched for whom & where to
ask, the more confused I became.
--
1) There ́s an IRC on freenode, '#fedora-containers' channel.
The TOPIC
Hello -- I'm the current Fedora maintainer for libffi, as well as the
upstream author/maintainer. I'm looking for help with libffi
packaging. Specifically, we need to roll out a new ABI-breaking
release (required for ARM64 and Intel CET support), and I don't have
the volunteer time available to
Hi all,
Today's an important day on the Fedora 32 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point
[2]. That means that from now on all Fedora 32 packages must be
submitted to updates-testing and pass the relevant requirements[3]
before they will be
On Tue, Feb 25, 2020 at 04:09:32PM +0100, Christophe de Dinechin wrote:
> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something
Hello there
We will be starting in about 15-20 minutes. It would be great if
people could join the meeting. :D
On Mon, Feb 24, 2020 at 6:48 PM Aniket Pradhan
wrote:
>
> Hey there!
>
> You are invited to attend the next Open NeuroFedora team meeting this
> week on Tuesday at 1600UTC in
On Tue, 25 Feb 2020 at 10:10, Christophe de Dinechin
wrote:
> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have
* Christophe de Dinechin:
> Is there any documented procedure to safely downgrade from rawhide to
> the latest release?
>
> I tried
>
> # dnf update --releasever=32 fedora-release
> # dnf distro-sync --allowerasing --skip-broken
>
> Does something like that have any chance of working? At first
Is there any documented procedure to safely downgrade from rawhide to
the latest release?
I tried
# dnf update --releasever=32 fedora-release
# dnf distro-sync --allowerasing --skip-broken
Does something like that have any chance of working? At first sight, it
seems to be somewhat successful.
Hi all,
Today's an important day on the Fedora 32 schedule[1], with several
significant cut-offs. First of all today is the Bodhi activation point
[2]. That means that from now on all Fedora 32 packages must be
submitted to updates-testing and pass the relevant requirements[3]
before they will be
Fabio Valentini wrote:
> The recent update from cantor 19.08 to cantor 12.12 in both fedora 32
> and rawhide bumped the SONAME of a shared library as mention in
> $SUBJECT (maintainers in CC).
>
> At least LabPlot still needs to be rebuilt on both f32 and rawhide
> (maintainers in CC).
Cantor is
https://bugzilla.redhat.com/show_bug.cgi?id=1806215
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #6 from
https://bugzilla.redhat.com/show_bug.cgi?id=1805790
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #4 from
On Tue, Feb 25, 2020 at 3:43 PM Ben Cotton wrote:
>
>
>
> On Mon, Feb 24, 2020, 17:32 Fabio Valentini wrote:
>>
>>
>> It sounds like you are both not aware that there's actually an
>> existing policy that covers stalled Review Requests:
>>
I've subscribed to the bug report, but I've also spoke with Jens Petersen
on IRC and he said it will be available rather soon =)
--
Best regards / S pozdravem,
BSc. Mark Stopka, BBA
mobile: +420 704 373 561
On Tue, Feb 25, 2020 at 3:26 PM Jos Vos wrote:
> On Tue, Feb 25, 2020 at 08:56:52AM
On Mon, Feb 24, 2020, 17:32 Fabio Valentini wrote:
>
> It sounds like you are both not aware that there's actually an
> existing policy that covers stalled Review Requests:
> https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
Ah ha! I thought I remembered seeing something
On Tue, Feb 25, 2020 at 3:12 PM Pierre-Yves Chibon wrote:
>
> On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> > On Tue, Feb 25, 2020 at 2:47 PM Remi Collet
> > wrote:
> > >
> > > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> > >
> > > > - You can easily opt-in by
On Tue, Feb 25, 2020 at 08:56:52AM -0500, Stephen John Smoogen wrote:
> [...] If you need a set of packages, go to https://bugzilla.redhat.com
> and check to see if there are outstanding bug tickets requesting a
> maintainer to support it in EPEL-8. If there are add your info to that
> ticket,
On Tue, Feb 25, 2020 at 02:55:37PM +0100, Fabio Valentini wrote:
> On Tue, Feb 25, 2020 at 2:47 PM Remi Collet wrote:
> >
> > Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> >
> > > - You can easily opt-in by using the macros
> >
> > Please keep opt-in as a mandatory need for such a
On Tue, Feb 25, 2020 at 12:59:39PM +0100, Vít Ondruch wrote:
>
> Dne 24. 02. 20 v 17:48 Pierre-Yves Chibon napsal(a):
> > Good Morning Everyone,
> >
> > This topic has already been discussed a few times over the past month, but
> > Adam
> > Saleh, Nils Philippsen and myself have had the
On Tue, Feb 25, 2020 at 2:47 PM Remi Collet wrote:
>
> Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
>
> > - You can easily opt-in by using the macros
>
> Please keep opt-in as a mandatory need for such a change.
>
>
> To be clear, I will be (perhaps the only) one to not use it.
>
>
> For
On Tue, 25 Feb 2020 at 08:53, Jos Vos wrote:
> Hi,
>
> Is there a specific reason why the Haskell platform is not available
> anymore in EPEL 8 (it was in EPEL 7)? Any ongoing work known to
> eventually support it again?
>
>
We do not automatically branch everything from one release to another.
On Sat, Feb 22, 2020 07:03:16 -0800, Erich Eickmeyer wrote:
>
>
> I have had a few people looking at my reviews. After I made corrections and
> posted that info, I have had zero responses on my bugs:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1801352
>
Hi,
After some test, is looks like the stream name of a module have to
match the branch name.
I think this constraint doesn't make sense.
We can want different content (.yaml file) for different
distributions (Fedora vs EPEL) or different Version
Reported as
Hi,
Is there a specific reason why the Haskell platform is not available
anymore in EPEL 8 (it was in EPEL 7)? Any ongoing work known to
eventually support it again?
Thanks,
--
--Jos Vos
--X/OS Experts in Open Systems BV | Office: +31 20 6938364
--Amsterdam, The Netherlands
https://bugzilla.redhat.com/show_bug.cgi?id=1806997
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
Le 24/02/2020 à 17:48, Pierre-Yves Chibon a écrit :
> - You can easily opt-in by using the macros
Please keep opt-in as a mandatory need for such a change.
To be clear, I will be (perhaps the only) one to not use it.
For now spec file are self-contained, which is nice.
I don't like the
https://bugzilla.redhat.com/show_bug.cgi?id=1806997
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=1806997
Bug ID: 1806997
Summary: perl-MooX-Struct-0.019 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-MooX-Struct
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=1785827
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1793146
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1794960
--- Comment #8 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1793146
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1795119
--- Comment #8 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1793459
--- Comment #12 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1791932
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1795119
--- Comment #7 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1792861
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1788685
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--- Comment #12 from Fedora Update
https://bugzilla.redhat.com/show_bug.cgi?id=1787958
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1786801
--- Comment #10 from Fedora Update System ---
FEDORA-MODULAR-2020-9eb54c7af8 has been submitted as an update to Fedora 30
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-9eb54c7af8
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1794960
--- Comment #7 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1785827
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1793459
--- Comment #11 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail
https://bugzilla.redhat.com/show_bug.cgi?id=1786801
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1792861
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1787958
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
https://bugzilla.redhat.com/show_bug.cgi?id=1791932
--- Comment #9 from Fedora Update System ---
FEDORA-MODULAR-2020-cc0fdb630a has been submitted as an update to Fedora 31
Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-cc0fdb630a
--
You are receiving this mail because:
On Mon, 24 Feb 2020 at 18:31, Eduardo Kienetz wrote:
>
> It would be my first time maintaining an EPEL package, but if nobody else
> already experienced is willing, I could probably do it with minimal
> supervision/hints to get started :)
> What has been the typical work? If they have git repos
1 - 100 of 146 matches
Mail list logo
