Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Florian Weimer
* Zbigniew Jędrzejewski-Szmek:

> https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
> in this particular case.

I looked at this extensively a couple of months ago.  There is also an
ICANN recommendation along similar lines, but focusing more on stub
resolver configuration and search path processing, which is a better fit
for systemd-resolved.

The feedback I received from subject matter experts is that complying
with these ICANN recommendations (for search path processing) would
break about 60% of all deployed Kubernetes clusters (and not just inside
containers).  I think some people have since started on updating
Kubernetes practices and recommendations, but I expect that it will be a
few more months until we see first effects.

I don't know if the systemd developers have conducted similar research
before implementing their stub resolver behavior, and why they have
reached opposite conclusions.

One problem with DNS is that you cannot take the standards and official
recommendations and use them as a reference for a new DNS
implementation.  Many of the specifications are very old, some are quite
poor, several of the sub-protocols are very badly designed (like using
timeouts for protocol version negotiation; obviously that one never made
it into an RFC, but was still widely deployed), and the entire space is
extremely politicized.  Not just by governments, but also by groups of
individuals who for some reason cannot get along at all.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-29 Thread Florian Weimer
* Michael Catanzaro:

> Of course, this problem is avoidable by unchecking "use this
> connection only for resources on its network" if you use only one
> VPN. And failing that: at least the situation is not worse than it was
> before.

Have you actually tried this with a corporate VPN recently?

It requires that the VPN is actually able to route general Internet
traffic for you.  At present, I don't think this is a reasonable
assumption.

I think the workaround you are suggesting is not available to most
users.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Florian Weimer
* Andrew Lutomirski:

> Paul may well have been mixing different things here, but I don't
> think you answered the one that seems like the most severe problem:
> systemd-resolved removed perfectly valid DNSSEC records that were
> supplied by the upstream server.  One might reasonably debate whether
> Fedora's default DNS resolver configuration should validate DNSSEC,
> but I think it should honor the DO bit in client requests and return
> DNSSEC data.

FWIW, this is .

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Florian Weimer
* Michael Catanzaro:

> I don't think it would be smart for employees to voluntarily opt-in to
> sending all DNS to their employer anyway... there's little benefit to 
> the employee, and a lot of downside. Importantly, if you're looking in
> your network settings and you see a checkbox that says "Use this 
> connection only for resources on its network," a reasonable user
> *expects* that the connection will *really* only be used for resources 
> on its network, not that it will be used for everything except DNS,
> which randomly goes to who knows where depending on what else you're 
> connected to. Our design must try to avoid this failure case: "Sadly
> for Distrustful Denise, her employer discovers that she has been
> making some embarrassing DNS requests that she had expected to go
> through public-vpn.example.com instead."

Eh, for a corporate laptop (which is not physically connected to the
corporate network due to present circumstances), I do expect that DNS is
handled by the corporate DNS servers.  I would also like to route all
network traffic over the corporate VPN, but as I tried to explain, that
is just not feasible at the moment.  I also don't see how this is a
trust issue for a *corporate* laptop used for work purposes.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Florian Weimer
* Michael Catanzaro:

> On Mon, Sep 28, 2020 at 5:18 pm, Florian Weimer 
> wrote:
>> But the DNS view provided by the Red Hat VPN is what disables the
>> centralized DNS resolvers in browsers in these configurations.  The
>> magic browser probe no longer fails with the change in DNS routing
>> (which the proposal confusingly names “Split DNS”) because it goes
>> out over the public Internet, where it is not filtered, unlike the
>> Red Hat VPN.
>
> Hm, I'm pretty sure this is a Firefox-specific issue, right? Fedora's
> Firefox is patched to use system DNS, so it shouldn't matter for us. 
> I'm not aware of any other browser that ignores system DNS; at least,
> I'm fairly certain Chrome and Epiphany will both never do this.

It seems that you are right about Chromium:

| We have no plans to support this approach. We believe that our
| deployment model is significantly different from Mozilla's, and as a
| result canary domains won't be needed.

<https://www.chromium.org/developers/dns-over-https>

However, you wrote earlier that “split DNS” is not available over
nss_dns, so I think Chromium is still impacted because it uses the same
interfaces that nss_dns would use in this mode (i.e., not nss_resolve).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Florian Weimer
* Michael Catanzaro:

> "Fedora 33 uses systemd-resolved for name resolution. Most users will
> not notice any difference, but VPN users will benefit from safer 
> defaults that ensure DNS requests are sent to the same network that
> would receive the corresponding traffic, avoiding unexpected DNS leaks 
> or failure to resolve internal domains."

I think this is rather misleading.

* The change disables protection mechanisms built into corporate VPNs
  that require them to observe all DNS traffic.  Now this may sound
  rather weak as far as countermeasures go, but DNS-based mechanisms are
  the only thing you have got if you do not enforce a client-side
  approach (ugh, no thanks), or disable split tunneling (i.e., default
  route over the VPN; frequently not possible with current VPN usage
  levels and virtual company meetings over video link).

