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
> >
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
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
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
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
* 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
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
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
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
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
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
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
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
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:
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
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
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
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
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 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
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
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
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
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 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
>
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
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 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
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
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
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
> >
> >
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, 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 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é
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
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é
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
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,
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
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
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,
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
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
> 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
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
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
> >>
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
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.
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 --
On Mon, 2020-09-28 at 16:50 +0200, Jan Kratochvil wrote:
>
> For example during Fedora Package Review Process do some packages get
> rejected
> because they would make the distribution too large? Not worth of
> including
> such new package? I am not aware of such decision and it even sounds
>
On 9/30/20 2:34 PM, Paul Wouters wrote:
> And as I indicated earlier, most server installs have no use for
> systemd-resolved. Yes it can be disabled, but we didn't go all the
> way to virtual servers and containers to have to install things
> we will never use.
+1, & simply 'minimal' installs
Am 30.09.20 um 23:00 schrieb Chris Murphy:
>
>
> And then these are current
> grub2-efi-x64-2.04-31.fc33.x86_64
> grub2-efi-x64-2.04-23.fc32.x86_64
> grub2-efi-x64-2.02-110.fc31.x86_64
>
> I wonder if the affected hardware is adversely affected by all three
> of these versions of GRUB?
>
I made
On Wed, 30 Sep 2020 at 17:42, Marius Schwarz wrote:
>
> Am 30.09.20 um 23:00 schrieb Chris Murphy:
> >
> >
> > And then these are current
> > grub2-efi-x64-2.04-31.fc33.x86_64
> > grub2-efi-x64-2.04-23.fc32.x86_64
> > grub2-efi-x64-2.02-110.fc31.x86_64
> >
> > I wonder if the affected hardware is
On Wed, Sep 30, 2020, at 4:17 PM, Michael Catanzaro wrote:
> 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
On 9/30/20 7:14 PM, Colin Walters wrote:
That's not true, you can `rpm-ostree override remove`. It'd still be
there in the ostree repository on disk, but you don't see it in the
"deployment" (what you actually boot into). Few people care about
disk space that much, and if you do you can do
On Wed, 30 Sep 2020, Neal Gompa wrote:
since it's only a
couple of binaries averaging 2MB with a few unit files.
My reply was aimed at Peter saying he'd like to not ship resolved, and
I'm saying that we should *not* do that, because it makes things even
harder and more complicated.
These
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
On Wed, Sep 30, 2020 at 11:49 pm, Björn Persson
wrote:
So there's no need to revert any changes to /etc/nsswitch.conf? I've
seen some discussion about that file in relation to systemd-resolved.
It seemed far from easy to understand how to make it work correctly.
You don't have to touch
Am 01.10.20 um 00:02 schrieb Chris Murphy:
>> I made some more tests. It's a race, 1 out of 10 tries succeeds and the
>> chance that it does is improoved by inserting the usb drive while being
>> in the bios.
>>
>> The F31 grub files i exchanged do not seem to have something to do with it.
> The
On Tuesday, September 29, 2020 9:36:38 AM MST Dan Williams wrote:
> On Tue, 2020-09-29 at 09:18 -0700, John M. Harris Jr wrote:
>
> > On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-
> > Szmek
> > wrote:
> >
> > > On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr
On Wed, Sep 30, 2020 at 4:45 PM PGNet Dev wrote:
>
> 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
On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller wrote:
>
> On Wed, Sep 30, 2020 at 04:32:07PM -0400, Neal Gompa wrote:
> > > > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree
> > > (rpm)ostree variants are Fedora variants - please don't using phrasing
> > > implying otherwise.
>
On 30. 09. 20 22:54, Tony Asleson wrote:
I posed the question on IRC if this fix-up script gets run after freeze
and the answer was it could. I don't want to get caught with this
again, so I'm in the process of adding epoch and rolling new releases
across the board as it seems like the safest
On Wed, Sep 30, 2020 at 7:34 pm, Colin Walters
wrote:
I know this is already an epic thread but, just a FYI: This
type of thing will completely not work on an rpm-ostree based
system because the %post is run server side. It can't compute
anything based on per-user data (and that's *also*
On 9/30/20 4:36 PM, Neal Gompa wrote:
On Wed, Sep 30, 2020 at 5:27 PM Matthew Miller wrote:
"All Fedora variants, both with ostree and without..." maybe? OSTree-based
variants are also "regular Fedora".
I would only even remotely consider agreeing with that premise for
Silverblue. Neither
On Wed, Sep 30, 2020 at 04:32:07PM -0400, 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.
>
Am 01.10.20 um 00:19 schrieb Elliott Sales de Andrade:
>> Could it be a timing issue of some kind?
>>
>> the sooner i hit the boot from usb button, after the stick got inserted,
>> the higher is the propability to start.
>>
> Are you saying you insert the USB stick _after_ turning on the
>
On Wed, Sep 30, 2020 at 01:45:13PM -0700, PGNet Dev wrote:
> 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 --
Michael Catanzaro wrote:
> 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
On Wed, Sep 30, 2020 at 3:42 PM Marius Schwarz wrote:
>
> Am 30.09.20 um 23:00 schrieb Chris Murphy:
> >
> >
> > And then these are current
> > grub2-efi-x64-2.04-31.fc33.x86_64
> > grub2-efi-x64-2.04-23.fc32.x86_64
> > grub2-efi-x64-2.02-110.fc31.x86_64
> >
> > I wonder if the affected hardware
On Wed, Sep 30, 2020, at 5:20 PM, Neal Gompa wrote:
> Regular Fedora variants are installed via normal package management
> actions and have full granularity. RPM-OSTree reduces the granularity
> of the operating system to a singular image that you layer on top. But
> you cannot pull out stuff
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
>>
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
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
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 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
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 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 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,
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:
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 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
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
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 (
>>
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,
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 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 --
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 --
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
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
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
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
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 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 Wed, Sep 30, 2020 at 12:59:20PM -0400, Matthew Miller wrote:
> 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
On Wed, Sep 30, 2020 at 10:46 AM 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
with the
1 - 100 of 144 matches
Mail list logo
