https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/25/report-389-ds-base-1.4.3.4-20200325git534c2cf.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova wrote:
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
I've finally had an opportunity to digest this change proposal, and
I've got some overall questions and feedback.
> == Summary ==
>
> The goal of the ELN project is
Hello there,
Hope this email finds you well!
This is in with reference to the project idea of improving the N/W Linux
System Role shared on GSoC 2020.
I would like to tell you that I really liked this idea of how we're trying
to uniformly handle the configurations for Network-Scripts and
https://bugzilla.redhat.com/show_bug.cgi?id=1788965
David Dick changed:
What|Removed |Added
Flags|needinfo?(dd...@cpan.org) |
--
You are receiving this mail
On Tuesday, March 24, 2020 5:25:30 AM MST Petr Pisar wrote:
> On Tue, Mar 24, 2020 at 12:13:57PM +, Tom Hughes via devel wrote:
> > I thought the above was saying there were fundamental architectural
> > differences in the way the builds worked, rather than just that people
> > might choose to
cheeselee opened a new pull-request against the project: `perl` that you are
following:
``
Set macros subpackage noarch
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/2
___
perl-devel mailing list --
https://bugzilla.redhat.com/show_bug.cgi?id=1816889
Bug ID: 1816889
Summary: perl-Future-0.44 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Future
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=1813603
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
https://bugzilla.redhat.com/show_bug.cgi?id=1813603
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
Hi everyone,
I am currently a Masters student in Computer Science and I wanted to work
on the "varlink support to Nmstate" project as part of GSoC 2020. I have
experience with the technologies required for the project, so it seems like
a good fit.
I had a few queries regarding the project -
In
> On 23 Mar 2020, at 12:52, William Brown wrote:
>
>
>
>> On 21 Mar 2020, at 01:37, thierry bordaz wrote:
>>
>> Hi William,
>>
>> I only have a vague knowledge of syntaxes/MR.
>>
>> Each syntax is a plugin. Its init function registers for a given set of OIDs
>> the matching rules
Hi clime,
not a "proper" answer, but at least parts of the functionality that you
desire must be present in Koschei. Maybe Mikolaj Izdebski (iirc the
main developer of Koschei) can help you out?
Cheers,
Dan
clime writes:
> Hello!
>
> Is there a tool to which I would provide a package name,
On Tue, 2020-03-24 at 17:49 -0500, Michael Cronenworth wrote:
> On 3/24/20 5:42 PM, Jared K. Smith wrote:
> > Just for kicks and giggles, I tried the first -- it still failed with an
> > undefined
> > reference to `DL_INSERT_INORDER'.
>
> Yeah, because our version of uthash is 2.0.2 and the
On 3/24/20 5:42 PM, Jared K. Smith wrote:
Just for kicks and giggles, I tried the first -- it still failed with an undefined
reference to `DL_INSERT_INORDER'.
Yeah, because our version of uthash is 2.0.2 and the latest, which has that macro,
is 2.1.0.
I can push a uthash update if we want
On Tue, Mar 24, 2020 at 5:50 PM Michael Cronenworth wrote:
> Two ways of fixing us:
> 1. Add a BR for 'uthash-devel' to properly de-bundle mosquitto (it has
> never been
> unbundled).
> 2. Add a Provides: bundled(uthash) and remove WITH_BUNDLED_DEPS=no.
>
Just for kicks and giggles, I tried the
On 3/24/20 10:39 AM, Fabian Affolter wrote:
I tried to rebuild mosquitto. No luck so far. I will try to fix is as
soon as possible but no promises on the timeframe.
Upon a first glance it appears that upstream fixed the WITH_BUNDLED_DEPS flag to
function correctly as it has never, not bundled
https://bugzilla.redhat.com/show_bug.cgi?id=1816303
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #1 from
Mohan cleaned up the tagging and hopefully it will go out with the next
push.
If it doesn't, please file a releng ticket and we can get it sorted out.
Ok, thanks!
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok wrote:
>
> On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
> > I am going to answer generally in this mail, before we dive in into
> > discussing the details.
> >
> > I think your approach to assessment of the Change is not fair.
>
> Ouch. It's just
Hi Lukasz,
On Tue, Mar 24, 2020 19:30:58 +0100, Łukasz Posadowski wrote:
>
> I recently upgraded to Fedora 3, but dnf didn't updated Python 3.7 to
> Python 3.8. I managed to get around it with some rpm e and ivh with
> nodeps, including python3-dnf, python3-rpm and rpm packages. Anyone had
>
On Tue, Mar 24, 2020 at 06:08:07PM +, Mattia Verga via devel wrote:
> Il 24/03/20 17:48, Sandro Mani ha scritto:
> > Hi
> >
> > I have this big update [1] which I cannot submit to stable because
> >
> > Cannot find relevant tag for bes-3.20.6-2.fc32. None of
> > ['f32-updates-pending'] are in
I recently upgraded to Fedora 3, but dnf didn't updated Python 3.7 to
Python 3.8. I managed to get around it with some rpm e and ivh with
nodeps, including python3-dnf, python3-rpm and rpm packages. Anyone had
this problem, too?
--
Łukasz Posadowski
On 24. 03. 20 17:12, José Abílio Matos wrote:
What about bugzilla? Will it follow the renaming?
That means that we need to know the python version (not difficult I admit) to
know the component where to submit the bug report.
We will still own the python3 component and triage the bugs as usual.
Il 24/03/20 17:48, Sandro Mani ha scritto:
> Hi
>
> I have this big update [1] which I cannot submit to stable because
>
> Cannot find relevant tag for bes-3.20.6-2.fc32. None of
> ['f32-updates-pending'] are in [...]
>
> (and also for other builds, if I just try to remove bes from the
> update).
https://bugzilla.redhat.com/show_bug.cgi?id=1004354
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
On Tue, Mar 24, 2020 at 1:13 PM Kevin Fenzi wrote:
> On Tue, Mar 24, 2020 at 09:28:35AM -0400, Kaleb Keithley wrote:
> > Now five. ppc64le this time.
>
> I've cleaned these up now.
>
> Mostly it was due to the upgrade on the builders this weekend pulling in
> mock 2.1 and enabling it's
On Tue, Mar 24, 2020 at 02:37:56PM +0100, Daniel Pocock wrote:
...snip...
Lets refrain from Holocaust and rape comparisons, they are completely
uncalled for.
I'd like to once again ask for this thread to die and folks to move back
to Fedora devel topics.
Thanks,
kevin
signature.asc
On Tue, Mar 24, 2020 at 09:28:35AM -0400, Kaleb Keithley wrote:
> Now five. ppc64le this time.
I've cleaned these up now.
Mostly it was due to the upgrade on the builders this weekend pulling in
mock 2.1 and enabling it's 'bootstrap' mode, so it made bootstrap cache
files for everything. I've
On Tuesday, 24 March 2020 16.38.38 WET Zbigniew Jędrzejewski-Szmek wrote:
> The binary path only cares about binary package names, so it is unaffected
> by this change.
My concern here is not about the path of binaries.
The issue is about the upgrade path. But after looking into the pull request
Hi folks,
Thanks for coming. We're making good progress on the Lab image and other
tasks in general.
We will meet again at the same time in 2 weeks.
Links to logs from today's meeting:
-
https://meetbot.fedoraproject.org/fedora-neuro/2020-03-24/neurofedora.2020-03-24-16.00.log.html
-
On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
I am going to answer generally in this mail, before we dive in into
discussing the details.
I think your approach to assessment of the Change is not fair.
Ouch. It's just that reading the proposal raises all of those questions. Sorry
if that's
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and
tl;dr: a scriptlet has been added to the fedora-release package that
performs a _one time_ "dnf module reset eclipse" operation when
fedora-release is upgraded. The update that does this is now in bodhi [1].
This was decided in a FESCo ticket [2] to solve bugzilla #1780827 [3]
and has a "F31
Hi
I have this big update [1] which I cannot submit to stable because
Cannot find relevant tag for bes-3.20.6-2.fc32. None of
['f32-updates-pending'] are in [...]
(and also for other builds, if I just try to remove bes from the
update). I suspect this is because some of the builds were
On Tue, Mar 24, 2020 at 04:12:29PM +, José Abílio Matos wrote:
> On Tuesday, 24 March 2020 12.40.24 WET Miro Hrončok wrote:
> > We would like ro rename the "python3" component (SRPM) to "python39" to
> > make maintaining various Python versions in various Fedora versions
> > easier. The
No missing expected images.
Soft failed openQA tests: 2/8 (x86_64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-IoT-32-20200323.0):
ID: 58 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL:
https://bugzilla.redhat.com/show_bug.cgi?id=1816754
--- Comment #2 from Upstream Release Monitoring
---
the-new-hotness/release-monitoring.org's scratch build of
perl-Config-IniFiles-3.03-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=42742679
--
https://bugzilla.redhat.com/show_bug.cgi?id=1816754
Bug ID: 1816754
Summary: perl-Config-IniFiles-3.03 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Config-IniFiles
Keywords: FutureFeature,
https://bugzilla.redhat.com/show_bug.cgi?id=1816754
--- Comment #1 from Upstream Release Monitoring
---
Created attachment 1673163
--> https://bugzilla.redhat.com/attachment.cgi?id=1673163=edit
[patch] Update to 3.03 (#1816754)
--
You are receiving this mail because:
You are on the CC
https://pagure.io/389-ds-base/pull-request/50982
--
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:
Hey, Daniel,
I would like to say you are welcome in Fedora.
I think nobody really has a time or motivation to follow the history
so there is nothing that you would need to be explaining.
Personally, I only perceive there is some off-topic discussion going
on and I have no idea why but I think
On Tuesday, 24 March 2020 12.40.24 WET Miro Hrončok wrote:
> We would like ro rename the "python3" component (SRPM) to "python39" to
> make maintaining various Python versions in various Fedora versions
> easier. The names of binary RPMs would be unchanged; you still do `dnf
> install python3`.
On Mon, Mar 23, 2020 at 10:16:59PM -0700, John M. Harris Jr wrote:
> Kevin,
>
> it is important that issues such as this can be talked about publicly,
Sure, how about the council-discuss list? Or your blog? Or some other
forum where such things are discussed?
> otherwise we are all "living in
Respected sirs,
I am Devsarshi Goswami, a final year student of Christ University
Bengaluru. I have been using Linux for many years now and I have
developed most of my projects in python, Django and flask. I am
comfortable using container solutions like Docker and have completed 3
successful
"John M. Harris Jr" writes:
> it is important that issues such as this can be talked about publicly,
I disagree. It has nothing to do with Fedora development[*], and allowing
EITHER side to continue this "discussion" allows either side to badger
and bully the opposition until people comply
On Tue, Mar 24, 2020 at 01:40:24PM +0100, Miro Hrončok wrote:
> Hello Pythonistas.
>
> (I've CC'ed the devel list for further exposure. But let's discuss
> this on python-devel list please to avoid noise.)
>
>
> We would like ro rename the "python3" component (SRPM) to
> "python39" to make
On 3/24/20 4:21 PM, Peter Robinson wrote:
>> On 3/13/20 2:24 AM, Fabian Affolter wrote:
>>> Thanks for the reminder. Sorry, guys, this would have been my job to
>>> inform you.
>>
>> Any update on the rebuilds? I need a new 'mosquitto' to build a package
>> update it
>> requires.
>
> the latest
No missing expected images.
Failed openQA tests: 3/171 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-32-20200323.n.0):
ID: 555316 Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/555316
ID: 555376 Test: x86_64
OLD: Fedora-Rawhide-20200323.n.0
NEW: Fedora-Rawhide-20200324.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 18
Dropped packages:4
Upgraded packages: 99
Downgraded packages: 1
Size of added packages: 51.86 MiB
Size of dropped packages
On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok wrote:
>
> On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
> > As Ben is on PTO, I'd like to present the System-Wide Change
> >
> > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >
> > == Summary ==
> >
> > The goal of the ELN
> On 3/13/20 2:24 AM, Fabian Affolter wrote:
> > Thanks for the reminder. Sorry, guys, this would have been my job to
> > inform you.
>
> Any update on the rebuilds? I need a new 'mosquitto' to build a package
> update it
> requires.
the latest version of mosquitto has a FTB error, not sure
No missing expected images.
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 7/171 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-Rawhide-20200323.n.0):
ID: 555128 Test: x86_64 universal upgrade_2_server_domain_controller
URL:
On 3/13/20 2:24 AM, Fabian Affolter wrote:
Thanks for the reminder. Sorry, guys, this would have been my job to
inform you.
Any update on the rebuilds? I need a new 'mosquitto' to build a package update it
requires.
Thanks,
Michael
___
devel
On Tue, 2020-03-24 at 09:52 -0400, Charalampos Stratakis wrote:
>
> - Original Message -
> > From: "Tomas Mraz"
> > To: "Miro Hrončok" , "Development discussions
> > related to Fedora"
> > Cc: "python-maint"
> > Sent: Tuesday, March 24, 2020 1:22:37 PM
> > Subject: Re: Heads up:
OLD: Fedora-32-20200323.n.0
NEW: Fedora-32-20200324.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 2
Dropped packages:0
Upgraded packages: 61
Downgraded packages: 0
Size of added packages: 14.85 MiB
Size of dropped packages:0 B
Size
On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way
- Original Message -
> From: "Tomas Mraz"
> To: "Miro Hrončok" , "Development discussions related to
> Fedora"
> Cc: "python-maint"
> Sent: Tuesday, March 24, 2020 1:22:37 PM
> Subject: Re: Heads up: OpenSSL-1.1.1e coming to Rawhide
>
> On Sun, 2020-03-22 at 17:29 +0100, Miro
On 24/03/2020 13:47, Martin Langhoff wrote:
> On Tue, Mar 24, 2020 at 7:28 AM Daniel Pocock wrote:
>> Sending this to another list is not the solution. Langhoff unleashed
>> this monster on this list and it is time for people to show some respect
>
> Of all the players in this saga, it turns
Now five. ppc64le this time.
On Tue, Mar 24, 2020 at 7:10 AM Kaleb Keithley wrote:
>
>
>
> Hi,
>
> I've had four ceph builds die in the last 12ish hours. One of them was a
> scratch build on x86_64; the others were regular builds, one on ppc64le,
> and the other two on x86_64.
>
> I don't know
Il giorno lun, 23/03/2020 alle 13.36 -0600, Chris Murphy ha scritto:
> However, they are no individually encrypted
I have try on VM and work as expected: no double encryption are done
But yesterday when I have try to install F32 on my new Dell G5-15 notebook the
behavior was this:
On Tue, Mar 24, 2020 at 10:31 am, Marius Schwarz
wrote:
If it's a requester after the desktop showed up, it's most likely the
keyring daemon asking to unlock your keyring.
Yup.
1. Install seahorse (Passwords and Keys)
2. Look for Login (login keyring) in the left sidebar
3. Right click ->
On Tue, Mar 24, 2020 at 7:28 AM Daniel Pocock wrote:
> Sending this to another list is not the solution. Langhoff unleashed
> this monster on this list and it is time for people to show some respect
Of all the players in this saga, it turns out that I am the unleasher
of monsters?
With
Hello Pythonistas.
(I've CC'ed the devel list for further exposure. But let's discuss this on
python-devel list please to avoid noise.)
We would like ro rename the "python3" component (SRPM) to "python39" to make
maintaining various Python versions in various Fedora versions easier.
The
Hello Pythonistas.
(I've CC'ed the devel list for further exposure. But let's discuss this on
python-devel list please to avoid noise.)
We would like ro rename the "python3" component (SRPM) to "python39" to make
maintaining various Python versions in various Fedora versions easier.
The
On Tue, 2020-03-24 at 12:27 +0100, Daniel Pocock wrote:
>
> On 24/03/2020 12:08, Charalampos Stratakis wrote:
>
> > Why would you care though, care to elaborate? And how would you
> > personally know what is going on? Clearly there are reasons for it
> > to go to a different venue and you just
On Tue, Mar 24, 2020 at 12:13:57PM +, Tom Hughes via devel wrote:
> I thought the above was saying there were fundamental architectural
> differences in the way the builds worked, rather than just that people
> might choose to make different choices in the spec file.
>
RHEL supports building
On Sun, 2020-03-22 at 17:29 +0100, Miro Hrončok wrote:
> On 19. 03. 20 17:31, Tomas Mraz wrote:
> > The new openssl-1.1.1e is coming to Rawhide.
> >
> > It reports premature EOF/improper shutdown on TLS connections more
> > properly. However this might make some dependencies broken in build
> >
On 24/03/2020 12:08, Vít Ondruch wrote:
Dne 24. 03. 20 v 11:43 Tom Hughes via devel napsal(a):
On 24/03/2020 09:32, Aleksandra Fedorova wrote:
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we
Dne 24. 03. 20 v 11:43 Tom Hughes via devel napsal(a):
> On 24/03/2020 09:32, Aleksandra Fedorova wrote:
>
>> ELN is an evolution of the request for an alternate buildroot for
>> newer x86_64 processors. The reasoning behind that new buildroot was
>> that we expected that the next major release
On 24/03/2020 12:08, Charalampos Stratakis wrote:
> Why would you care though, care to elaborate? And how would you personally
> know what is going on? Clearly there are reasons for it to go to a different
> venue and you just blindly assume that this is censorship and whatnot.
>
I just
Hi,
I've had four ceph builds die in the last 12ish hours. One of them was a
scratch build on x86_64; the others were regular builds, one on ppc64le,
and the other two on x86_64.
I don't know if this is a new problem or just repeat occurrences of a long
standing problem.
Anyway, just FYI. (I
- Original Message -
> From: "John M. Harris Jr"
> To: "Development discussions related to Fedora"
>
> Sent: Tuesday, March 24, 2020 11:34:50 AM
> Subject: Re: Code of Conduct issue
>
> On Tuesday, March 24, 2020 3:29:58 AM MST Dominik 'Rathann' Mierzejewski
> wrote:
> > John,
> >
>
Am 24.03.20 um 11:49 schrieb Fabian Affolter:
> A month ago was msgpack 1.0.0 released. I'm planning to update the
> package in rawhide in the near future.
>
> This should start a conversation about a coordinated approach to keep
> the update smooth for all packages which depends on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
A month ago was msgpack 1.0.0 released. I'm planning to update the
package in rawhide in the near future.
This should start a conversation about a coordinated approach to keep
the update smooth for all packages which depends on
On 24/03/2020 09:32, Aleksandra Fedorova wrote:
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore
On Tuesday, March 24, 2020 3:29:58 AM MST Dominik 'Rathann' Mierzejewski
wrote:
> John,
>
> On Tuesday, 24 March 2020 at 06:16, John M. Harris Jr wrote:
> [...]
>
> > Further, attempting to censor *this topic* is not in the spirit of the
> > Friends foundation either. It is important that we,
John,
On Tuesday, 24 March 2020 at 06:16, John M. Harris Jr wrote:
[...]
> Further, attempting to censor *this topic* is not in the spirit of the
> Friends foundation either. It is important that we, as a community,
> can discuss the rules we've chosen to govern our actions within this
> project.
On 24. 03. 20 11:14, Neal Gompa wrote:
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova wrote:
The RPM variables:
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
This will break things. %fedora has always returned an integer, why do
you want to
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova wrote:
>
> The RPM variables:
>
> * `%{fedora}` will return `.fcXX` (where XX is the Fedora version
> represented by Rawhide).
This will break things. %fedora has always returned an integer, why do
you want to change it to return a
https://bugzilla.redhat.com/show_bug.cgi?id=1813602
--- Comment #8 from Fedora Update System ---
FEDORA-2020-cada965801 has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1815667
--- Comment #5 from Fedora Update System ---
FEDORA-2020-cada965801 has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1811612
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1797039
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In Version|
Hi,
New version 2.3.0 have been released:
https://github.com/libgd/libgd/releases/tag/gd-2.3.0
ABI/API is compatible
https://rpms.remirepo.net/compat_reports/libgd/2.2.5-2_to_2.3.0/compat_report.html
(some constified function parameters)
Notice that the gdlib-config command have been dropped
https://bugzilla.redhat.com/show_bug.cgi?id=1815667
--- Comment #4 from Fedora Update System ---
FEDORA-2020-06d0a81f9f has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1813602
--- Comment #7 from Fedora Update System ---
FEDORA-2020-06d0a81f9f has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and
Am 24.03.20 um 03:27 schrieb Marty Felker:
> I am in Ubuntu for the moment but have a wicked fast F32
> workstation. My only "issue" is that I get asked for an unlock key
> when I boot when what I want is to boot directly to the desktop. I
> am the only one with physical or any other access to
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
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://bugzilla.redhat.com/show_bug.cgi?id=1816303
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |MODIFIED
Fixed In Version|
91 matches
Mail list logo