There will be an outage starting at 2020-10-01 08:00 UTC,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2020-10-01 08:00 UTC'
Reason for outage:
We are moving the service to a new s
* Neal Gompa:
> Why don't you add an lldb-add-index tool to generate LLVM indexes for
> LLDB? Then we just invoke it as part of the buildroot policy setup and
> get both GDB and LLDB indexes? This proposal seems to be particularly
> destructive to GDB users to favor LLDB.
You can use:
set inde
Hi,
the livecds from F32 and F33 are suffering from a problem not booting on
Microsoft device(s)
https://bugzilla.redhat.com/show_bug.cgi?id=1879921
https://bugzilla.redhat.com/show_bug.cgi?id=1883593
F31 is booting fine, the newer ones not. Looks like a GrubBootloader
issue to me, as not even g
Hi,
> For example, if I have my laptop in my home wifi, connected to RH VPN,
> then there are some names resolvable only via the local
> DNS. Specifically: my router's, my printer's and my NAS' address. And
> there are other names only resolvable via RH VPN. systemd-resolved for
> the first time
On Wed, Sep 30, 2020 at 09:55:53AM +0200, Florian Weimer wrote:
> > Why don't you add an lldb-add-index tool to generate LLVM indexes for
> > LLDB? Then we just invoke it as part of the buildroot policy setup and
> > get both GDB and LLDB indexes? This proposal seems to be particularly
> > destruct
Zbigniew Jędrzejewski-Szmek writes:
> On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
>> > Hi,
>> >
>> > I'm coordinating rebuilds of packages due to the libevent rebase [1]
>> > and I'm having troubl
On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote:
> Why don't you add an lldb-add-index tool to generate LLVM indexes for
> LLDB?
Because doing it separately like GDB does is a wrong thing for
edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR
already in memory it can
Am 30.09.20 um 10:05 schrieb Gerd Hoffmann:
>> So sending the requests to all available DNS servers in absence of
>> better routing info is a great enabler:
> I fail to see why sending queries to all servers is a good plan. The
> redhat vpn dns servers surely can't resolve the hostnames for my loc
On Wed, 30 Sep 2020 10:14:55 +0200, Jakub Jelinek wrote:
> it would be great if the
> .debug_names some tool generates (whether it is GDB, some standalone
> post-linking (and post dwz) tool, dwz itself, ...) is usable by both GDB and
> LLDB, because the point in DWARF5 standardizing .debug_names wa
On Wed, Sep 30, 2020 at 10:32:28AM +0200, Ondřej Lysoněk wrote:
> Zbigniew Jędrzejewski-Szmek writes:
>
> > On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk wrote:
> >> > Hi,
> >> >
> >> > I'm coordinating
On Wed, Sep 30, 2020 at 10:33:59AM +0200, Jan Kratochvil wrote:
> On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote:
> > Why don't you add an lldb-add-index tool to generate LLVM indexes for
> > LLDB?
>
> Because doing it separately like GDB does is a wrong thing for
> edit-compile-debug cycle.
On Wed, 30 Sep 2020 02:00:52 +0200, Michel Alexandre Salim wrote:
> On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
> > Currently the change will affect only packages using:
> > %global toolchain clang
> > Those are currently only
Zbigniew Jędrzejewski-Szmek writes:
> On Wed, Sep 30, 2020 at 10:32:28AM +0200, Ondřej Lysoněk wrote:
>> Zbigniew Jędrzejewski-Szmek writes:
>>
>> > On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek
>> > wrote:
>> >> On Tue, Sep 29, 2020 at 05:04:12PM +0200, Ondřej Lysoněk
On Wed, 30 Sep 2020 10:44:06 +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 10:33:59AM +0200, Jan Kratochvil wrote:
> > Because doing it separately like GDB does is a wrong thing for
> > edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR
> > already in memory it can
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-32-20200929.0):
ID: 681208 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproj
On Wed, Sep 30, 2020 at 11:06:44AM +0200, Jan Kratochvil wrote:
> > That is why the index should be added by linkers or post-link tools.
>
> This is how slow GNU Toolchain does that. LLVM has learned from those
> mistakes.
Can you please stop this? If you think everything LLVM does is great and
On Tue, Sep 29, 2020 at 09:56:22PM -, Artur Frenszek-Iwicki wrote:
> I maintain two Rust packages, rust-copydeps [1] and rust-desed [2]. Both
> were built for F33 ([3], [4]) before it branched off for Rawhide (and
> submitted to bodhi ([5], [6])). I gave the F33 beta a spin and when I tried
> "
On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> But the GCC community
> doesn't really test that option and it's known to be broken with LTO.
I haven't seen any GCC PR for -fdebug-types-section being broken with LTO.
During one abigail diff I did not see any difference. I plan to run a full
On Wed, Sep 30, 2020 at 11:43 AM Petr Pisar wrote:
>
> On Tue, Sep 29, 2020 at 09:56:22PM -, Artur Frenszek-Iwicki wrote:
> > I maintain two Rust packages, rust-copydeps [1] and rust-desed [2]. Both
> > were built for F33 ([3], [4]) before it branched off for Rawhide (and
> > submitted to bodh
Hi, this was during the branching. Looking into releng scripts[1] we are
skipping rust-* packages.
[ 1 ] -
https://pagure.io/releng/blob/master/f/scripts/pdc/create-new-release-branches.py#_60
On Wed, Sep 30, 2020 at 11:43 AM Petr Pisar wrote:
> On Tue, Sep 29, 2020 at 09:56:22PM -, Artur
OLD: Fedora-Rawhide-20200928.n.0
NEW: Fedora-Rawhide-20200930.n.0
= SUMMARY =
Added images:8
Dropped images: 2
Added packages: 32
Dropped packages:2
Upgraded packages: 185
Downgraded packages: 0
Size of added packages: 308.54 MiB
Size of dropped packages
Hi,
I am sorry if this has been discussed before but I do not remember it.
The culprit to this message was the review of R-pak
https://bugzilla.redhat.com/show_bug.cgi?id=1883047
While running fedora-review that uses mock I found that I had an issue
installing the corresponding rpm in rawhide.
Missing expected images:
Xfce raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 12/181 (x86_64)
New failures (same test not failed in Fedora-Rawhide-202
On Wed, Sep 30, 2020 at 12:55 PM José Abílio Matos wrote:
>
> Hi,
>
> I am sorry if this has been discussed before but I do not remember it.
>
>
> The culprit to this message was the review of R-pak
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1883047
>
>
> While running fedora-review that us
On Fri, 25 Sep 2020 16:29:26 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > I would love to see a comparison of numbers for three things:
> > - raw debuginfo without dwz or -fdebug-types-section
>
> Oops, I do not have this number, I can r
Neal Gompa wrote:
> On Tue, Sep 29, 2020 at 7:48 AM Björn Persson wrote:
> >
> > Lennart Poettering wrote:
> > > On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> > >
> > > > It can work in company-scope if the company has competent network
> > > > admins. My local DNS server
On Wed, Sep 30, 2020 at 11:00:46AM +0200, Ondřej Lysoněk wrote:
> Zbigniew Jędrzejewski-Szmek writes:
>
> > On Wed, Sep 30, 2020 at 10:32:28AM +0200, Ondřej Lysoněk wrote:
> >> Zbigniew Jędrzejewski-Szmek writes:
> >>
> >> > On Tue, Sep 29, 2020 at 06:46:49PM +, Zbigniew Jędrzejewski-Szmek
On Wed, Sep 30, 2020 at 01:39:15PM +0200, Fabio Valentini wrote:
> On Wed, Sep 30, 2020 at 12:55 PM José Abílio Matos wrote:
> >
> > Hi,
> >
> > I am sorry if this has been discussed before but I do not remember it.
> >
> >
> > The culprit to this message was the review of R-pak
> >
> > https://
Hello.
I've just orphaned my package python-pytest-spec. Nothing in Fedora
depends on it.
Have a nice day.
Lumír
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code
On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> -fdebug-types-section a supported option in the sense that it's in the
> compiler and we'll fix bugs in it when we can. But the GCC community
> doesn't really test that option and it's known to be broken with LTO.
I believe you base this infor
Hi,
This is a non-responsive maintainer check for ichavero, in accordance
with
policy [0].
I submitted 2 bugs [1][2] related to outdated nextcloud versions
containing multiple (moderate) CVEs [3] about a month ago, but have not
had any response. nextcloud has a huge number of open bugs [4],
On Tue, 29 Sep 2020 22:35:14 +0200, Mark Wielaard wrote:
> On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote:
> > * DW_TAG_partial_unit should have DW_AT_language.
> > * DW_TAG_partial_unit must contain only types (struct/class).
> >Currently they contain for example also static
Hi Neal,
On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote:
> For the record, Mark has started implementing DWARF-5 support in dwz:
> https://sourceware.org/git/?p=dwz.git;a=log
>
> I think I would rather like to see a Change proposal to switch to
> DWARF-5 for Fedora 34, especially since it lo
On Wednesday, September 30, 2020 12:39:15 PM WEST Fabio Valentini wrote:
> If anything, this is a bug in the R-rprojroot package, because version
> 1.3.2 provides: "R(rprojroot) = 1.3-2", which is smaller than 1.3.2,
> and hence is not enough for >= 1.3.2.
Thank you Fabio. Since this is done autom
On Wednesday, September 30, 2020 1:19:51 PM WEST Pierre-Yves Chibon wrote:
> It actually queries bodhi and failing to find things in it, it fallsback to
> mdapi normally.
> Potential bug in the logic?
I noticed it before, since at least June, in other packages so I would say
yes.
--
José Abílio
Hi, in accordance with
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
this is a Non-responsive maintainer check for James Hogarth.
Non-responsive bug: https://bugzilla.redhat.com/show_bug.cgi?id=1883892
Unactioned bugs (CVEs from 2019, oldest from 2017):
On 29 Sep 2020, at 23:44, Michael Catanzaro wrote:
> This is either a very strange misunderstanding, or trolling. I will assume
> positive intent. Internet RFCs are not regulatory requirements. If you're
> aware of some government regulation that requires us to forward RRSEC
> records, I would
On Wednesday, September 30, 2020 1:19:51 PM WEST Pierre-Yves Chibon wrote:
> It actually queries bodhi and failing to find things in it, it fallsback to
> mdapi normally.
> Potential bug in the logic?
Another example:
https://src.fedoraproject.org/rpms/texlive
--
José Abílio_
On Tue, 29 Sep 2020 22:31:28 +0200, Mark Wielaard wrote:
> Note that you are using -ffunction-sections together with -flto.
> With -flto you don't need -ffunction-sections.
>
> -ffunction sections might cause functions to be dropped by the linker
> without updating the DWARF DIEs, causing things l
On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote:
> So we're at a point where the F33 FTBFS issues related to LTO that I'm aware
> of
have been resolved (by opting the package out of LTO). I still expect
> some LTO issues will pop up as packages fix things like missing
> dependencies, cma
On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote:
> = What I am NOT working on
[...]
> - Any other tool, project not mentioned above or other
> native toolchains like golang, rust, clang/llvm or ocaml.
> I expect those to simply keep producing DWARF4.
So because of a DWZ deficiency you
On Wed, 30 Sep 2020 at 15:19, José Abílio Matos wrote:
>
> On Wednesday, September 30, 2020 12:39:15 PM WEST Fabio Valentini wrote:
>
> > If anything, this is a bug in the R-rprojroot package, because version
> > 1.3.2 provides: "R(rprojroot) = 1.3-2", which is smaller than 1.3.2,
> > and hence is
On Wed, Sep 30, 2020 at 03:14:10PM +0200, Graham Leggett wrote:
> I am required by these regulations and many other regulations in
> multiple jurisdictions to make sure my users comply. If you have gone
> out of your way to break secure operation on Fedora, we will have to
> ban the use of Fedor
On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil
wrote:
> On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote:
> > = What I am NOT working on
> [...]
> > - Any other tool, project not mentioned above or other
> > native toolchains like golang, rust, clang/llvm or ocaml.
> > I expect those to
On 9/30/20 7:39 AM, Robert-André Mauchin wrote:
On Tuesday, 18 August 2020 17:12:02 CEST Jeff Law wrote:
So we're at a point where the F33 FTBFS issues related to LTO that I'm aware
of
have been resolved (by opting the package out of LTO). I still expect
some LTO issues will pop up as pac
=
#fedora-meeting-2: FESCO (2020-09-30)
=
Meeting started by mhroncok at 14:00:01 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-09-30/fesco.2020-09-30-14.00.log.html
.
Meeting
On Wed, Sep 30, 2020 at 3:14 pm, Graham Leggett
wrote:
Regulations like the GDPR exist, and ignorance of them is not a
defence.
I am required by these regulations and many other regulations in
multiple jurisdictions to make sure my users comply. If you have gone
out of your way to break se
On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz wrote:
>
> Hi,
>
> the livecds from F32 and F33 are suffering from a problem not booting on
> Microsoft device(s)
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1879921
> https://bugzilla.redhat.com/show_bug.cgi?id=1883593
>
> F31 is booting fine, th
On Wed, Sep 30, 2020 at 10:05 am, Gerd Hoffmann
wrote:
Sorry, but that is not correct.
NetworkManager can handle split-dns just fine, by using dnsmasq and
reconfiguring it via dbus when vpn connections come and go. I can
easily add more servers + zones by dropping a config file snippet into
I pushed the following to fix build of sems:
https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master
Not my package, and the code is a bit iffy, so it's quite likely that
the problem is in the package... Just letting you know in case you're still
looking for
On 9/30/20 9:25 AM, Zbigniew Jędrzejewski-Szmek wrote:
I pushed the following to fix build of sems:
https://src.fedoraproject.org/rpms/sems/c/beef747b4641429459065bd39dbea447405f33e9?branch=master
Not my package, and the code is a bit iffy, so it's quite likely that
the problem is in the package
On 9/29/20 5:59 PM, Neal Gompa wrote:
I feel like it's worth giving my perspective here as someone who has
done similar work in other distributions.
Thanks for that viewpoint. As a compiler optimizer junkie, I don't
really follow things on the RPM side, so hearing about that process has
On 9/30/20 6:50 AM, Mark Wielaard wrote:
Hi Neal,
On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote:
For the record, Mark has started implementing DWARF-5 support in dwz:
https://sourceware.org/git/?p=dwz.git;a=log
I think I would rather like to see a Change proposal to switch to
DWARF-5 fo
On 9/30/2020 8:17 AM, Chris Murphy wrote:
> On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz wrote:
>> Hi,
>>
>> the livecds from F32 and F33 are suffering from a problem not booting on
>> Microsoft device(s)
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1879921
>> https://bugzilla.redhat.com/sh
On Wed, Sep 30, 2020 at 02:15:34PM +0100, José Abílio Matos wrote:
> On Wednesday, September 30, 2020 1:19:51 PM WEST Pierre-Yves Chibon wrote:
> > It actually queries bodhi and failing to find things in it, it fallsback to
> > mdapi normally.
> > Potential bug in the logic?
>
> Another example:
>
On 9/30/20 2:33 AM, Jan Kratochvil wrote:
On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote:
Why don't you add an lldb-add-index tool to generate LLVM indexes for
LLDB?
Because doing it separately like GDB does is a wrong thing for
edit-compile-debug cycle. When clang (lld for LTO) has all
On 9/30/20 2:56 AM, Jan Kratochvil wrote:
On Wed, 30 Sep 2020 02:00:52 +0200, Michel Alexandre Salim wrote:
On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
Currently the change will affect only packages using:
%global toolchain c
Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^
is.
What _is_ clear is that there's significant disagreement -- which,
unfortunately, has at times here become nasty & personal -- about needed vs
planned functionality, and, of late, regulatory compliance.
And, iiuc
On Wed, Sep 30, 2020 at 12:15 PM PGNet Dev wrote:
>
> Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^
> is.
>
> What _is_ clear is that there's significant disagreement -- which,
> unfortunately, has at times here become nasty & personal -- about needed vs
> planne
On 30.09.2020 15:39, Robert-André Mauchin wrote:
> I have an issue with both Clementine and Strawberry (a fork of Clementine)
> in F33 and above, users reported that disabling LTO fixes the problem.
I have the same issue with Telegram Desktop:
https://bugzilla.redhat.com/show_bug.cgi?id=1880290
On 9/30/20 9:16 AM, Neal Gompa wrote:
> If you're not using NetworkManager, this change has _zero_ impact.
perfect.
clearly, i've missed or lost the obviousness of that incredibly useful tidbit
in this novella :-/
thx!
___
devel mailing list -- devel@
Hi,
the systemd package is getting a systemd-networkd subpackage split out
that will contain systemd-networkd, networkctl, and the associated data files.
This was requested by coreos maintainers: NetworkManager is used and skipping
systemd-networkd allows the installation footprint and potential u
Hi Zbyszek,
Would it make sense to do the same for systemd-resolved ?
Sounds like it has similar impact/scope wrt coreos.
On Wed, 2020-09-30 at 16:26 +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> the systemd package is getting a systemd-networkd subpackage split out
> that will contain syst
On Wednesday, 30 September 2020 at 18:16, Neal Gompa wrote:
[...]
> If you're not using NetworkManager, this change has _zero_ impact.
What if I'm using NetworkManager and dnssec-trigger? This has been
working very well for me for the last couple of releases and I'd hate
to be forced to manually r
On Wed, 30 Sep 2020 at 11:54, Erich Eickmeyer
wrote:
> On 9/30/2020 8:17 AM, Chris Murphy wrote:
> > On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz
> wrote:
> >> Hi,
> >>
> >> the livecds from F32 and F33 are suffering from a problem not booting on
> >> Microsoft device(s)
> >>
> >> https://bugz
> Hi Zbyszek,
> Would it make sense to do the same for systemd-resolved ?
> Sounds like it has similar impact/scope wrt coreos.
Yes please, I would like this for Edge/IoT too (both network/resolved)
as there are use cases there where we'd like not to ship these too.
Peter
> On Wed, 2020-09-30 at
On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski
wrote:
What if I'm using NetworkManager and dnssec-trigger? This has been
working very well for me for the last couple of releases and I'd hate
to be forced to manually reconfigure things so that it starts working
again.
The upgra
On 30. 09. 20 18:26, Zbigniew Jędrzejewski-Szmek wrote:
The main systemd systemd package Obsoletes the -standalone- packages, so it
should smoothly replace them whenever it is pulled in.
I am confused by this bit. If systemd package Obsoletes the -standalone-
packages, installing them is not p
On 9/30/20 9:50 AM, Michael Catanzaro wrote:
> You'll need to manually disable systemd-resolved after upgrade, restore
> /etc/resolv.conf from the backup file that will be created during upgrade
So the upgrade WILL ignore current F32 state -- systemd-resolved DISABLED +
'my' /etc/resolv.conf -- a
On Wed, Sep 30, 2020 at 06:50:08PM +0200, Miro Hrončok wrote:
> >The main systemd systemd package Obsoletes the -standalone- packages, so it
> >should smoothly replace them whenever it is pulled in.
>
> I am confused by this bit. If systemd package Obsoletes the
> -standalone- packages, installing
On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev wrote:
So the upgrade WILL ignore current F32 state -- systemd-resolved
DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite
(respectively) each, regardless of whether we're _using_
NetworkManager (afaict it's impossible to completely remove all
On 9/11/20 5:07 PM, Kevin Fenzi wrote:
> On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote:
>> This release:
>>
>> https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b
>>
>> has been stuck waiting to get moved to stable. Is some error going on
>> that isn't evident?
>
> We ar
On Wed, Sep 30, 2020 at 7:48 PM Tony Asleson wrote:
> On 9/11/20 5:07 PM, Kevin Fenzi wrote:
> > On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote:
> >> This release:
> >>
> >> https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b
> >>
> >> has been stuck waiting to get moved
On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
the systemd package is getting a systemd-networkd subpackage split out
that will contain systemd-networkd, networkctl, and the associated data files.
This was requested by coreos maintainers: NetworkManager is used and skipping
systemd-netw
On 9/30/20 11:21 AM, Paul Wouters wrote:
> It also allows those Destop users that want to use their own validating
> resolvers on the end node to uninstall systemd-resolved.
Would separating the package preserve existing setups across upgrades?
It's not simply Enterprise/Server 'or' Desktops that
On Wed, Sep 30, 2020 at 12:48 PM Peter Robinson wrote:
>
> > Hi Zbyszek,
> > Would it make sense to do the same for systemd-resolved ?
> > Sounds like it has similar impact/scope wrt coreos.
>
> Yes please, I would like this for Edge/IoT too (both network/resolved)
> as there are use cases there w
On Wed, Sep 30, 2020 at 12:45:40PM -0400, Stephen John Smoogen wrote:
> The Fedora secure boot signing keys were updated after F32 was initially
> released to deal with the grub2 problems found during the summer. I believe
> some systems have needed firmware updates from the manufacturer to work
>
On 9/30/20 1:35 PM, Neal Gompa wrote:
Please, no more package splitting. And NetworkManager is used across
all variants of Fedora, so resolved should be installed in all places
where NetworkManager is used.
And what about places where NetworkManager isn't used? (Just because
it's the default,
FYI: No need to cc me on list posts. I'm subscribed and read all the
list posts. ;)
On Wed, Sep 30, 2020 at 08:05:09PM +0200, Kalev Lember wrote:
...snip...
>
> The older build was tagged over the new one because Kevin ran a fixup
> script to find packages where Bodhi accidentally pushed an olde
On 9/30/20 1:05 PM, Kalev Lember wrote:
> On Wed, Sep 30, 2020 at 7:48 PM Tony Asleson wrote:
>
>> On 9/11/20 5:07 PM, Kevin Fenzi wrote:
>>> On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote:
This release:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b
>
On 30. 09. 20 21:12, Tony Asleson wrote:
On 9/30/20 1:05 PM, Kalev Lember wrote:
On Wed, Sep 30, 2020 at 7:48 PM Tony Asleson wrote:
On 9/11/20 5:07 PM, Kevin Fenzi wrote:
On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote:
This release:
https://bodhi.fedoraproject.org/updates/FE
On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher
wrote:
And what about places where NetworkManager isn't used? (Just because
it's the default, doesn't mean that it's used everywhere.)
NetworkManager is used everywhere by default. If you want to disable
it, you have to do manual work to do that.
On Wed, Sep 30, 2020 at 9:18 PM Miro Hrončok wrote:
> On 30. 09. 20 21:12, Tony Asleson wrote:
> > On 9/30/20 1:05 PM, Kalev Lember wrote:
> >> Looks like your update briefly made it stable, but then the older build
> >> (pywbem-1.0.1-1.fc33) was tagged back over the new one
> >> (pywbem-0.14.6-6
On Wednesday, September 30, 2020 2:45:28 PM WEST Iñaki Ucar wrote:
> The thing is that R(package) is meant to provide the original
> versioning (which allows hyphens and stuff), while R-package takes the
> adaptation to our versioning system. The problem is that we generally
> declare dependencies
On 9/30/20 2:19 PM, Michael Catanzaro wrote:
On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote:
And what about places where NetworkManager isn't used? (Just because
it's the default, doesn't mean that it's used everywhere.)
NetworkManager is used everywhere by default. If you want to disabl
On 9/30/20 7:11 PM, Michael Catanzaro wrote:
> On Wed, Sep 30, 2020 at 9:54 am, PGNet Dev wrote:
>> So the upgrade WILL ignore current F32 state -- systemd-resolved
>> DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite
>> (respectively) each, regardless of whether we're _using_
>> Networ
On Wed, Sep 30, 2020 at 9:58 pm, Petr Menšík
wrote:
Shouldn't it change resolv.conf only in case NM is active AND
resolv.conf is generated by Network Manager?
Correct, that's indeed what it does. (Since Zbigniew changed it
yesterday. Previously, it did not check if NM is active.)
The system
Am 30.09.20 um 17:17 schrieb Chris Murphy:
>
> That suggests the scary region of firmware, hybrid ISO, shim, and boot loader.
>
> The bug reports have the wrong component set on them, and aren't
> discrete actionable bug reports. It's just saying "this doesn't work"
which one do you suggest?
>> An
Am 30.09.20 um 18:45 schrieb Stephen John Smoogen:
>
>
>
> The Fedora secure boot signing keys were updated after F32 was
> initially released to deal with the grub2 problems found during the
> summer. I believe some systems have needed firmware updates from the
> manufacturer to work with the new
Am 30.09.20 um 20:54 schrieb Brian C. Lane:
> On Wed, Sep 30, 2020 at 12:45:40PM -0400, Stephen John Smoogen wrote:
>> The Fedora secure boot signing keys were updated after F32 was initially
>> released to deal with the grub2 problems found during the summer. I believe
>> some systems have needed
On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote:
>
> On 9/30/20 2:19 PM, Michael Catanzaro wrote:
> > On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote:
> >> And what about places where NetworkManager isn't used? (Just because
> >> it's the default, doesn't mean that it's used everywhere.)
>
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote:
> With enterprise server deployments, DNS will be managed by the network
> via resolve.conf to enterprise DNS servers. These servers tend to have
> "bind views" for different category of deployments. These deployments
> will have no VPN,
On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote:
> Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
(rpm)ostree variants are Fedora variants - please don't using phrasing implying
otherwise.
IOW you just say: *all* Fedora variants use NetworkManager.
_
On Wed, Sep 30, 2020 at 4:29 PM Colin Walters wrote:
>
>
>
> On Wed, Sep 30, 2020, at 4:26 PM, Neal Gompa wrote:
>
> > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
>
> (rpm)ostree variants are Fedora variants - please don't using phrasing
> implying otherwise.
>
> IOW you just
On Wed, Sep 30, 2020 at 02:21:19PM -0400, Paul Wouters wrote:
> On Wed, 30 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
>
> >the systemd package is getting a systemd-networkd subpackage split out
> >that will contain systemd-networkd, networkctl, and the associated data
> >files.
> >This was requ
On Wed, Sep 30, 2020 at 09:27:33PM +0200, Kalev Lember wrote:
>
> Ahh, sure, if the previous package was uninstallable then it should be fine
> to not use epoch.
I suppose...
> So two options here: a) file a releng ticket (
> https://pagure.io/releng/issues) and ask them to re-tag the other bui
On 9/30/2020 1:26 PM, Neal Gompa wrote:
On Wed, Sep 30, 2020 at 3:42 PM Ian Pilcher wrote:
On 9/30/20 2:19 PM, Michael Catanzaro wrote:
On Wed, Sep 30, 2020 at 2:00 pm, Ian Pilcher wrote:
And what about places where NetworkManager isn't used? (Just because
it's the default, doesn't mean tha
anyone else more confused?
On 9/30/20 1:26 PM, Neal Gompa wrote:
> And like it or not, all our legacy network configuration mechanisms
> are deprecated and*will be removed eventually*.
is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct
dependency on systemd-resolved -- c
Am 30.09.20 um 18:45 schrieb Stephen John Smoogen:
>
> The Fedora secure boot signing keys were updated after F32 was
> initially released to deal with the grub2 problems found during the
> summer. I believe some systems have needed firmware updates from the
> manufacturer to work with the new key
On 9/30/20 3:37 PM, Kevin Fenzi wrote:
> On Wed, Sep 30, 2020 at 09:27:33PM +0200, Kalev Lember wrote:
>>
>> Ahh, sure, if the previous package was uninstallable then it should be fine
>> to not use epoch.
>
> I suppose...
>
>> So two options here: a) file a releng ticket (
>> https://pagure.io/
1 - 100 of 129 matches
Mail list logo