* There is no real protocol for sharing internal domains, so
  systemd-resolved cannot know all of them, and resolving some of them
  will fail or receive unexpected resolution results (probably
  observable for some jboss.org subdomains for Red Hatters, but I don't
  work in that area, so I don't have a good example at hand).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Florian Weimer
* Michael Catanzaro:

> On Mon, Sep 28, 2020 at 4:39 pm, Florian Weimer 
> wrote:
>> My understanding is that the DNS request routing in systemd-resolved
>> effectively disables any security mechanisms on the VPN side, and
>> instructs most current browsers to route DNS requests to centralized
>> DNS
>> servers for all requests (i.e., overriding what came from both the VPN
>> and DHCP).
>
> No... certainly not. Previously, VPNs only worked properly if you have
> exactly one VPN, and it's configured to receive all traffic. Using a 
> VPN that receives traffic only for resources on its network, or using
> multiple VPNs at once, would result in DNS leaks. In fact, making VPNs 
> work properly is the *only* reason I'm involved in this. I was
> frustrated to see that Fedora sometimes sent my requests for internal 
> Red Hat resources to my public VPN's DNS server instead of Red Hat's
> DNS servers. See [1] for a comparison between previous and new
> behavior.

But the DNS view provided by the Red Hat VPN is what disables the
centralized DNS resolvers in browsers in these configurations.  The
magic browser probe no longer fails with the change in DNS routing
(which the proposal confusingly names “Split DNS”) because it goes out
over the public Internet, where it is not filtered, unlike the Red Hat
VPN.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Florian Weimer
* Michael Catanzaro:

> If you're running mail servers or VPN servers, you can probably
> configure the DNS to your liking, right? Either enable DNSSEC support 
> in systemd-resolved, or disable systemd-resolved. I'm not too
> concerned about this

What about end users who just enable a VPN client?

My understanding is that the DNS request routing in systemd-resolved
effectively disables any security mechanisms on the VPN side, and
instructs most current browsers to route DNS requests to centralized DNS
servers for all requests (i.e., overriding what came from both the VPN
and DHCP).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-25 Thread Florian Weimer
* Jan Kratochvil:

> On Fri, 25 Sep 2020 17:09:54 +0200, Robbie Harwood wrote:
>> So saying "Google does it" (or similar) is *not* a good argument.
>
> So let's stick only to the numbers I sent in other mails.
> In fact I do not understand why we talk about anything except the
> numbers.

The numbers are very difficult understand because it's not clear what
you are measuring.  Especially since as far I understand it, parts are
not yet fully implemented, so we can't know yet if all the required data
is there.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-25 Thread Florian Weimer
* Robbie Harwood:

> Jan Kratochvil  writes:
>
>> So why is Google using it for everything?
>
> If I could eliminate one bad thought pattern in software design it would
> probably be this one.
>
> In brief: you are not Google, nor are you Facebook, nor Amazon.  Your
> problems are not their problems.  Your use case is not their use case.
> Plenty of things work great for them that will work terribly for you.
>
> So saying "Google does it" (or similar) is *not* a good argument.

Agreed, especially since we know that e.g. Google's use of C++ does not
align well with how many other programmers use the language.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

2020-09-25 Thread Florian Weimer
* Jan Kratochvil:

> On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
>> Then that certainly means that Ubuntu uses this too, since they reuse
>> the dbgsym subpackage generation for the ddeb system they have now.
>
> I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
> there:
>   https://packages.ubuntu.com/groovy/amd64/bluez-dbg/download
>   llvm-dwarfdump -color=0 
> bluez-dbg_5.55-0ubuntu1_amd64/data/usr/lib/debug/.build-id/*/*.debug|grep 
> DW_TAG_partial_unit
>
> This debuginfo package has been built 2020-09-15.

This is not a -dbgsym package, so it probably has been created by a
different procedure.  I do not know how Ubuntu distributes their -dbgsym
packages.  An example from Debian with .dwz paths is here:



Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Side tag rebuilds an ELN

2020-09-21 Thread Florian Weimer
* Aleksandra Fedorova:

> Hi, Florian,
>
> On Mon, Sep 21, 2020 at 11:35 AM Florian Weimer  wrote:
>>
>> How do side tag rebuilds and ELN interact?  If we do a complicated
>> synchronous package update in a side tag, will ELN track this closely?
>> Or will someone have to redo the same steps in ELN manually?
>
> For now we react on tagging events and process each "package is tagged
> to f34" koji event separately.
> For sidetags this means that we will try to rebuild all packages from
> the sidetag, but the order of rebuilds is not preserved.
>
> We are waiting for permissions to create sidetags for ELN in
> https://pagure.io/fedora-infrastructure/issue/9329
>
> Once it is available we will be setting up the automation for sidetag
> rebuilds in the same order as they were built for Rawhide.
> The work will be tracked by https://github.com/fedora-eln/eln/issues/2

Very nice.  Please stop before you've reimplemented MBS. 8-)

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Side tag rebuilds an ELN

2020-09-21 Thread Florian Weimer
How do side tag rebuilds and ELN interact?  If we do a complicated
synchronous package update in a side tag, will ELN track this closely?
Or will someone have to redo the same steps in ELN manually?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

2020-09-11 Thread Florian Weimer
* Tom Hughes via devel:

> On 11/09/2020 07:13, Ondrej Dubaj wrote:
>
>> There seemed to be no big reason for moving the libraries to the
>> main package in the past, so I consider f34 as a good candidate for
>> such a change. It would be great, if  you share your opinions and
>> concerns for this topic.
>
> Tom Lane has explained the reason on the ticket, it's because the
> library is often dlopened by a client application instead of being
> linked to.

Yes, that is sufficient reason not to do the move.  Third-party
applications will break.  Some people also really dislike installing
*-devel packages in production, so there might not be an easy fix for
them.

The library probably should not have a versioned soname in the first
place, with backwards compatibility achieved by different means.  But
that does not matter now.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-10 Thread Florian Weimer
* Ben Cotton:

> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
>
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>
> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
>
>
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
>
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.

Could the static_call framework be used instead for this?

  

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


noarch packages only for some architecture composes

2020-09-07 Thread Florian Weimer
Is it possible to include a noarch package only in some of the composes?

The background is that I added glibc-headers-x86.noarch to deal with a
conflict between inconsistent composes (glibc-headers.i686 was sometimes
in the x86_64 compose, sometimes it was not).  glibc-headers-x86.noarch
is always in the compose, and thus avoids the issue.  But an
unanticipated side effect is that glibc-headers-x86 (and
glibc-headers-s390) show up across all architectures.  I'm concerned
that this is potentially confusing.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-02 Thread Florian Weimer
* John M. Harris, Jr.:

> On Tuesday, September 1, 2020 5:19:15 AM MST Florian Weimer wrote:
>> * John M. Harris, Jr.:
>> 
>> 
>> > Sure, those two companies will be thrilled, I'm sure. This is a huge 
>> > disservice to our users. Why in the world does systemd try to force DNS 
>> > servers when none are configured? If no DNS servers are configured, there
>> > 
>> > should be no DNS servers in use.
>> 
>> 
>> Acutally, the historic default is to use localhost (127.0.0.1).  This is
>> what an empty or missing /etc/resolv.conf file has always meant.
>> 
>> (Okay, there was apparently a time when localhost could also be reached
>> at 0.0.0.0, and that was the default before 127.0.0.1.  But that likely
>> predates the Linux networking stack.)
>
> Well, that was only reading host files, right? Or do you mean the
> system would actually perform lookup against itself?

It actually sends UDP packets to 127.0.0.1, port 53.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-01 Thread Florian Weimer
* Roberto Ragusa:

> Standard DNS has a hierarchical structure with roots and delegation.
> The idea of asking somebody to do DNS resolution for you comes from
> the widespread tendency to centralize everything (i.e. inability to
> understand how the Internet was originally designed).

DNS originally did not have a clear hierarchical structure.  You just
asked one server you liked, and it would point you towards a server
somewhat closer to the data source if it did not have the answer itself.

The hierarchy was always there in the background, to ensure eventually
successful lookups, but it gained prominence in implementations only
once it became apparent that you can only use data from servers that are
actually authoritative for the subtree in which the data resides.
Otherwise, you end up with rather trivial spoofing attacks.

> Insisting on using a DNS server for name resolution is like insisting
> on using a proxy for HTTP access.

I'm not sure if that's the appropriate analogy.  Most of us don't run
BGP on their laptops, and DNS is closer to that layer than to HTTP.

But it definitely doesn't make sense to create a deep hierarchy of
resolvers, somehow mirroring the hierarchy of delegation.

> The only sane DNS server we should have is the one on localhost (doing
> proper caching according to TTLs).

Many networks block outgoing UDP traffic, so you cannot run DNS locally
at all.  There are also concerns that the DNS infrastructure cannot
handle the load unless there is one level of shared caching betweeen the
endpoints and the authoritative servers.  Those DNS caches certainly
suppress some of the problematic client behavior (but they also add
their own share of broken queries, of course).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-01 Thread Florian Weimer
* John M. Harris, Jr.:

> Sure, those two companies will be thrilled, I'm sure. This is a huge 
> disservice to our users. Why in the world does systemd try to force DNS 
> servers when none are configured? If no DNS servers are configured, there 
> should be no DNS servers in use.

Acutally, the historic default is to use localhost (127.0.0.1).  This is
what an empty or missing /etc/resolv.conf file has always meant.

(Okay, there was apparently a time when localhost could also be reached
at 0.0.0.0, and that was the default before 127.0.0.1.  But that likely
predates the Linux networking stack.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: calculating process memory usage

2020-08-15 Thread Florian Weimer
* Samuel Sieb:

> Since you've brought this up, this is a question I've had for a long 
> time.  How do you get real memory+swap usage information for processes 
> or is that even possible?  Looking in ps or top, the RES is way too 
> small and the VIRT/VSIZE is way too big.  ps_mem is also way too small, 
> or at least the total is less than half of the real memory usage.  Is 
> there something else using that much memory that isn't processes? 
> buffers and cache don't account for the difference either.

There's a tool called smem which is supposed to attribute shared
mappings in a more reasonable way.  People use it with ZGC (pne of the
OpenJDK garbage collectors) because it maps the heap multiple times,
grossly inflating traditional RSS values.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Lost ELF library auto-provides since mass rebuild

2020-08-06 Thread Florian Weimer
* Daniel P. Berrangé:

> This AC_LANG_PROGRAM call puts the code snippet inside a main() { ...}
> so what configure was actually attempting to compile is:
>
>  int
>  main ()
>  {
>  
>int f1() { }
>int f2() { }
>asm(".symver f1, f@VER1");
>asm(".symver f2, f@@VER2");
>int main(int argc, char **argv) { }
>  
>;
>return 0;
>  }
>
>
> clearly this code is nonsense, but by luck it still worked until newer
> GCC came along.

I think it's actually a binutils change.  Older binutils was happy to
apply .symver to undefined symbols, effectively ignoring the directive
(because there is nothing to attach it to).  That changed in binutils
2.35, which started to diagnose the problem with an error.

> The code has to be passed as the first arg of AC_LANG_PROGRAM, not the
> second arg, so that its outside the main() {...}

Glad it's been fixed.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Lost ELF library auto-provides since mass rebuild

2020-08-06 Thread Florian Weimer
* Daniel P. Berrangé:

> This is in relation to this bug
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1862745
>
> The last but one build of libgphoto have auto-provides for the ELF
> libraries:
>
> libgphoto2 = 2.5.24-2.fc33
> libgphoto2(x86-64) = 2.5.24-2.fc33
> libgphoto2.so.6()(64bit)
> libgphoto2_port.so.12()(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit)
> libgphoto2_port.so.12(LIBGPHOTO2_INTERNAL)(64bit)
>
> any new build both in the mass rebuild and any scratch builds I try
> looses some of these auto deps leaving just
>
> libgphoto2 = 2.5.24-3.fc33
> libgphoto2(x86-64) = 2.5.24-3.fc33
> libgphoto2.so.6()(64bit)
> libgphoto2_port.so.12()(64bit)
>
>
> Was there any change people are aware of that would explain this and
> suggest what we need todo to get these deps back in libghoto ?

I think this isn't the real issue.  As far as I can tell, all the symbol
versioning information is gone.  The RPM dependencies are correct, but
the ABI is not. 8-p

configure.ac has this:

AC_MSG_CHECKING([for asm .symver support])
AC_COMPILE_IFELSE([dnl
AC_LANG_PROGRAM([[]],[[
int f1() { }
int f2() { }
asm(".symver f1, f@VER1");
asm(".symver f2, f@@VER2");
int main(int argc, char **argv) { }
]])dnl
],[
AC_DEFINE([HAVE_ASM_SYMVERS],1,[Define if there is asm .symver 
support.])
VERSIONMAPLDFLAGS="-Wl,--version-script=\$(srcdir)/libgphoto2.ver"
AC_MSG_RESULT(yes)
],[
VERSIONMAPLDFLAGS=""
AC_MSG_RESULT(no)
])
AC_SUBST(VERSIONMAPLDFLAGS)

And build.log shows:

checking for asm .symver support... no

The HAVE_ASM_SYMVERS macro is apparently unused, but setting
VERSIONMAPLDFLAGS looks *very* relevant.

The cause seems to be this:

/tmp/ccAbnnro.s: Assembler messages:
/tmp/ccAbnnro.s: Error: invalid attempt to declare external version name
as default in symbol `f@@VER2'

It's LTO-related in the sense that f1 & f2 get different symbols with
LTO.  This fixes the test:

int __attribute__ ((externally_visible)) f1() { }
int __attribute__ ((externally_visible)) f2() { }
asm(".symver f1, f@VER1");
asm(".symver f2, f@@VER2");
int main(int argc, char **argv) { }

Not sure this was missed by Jeff's config.log differ.  Maybe its
binutils version was too old?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: mpich always injects lto flags

2020-08-06 Thread Florian Weimer
* Christoph Junghans:

> I am trying to rebuild espresso to adapt to the recent cmake changes,
> when doing this I hit
> https://github.com/espressomd/espresso/issues/3396, which prevents us
> from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> which works for the build with openmpi, but gets ignored for the mpich
> build.
>
> I think the problem is that CMake picks up the lto flags from mpicxx
> and then puts them in
> MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
>
> So I think the fix would be to strip these flags from mpicc. Sounds
> reasonable?

I think this could be an application for the extension_*flags macros in
redhat-rpm-config:

# Internal-only.  Do not use.  Expand a variable and strip the flags
# not suitable to extension builders.
%__extension_strip_flags() %{lua:
local name = rpm.expand("%{1}")
local value = " " .. rpm.expand("%{build_" .. name .. "}")
local result = string.gsub(value, "%s+-specs=[^%s]+", " ")
print(result)
}

# Variants of CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS for use within
# extension builders.
%extension_cflags %{__extension_strip_flags cflags}
%extension_cxxflags %{__extension_strip_flags cxxflags}
%extension_fflags %{__extension_strip_flags fflags}
%extension_ldflags %{__extension_strip_flags ldflags}

These were intended for scenarios where the flags are hard-coded into
other tools at build time.  It's unfortunately rather difficult to
decide what should go into those flags.

Ideally, tools like mpicc would use a more dynamic approach to determine
the proper flags.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Test machines for s390x?

2020-08-06 Thread Florian Weimer
* Elliott Sales de Andrade:

> Just like we have test machines for other less used architectures [1],
> I am wondering if there is some way we can spin up a test machine for
> s390x?

Marist offers machine access for open-source development:





Debian has a porterbox as well.

I don't know which setup is more straightforward to use for Fedora
development.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Reminder: upcoming Fedora 33 deadlines & milestones

2020-08-05 Thread Florian Weimer
* J. Scheurich:

> It lloks like boost.173 would require a future verson of gcc/g++

Why do you think that?

According to Boost upstream, anything later than GCC 8 is untested, but
I don't think this is actually true.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: OCaml + binutils 2.35 on i386

2020-08-05 Thread Florian Weimer
* Richard W. M. Jones:

> On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote:
>> When ocamlopt is used with binutils 2.35 to link an executable, we now
>> get warnings that look like this:
>> 
>> /usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only
>> section `.text'
>> /usr/bin/ld: warning: creating DT_TEXTREL in a PIE
>
> 32 bit is an architectural problem for OCaml.  Specifically because of
> how the GC block headers are implemented it limits arrays / strings to
> a maximum of 4M entries / 4M bytes, which was probably fine back in
> the day but is unreasonably small today. [1]

I don't see how this is related to text relocations.

The problem seems to be lack of PIE support in ocamlopt on i386, as
correctly identified by the warning.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

2020-08-04 Thread Florian Weimer
* Jeff Law:

> Actually, isn't it "just" 234MB.  Still I'm surprised why that failed.  Do we
> have more than one build running at a time on those boxes?

It's a 32-bit build.  I assume it's not the first large allocation.
(FWIW, GDB always prints “virtual memory exhausted”, even if the malloc
failure has a different cause.)

Does LTO produce more complicated debugging information?  Then maybe
disabling LTO on armhfp is a workaround.  There's also a way to disable
debuginfo package generation altogether, something along these lines
(untested):

%define debug_package %{nil}
%define __debug_install_post %{nil}
%global __debug_package %{nil}
%undefine _debugsource_packages
%undefine _debuginfo_subpackages
%undefine _unique_debug_names
%undefine _unique_debug_srcs

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

2020-08-04 Thread Florian Weimer
* Miro Hrončok:

> Hello, I've got this failure I cannot really understand, it happens on
> armv7hl only (aarch64 and s390x were cancelled):
>
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm
> error: Installed (but unpackaged) file(s) found:
>/usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
> Installed (but unpackaged) file(s) found:
>/usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
>
> The gdb-index-9pY4kY files are not created explcitiyl by anything in
> the package.

This happens if debuginfo generation fails with a crash:

extracting debug info from 
/builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped
../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 
234696314 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
This is a bug, please report it.  For instructions, see:
.
/usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) 
$GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save gdb-index 
$dwarf5 $dir"

The crash is normally ignored.

> Does anybody know what this is?

Not enough RAM, apparently.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

2020-08-04 Thread Florian Weimer
* Daniel P. Berrangé:

> Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923

Sorry, what would be more interesting is the linker invocation.  The
build log does not show this, only the libtool invocation.  We don't
really know what kind of transformations libtool does in this case.

libtool is really not built for LTO, and it really should not be used on
GNU systems.  But I understand that this is not uncontroversial.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

2020-08-03 Thread Florian Weimer
* Daniel P. Berrangé:

> If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups
> at all for qemuProcessStartManagedPRDaemon. It looks very much like the
> call was resolved and bound at link time when built with LTO.

It's possible that the symbol extraction logic is confused by LTO, but
-ffat-lto-objects should prevent that.

Can you collect all the linker input scripts/command lines after libtool
has done its thing?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

2020-08-03 Thread Florian Weimer
* Daniel P. Berrangé:

> Disabling LTO in the RPM spec confirms this and makes things pass
> again. Hacking the makefiles to remove the -fno-lto option when
> building the test suite binaries also fixes things.
>
> I don't see any mention of LD_PRELOAD being impacted by LTO in the
> Fedora feature change page, but I can imagine how it would be.

LTO should still export the same functions as before, and should not
imply -fno-semantic-interposition by default.  The linker plugin
provides the necessary information to GCC.  What you are observing could
be the result of a toolchain bug.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Florian Weimer
* Richard W. M. Jones:

> Here's another one:
>
>   $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8
>   libguestfs-tools-c-1.43.1-2.fc33.x86_64
>   readline-8.0-5.fc33.x86_64
>   $ guestfish --version
>   Segmentation fault (core dumped)
>
>   (gdb) bt
>   #0  0x in  ()
>   #1  0x7f3212b72dad in history_filename
>   (filename=0x5592dd41bfa0 "/home/rjones/.guestfish") at ../histfile.c:152
>   #2  0x7f3212b75e2d in read_history_range
>   (filename=, from=0, to=-1) at ../histfile.c:280
>   #3  0x5592dd33e646 in main ()
>
> It also caused a build failure of another package in Koji
> (search the logs for "ext2.img] Segmentation fault (core dumped)"):
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=48245041
>
> I suspect the problem isn't in readline but is in the main package,
> mainly because I tried an older readline and that failed in the same
> way.

This looks like the ld bug producing incorrect absolute symbols:

$ eu-readelf --symbols=.dynsym usr/bin/guestfish  | grep -w ABS
  790:  54 FUNCGLOBAL DEFAULT  ABS xrealloc
  791:  35 FUNCGLOBAL DEFAULT  ABS xmalloc
  799:    1294 FUNCGLOBAL DEFAULT  ABS locale_charset



I believe a fix for that is on its way to rawhide.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Florian Weimer
* Daniel P. Berrangé:

>> For emulating 32-bit targets, we have a broken readdir/telldir/seekdir
>> implementation in glibc on 64 bit host kernels because we try to use
>> d_ino directly, which is 64 bit and does not fit into the long value

recte: d_off

>> that POSIX requires.  A kernel patch with a new interface has been
>> posted which would work around this has been proposed, but it is not
>> going anywhere.
>
>> The second issue also affects full-system virtualization if p9fs (not
>> sure what the right name is, it's the older pass-through file system) is
>> used.  But it's specific to 32 bit, so maybe not that important after
>> all.
>
> Yep, 9p, its generally not great POSIX emulation no matter what.
>
> The more modern virtio-fs is a more promising solution for the
> future, based on FUSE.

The second problem is not a matter of old vs modern interfaces, it's
that POSIX requires us to fit the 64-bit d_off value we get from the
kernel into a 32-bit long, because that's what telldir returns.  This is
true even for builds with 64-bit off_t values.  The kernel cannot really
fix this on our behalf because it would have to perform a
side-translation for every directory entry.  That's problematic for
large directories.

But in glibc, we know when we need the translation (when the application
calls telldir), and we can defer the translation until then.  It's just
a little bit awkward to implement because telldir must not fail, so we
need to preallocate space for the translation during the readdir call.
But it's not impossible.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Florian Weimer
* Daniel P. Berrangé:

> I'm not familiar with what COPR is doing for s39x0 ?  Is it using the
> simple QEMU linux-user syscall emulation, or is it running a proper
> QEMU s390x VM.
>
> I'm guessing probably the former. The linux-user syscall emulation is
> truely amazing, but it is certainly not feature complete or fully
> robust.

It still implements vfork using fork, right?  This means we should
likely fix posix_spawn in glibc to support this deviation from the
kernel interface.  Other Linux emulations have exactly the same problem.

For emulating 32-bit targets, we have a broken readdir/telldir/seekdir
implementation in glibc on 64 bit host kernels because we try to use
d_ino directly, which is 64 bit and does not fit into the long value
that POSIX requires.  A kernel patch with a new interface has been
posted which would work around this has been proposed, but it is not
going anywhere.

The second issue also affects full-system virtualization if p9fs (not
sure what the right name is, it's the older pass-through file system) is
used.  But it's specific to 32 bit, so maybe not that important after
all.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How do Fedora developers get access to devtoolset for testing.

2020-07-29 Thread Florian Weimer
* Jonathan Wakely:

> It's not about devtoolset. Installing CentOS 7 RPMs on Fedora rawhide
> is outlandish. It won't work in general, because the CentOS RPMs have
> dependencies on CentOS packages, and Fedora has different versions.

Steven has a point, though.  For software not built by Red Hat,
installing RPMs on Fedora works most of the time even if they have been
packaged for the enterprise downstreams (or vice versa, sometimes the
intended user base is not entirely clear).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-07-27 Thread Florian Weimer
* Michael Catanzaro:

> On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
>  wrote:
>> Please do not disable reading from /etc/resolv.conf. If you do so,
>> please
>> limit that to the Spins that it won't affect people on, such as
>> Workstation,
>> if you believe people there don't set their own DNS servers.
>
> Except:
>
> * /etc/resolv.conf is broken by design, as you would know if you read
> the section on split DNS that you just quoted

It works for the things it's meant to do.

Split DNS does not exist as a concept.  Some web browser concepts, such
as the canary domain for DoH are explicitly incompatible with it:

  

Incompatible in the sense that when connecting to a VPN, DNS traffic
will now be sent to a third party, when it would not before.

> * There's no value in reading from /etc/resolv.conf unless you have
> written something custom to it

Any DNS client library has to read /etc/resolv.conf to determine the
system DNS configuration.

The format is about as stable than _res, and from languages which are
not C, much easier to access.

This isn't an obscure use case, this is something that really has to
work.  Even C programs use alternative DNS clients for asynchronous name
resolution and similar things.

> Fact is that unless you have done custom work to allow manual
> modifications to /etc/resolv.conf, you're not going to notice this
> change at all.

It depends on the quality of the DNS implementation whose address is
given in /etc/resolv.conf.

> And if you have, then surely you'll be able to figure
> out the very, very simple steps to get back to the original
> behavior. In fact, it should actually be *easier* than before to get
> traditional behavior. Remove the symlink. Create your own
> /etc/resolv.conf. Hey presto! systemd will read it

What if I want to manage name servers via DHCP (and Network Manager),
but still retain DNSSEC support for local applications?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

2020-07-24 Thread Florian Weimer
* Mark Wielaard:

> BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <=
> 0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004
> because there used to be a different libelf implementation (with a dead
> upstream these days). Can I remove that? Or is it better to keep it
> "just in case"?

My rule of thumb is that if it's not possible to directly upgrade from
the last release which still had the package, it's okay to remove the
Obsoletes:.  It's derived from first principles (the intermediate update
step will remove the package); I don't know if it's an official
guideline.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: gcc-gnat

2020-07-14 Thread Florian Weimer
* Björn Persson:

> In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage
> of gcc. Adding it to EPEL would make it a separate package. I'm not
> sure what complications might arise from that.

The main problem is that /usr/bin/gcc does not have Ada support.  It
will not try to invoke gnat1 (the actual Ada compiler) even if it is
installed at the correct path.  I'm trying to figure out if anything can
be done about this.  This change would have to happen in the gcc
package.

If this change does not happen, you will have to ship /usr/bin/gnatgcc
instead, with some patching of the GNAT tools to use that.  Ada packages
that assume a single compiler driver for Ada/C/C++ will need fixing,
too.

Thanks,
Florian
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


Re: Can we do away with release and changelog bumping?

2020-07-06 Thread Florian Weimer
* Björn Persson:

> The macro could be defined like this for example:
>
>   %buildtag .%(date +%%s)

Using time for synchronization is always a bit iffy.

> It would be used in each spec like this:
>
>   Release: 1%{?dist}%{?buildtag}

We could put the Koji task ID directly into the %dist tag.  We know that
this works in principle.  If we are worried that the number gets too
large, we could subtract the current task ID at the time the fcNN part
of the %dist tag changes.

The %dist tag is not recorded in the changelog by most packages, so the
changelog does not need changing.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Florian Weimer
* Nicolas Mailhot via devel:

> Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit :
>> On 02.07.2020 07:35, Nicolas Mailhot via devel wrote:
>>> The detached changelog is just one more file in SRPM sources, which is
>>> modified by rpmbuild at `%build` time with other files rpmbuild
>>> modifies.
>>
>> I don't like that. %changelog should be generated automatically on Koji
>> side.
>
> Why? Koji schedules a build.

No, Koji also builds the SRPM, via fedpkg-simple or a similar mechanism.
That seems to be natural place where the SPEC file is completed for
inclusion in the SRPM, in my opinion.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-07-02 Thread Florian Weimer
* Vít Ondruch:

> I just met something which might be of similar nature. Recent FF
> 78.0-1.fc33.x86_64 fails to start with older glibc:
>
>
> ~~~
>
> $ firefox
> XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
> /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np,
> version GLIBC_2.32
> Couldn't load XPCOM.
>
> ~~~
>
>
> Update of glibc from glibc-2.31.9000-13.fc33.x86_64 to
> glibc-common-2.31.9000-16.fc33.x86_64 resolved the issue. Nevertheless
> issues like this are unexpected. There should be something, what would
> force glibc update if FF requires more recent one.

Partial rawhide updates used to be unsupported.  Has this changed?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Florian Weimer
* Nicolas Mailhot:

> Le 2020-07-02 09:52, Florian Weimer a écrit :
>> * Nicolas Mailhot via devel:
>>
>>>> How do I let rpm generate the changelog automatically?
>>>
>>> This feature is not changelog generation, just changelog bumping on
>>> build events. You still need some other method to put non-build events
>>> in the changelog.
>>
>> What is “changelog bumping”?  Why is it needed?  What about release
>> bumping?
>
> Changelog bumping is the act of putting the actual release bump and
> build time in the changelog.
>
> With the change, the spec is able to self-compute its next release if
> the spec file evr is older or equal to the last build event.
>
> On build, it will both bump the release, without touching the spec
> file (that is release bumping) and commit the new build event
> timestamp in the detached changelog file at %build time (that is
> changelog bumping).

Isn't this totally over-engineered?

A much simpler alternative would just put the Koji task ID into the
%dist tag.  Since the %dist tag is not included in the version-release
fields on the %changelog section, no changelog update is needed.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Florian Weimer
* Nicolas Mailhot via devel:

>> How do I let rpm generate the changelog automatically?
>
> This feature is not changelog generation, just changelog bumping on
> build events. You still need some other method to put non-build events
> in the changelog.

What is “changelog bumping”?  Why is it needed?  What about release
bumping?

> The detached changelog is just one more file in SRPM sources, which is
> modified by rpmbuild at `%build` time with other files rpmbuild
> modifies. The tricky part is to modify the source file as a source file
> so rpmbuild adds the result to the produced SRPM (and, that does not
> work in mock right now, because mock serves the SRPM that existed at
> the start, not at the end of the build. Though it’s probably just a
> matter of getting mock to call again its SRPM creation method at the
> end of the build).
>
> The packager does not have to request the modification in his spec,
> it’s done as part of the various %auto_foo calls the change introduced

Can you list the relevant %auto macros explicitly somewhere?  Is
%autosetup included in the set of macros that trigger this behavior?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-02 Thread Florian Weimer
* Konstantin Kharlamov:

> FWIW, I was just thinking about it, and I came up with example you
> may like which shows exactly why BTRFS is bad for HDD. Consider
> development process. It includes rewriting source files over and
> over: you do `git checkout foo` and files are overwritten, you
> change a file in text editor, and it gets overwritten. And since
> BTRFS is CoW, it will always write files to a new place.

Editors that make a backup copy typically do not overwrite files in
place.  They rename the file to the backup location and then write the
new file.

git checkout unlinks changed files first, before writing them anew
from scratch.

A COW file system does not make a difference for these use cases
because there is already COW at the application level.

The GNU assembler truncates the output object file first.  On XFS,
that triggers relocation to a new file system location as well, even
if the output file size (or contents) does not change.  So that
scenario is essentially COW as well today.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-06-30 Thread Florian Weimer
* Alex Scheel:

> Is Fedora Rawhide unstable at the moment, pending a mass rebuild?
>
> I've seen a lot of random problems related to pthreads at the
> moment, such as:
>
> 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child 
> aborted***Exception:   0.99 sec
> FINE: CryptoManager: loading JSS library
> FINE: CryptoManager: loaded JSS library from java.library.path
> java: ../nptl/pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion 
> `mutex->__data.__owner == 0' failed.
>
>
> Another, different stack trace here (pthreads fails to lock,
> triggering a bug in opencryptoki):
>
> https://pagure.io/dogtagpki/issue/3181#comment-661911

I don't see why this would be fixed by a mass rebuild.

This is probably some sort of memory corruption: something has
overwritten the mutex data structure, and glibc happens to detect that.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: The future of legacy BIOS support in Fedora.

2020-06-30 Thread Florian Weimer
* Jóhann B. Guðmundsson:

> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
> changes it beg the question if now would not be the time to stop
> supporting booting in legacy bios mode and move to uefi only supported
> boot which has been available on any common intel based x86 platform
> since atleast 2005.

Even for virtualization?  Not sure if that can be done.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-30 Thread Florian Weimer
* Steven Whitehouse:

> On 27/06/2020 11:00, Florian Weimer wrote:
>> * Josef Bacik:
>>
>>> As for your ENOSPC issue, I've made improvements on that area.  I
>>> see this in production as well, I have monitoring in place to deal
>>> with the machine before it gets to this point.  That being said if
>>> you run the box out of metadata space things get tricky to fix.
>>> I've been working my way down the list of issues in this area for
>>> years, this last go around of patches I sent were in these corner
>>> cases.
>> Is there anything we need to do in userspace to improve the behavior
>> of fflush and similar interfaces?
>>
>> This is not strictly a btrfs issue: Some of us are worried about
>> scenarios where the write system call succeeds and the data never
>> makes it to storage *without a catastrophic failure*.  (I do not
>> consider running out of disk space a catastrophic failure.)  NFS
>> apparently has this property, and you have to call fsync or close the
>> descriptor to detect this.  fsync is not desirable due to its
>> performance impact.
>
> It doesn't matter which filesystem you use, you can't be sure that the
> data is really safe on disk without calling fsync. In the case of a
> new inode, that means fsync on the file and on the containing
> directory.

In my opinion, there is a conceptual difference between the machine or
storage crashing hard, and just running out of disk space.

> There can be performance issues depending on how that is done, however
> there are a number of solutions to those issues which can reduce the
> performance effects to the point where they are usually no longer a
> problem. That is with the caveat that slow storage will always be
> slow, of course!
>
> The usual tricks are to avoid doing lots of small fsyncs, by gathering
> up smaller files, ideally sorting them into inode number order for
> local filesystems, and then issuing fsyncs asynchronously, waiting for
> them all only once all the fsyncs have been issued. Also
> fadvise/madvise can be useful in these situations too,

None of this applies to shell utilities such as grep and cat.  They work
around data loss as a result of the write system call not reporting
ENOSPC errors: they close stdout and stderr underneath glibc, which
leads to a different class of problems.  It turns out that on Linux,
close does more space checks than write, so this allows the shell
utilities to check for ENOSPC without issuing fsyncs.  At present, lack
of space checks from write seems to primarily happen with NFS.

So let me rephrase: Does btrfs report ENOSPC during write?  If it does
not, what can we do to check for sufficient space during fflush and
similar operations?

If we change the shell utilities to do an fsync on close, we get
traditional UNIX behavior with traditional UNIX performance.  I don't
think that's what people want.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-29 Thread Florian Weimer
* Solomon Peachy:

> On Mon, Jun 29, 2020 at 11:33:40AM +0200, Florian Weimer wrote:
>> Just to be clear here, the choice of XFS here is purely based on
>> performance, not on the reliability of the file systems, right?
>> (So it's not “all the really important data is stored in XFS”.)
>
> Be careful about overloading quite a few definitions into the single 
> word "reliability".
>
> You seem to be referring to btrfs features like file checksumming that 

No, I was not.  To me, for file systems, it means that under conditions
I personally consider reasonable (generally healthy hardware, and only
the occasional hard power-off after a system becomes unresponsive), the
file system can be mounted, retains consistent metadata, and most of the
data is still there, with the possible exception of things that have
been written a short time after the crash.

It's not about getting the best out of partially faulty hardware or an
execution environment with frequent power outages.

As you point out, historically, checksumming file systems weren't very
good at this, but I think for btrfs, this has improved.  (For a long
time, there was a FAQ for a different checksumming file system that had
something along the lines of “Q: I can't mount my file system due to a
checksum error.  A: Restore form backup.”.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-29 Thread Florian Weimer
* Josef Bacik:

> That being said I can make btrfs look really stupid on some workloads.
> There's going to be cases where Btrfs isn't awesome.  We still use xfs
> for all our storage related tiers (think databases).  Performance is
> always going to be workload dependent, and Btrfs has built in overhead
> out the gate because of checksumming and the fact that we generate far
> more metadata.

Just to be clear here, the choice of XFS here is purely based on
performance, not on the reliability of the file systems, right?
(So it's not “all the really important data is stored in XFS”.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: User experience issue on btrfs

2020-06-29 Thread Florian Weimer
* Chris Adams:

> Once upon a time, John M. Harris Jr  said:
>> XFS proved to be troublesome, and still is up to the latest of RHEL7. It's 
>> not 
>> uncommon to have to run xfs_repair on smaller XFS partitions, especially /
>> boot. I'm not sure if btrfs has the same issue there?
>
> [citation needed]
>
> I haven't run xfs_repair in probably 15 years (and so never on Fedora or
> RHEL/CentOS).

The relatively common issue isn't that running xfs_repair is necessary,
it's that any kind of log replay is needed.  A regular mount suffices.
GRUB does not implement XFS journal replay, and if a system is rebooted
to briefly after a kernel update, it's possible that GRUB cannot find
the new entries in /boot.  There was also a system shutdown issue which
prevented clean unmounts of /boot during regular reboots, making this
issue more apparent.

However, I haven't seen any recent reports of this issue, and have not
seen it myself for quite some time.

Technically, this isn't even an XFS bug.  Whether other file systems are
more well-behaved depends on their GRUB implementation, and not so much
on the file systems themselves.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Packaging firmwares

2020-06-28 Thread Florian Weimer
* Richard Hughes:

> On Fri, 26 Jun 2020, 22:21 Florian Weimer,  wrote:
>
>  Is FirmwareUpdate.efi really firmware in Fedora's sense?  Won't it run
>  on the host CPU?
>
> This is flashed hardware!? Can't mellanox just use the LVFS to
> distribute firmware rather than having to install a package of blobs
> you're going to use exactly once?

I don't know if the binary is included by accident.  But it's something
that needs to be investigated.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Florian Weimer
* Josef Bacik:

> As for your ENOSPC issue, I've made improvements on that area.  I
> see this in production as well, I have monitoring in place to deal
> with the machine before it gets to this point.  That being said if
> you run the box out of metadata space things get tricky to fix.
> I've been working my way down the list of issues in this area for
> years, this last go around of patches I sent were in these corner
> cases.

Is there anything we need to do in userspace to improve the behavior
of fflush and similar interfaces?

This is not strictly a btrfs issue: Some of us are worried about
scenarios where the write system call succeeds and the data never
makes it to storage *without a catastrophic failure*.  (I do not
consider running out of disk space a catastrophic failure.)  NFS
apparently has this property, and you have to call fsync or close the
descriptor to detect this.  fsync is not desirable due to its
performance impact.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Packaging firmwares

2020-06-26 Thread Florian Weimer
* Robert-André Mauchin:

> I have a review request for a firmware: Boot firmware (ATF, UEFI...) for 
> Mellanox BlueField:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1846139
>
> I would like some opinions on whether this is acceptable firmware. The
> binary contains open source code for which the license are documented,
> but no code source is provided, only the resulting binary firmware.

Is FirmwareUpdate.efi really firmware in Fedora's sense?  Won't it run
on the host CPU?

In the Git repository

  

Mellanox does not provide permission to redistribute the firmware, only
required notices of components that they have used to build it.  Just
saying that something has been derived (in part) from open source
software does not make it open source, or even redistributable.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: undefined symbol: pthread_getattr_np, version GLIBC_2.32

2020-06-16 Thread Florian Weimer
* Igor Raits:

> On Tue, 2020-06-16 at 18:39 +0800, 西木野羰基 wrote:
>> Could please check what version of glibc has been installed during
>> mock build? I can;t find the logs or the build artifacts.
>> But by checking other build yesterday I can found that glibc in koji
>> build is newer than the one on my computer (fedora rawhide x86_64)
>> I think the problem is because koji is using
>> glibc-common-2.31.9000-14.fc33 for f33 and we can only get a
>> 2.31.9000-13.fc33 now.
>> Maybe wait for mirrors to update (and install new glibc) and retry?
>
> That's true, but I am surprised that this is not handled by symbol
> versioning. This function seems to exist for long long time, so why did
> it break just now?

The symbol was moved from libpthread to libc.  The new symbol version is
required so that newly linked applications depend on glibc 2.32 as the
minimum glibc version.  Without it, RPM would not generate correct
dependency information.

You do not get an RPM dependency error in rawhide because there is just
one GLIBC_2.32 symbol version, but the symbol set covered by it is still
evolving.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: undefined symbol: pthread_getattr_np, version GLIBC_2.32

2020-06-16 Thread Florian Weimer
* Igor Raits:

> I built gitui in koji (f33) yesterday and tried to run it on my laptop
> with Fedora Rawhide today and it does not work:
>
> gitui: symbol lookup error: gitui: undefined symbol:
> pthread_getattr_np, version GLIBC_2.32
>
> Did anybody see something similar in other applications? Any ideas
> what's broken?

The rawhide compose probably lags what's in the buildroot.  Try:

# dnf --enablerepo=local update

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

2020-06-15 Thread Florian Weimer
* Jiri Vanek:

> Is there some replacemnt for this subpackage? At least theoretical?

For the JDBC connector to SQLite, there's sqlite-jdbc and javasqlite.
But the on-disk format will be different.

For the key-value store, there is the je package, but again the on-disk
format is different.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

2020-06-15 Thread Florian Weimer
* Ondrej Dubaj:

> The problem is unknown runtime behaviour of libdb-java (build with
> jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an
> active user of libdb java ?

I am not.

Upon second thought, it doesn't seem to make sense to preserve
libdb-java (although I expect that it's only necessary to fix the
autoconf check).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

2020-06-11 Thread Florian Weimer
* Ondrej Dubaj:

> we are aiming to remove libdb-java package from Fedora-rawhide, as we
> are currently preparing for jdk update from jdk-1.8 to jdk-11 in
> Fedora rawhide. The problem is that we are unable to rebuild this
> package with jdk-11. It is still possible to "hack" it and rebuild it
> with jdk-1.8, but that can cause unexpected runtime behaviour
> according to JVM-11, which will soon be default in Fedora-rawhide.

Out of curiosity, what is the exact problem?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is there an official Fedora for WSL?

2020-06-08 Thread Florian Weimer
* Iñaki Ucar:

> On Mon, 8 Jun 2020 at 07:12, Gordon Messmer  wrote:
>>
>> > - I found that [1] does a pretty good job replacing /usr/bin/systemctl
>> > [1] https://github.com/gdraheim/docker-systemctl-replacement
>>
>> I only use WSL for an interactive shell, so I haven't needed to do much
>> of anything with systemd.  Does it not run in WSL, out of curiosity?
>
> No, because systemd needs to be PID 1, and WSL has its own init that
> knows how to connect stuff back and forth. That script aims to emulate
> systemctl and allows you to run services in a systemd-based image.
> It's not perfect (I found e.g. that some child processes are not
> properly killed), but it works reasonably well.
>
> For WSL2, there's the same issue, and there's another workaround:
> https://github.com/arkane-systems/genie

Ugh.  Thanks for the clarification.  And people still think that the
alleged legal issues are the main issue here?

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: devel Digest, Vol 196, Issue 58

2020-06-05 Thread Florian Weimer
* Jeff Law:

> As we both know, GCC has had ABI bugs as well.  Both compilers strive
> to be ABI compatible with each other and we should continue to work
> together to find and address such issues.  SImilarly both compilers
> are going to have codegen issues, or rejects-valid-code bugs.
> Ultimately they're just bugs and I don't see that one toolchain or the
> other is inherently better than the other, particularly WRT ABI
> issues.

More problematic are not ABI bugs, but the cases where the ABI
divergence is a matter of opinion (more or less).

I think we really should figure out what to do about the alignment of
_Atomic long long on 32-bit.  GCC has 4, Clang has 8.  Clang seems to be
correct here.  This also has implications for the use of libatomic.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Florian Weimer
* Ben Cotton:

> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
> == Summary ==
> Fedora has historically forced packages to build with GCC unless the
> upstream project for the package only supported Clang/LLVM.  This
> change proposal replaces that policy with one where compiler selection
> for Fedora follows the package's upstream preferences.

Jeff, would you please clarify in the proposal that libc++ is out of
scope (as already discussed)?

What about compiler-rt?  And lld?  Any other LLVM subprojects that could
be relevant?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Florian Weimer
* Jeff Law:

> I'm not suggesting switching the default.  I'm suggesting the compiler
> choice be made by the upstream projects.  Some prefer LLVM, others
> prefer GCC.  Fedora should get out of the way and use the same tools
> that the upstream projects are using.

Do we know how many upstream projects actually recommend building with a
recent Clang upstream release?  Chromium explicitly does not:

| Chromium ships a prebuilt clang binary. It's just upstream clang built
| at a known-good revision that we bump every two weeks or so.
|
| This is the only supported compiler for building Chromium.



Currently, it's this build:

$ ./src/third_party/llvm-build/Release+Asserts/bin/clang++ --version
clang version 11.0.0 (https://github.com/llvm/llvm-project/ 
a6ae333a0c23fc9b0783ca45e2676abac00c6723)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: 
/home/test/chromium/./src/third_party/llvm-build/Release+Asserts/bin

So something pulled recently from the development branch, not a release
branch.

In my experience, this is pretty typical: Upstreams leaning towards
Clang expect that you use their prebuilt compiler, not a system
compiler.

Using Clang downstream may make things simpler for packagers, but a
system-supplied Clang compiler is rarely a preferred upstream choice
(not even on Macos, where there is no real choice anymore).

On the other hand, there is demand from users (not just packagers) for
the LLVM-based toolchain, and increased use by Fedora packagers will
help us to improve the quality of Fedora's version of it.  Fortunately,
for this effect, it does not matter *why* Fedora packagers choose Clang.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Florian Weimer
* Igor Raits:

> From what I see, GCC supports it on x86, x86_64, s390x, riscv64,
> ppc64le. So this just does not include ARM / AArch64 from Fedora
> architectures.

GCC has aarch64 support for stack-clash-protection, but it only works
well with 64K pages (otherwise detection is not reliable).  This is due
to a choice by the target maintainers I do not understand.  At least it
does not break anything.

I don't know the state on armhfp.  It used the generic GCC
implementation in the past, which we considered too buggy to enable.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Has something changed with RPMS?

2020-06-02 Thread Florian Weimer
* Panu Matilainen:

> Lets start with the basics:
> - is sqlite even involved - it will only be used on rawhide builds if
> mock bootstrap is used
> - does it make a difference if you override _db_backend to bdb/sqlite
> from mock config / cli define
> - a reproducer please (eg, what package is considerably slower to
> build than before, and by how much)

And: Does the difference reproduce when building on tmpfs?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Location of executable code

2020-05-22 Thread Florian Weimer
* Petr Viktorin:

> Does "read-only architecture independent data" mean the files must not
> be programs?

Not according to the FHS.  From the FHS perspective, /usr/share is just
like RPM's noarch architecture: completely portable across all
architectures.  It can even be machine code if it does not need
customization based on host processor architecture (e.g., firmware for
some peripheral device).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Problems with packages compiled with gcc 10.0

2020-05-19 Thread Florian Weimer
* Guido Aulisi:

> I'm getting some strange errors from some packages built for f32 with
> gcc 10.0 [0].
> Building with g++ 10.1 ardourd5 seems fine...
>
> It seems GCC 10.0 had some bugs that could be discovered only at
> runtime. Did you have any similar problems?
>
> Ciao
> Guido
> FAS: tartina
>
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089

Comment 12 on that bug suggests that it's the known underlinking issue
in Ardour (“it seems related to a missing symbol (__atan2_finite) in
libvampplugins”).  If true, this is not related to GCC 10 at all.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Many packages unnecessarily link to libpython

2020-05-16 Thread Florian Weimer
* Charalampos Stratakis:

> If your package links to libpython without requiring it, it won't be
> possible to use the python3-debug binary with your python C extension,
> unless you recompile the extension against it.

Would it make sense to work around this by some other means?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: armv7l status?

2020-05-14 Thread Florian Weimer
* Peter Robinson:

> armhfp is "Arm hard floating point" which covers the overall ARM 32
> bit architecture, there can be different variants in there, armv6,
> armv7, armv7+NEON, armv8 (the 32 bit variant as opposed to aarch64)
> and so on...

Just to be clear here, armhfp is *not* the common denominator of all
32-bit Arm architectures.  It does not cover the overall architecture in
the sense that is compatible to with everything out there.  (I'm not
sure if that is even possible.)  Fedora's 32-bit Arm requirements have
always been fairly advanced, resulting in fewer compatible devices than
other Linux distributions.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: armv7l status?

2020-05-14 Thread Florian Weimer
* Stephen John Smoogen:

> When x86_64 splits into 48 bit memory path to some larger memory (60
> bit I think is discussed) sometime in the future, we will probably
> still call it x86_64 but build x86_64b packages.

This has already happened.  You did not notice it because it did not
require x86_64b packages.

It's possible to hide most of the effect of the change by not handing
higher memory regions to userspace unless it requested it explicitly.
This is similar to how things are handled on ppc64le.  aarch64 had a
similar transition, but opted for a hard break, if I recall correctly.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-13 Thread Florian Weimer
* Stephen John Smoogen:

> No because the things that backups and rsync do works in a slow way.
> We can do the backup the look-aside cache with tar-balls in a couple
> of hours. We can also rsync that in the same amount of time. It takes
> that long or longer to do that with a couple of git trees which are
> much smaller in size but larger in file numbers. Every file in a git
> tree is stat'd and while there is some deduplication, there is a lot
> of files.

I think there's a logic bug somewhere. 8-)

The number of files in the lookaside cache is small only because we
check in patch files into dist-git.  Upstream glibc.git isn't too bad,
despite not having a particularly clean repository due to frequently
rebased user branches (and tons of lose objects as a result):

$ find glibc.git/ | wc -l
1725

That's not two far off from the number of files we have in downstream
dist-git at the tip of each release branch:

$ for x in {7..32} ; do git ls-tree origin/f$x: ; done | awk '{print $3}' | wc 
-l
1232

Admittedly, the deduplicated number is somewhat lower:

$ for x in {7..32} ; do git ls-tree origin/f$x: ; done | awk '{print $3}' | 
sort -u | wc -l
711

(I don't know how many files end up on the dist-git server for that.)

There must be hundreds of glibc tarballs in the lookaside cache by now,
too, but I don't have insight into that.  (Clearly, we aren't model
citizens.)  The file count would likely be way lower if you had to back
up only one or two Git repositories.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-07 Thread Florian Weimer
* Fabio Valentini:

> In the rare occasion that I need to make downstream-only changes with
> patches, I usually just explode the upstream tarball, run "git init",
> then "git add .", "git commit -m import", apply my changes, and then
> do "git diff --patch > ../00-my-changes.patch" (if it's just one
> commit), or "git format-patch -o ../" if there are multiple commits,
> and then delete the exploded sources again.

That's what we do for glibc, too.  In Fedora, we do not have that many
patches, but we do in downstream.

Like so many of us, I wrote some fairly elaborate scripts for that:

  

Carlos wrote some documentation for them:

  

However, they still require training in an unusual process, and there
are corner cases which are difficult to fix.  Most of that would just go
away if the generated Git tree where the primary artifact developers
worked with.

There would still be corner cases (especially if dist-git were kept in
the background), but I expect that they would not interrupt developer
workflow (unlike with the non-authoritative, on the fly repository).
They could still produce their patches, submit merge requests, and get
reviews and (CI) test results that way.  The dist-git update (with a
potential merge first in the other direction) would have to be handled
by people experienced with that process, though.  But for large packages
with a lot of backporting activity, that might be fine.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-07 Thread Florian Weimer
* Pierre-Yves Chibon:

> On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote:
>> But I would like to note that exploded repos (or source-git repos)
>> have at least two other advantages.
>> 
>> 1) they consume less space than tarballs for each version because
>> objects in git repo are deduplicated
>> 2) instead of downloading/uploading tarballs, you can just do
>> something like: git pull --rebase upstream master; git push
>
> Just a note that this is not something you can do today since a rebase rewrite
> history, so you would have to do `git push --force` which isn't allowed
> currently.
> So if we were to move forward with this model, we will need to find a solution
> for the question that has led us to forbid force pushes until now.

You could do a fake merge (git merge -s ours) to include the old master
branch in the history, so that from a Git perspective, it's again a
fast-forward push.

I'm more concerned that a standard git rebase will not produce great
results, producing a history that contains the new upstream version with
a bit of cruft on top of it, only some of it actually needed.  But it is
worth a try.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: sorting of git N-V-R tags in rpm package repositories

2020-05-06 Thread Florian Weimer
>> >> Tags can also be added retroactively and backdated.  These things
>> >> conflict with the advantages you list (in particular, with NVR
>> >> auto-generation, git is not the sole source of truth).
>> >
>> > If the tag ordering function is done properly, I believe even
>> > retroactive tagging (i.e. tagging into past) and/or tag backdating
>> > would be supported and NVR auto-generation would work correctly. So I
>> > don't think it needs to conflict. But can you perhaps expand more on
>> > "Tags can also be added retroactively and backdated", please?
>> > I.e. why/when would one do that.
>>
>> No, you can push tags with incorrect dates.  This can change the
>> auto-generation.
>
> It really depends on what the tag ordering function is. If the
> function does not consider dates at all, this wouldn't be a problem.

The commit graph is ordered, but everything else is not.  Tags (whether
annotated or not) are outside the commit graph, so their order is not
fixed.

I think this is different with Mercurial, where tags are part of the
commit graph.

>> You can only avoid this if you use data from commits (both current and
>> earlier) *on the same branch* exclusively for generating metadata (or
>> hash-linked from there).  Everything else can get of sync and change
>> over time even if the commit hash stays the same, so the repository
>> state at a specific commit hash is longer the sole source of truth.
>> (Because you need to reconstruct that other state *at the right time*.)
>
> What do you mean by "everything else which can get out of sync and
> change"? If you are talking about tags (or refs in general), it's true
> that you can add tags into past which may or may not affect
> auto-generation depending on the ordering function.

What kind of ordering function could tell apart a retroactively added
tag and one that was there when the build was submitted?

>> That's why I proposed to auto-generate release numbers and changelogs
>> based on the commits going back to the last Release: line and %changelog
>> section update in the spec file.  That would be stable (unless the tool
>> changes how it generates those spec file parts).
>
> I don't think you can automatically generate %changelog and Release
> and at the same time base their auto-generation on their last change
> in spec file in git history. That somehow doesn't seem that it would
> work.

I don't know of any problems, and I have implemented this in the past
(although in a very different context).

> Tagging into past is imho rather a theoretical use-case but useful to
> consider.

Is it?  It can easily happen if you forget to push a tag and then do a
build, and push it later.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-05 Thread Florian Weimer
* Neal Gompa:

> On Tue, May 5, 2020 at 1:33 PM Florian Weimer  wrote:
>>
>> * Neal Gompa:
>>
>> > In the merged-source world, the packaging is an aspect of managing the
>> > software codebase. This is common in Debian and ALT Linux, where the
>> > standard practice with their tooling is to fork the codebase and
>> > integrate the packaging files into the tree. Changes then are managed
>> > as part of evolving the sources, and packaging is mainly touched when
>> > preparing to push to build. And for $DAYJOB, I've implemented this
>> > model for software that $DAYJOB makes (we use the split-source model
>> > for stuff we didn't write).
>>
>> This is not an accurate representation of what Debian does.  The
>> guidelines and tools very much encourage broken-out patches.  The
>> representation is slightly different (via the “debian” subdirectory in a
>> source tree), but this does not mean that you can just change files
>> outside the “debian” directory (i.e., upstream sources), build the
>> Debian SRPM equivalent, and have it built.
>>
>
> Debian *does* have this merged-source model. There are two variants of
> this model:
> * merged source with patch trees (debian 2.0/3.0 formats)
> * merged source with no patch trees (debian 1.0 format)
>
> There is no singular SRPM equivalent, this differs across variants:
> * singular source tarball (debian 1.0 format)

1.0 covers both singular source tarball (so-called native package) and
tarball plus .diff.gz file.

> * source tarball + compressed super-patch (debian 2.0 format)
> * source tarball + debian folder tarball (debian 3.0 format)

Actually, 2.0 and 3.0 (quilt) both have broken-out patches.  3.0
(native) is very similar to 1.0 without a separate patch file.

> The 3.0 source format is the closest to our model.

And the tools (and not just them) push you gently towards using the 3.0
(quilt) format, so most packages do.  And in that case, you cannot
simply make changes to the source tree and build a new source package.

Even with the original .orig.tar.gz plus .diff.gz approach, *many*
packages had broken-out patches in debian/patches and used various
approaches to apply them during the build.  The 3.0 (quilt) format just
made that part declarative.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-05 Thread Florian Weimer
* Neal Gompa:

> In the merged-source world, the packaging is an aspect of managing the
> software codebase. This is common in Debian and ALT Linux, where the
> standard practice with their tooling is to fork the codebase and
> integrate the packaging files into the tree. Changes then are managed
> as part of evolving the sources, and packaging is mainly touched when
> preparing to push to build. And for $DAYJOB, I've implemented this
> model for software that $DAYJOB makes (we use the split-source model
> for stuff we didn't write).

This is not an accurate representation of what Debian does.  The
guidelines and tools very much encourage broken-out patches.  The
representation is slightly different (via the “debian” subdirectory in a
source tree), but this does not mean that you can just change files
outside the “debian” directory (i.e., upstream sources), build the
Debian SRPM equivalent, and have it built.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: sorting of git N-V-R tags in rpm package repositories

2020-05-05 Thread Florian Weimer
> Hey Florian,
>
> On Mon, 4 May 2020 at 10:03, Florian Weimer  wrote:
>>
>> > as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags
>> > pushed by package maintainers) effort, I revisited the sorting
>> > algorithm that is used to determine the "latest" tag for a given
>> > package which is needed to determine correct package version.
>> > Basically, if the current commit is tagged, then the N-V-R information
>> > from that tag name is directly used to render version or release
>> > (depending on macro usage). If the latest tag is on some older commit,
>> > we still use information from it but the version (or release) string
>> > will contain some appendices like .git.4.abcdef12 to mark a commit
>> > offset from that latest tag. Note that only tags accessible from the
>> > current branch tip when traversing git history backward are considered
>> > to pick the latest one (i.e. tags on other separate branches are not
>> > considered).
>>
>> Is this really necessary?  Koji goes by latest tagged build, it does not
>> sort by NVR when constructing the buildroot.  The same thing seems to
>> apply to composes (but I am less sure about that).
>

> is it certain? I tried to poke around koji/kojira code, kojí IRC, and
> also logs at: https://koji.fedoraproject.org/koji/tasks which are very
> slow for owner:kojira, state:all but I couldn't really determine so
> far whether only the latest build of a package gets to "build"
> repository (that is used for builds subsequently) for a given tag.

The latest tag for a source package name wins for the Koji-generatged
repository.  I don't know what happens if different source packages
build subpackages of the same name.

> If you build a package with an older version than what was there for
> previous build, does that older version overrides the newer one? I
> would need to poke more to find out. But it would be very interesting
> to know.

Yes, if it gets tagged into the buildroot, it replaces a build with a
higher NVR.

>> Tags can also be added retroactively and backdated.  These things
>> conflict with the advantages you list (in particular, with NVR
>> auto-generation, git is not the sole source of truth).
>
> If the tag ordering function is done properly, I believe even
> retroactive tagging (i.e. tagging into past) and/or tag backdating
> would be supported and NVR auto-generation would work correctly. So I
> don't think it needs to conflict. But can you perhaps expand more on
> "Tags can also be added retroactively and backdated", please?
> I.e. why/when would one do that.

No, you can push tags with incorrect dates.  This can change the
auto-generation.

You can only avoid this if you use data from commits (both current and
earlier) *on the same branch* exclusively for generating metadata (or
hash-linked from there).  Everything else can get of sync and change
over time even if the commit hash stays the same, so the repository
state at a specific commit hash is longer the sole source of truth.
(Because you need to reconstruct that other state *at the right time*.)

That's why I proposed to auto-generate release numbers and changelogs
based on the commits going back to the last Release: line and %changelog
section update in the spec file.  That would be stable (unless the tool
changes how it generates those spec file parts).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: will disappear from rawhide glibc soon

2020-05-05 Thread Florian Weimer
* Fabio Valentini:

> On Wed, Apr 15, 2020 at 5:50 PM Florian Weimer  wrote:
>>
>> This follows the removal of the system call from Linux 5.5.  Having the
>> header and function just confuses configure checks that assume that if
>> the function is present, it will do something useful (it never did on
>> aarch64, and it's been many years since it worked on Fedora kernels on
>> other architectures).
>>
>> Replacements are uname, getentropy, and reading from /proc, but I really
>> do not expect much fallout from this (famous last words).
>>
>> The kernel headers still provide , but that will
>> eventually disappear as well.
>
> java-1.8.0-openjdk also fails to build due to the missing header on
> rawhide - this is blocking some work towards OpenJDK 11.

Do you have a build log?  Do you need help with fixing this?

I thought that OpenJDK builds with -Werror, so it should have already
trippeed on the deprecation warning?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-05 Thread Florian Weimer
* Tomas Tomecek:

> Florian, a very good point. Yes, we are planning to support GitLab -
> we have a GSoC project for it:

> https://pagure.io/mentored-projects/issue/69

Is a GSoC project really the appropriate vehicle for this?

Gitlab has one major advantage over Github: it is possible to restrict
merge requests.  This makes it much simpler to experiment with it.
With Github, once you are on that platform, you have to deal with pull
requests in some way, even if you don't want to.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Is dist-git a good place for work?

2020-05-04 Thread Florian Weimer
* Tomas Tomecek:

> In the packit project, we work in source-git repositories. These are
> pretty much upstream repositories combined with Fedora downstream
> packaging files. An example: I recently added a project called nyancat
> [n] to Fedora. I have worked [w] on packaging the project in the
> GitHub repo and then just pushed the changes to dist-git using packit
> tooling. These source-git repositories can live anywhere: we have
> support for GitHub right now and are working on supporting pagure.

I think Fedora has decided to adopt Gitlab, not Github (or Pagure).  Are
there plans to port Packit over to Gitlab?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

2020-05-04 Thread Florian Weimer
* Milan Crha:

> out of the interest (no offense meant), would this not be caught by the
> rawhide gating? I'd expect that this is something what the rawhide
> gating would avoid.

There is no simple way to run buildroot readiness tests in Fedora.  One
has to use weird scripts for that, and the environment is quite far away
from what Koji provides.  It seems that this issue would have been
caught even with these limitations if there was an attempt to build the
right packages—if it affected x86_64 or i686, which it did not (because
x86 already dealt with it).  There is no CI for the other architectures
at all, as far as I know.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: sorting of git N-V-R tags in rpm package repositories

2020-05-04 Thread Florian Weimer
> as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags
> pushed by package maintainers) effort, I revisited the sorting
> algorithm that is used to determine the "latest" tag for a given
> package which is needed to determine correct package version.
> Basically, if the current commit is tagged, then the N-V-R information
> from that tag name is directly used to render version or release
> (depending on macro usage). If the latest tag is on some older commit,
> we still use information from it but the version (or release) string
> will contain some appendices like .git.4.abcdef12 to mark a commit
> offset from that latest tag. Note that only tags accessible from the
> current branch tip when traversing git history backward are considered
> to pick the latest one (i.e. tags on other separate branches are not
> considered).

Is this really necessary?  Koji goes by latest tagged build, it does not
sort by NVR when constructing the buildroot.  The same thing seems to
apply to composes (but I am less sure about that).

So I don't see why you would need any sort of NVR sorting.  Basically,
you can go back through the history and use the first tag you encounter
as the baseline.

However, I think this whole approach is a bit fishy.  Tags should be
pushed by Koji once a build completes, so that it is easy to identify
matching sources reliably, not by the packager.  Tags can also be added
retroactively and backdated.  These things conflict with the advantages
you list (in particular, with NVR auto-generation, git is not the sole
source of truth).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Backports of fixes from F32 -> F31?

2020-04-29 Thread Florian Weimer
* Alex Scheel:

> Hi Florian,
>
> I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> such as this one against mutter:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1770296
>
>
> Could we get some of these fixes backported? I've not heard from you on
> this bug at all, despite a needinfo request since March.

I'm another Florian.  I'm not involved in GNOME development at all,
sorry.

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: ckermit?

2020-04-29 Thread Florian Weimer
* Steven A. Falco:

> I'd like to request a rebuild for F32.  Is it sufficient to request
> that here, or is there some other procedure that I should use?

I've merged the F33 change (dropping termcap-devel) and kicked off a new
build.  Please test the update and provide karma
,
so that it can ship to users.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Florian Weimer
* Kevin Kofler:

> Jun Aruga wrote:
>> simde is a header files only library. It's not a binary.
>
> Then it is inherently unsuitable for automatic runtime selection, and
> all the runtime selection still has to be done in the client program.
>
> GCC requires you to compile for separate vector instruction sets in
> separate compilation units. A header-only library cannot possibly do
> that for you.

In general, that is not true.  You can use the target function attribute
and function multiversioning instead in many cases.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++

2020-04-22 Thread Florian Weimer
* Jerry James:

> On Wed, Apr 22, 2020 at 6:01 AM Richard W.M. Jones  wrote:
>> It turns out it comes from dune (the build tool), although I'm still
>> unclear how and why.  In any case I added a rather hacky workaround so
>> I can get the build going again:
>
> No, it isn't dune; it's ocaml itself.  From "Changes" under "Bug fixes":
>
> - #7917, #9426: Use GCC option -fexcess-precision=standard when available,
>   avoiding a problem with x87 excess precision in Float.round.
>   (Xavier Leroy, review by Sébastien Hinderer)

This option should not have an effect on Fedora because we use SSE2 math
on i686 (and x86-64, of course), which does not suffer from this issue.
I think we can remove it.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What CPU extensions can we assume are available by arch?

2020-04-22 Thread Florian Weimer
* Dominik Mierzejewski:

> If upstream doesn't support runtime selection of SIMD-optimized code
> paths based on CPU capabilities, you can build several versions and
> have glibc handle that by putting each version in a special subdirectory
> of /usr/lib64, e.g.:
> /usr/lib64/haswell
> /usr/lib64/haswell/avx512_1/
>
> See
> https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture
> for some details.

These are ill-defined unfortuantely and as such not very useful.
For example, -march=haswell does not result in code that can be
placed in a haswell subdirectory.

I'm working with AMD and Intel to come up with a better subdirectory
definition that also matches between GCC and glibc.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What CPU extensions can we assume are available by arch?

2020-04-22 Thread Florian Weimer
* Peter Robinson:

>> > What about VSX on ppc64le?
>>
>> Yes, but only the parts that are in POWER8.
>
> We on;y support POWER8 and later in Fedora for ppc64le.

Yes, that's what I meant: you cannot assume POWER9 or -mfuture.

(There is nothing earlier than POWER8 for ppc64le anyway, some earlier
machine types were only used for the architecture bringup and do not
implement the ppc64le ISA.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What CPU extensions can we assume are available by arch?

2020-04-22 Thread Florian Weimer
* Richard Shaw:

> I'm working on packaging a project that makes use of AVX/AVX2/NEON to process 
> and
> improve the quality of low bitrate human speech:
>
> https://github.com/mozilla/LPCNet
>
> I'm having trouble determining what the base CPU targets for Fedora can 
> accommodate.
>
> For example, ss it safe to assume AVX2 on x86_64?

No (although the builders support it).

You can assume SSE2, but nothing more recent.

The glibc dynamic loader can select different library versions based on
the ISA support level, but that this is more of a theory at this point
because there are no useful, well-documented selection criteria.

> At this time upstream only supports AVX/AVX2/NEON, but if they did add
> support for SVE on aarch64, can I use it?

No.  I don't think the builders support it yet.

> What about VSX on ppc64le?

Yes, but only the parts that are in POWER8.

> It doesn't look like I have any options on s390x since the base is
> "-march=zEC12+" which from what I can tell doesn't support the
> extended intrinsics required.

Yes, vectorization is added in z13 (with more extensions in later ISAs).
Red Hat Enterprise Linux 8 is built for z13, so it may make sense to
have conditionals that automatically detect this.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: will disappear from rawhide glibc soon

2020-04-18 Thread Florian Weimer
* Ron Olson:

> Already fixed it and sending it to Rawhide now.

Have you submitted the fix upstream?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Matthew Miller:

> On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote:
>> > If there are no servers configured... Shouldn't it use no servers?
>> Well, our assumption is that working DNS is better than DNS that
>> doesn't work.
>
> I hope no one is using lack of configured DNS as a security measure! But I
> can see a case for wanting lack of configuration to be a failure rather than
> working but non-obviously not in the way you expected.

At the lowest level, lack of configuration (i.e., no name servers in
/etc/resolv.conf or no such file at all) currently means that 127.0.0.1
is used as the DNS resolver.  This has been the case for such a long
time that I think it would not be a good idea to configure different
servers instead.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering:

> On Do, 16.04.20 17:14, Florian Weimer (fwei...@redhat.com) wrote:
>
>> > I don't think we can reliably determine whether people have deployed
>> > things in a way that relies on /etc/resolv.conf only listing a fully
>> > blown DNS server or who are fine with it being a more restricted stub
>> > like systemd-resolved.
>>
>> Unfortunately, I see something similar to what Tom Hughes reported
>> earlier: dig +dnssec responses are not even correctly formatted.  The CD
>> query flag is not handled, either.  The AD bit is not set on validated
>> responses.  I also see some really strange stability issues.  It seems
>> that resolved is incorrectly blacklisting upstream servers with an
>> incompatible-server error after a validation failure.
>
> Again, we do not support DNSSEC from client to the stub.

I don't think this change is ready for Fedora, then.

> If you set CD we'll return NOTIMP as rcode, indicating that. We do not
> implement a full DNS server, but just enough for local stub clients
> (such as the one implemented in glibc or Java) to work.

Sorry?  RES_USE_DNSSEC is part of the glibc stub resolver.  It does not
work anymore.

The libunbound validator is broken by this, too.

> If you want the full DNSSEC client stuff, talk directly to the
> upstream DNS server.

How?  The address is no longer in /etc/resolv.conf.  According to the
change proposal, this also endangers Denise, who relies on the request
routing in systemd-resolved.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Tomas Mraz:

> On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote:
>> On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer  
>> wrote:
>> > Not sure if that's compatible with the new split DNS model because 
>> > VPN1
>> > could simply start pushing longer names in the scope of VPN2, thus
>> > hijacking internal traffic there (and this sort of hijacking is 
>> > exactly
>> > what a DNS sinkhole against typosquatting would need).
>> 
>> You deserve bonus points for thinking like an attacker and exploring 
>> the security model, but let's assume the configured VPNs are
>> trusted. 
>> Otherwise the user is screwed no matter what. ;)
>
> Trusted for what? I would expect corporate VPNs doing such tricks to
> monitor the user's internet traffic. Which does not mean the user is
> fully screwed with such VPN if he for example uses hardcoded
> configuration of a caching nameserver.

Yes, what I described was given as a motivation for this change.

I find the response puzzling.  I would definitely like to see greater
robustness to hostile networks, but it is a lot of work.  Really a lot.
Lots of code to review, and quite a few shell scripts as well.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering:

> On Do, 16.04.20 12:49, Florian Weimer (fwei...@redhat.com) wrote:
>
>> As explained elsewhere, NetworkManager-openvpn extracts the search list
>> from OpenVPN parameters, passes that to NetworkManager, which I expect
>> will pass ito to systemd-resolved in the future.
>>
>> >> Ugh.  That will have to be fixed, otherwise it will break DANE/TLSA
>> >> and
>> >> other DNSSEC-mandatory functionality on upgrades: the system used to
>> >> have a DNSSEC-clean path to the outside world, and after the switch to
>> >> systemd-resolved, it won't.
>> >
>> > I think that, if you need DNSSEC, you will just need to enable it
>> > manually. I think >99% of users won't need to do this, and it's a
>> > one-line config file change for power users who do need it, just edit
>> > /etc/systemd/resolved.conf and then restart systemd-resolved
>> > service. Problem is that DNSSEC is just not safe to enable by
>> > default. :(
>>
>> See my message to Lennart about separate DO/CD query caching.
>>
>> My point is that these users *have* enabled DNSSEC in their
>> infrastructure, and we break what they have during an update (assuming
>> that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather
>> than just disabling validation).
>
> Maybe a safer bet might be to leave resolved off during upgrades on
> the server edition?

A Fedora upgrade can also mean reprovision from start via
kickstart/ansible, so I assume that this isn't a proper mitigation,
sorry.

> I don't think we can reliably determine whether people have deployed
> things in a way that relies on /etc/resolv.conf only listing a fully
> blown DNS server or who are fine with it being a more restricted stub
> like systemd-resolved.

Unfortunately, I see something similar to what Tom Hughes reported
earlier: dig +dnssec responses are not even correctly formatted.  The CD
query flag is not handled, either.  The AD bit is not set on validated
responses.  I also see some really strange stability issues.  It seems
that resolved is incorrectly blacklisting upstream servers with an
incompatible-server error after a validation failure.

This is with systemd-245.4-1.fc33.x86_64 in rawhide.  Is this
approximately what will land in Fedora 33?  Or is this old code, long
replaced upstream?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering:

> On Do, 16.04.20 12:53, Florian Weimer (fwei...@redhat.com) wrote:
>
>> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
>>
>> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
>> still forward queries to the daemon, which contacts the upstream server
>> on nss_resolve's behave (possibly with some caching), and eventually
>> return the data to the application?
>
> correct.
>
>> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
>> data?
>
> no.

Okay, this behavior is nice and what I expect.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Zbigniew Jędrzejewski-Szmek:

> On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote:
>> * Lennart Poettering:
>> 
>> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote:
>> >
>> >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote:
>> >>
>> >> > * Lennart Poettering:
>> >> >
>> >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it
>> >> > >for DNS configuration, and never change it or modify it or replace
>> >> > >it. If this mode is selected arbitrary other programs that do DNS
>> >> > >will talk directly to the provided DNS servers, and resolved is out
>> >> > >of the loop.
>> >> >
>> >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts
>> >> > > itself into DNS resolution in any way.
>> >> >
>> >> > What will nss_resolve do in this case?  Nothing?
>> >>
>> >> The nss_resolve module is just a wrapper around resolved's bus
>> >> API. And the bus API uses resolved's own DNS resolution code. And
>> >> resolved is smart enough to automatically become a *consumer* of
>> >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
>> >> file instead of a symlink to resolved's own files in /run.
>> >
>> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.
>> 
>> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
>> still forward queries to the daemon, which contacts the upstream server
>> on nss_resolve's behave (possibly with some caching), and eventually
>> return the data to the application?
>
> nss-resolve is enabled/disabled through nsswitch.conf. It always talks to
> systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf
> in any way.
>
> What Lennart wrote above applies to systemd-resolved and to things
> which look at /etc/resolv.conf for some reason. If nss-resolve is enabled,
> then only things which do not use nss at all would fall into this category.
>
>> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
>> data?
>
> nss_resolve fails with UNAVAIL when systemd-resolved is not running.
> So yeah, we use want to use nss_dns as a fallback for that case. I'm not
> sure if that is what you are asking about.

Let me rephrase:

If /etc/resolv.conf is a regular file, will systemd-resolved deactivate
itself?  Or use the name server configuration found there instead?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering:

> On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote:
>
>> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote:
>>
>> > * Lennart Poettering:
>> >
>> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it
>> > >for DNS configuration, and never change it or modify it or replace
>> > >it. If this mode is selected arbitrary other programs that do DNS
>> > >will talk directly to the provided DNS servers, and resolved is out
>> > >of the loop.
>> >
>> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts
>> > > itself into DNS resolution in any way.
>> >
>> > What will nss_resolve do in this case?  Nothing?
>>
>> The nss_resolve module is just a wrapper around resolved's bus
>> API. And the bus API uses resolved's own DNS resolution code. And
>> resolved is smart enough to automatically become a *consumer* of
>> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular
>> file instead of a symlink to resolved's own files in /run.
>
> Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf.

So if /etc/resolv.conf comes from somewhere else, then nss_resolve will
still forward queries to the daemon, which contacts the upstream server
on nss_resolve's behave (possibly with some caching), and eventually
return the data to the application?

Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the
data?

I'd prefer the first approach, but it really means that resolved is out
of the loop only for queries submitted over the DNS transport (so
res_query and the like, or direct use of UDP & TCP).  Hence my
confusion. 8-)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Michael Catanzaro:

> On Wed, Apr 15, 2020 at 10:48 am, Florian Weimer 
> wrote:
>> The second Kubernetes issue I worry about [1] is that the CoreDNS name
>> server is installed first, and it does additional rule-based
>> processing
>> for in-cluster names.  External DNS servers are listed later.
>> Parallel
>> queries and random server selection could bypass the CoreDNS service
>> for
>> queries that need to be handled by it.
>
> Hm, CoreDNS might need to construct its own nss module,

This is not possible.  You cannot realistically inject binary code into
the container (see the fun with GPU userspace driver parts).

> or you might need to use /etc/resolv.conf in "mode 1" or "mode 3"
> described by Lennart. (Or disable systemd-resolved, but that shouldn't
> be necessary.) We'll default to Lennart's "mode 2" so it sounds like
> that might be a problem indeed.

Yeah.

>> Does OpenVPN log the list of these domains somewhere?  Or do they have
>> to be configured manually?
>
> This managed by NetworkManager and systemd-resolved. You can inspect
> with 'resolvectl status'. I don't think OpenVPN knows anything about
> it.

As explained elsewhere, NetworkManager-openvpn extracts the search list
from OpenVPN parameters, passes that to NetworkManager, which I expect
will pass ito to systemd-resolved in the future.

>> Ugh.  That will have to be fixed, otherwise it will break DANE/TLSA
>> and
>> other DNSSEC-mandatory functionality on upgrades: the system used to
>> have a DNSSEC-clean path to the outside world, and after the switch to
>> systemd-resolved, it won't.
>
> I think that, if you need DNSSEC, you will just need to enable it
> manually. I think >99% of users won't need to do this, and it's a
> one-line config file change for power users who do need it, just edit
> /etc/systemd/resolved.conf and then restart systemd-resolved
> service. Problem is that DNSSEC is just not safe to enable by
> default. :(

See my message to Lennart about separate DO/CD query caching.

My point is that these users *have* enabled DNSSEC in their
infrastructure, and we break what they have during an update (assuming
that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather
than just disabling validation).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering:

> Long story short: if you experienced issues with DNSSEC on with
> resolved today, then be assured that with DNSSEC off things are much
> much better, and that's how we'd ship it in Fedora if it becomes the
> default.

Would you please clarify what switching DNSSEC off means?  Just no
validation, or no DNSSEC support at all?

I'm worried that the following scenario will break: A Fedora system on a
uses a DNSSEC-capable resolver (validating or not) and performs its own
DNSSEC validation, using data obtained by contacting the name servers in
/etc/resolv.conf.  (/etc/resolv.conf is managed by NetworkManager or
cloud-init in this scenario.)

Since /etc/resolv.conf is already managed, I expect that after the
upgrade, systemd-resolved will be active, with the same upstream
recursive resolvers as before.  The new /etc/resolv.conf contents will
point to the local systemd-resolved DNS service, though.

If systemd-resolved is not DNSSEC-aware with DNSSEC=off on the DNS
interface, this will break DNSSEC validation in the application.  It
requires an explicit configuration change to fix.

In the past, caching resolvers have dealt with this situation by having
separate caches for DO (DNSSEC answer OK) or CD (Checking Disabled)
queries.  This allows non-DNSSEC operations to continue even if the
DNSSEC side is broken, so it is safe to enable it by default.  It would
also ensure that the configuration sketched above would not break (at
least not for this reason).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: buildroot problems on rawhide i386, armv7hl ??

2020-04-15 Thread Florian Weimer
* Vít Ondruch:

> Is this problem back?
>
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43439516
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43439614

Yeah, sorry, I made a mistake, rebuilding with the broken source
tarball.  I realized my mistake as soon as I received mail about the
completed build. 8-(

I've filed and untag request with releng:

  

Would anyone be willing to help us to set up a gating test which builds
lua, bash, ninja-build using the new glibc in Koji?  (I hope this is
something the infrastructure supports.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


will disappear from rawhide glibc soon

2020-04-15 Thread Florian Weimer
This follows the removal of the system call from Linux 5.5.  Having the
header and function just confuses configure checks that assume that if
the function is present, it will do something useful (it never did on
aarch64, and it's been many years since it worked on Fedora kernels on
other architectures).

Replacements are uname, getentropy, and reading from /proc, but I really
do not expect much fallout from this (famous last words).

The kernel headers still provide , but that will
eventually disappear as well.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


  1   2   3   4   5   6   7   8   9   10   >