date:20210225

Re: systemd-resolved fallback DNS servers: usability vs. GDPR

2021-02-25 Thread Lennart Poettering

On Mi, 24.02.21 22:08, Alexander Bokovoy (aboko...@redhat.com) wrote:

> I think one of the issues reported in the discussion you mention was
> that systemd-resolved considered invalid a DNS= line where addresses
> were separated by a comma rather than space. Can systemd-resolved be
> improved to allow common separators like both space and comma?

I am not a fan of such needless ambiguity, and it's not going to
retroactively fix the original reporter's configuration that has now
been fixed anyway... Moreover, across the systemd codebase in
configuration files we so far stuck to using mostly whitespace for
separating multiple values on the same config option line.

The thing is: separator characters end up being used for various other
purposes sooner or later. For example the DNS= lines in resolved.conf
already uses:

1. Dots (".") for separating IPV4 address bytes
2. Colons (":") for separating IPv6 address parts, as well as separating
   port numbers from the IP addres
3. Brackets ("[]") for separating ipv6 addresses from the rest of the
   construct
4. Percent ("%") characters to separate interface info from the rest
5. Hash ("#") characters to separate SNI host name specifications

Now, we currently don't use "," and ";" for separators here, but as
these things keep growing we might need them for something soon too.

Lennart

--
Lennart Poettering, Berlin
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Dilemma: -source repository data randomized by koji builder arch

2021-02-25 Thread Miroslav Suchý

Dne 25. 02. 21 v 18:19 Miro Hrončok napsal(a):

What I do is use "rpmspec -q --srpm" to do queries on packages for dependencies.

For example, you can do something like:

rpmspec --target x86_64 -q --srpm --buildrequires package.spec

That gets you a list of BRs for x86_64.

I suppose this doesn't support %generate_buildrequires, so it's not always possible. (But I have not verified this
assumption.)

Neal is correct that you only need to **query** on different architecture.

> However, I agree that keeping 6 SRPM files with identical *content*
> and only different *metadata* is incredibly wasteful.

The SPEC file is always the same. On all arches. [*] So the different metadata you mentioned are result of **query** of
that SRPM on that architecture. Even dynamic buildrequires.

Therefore I propose to:
* still generate only one SRPM like we do now.
* only generate list of builddeps on that architecture.

I.e., even in your case with "Qt5WebEngine on ppc64le and s390x" if you
generate SRPM on s390x and then run
mock --installdeps foo.src.rpm
on x86_64, then Mock should install Qt5WebEngine. Because it evaluates the SPEC
file on x86_64 architecture.

Browsing through code of Koji - I see no use of `--installdeps`. Therefore I think the Builrequires used are **always**
correct and relevant on that architecture. There is only one issue - it is hardly visible. It can be seen only in
root.log, which is pretty verbose.

And the "(info)" page on Koji, e.g.:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1715542
-> src - > info ->
https://koji.fedoraproject.org/koji/rpminfo?rpmID=25390046
lies, because its Requires section (which is in case of SRC.RPM actually BuildRequires of RPM) contains the
BuildRequires from just one architecture.

There what we actually needs:
* move the src.rpm on info page to each architecture (but still keep only one
src.rpm)
* query for install deps on each architecture
* have separate (info) page for each architecture

Query the deps can be tricky as Mock does not support it. There is only --installdeps, but not --querydeps. But I can
add it.

[*] the exception is
%ifarch FOO
SourceX: bar
but as you mentioned **that** is forbidden in Fedora.

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure

67 matches

Mail list logo