Hello.
I've upgraded to Fedora 33 beta and I've discovered a problem with
Thunderbird. All email accounts work well except the Red Hat one with
mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
The problem is that Thunderbird does not show any error message but it's
On 9/30/20 10:28 PM, Elliott Sales de Andrade wrote:
On Wed, 30 Sep 2020 at 18:27, Marius Schwarz wrote:
The working/non-working procedure is:
Power on
...
inserting the stick
OK, but why insert the USB stick after power on?
Wouldn't it be less trouble to insert beforehand so that the
On Wed, 30 Sep 2020 at 18:27, Marius Schwarz wrote:
>
> 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
On Wed, Sep 30, 2020 at 4:22 PM Marius Schwarz wrote:
>
> 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
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 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 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
https://fedorapeople.org/groups/389ds/ci/nightly/2020/10/01/report-389-ds-base-1.4.4.4-20200930gitf6799c2.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
The following Fedora EPEL 8 Security updates need testing:
Age URL
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-11f765300e
singularity-3.6.3-1.el8
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-17fdec3133
zeromq-4.3.3-1.el8
5
The following Fedora EPEL 7 Security updates need testing:
Age URL
25 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83bdeb2965
ansible-2.9.13-1.el7
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-92064b5b2b
singularity-3.6.3-1.el7
6
https://github.com/389ds/389-ds-base/pull/4354
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
https://bugzilla.redhat.com/show_bug.cgi?id=1882837
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=1882958
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #3 from
https://github.com/389ds/389-ds-base/pull/4353
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
https://github.com/389ds/389-ds-base/pull/4352
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
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
https://bugzilla.redhat.com/show_bug.cgi?id=1880857
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Module-CoreList-5.2020 |perl-Module-CoreList-5.2020
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 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 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
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
>
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 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 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
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 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
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 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, 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 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 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.
>
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 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 --
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
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 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 (
>>
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
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 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
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 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 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 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 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.)
>
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
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 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 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
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_
>>
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
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 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 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 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 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
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
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 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 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
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
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 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/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
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 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 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 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1883959
Bug ID: 1883959
Summary: perl-File-Listing-6.07 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-File-Listing
Keywords: FutureFeature, Triaged
> 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 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)
> >>
> >>
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.
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
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
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 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 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
>
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,
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 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 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/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 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
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 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
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
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
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,
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
=
#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
.
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, 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 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
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, 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 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 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
1 - 100 of 144 matches
Mail list logo
