ra/legal/fedora-license-data/-/issues/152
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
ither Fedora Legal nor the packaging committee
request removal in such cases or carry it out themselves. At most, a
bug will be filed, but if the maintainer ignores it, basically nothing
happens.
Thanks,
Florian
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com
vel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- d
://indico.csnog.eu/event/13/contributions/121/
[2] https://ripe85.ripe.net/archives/video/923/
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel
FYI, I have created tracker bug ipv6-mostly [1], which links bugs in
different components to make that possible.
More below
On 01. 06. 23 21:05, Björn Persson wrote:
Petr Menšík wrote:
...
Fortunately there is roughly the same presentation[2] in English, which
took the place on RIPE 85
ea, fill a bug! Even to me.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, May 25, 2023 at 10:51 PM Petr Menšík wrote:
Hello everyone,
I have attended recently csnog.eu conference [1], where some interesting
presentations took place. They were usu
ially because it cannot be done by PackageKit GUI tools.
Is there a reason, why my idea cannot work? Is there an unsolved problem
it could not solve? Have something similar been considered already?
Best Regards,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com
: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http
etely. Is that right?
Thank,
Pavel
No, not at all. We want minimal variants preferred until nss-mdns is
changes significantly. Check nss-mdns issue #88 [1].
1. https://github.com/lathiat/nss-mdns/issues/88
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://
, Zdenek Dohnal wrote:
On 8/1/23 12:41, Petr Menšík wrote:
Hi Zdenek,
the current logic is:
- with-mdns4: mdns4_minimal
- with-mdns6: mdns6_minimal
- with-mdns4 and with-mdns6? mdns_minimal
Ah, I have missed last part, that it uses mdns plugin for both queries.
If I understand your message
On 07. 08. 23 12:49, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes sense to
have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should
awhide. We don't think
it's worth going through the changes process, but would like to
provide a heads-up.
See the details in https://bugzilla.redhat.com/show_bug.cgi?id=2025716.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E5299
2258062
2. https://src.fedoraproject.org/rpms/dnsmasq/pull-request/15
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP d
. 24 1:57, Kevin Kofler via devel wrote:
Petr Menšík wrote:
That might create a regression in special case. If you are running by
default systemd-resolved, it listens already on domain port on address
127.0.0.53 address. But if bind-interfaces or bind-dynamic is not used
explicitly, dnsmasq will
in rawhide actually, verify
what is listening on and whether it does conflict with anything. I use
"lsof -np $(pidof dnsmasq)" command for quick checks.
On 15. 01. 24 20:04, Stephen Gallagher wrote:
On Mon, Jan 15, 2024 at 11:32 AM Kevin Kofler via devel
wrote:
Petr Menšík wrote
.
On 16. 01. 24 10:18, Miroslav Lichvar wrote:
On Mon, Jan 15, 2024 at 05:31:36PM +0100, Kevin Kofler via devel wrote:
Petr Menšík wrote:
Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard
resolver does. You can use listen-address=127.0.0.53 if you like, but
then it will
#x27;t notice a
difference when launching a cloud instance after this change, but I
wanted to ensure everyone was aware it was coming. 😉
Have a great rest of the week!
[0] https://bugzilla.redhat.com/show_bug.cgi?id=2247055
[1] https://en.wikipedia.org/wiki/Udhcpc
--
Petr Menšík
Software
it would be possible reuse NM both times? If changes would be
required, how significant? Maybe it were already ruled out for a good
reason. I haven't found any discussion about that topic on cloud-init
upstream.
On 06. 02. 24 21:04, Major Hayden wrote:
On Tue, Feb 6, 2024, at 13:56, Petr M
ifarch %{rust_arches} this change
4) something else (what?)
IMHO if we do 1) we could as well do 2) because without rpm, we won't
be able to build rpms. 3) seems somewhat tedious for no good reason.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8
%files sections into exactly the same paths?
If there is an example floating somewhere, that would be very useful.
Thanks,
--
Bojan
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
important to use dlopen for
them. But now that there's a new motivation, as mentioned elsewhere in the
thread, we'll load pretty much all dependencies of libsystemd via dlopen.
Zbyszek
Petr Menšík
Software Engineer, RHEL
Red Hat,http:
On 02. 04. 24 14:17, Lennart Poettering wrote:
On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:
I am not convinced dlopen will it make secure in the end. I am not sure this
is a good solution. dlopen makes those dependencies non-obvious from
packaging side and non-visible from
y ways one can get this wrong. E.g., using some abstraction for
the socket write that can also write to regular files, without checking that
"$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU
vulnerability), introducing an arbitrary file overwrite vulnerability.
tps://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries
--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
___
devel mailing list -- devel@lists.fedoraproject
)
- people submitting pull requests against src.fp.o MAY also
include a conversion in the pull request and packagers SHOULD
merge it.
Big -1 to all
git log IS NOT a package changelog
Read https://keepachangelog.com/en/1.1.0/
Remi
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http
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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http:/
.conf as a target of current /etc/resolv.conf
symlink.
If systemd-resolved ever becomes capable as a good DNS cache, we can
return it back to domain port. I don't think it is ready for that.
Opinions?
Regards,
Petr
1. https://github.com/systemd/systemd/issues/23494
--
Petr Menšík
Software
t help
attract attention to the bugs.
Michael
I can set severity in bugzilla, but they tend to be ignored. I don't
know how to express severity on github issues, which at least receive
some feedback.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.re
d. We have a workflow for that in
bugzilla, but it is not used on upstream.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel@lists.fedoraproject.org
T
disable systemd-resolved, it leaves your system without working
resolution. Even reboot would not fix it automatically. It is fine to
have /etc/resolv.conf missing in some cases, but that is not supported
by resolved.
1. https://github.com/systemd/systemd/pull/21317
--
Petr Menšík
Software
le are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
#
Any more thoughts, comments, adjustments etc? Thanks!
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.
ven't made a single comment after his comments it is
still worth to proceed. I don't know if you vote, but I got an
impression Lennart has to agree or don't be involved. Was that wrong?
Petr
1. https://github.com/systemd/systemd/pull/21257
--
Petr Menšík
Software Eng
olved#DNSSEC
2. https://github.com/systemd/systemd/issues/4621
On 09. 06. 22 20:32, Adam Williamson wrote:
On Thu, 2022-06-09 at 19:50 +0200, Petr Menšík wrote:
I would propose also ability keep DNSSEC validation passthru. If
infrastructure provides cryptographic records, they should be available
://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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com
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
a build dependency on nscd that will also need to be removed.
>
> Both changes are minimal, requiring a removal of the dependency in the
> spec file, and a rebuild.
>
> == Contingency Plan ==
> * Contingency mechanism: Revert changes to glibc spec file and
> continue to ship nsc
On 11/5/20 12:49 PM, Florian Weimer wrote:
> * Petr Menšík:
>
>
> nscd has more usage downstream, leading to bugs such as:
>
> <https://bugzilla.redhat.com/show_bug.cgi?id=1551616>
I have very limited understanding of sssd principles. But I think it is
not compa
have to
verify it.
Cheers,
Petr
On 11/7/20 3:33 PM, Marius Schwarz wrote:
> Am 05.11.20 um 12:39 schrieb Petr Menšík:
>> There is no controversy with nscd, it just caches names and nothing
>> more. I think this is its advantage. Unless there is any stronger
>> reason, I am a
Hi Florian,
more below...
On 11/11/20 11:39 AM, Florian Weimer wrote:
> * Petr Menšík:
>>> This proposal is about nscd, not systemd-resolved.
>
>> systemd-resolved is mentioned in the title and the body of proposal. So
>> it seems it is about it.
>
> Fedora mad
o each connection. Reuse of TLS connection is
definitely wanted feature. Again, it might be limitation of current
implementation, but it is possible. I admit maintaining multiple
connections is much harder to implement (properly).
>
> or in other words: adding this conflicts with other (
On 11/17/20 10:12 AM, Lennart Poettering wrote:
> On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote:
>
>> But it does not have to learn everything about a server, because it
>> switched the active one. If it has to, try to find way to store server
>> instanc
t;
> ~~~
>
> $ sudo dnf update fedora-gpg-keys
>
> $ sudo dnf update fedora-repos --release 34
>
> ~~~
>
>
> Unfortunately, there has been no progress on [1] during past months.
>
>
>
> Vít
>
>
>
> [1] https://pagure.io/releng/issu
--releasever 34 upgrade \
fedora-gpg-keys fedora-repos fedora-repos-rawhide
Then just
(sudo) dnf upgrade
Correct key made it into updates, but no architecture symlinks were
provided.
On 8/25/20 11:40 AM, Petr Menšík wrote:
> Hi Vít,
>
> Unfortunately your workaround does not on m
now, but not great.
1. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/76
2. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/77
On 8/25/20 12:16 PM, Vít Ondruch wrote:
>
> Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a):
>> Hi Vít,
>>
>> Unfortunat
. And rawhide contains packages already
signed by the new key. Either install first gpg keys from koji, or
disable gpg when upgrading fedora-gpg-keys.
Best Regards,
Petr
On 8/25/20 12:05 PM, Daniel P. Berrangé wrote:
> On Tue, Aug 25, 2020 at 11:40:21AM +0200, Petr Menšík wrote:
>&g
e:
> Il 25/08/20 11:40, Petr Menšík ha scritto:
>> Hi Vít,
>>
>> Unfortunately your workaround does not on my rawhide container.
>> ...
>
> I just did
>
> ~~~
>
> $ sudo dnf update fedora-gpg-keys --nogp
ne is rebuilt, we can rebuild:
> mediaconch
>
> After pmix and avahi is rebuilt, we can rebuild:
> openmpi
>
> Best regards
> Ondřej Lysoněk
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send
> configured so. Both options make sense depending on whom you trust
>> more, but
>> resolved cannot guess by itself.)
>
> See RFC 8598 for a detailed instruction on how you must implement this
> for IKEv2 / IPsec VPNs. Other VPN technologies should do something
l-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.
info. If you don't know which variant, choose
the same as without resolved. That usually would be #2, right? If that
VPN specified server and it has higher priority, route there. Use any
place default route is sent to.
>
> Anyway, I think I am repeating myself here.
Sure,
;
> 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
>
--
st (for blocklist inclusion).
I am dnsmasq maintainer, which is found in most of cheap boxes you were
referring to. It can proxy DNSSEC, unlike resolved with turned off
support. Quite similar to resolved, it is not full-fledged DNS server,
it just forwards (and optionally caches) queries f
On 9/29/20 5:23 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:51, Petr Menšík (pemen...@redhat.com) wrote:
>
>>> I am just saying: Fedora cannot be focussed on just working for people
>>> who have a competent company admin and use their laptops in
>>> co
On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:
>
>>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>>> then there are some names resolvable only via the local
>>> D
On 9/29/20 5:21 PM, Lennart Poettering wrote:
> On Di, 29.09.20 16:03, Petr Menšík (pemen...@redhat.com) wrote:
>
>>> For example, if I have my laptop in my home wifi, connected to RH VPN,
>>> then there are some names resolvable only via the local
>>> D
l network, provided by mdns. Sure,
resolved can find it! As can avahi. No problems with signatures, it just
works. Because it was well designed by DNS aware people. Made in
validating client in mind. Do you need it anywhere else but local network?
I think these cases have simple wo
On 9/29/20 10:05 PM, Michael Catanzaro wrote:
>
>
> On Tue, Sep 29, 2020 at 4:28 pm, Petr Menšík wrote:
>> nss-dns is allright. All you need to have is dns server with domain
>> configurable servers.
>>
>> Those are:
>> - unbound (with dnssec-trigger au
at is correct, when resolved has serious
limitations in security.
I expect it would break any local resolver configured, unless it can
detect existing resolver and avoid activation of systemd-resolved.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
P
clear which part is related to systemd-resolved,
which part is related to systemd itself.
>
> But I see you point: it should be possible to opt out of systemd-resolved,
> and right now that's not entirely functional, because presets only decide
> whether systemd-resolved.service w
e resolution. They are not going better
with systemd upstream ignoring research of DNS specialists and instead
pushing its own 'correct' ideas.
And that precisely what we demand. If disabling systemd-resolved should
work and be tested, it should be the same with resolved not installed.
We
ture Fedora release, providing improved security if the user's
>> DNS server supports DNS over TLS.
>
> Why wait?
>
> This is something I've been interested in and was interested in
> implementing in Fedora.
--
Petr Menšík
Software E
ed into nameservers list when its broken. It should be
possible to use resolved just for mdns and llmnr and leave dns for
proper servers. If it were opt-in and not opt-out, no annoyed comments
would be required.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@red
tion files. It is only mentioned by resolvectl, which
normal user would never hear about.
It seems this should be easily configurable on installation (kickstart
default or something), but by default should be empty.
Prepared commented out FallbackDNS=8.8.8.8,... would work well.
-
On 10/1/20 5:44 PM, Vitaly Zaitsev via devel wrote:
> On 01.10.2020 16:54, Petr Menšík wrote:
>> But DNS over TLS does not bring you more privacy usually.
>
> It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
> on you and sell the collected data to th
ny way to signal systemd-resolved from
>> libvirt to say that in the bridge interface there is a DNS server and a
>> domain?
>>
>> Thank you.
>
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931C
DoT
> does not appear to be supported, reducing the security benefit. If you
> wish to manually configure systemd-resolved to prevent fallback to
> unencrypted DNS, set `DNSOverTLS=yes` in `/etc/systemd/resolved.conf`.
> Note that DoT is different than DNS over HTTPS (DoH) in that
ives:
> 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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E
with the editorial pass mostly being for
> egregious problems. In other words, I don't think it's actually much more
> heavyweight than a moderated announce mailing list would be.
>
> But I also am not sure Community Blog is the right audience — that's
> intended to be co
es/daemons. If you have shared library, I think
you should have 4 subpackages in total.
- usbrelay (utility and daemon)
- usbrelay-libs (shared library)
- usbrelay-devel (header files and usbrelay.so)
- python3-usbrelay (python module)
>
> Any help greatly appreciated
>
> Darryl
ect.org/en-US/packaging-guidelines/FontsPolicy/#_exceptions
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel@lists.fedoraproj
I prefer much more HTML documentation than PDF. While I try to make PDF
also available, HTML is more useful in offline situations, on a train
for example.
On 2/8/22 15:18, Daniel P. Berrangé wrote:
> On Mon, Feb 07, 2022 at 04:51:35PM +0100, Petr Menšík wrote:
>> Hi!
>>
>> I
On 2/8/22 20:13, Miro Hrončok wrote:
> On 08. 02. 22 19:50, Petr Menšík wrote:
>> Is FESCO okay with bundled javascript libraries in similar
>> packages?
>
> FESCo/FPC does allow bundling. See e.g.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedorap
On 9/15/21 1:54 PM, Miro Hrončok wrote:
> On 15. 09. 21 13:00, Vít Ondruch wrote:
>>
>> Dne 15. 09. 21 v 12:57 Petr Menšík napsal(a):
>>>
>>> Hi Sahana,
>>>
>>> it would be nice, if changelog entry contained bug id we could use
>>> to wat
for. This
>> works for me:
>>
>> /etc/libvirt/hooks/network.d/laptop-lab.sh
>>
>> #!/bin/bash
>> set -o nounset
>>
>> object="$1"
>> operation="$2"
>> suboperation="$3"
>> extra="$4&qu
g/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://pagu
de 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,
try and rebuild things, at least compose-critical
> things, now, but if straight rebuilds don't work might need people to
> help out.
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
On 1/4/21 12:38 PM, Miro Hrončok wrote:
> On 04. 01. 21 12:26, Petr Menšík wrote:
>> I had not time to coordinate rebuilt before Christmas, so I left it
>> intentionally without build. It was built by Jeff Law one day before I
>> departed to vacation. I haven't noticed
side tag yet.
>>
>> What's the name of the side tag?
>
> Right, I should have mentioned that: f34-build-side-35763
>
> Adrian
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931C
taskinfo?taskID=59985548
3. http://koji.fedoraproject.org/koji/taskinfo?taskID=59985586
4. https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/build/1886936/
--
Petr Menšík
Software Engineer, Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4
ending on' \
> -ex 'r -Ilib:test -e '\''Dir.glob %|./test/**/*_test.rb|,
> &method(:require)'\'' -- -v' \
> -ex 'bt full' \
> -ex c \
> -ex 'bt full' \
> -ex quit
> ~~~
>
> (and of course modif
; I don't think we should do a full %prep (because that sometimes sources
> can be huge and people do some preprocessing in %prep that might take
> a few minutes). But we should check that Source* and Patch* is defined
> and the spec file is syntactically valid. This would go a long wa
R CI results myself and do manual steps
depending of its result, it discourages me. Would like some bot to do that.
There seems to be support for [citest] for retriggering CI on package.
Could something similar be used to autobuild PR of people with commit
rights on explicitly enabled br
On 1/27/21 2:22 PM, Miro Hrončok wrote:
> On 27. 01. 21 13:45, Petr Menšík wrote:
>> I think one reason against maintainer's pull requests is poor tooling to
>> work with them. Filled fedpkg proposal to include ability to fork and
>> add personal fork to current reposit
in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end.
>
>
> Regards,
>
-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP:
.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
subscribe 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
rywhere even once,
> and promising to do that continuously as things change would be even
> worse.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedor
ave any opinion, how should resolvconf be supported on Fedora?
Any opinion against it?
1. https://src.fedoraproject.org/rpms/openresolv
2. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS
3. https://roy.marples.name/projects/openresolv/configuration/
--
Petr Menšík
Software Enginee
/sbin/resolvconf, in which case openvpn or dhclient knows it should
try to rewrite /etc/resolv.conf itself. Unless driven by NM or similar.
Init system and dns cache have very different requirements in system
integration.
On 2/22/21 4:38 PM, Lennart Poettering wrote:
> On Mo, 22.02.21 16
; 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
any
> guarantee when this piece of code will be migrating - so we are far from
> enabling this by default.
>
> Comments are welcomed.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
move resolvconf, when not
used. Current systemd does not pass such requirement.
1. https://bugzilla.redhat.com/show_bug.cgi?id=1923727
2.
https://src.fedoraproject.org/rpms/openresolv/blob/rawhide/f/openresolv.spec#_56
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.co
Hi Tadej,
thanks for confirmation.
On 2/23/21 10:37 AM, Tadej Janež wrote:
> Petr,
>
> thanks for looking into this.
>
> On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
>> After a quick glance at cloud-init code, it seems to me it does not
>> check /etc/resolv.
On 2/23/21 9:30 AM, Miroslav Suchý wrote:
> Dne 22. 02. 21 v 21:11 Petr Menšík napsal(a):
>> as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used,
>> when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61
>> might be used as fallback for older re
Hi David,
more below.
On 2/25/21 11:57 AM, David Sommerseth wrote:
> On 22/02/2021 16:29, Petr Menšík wrote:
>> Why? I thought about common interface to various DNS cache
>> implementations for workstations and different VPN providers available.
>> While I think the best p
ur DNS
> will be slower. Without split DNS, your DNS may not work properly at all.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_signature
Description:
e, we
> never did that, we only did that in case no better DNS configuration
> was available, i.e. as *last* *resort*, one step before giving up
> entirely).
But no-one asked that user, whether he hates Microsoft, Google or
Martians. Fallback
1 - 100 of 128 matches
Mail list logo
