)
- 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
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
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.
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
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:
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
#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
.
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
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
. 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
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
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
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
, 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
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://
: 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
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
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
://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
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
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
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
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
%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
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
://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
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
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
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.
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
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
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
.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
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:/
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
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
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
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
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
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
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,
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
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
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
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
/21 1:44 AM, Björn Persson wrote:
> Petr Menšík wrote:
>> No, that is the reason why I proposed it. Guidelines already state
>> *-filesystem packages does not have to be depended on [1]. Just one,
>> probably systemd or systemd-libs, should depend on it to get it
>> install
On 8/5/21 6:47 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Aug 05, 2021 at 04:45:31PM +0200, Petr Menšík wrote:
>> Depends on how many maintainers should fix their package, more below.
>>
>> On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Wed, Au
Depends on how many maintainers should fix their package, more below.
On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:
>> Hi Zbyszek,
>>
>> thanks for your comment. Wouldn't it be much clearer instead
ll I try a pull request on systemd?
Few notes below.
On 8/3/21 5:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 03, 2021 at 05:12:22PM +0200, Petr Menšík wrote:
>> It seems to me most of common services do not require systemd for
>> functionality. They might be able to
.org/en-US/packaging-guidelines/#_the_directory_is_also_owned_by_a_package_implementing_required_functionality_of_your_package>
>
> If you mean warning from fedora-review then it tool may be old. But
> reviewer must manually check all points and not use only automatic
> reviewing to
service should hard require systemd. Take dnsmasq package as an example.
# rpm -qv --requires dnsmasq | grep systemd
post: systemd
preun: systemd
postun: systemd
Which means it is not required outside upgrading process. Is that okay?
Is that wrong? I am not sure, not perfect I would say.
equired by
systemd, which would pass general rule about *-filesystem package not
required.
Any opinions?
Regards,
Petr
1.
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redh
sufficient research about usage of guile? If
package provides it as optional feature among many other features, how
should package owner test one feature is still demanded? Do we have any
best practice? Is asking on users@ and devel@ list enough?
>
> So: I'd like to see actual investi
Thanks, added you both. Anyone with direct feedback from people using it
is quite welcome.
On 3/31/21 7:38 PM, Michel Alexandre Salim wrote:
> Hi Petr,
>
> On Wed, 2021-03-31 at 14:12 +0200, Petr Menšík wrote:
>> Hello,
>>
>> strongswan and NetworkManager-strongswan
ccess with anyone willing to improve those packages.
Especially someone using they (almost) everyday would be ideal maintainer.
Regards,
Petr
--
Petr Menšík
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_signature
Description: OpenPGP digital sign
ld not timeout. DNS settings should be changed only after VPN is
connected and ready to forward packets. Are you sure no IP range
conflicts with used DNS servers?
Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4
On 3/10/21 5:43 PM, Colin Walters wrote:
>
>
> On Wed, Mar 10, 2021, at 7:32 AM, Petr Menšík wrote:
>> I think Björn's point is valid note. Because DNSSEC is used to verify
>> email of used key, but fedora.repo does not contain any hint about how
>> email in GPG
in DNS is not
> equivalent of **authorization**. It is still up to admin to approve the
> key. And it will not open your system. Not more than it is now.
> GPG in DNS is more equivalent of **authentication**. You will not need
> to compute fingerprint and manually compare it with fi
n 3/1/21 2:35 PM, Kevin Kofler via devel wrote:
> Petr Menšík wrote:
>> It is about 2 years when we were removing CAP_DAC_OVERRIDE from our
>> services, because selinux-policy does not grant it anymore. I think it
>> is a good thing. Running as openvpn user, but requiring t
On 2/25/21 4:50 PM, David Sommerseth wrote:
> Hi!
>
> On 25/02/2021 14:39, Petr Menšík wrote:
> [..snip...]
>>
>> This case is exactly what I am trying to prevent. There is multiple
>> implementations of dns cache, most of them can support split-DNS by some
>>
ng also by a big DNS cache for whole network. On
the contrary. It is a bit suppressed by DNS over TLS/HTTPS, but default
configuration still should obtain DNS from DHCP/autoconfiguration. On
servers, clients, VMs and containers.
>
> best regards,
> Marius Schwarz--
Petr Menšík
Software Eng
On 2/26/21 9:06 AM, Lennart Poettering wrote:
> On Do, 25.02.21 23:58, Petr Menšík (pemen...@redhat.com) wrote:
>
>> No, I don't think so. Anyone who manages the system should have basic
>> understanding how to configure it. If not obvious, needs good
>> document
1
resolvectl dns virbr0 example.lan
I don't know any permanent way to store this information to NM or
systemd-resolved, so it would configure it itself next boot. Maybe
systemd guys would know a way.
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP
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
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:
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
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 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.
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
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
; 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
/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
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
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
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
.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
-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:
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,
>
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
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
; 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
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
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
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
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
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 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
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 (
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
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
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
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
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
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
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
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
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.
-
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
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
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
1 - 100 of 118 matches
Mail list logo