On Wednesday, April 15, 2020 10:22:42 PM CEST Göran Uddeborg wrote:
> Just in case someone with the same problem stumbles on my mail when
> googling, I'll explain what I did in the end.
>
> I got the suggestion to disable nspawn when building. That solved the
> initial problem, but introduced two
Wed, 15 Apr 2020 16:59:04 -0600
Chris Murphy :
> Maybe this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1823463
Thank You. I'm still on util-linux-2.35.1-7 and I'll closely check an
update with util-linux-2.35.1-8.
> I can reproduce the complaint from 'hwclock -s' but it seems at least
> on
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-04-16 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2020-04-16 09:00 PDT US/Pacific
2020-04-16
On Thu, 16 Apr 2020 at 00:52, Dan Čermák wrote:
>
> clime writes:
>
> > On Mon, 13 Apr 2020 at 10:55, Dan Čermák
> > wrote:
> >>
> >> Hi list,
> >>
> >> my question is pretty much $subject: Why doesn't Koschei kick of
> >> real builds off packages on dependency changes? From my naive POV that
>
On Wed, Apr 15, 2020 at 3:08 AM Łukasz Posadowski
wrote:
>
>
> Today I had an issue during regular system update. Apparently time was
> set on Unix 0 (with +1 hour for a timezone), which confused at least
> dnf, upgrade failed and system didn't respond to anything, including
> ctrl+alt+del. Kernel
https://bugzilla.redhat.com/show_bug.cgi?id=1813603
--- Comment #23 from Fedora Update System ---
FEDORA-MODULAR-2020-b6c633d5fe has been pushed to the Fedora 30 Modular stable
repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail be
clime writes:
> On Mon, 13 Apr 2020 at 10:55, Dan Čermák
> wrote:
>>
>> Hi list,
>>
>> my question is pretty much $subject: Why doesn't Koschei kick of
>> real builds off packages on dependency changes? From my naive POV that
>> looks like the missing piece to give us the "OBS-experience". Havi
On Mon, 13 Apr 2020 at 10:55, Dan Čermák wrote:
>
> Hi list,
>
> my question is pretty much $subject: Why doesn't Koschei kick of
> real builds off packages on dependency changes? From my naive POV that
> looks like the missing piece to give us the "OBS-experience". Having
> that at least in Rawhi
Fabio Valentini writes:
> On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák
> wrote:
>>
>> Hi list,
>>
>> my question is pretty much $subject: Why doesn't Koschei kick of
>> real builds off packages on dependency changes? From my naive POV that
>> looks like the missing piece to give us the "OBS-exper
This is your reminder that the Go/No-Go meeting for the Fedora 32
Final release will be held tomorrow, Thursday, 2020-04-16 at 17:00 UTC
in #fedora-meeting-1. For more information, see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting
View the meeting on Fedocal at:
https://apps.fedoraproject.org/c
On Wed, Apr 15, 2020, at 1:27 PM, Daniel Walsh wrote:
> On 4/15/20 10:07, Lennart Poettering wrote:
> > On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
> >
> >> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/systemd-resolv
On 4/15/20 15:01, clime wrote:
> On Wed, 15 Apr 2020 at 09:50, Pavel Raiskup wrote:
>> Hey all, I'd like to write scripts like:
>>
>> $ cat script
>> #! /bin/shebang which python3-evaluates this in container from image FOO
>> print("Hello world")
>>
>> .. and be able to run them just l
Just in case someone with the same problem stumbles on my mail when
googling, I'll explain what I did in the end.
I got the suggestion to disable nspawn when building. That solved the
initial problem, but introduced two other. I was able to work around
those too by bind mounting /run and /tmp in
On Wed, 2020-04-15 at 18:50 +0200, Igor Gnatenko wrote:
> Hello,
>
> I have ThinkPad T480s and after latest kernel upgrades on Rawhide I
> see something like:
>
> ```
> exit_boot() failed!
> efi_main() failed!
> ```
>
> Right after grub and then system reboots.
>
> I found on the internet that
On Wed, 15 Apr 2020 at 09:50, Pavel Raiskup wrote:
>
> Hey all, I'd like to write scripts like:
>
> $ cat script
> #! /bin/shebang which python3-evaluates this in container from image FOO
> print("Hello world")
>
> .. and be able to run them just like `./script [ARGS ...]`.
>
> I playe
On 15. 04. 20 20:30, Josh Stone wrote:
On 4/15/20 11:19 AM, Miro Hrončok wrote:
I can help you setup a test that builds the packages with rpmbuild or in local
mock. However, the CI pipeline only runs on x86_64.
Can that x86_64 host still use an i686 mock?
We use it in PR workflow and we only
On 4/15/20 11:19 AM, Miro Hrončok wrote:
> I can help you setup a test that builds the packages with rpmbuild or in
> local
> mock. However, the CI pipeline only runs on x86_64.
Can that x86_64 host still use an i686 mock?
___
devel mailing list -- dev
On Wed, Apr 15, 2020 at 12:05:40PM -0500, Michael Catanzaro wrote:
> On Wed, Apr 15, 2020 at 4:33 pm, Zbigniew Jędrzejewski-Szmek
> wrote:
> >https://github.com/systemd/systemd/pull/15437
>
> To change this for existing Fedora systems is going to require some
> scriptlet hackery... somewhere (sys
On 15. 04. 20 20:11, Florian Weimer wrote:
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.)
I can help you setup a test that builds the packages with rpmbuild or i
* 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 ab
Is this problem back?
https://koji.fedoraproject.org/koji/taskinfo?taskID=43439516
https://koji.fedoraproject.org/koji/taskinfo?taskID=43439614
Vít
Dne 09. 04. 20 v 20:28 Florian Weimer napsal(a):
> Sorry about your troubles.
>
> I have identified the problematic upstream change, and we will
On Wed, 15 Apr 2020 15:46:02 +0200
Lennart Poettering wrote:
> resolved has three modes:
[Snipped for brevity.]
Thanks. Saved for future reference.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@li
On 4/15/20 10:07, Lennart Poettering wrote:
> On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
>
>> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/systemd-resolved
>>>
>>> == Summary ==
>>>
>>> Enable systemd-resolved by defau
On Wed, Apr 15, 2020 at 4:33 pm, Zbigniew Jędrzejewski-Szmek
wrote:
https://github.com/systemd/systemd/pull/15437
To change this for existing Fedora systems is going to require some
scriptlet hackery... somewhere (systemd package, maybe?).
___
dev
OLD: Fedora-32-20200414.n.0
NEW: Fedora-32-20200415.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:2
Upgraded packages: 4
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:828.16 KiB
Size of
Hello,
I have ThinkPad T480s and after latest kernel upgrades on Rawhide I
see something like:
```
exit_boot() failed!
efi_main() failed!
```
Right after grub and then system reboots.
I found on the internet that passing `efi=no_disable_early_pci_dma`
could help and it actually did!
Anybody el
On Wed, Apr 15, 2020 at 10:02:17AM -0500, Michael Catanzaro wrote:
> On Wed, Apr 15, 2020 at 4:12 pm, Lennart Poettering
> wrote:
> >The suggested line in nsswitch.conf is:
> >
> >hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
>
> My plan is to use:
>
> hosts: files resolve
OLD: Fedora-Rawhide-20200414.n.0
NEW: Fedora-Rawhide-20200415.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 0
Dropped packages:2
Upgraded packages: 141
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:828.16
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 architect
On Mi, 15.04.20 10:48, Florian Weimer (fwei...@redhat.com) wrote:
> > As I understand the terminology the "stub resolver" in systemd-resolved
> > refers to the thing that listens on 127.0.0.53 and that won't do
> > anything clever with single label queries because it will expect
> > it is answerin
* Michael Catanzaro:
> On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer
> wrote:
>> And we really need to move /etc/nsswitch.conf out of glibc. We spend
>> some time on maintaining that file, when in fact it doesn't matter
>> because too many scriptlets and programs patch it.
>
> Moving it to aut
* Lennart Poettering:
> On Mi, 15.04.20 10:09, Michael Catanzaro (mcatanz...@gnome.org) wrote:
>
>> You're right that continuing to use nss-dns would avoid any such problems
>> while maintaining the other benefits of systemd-resolved. That could be a
>> fallback plan if needed.
>
> So, it is my un
On Mi, 15.04.20 10:53, Florian Weimer (fwei...@redhat.com) wrote:
> Thanks. Does this mean that no search list processing happens, for
> neither single-label names (per for the first paragraph), nor for
> multi-label names (per the routing description)? Or is this process
> described in some oth
On Wed, Apr 15, 2020 at 5:06 pm, Lennart Poettering
wrote:
If RH VPN configures "redhat.com" as search domain for their VPN then
this means all redhat.com traffic is automatically pulled over to the
VPN and will not be routed elsewhere anymore.
In particular: current behavior is that redhat.co
On Mi, 15.04.20 09:29, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > Most Kubernetes/OKD clusters assume that both single-label and
> > multi-label query names are forwarded over DNS (contrary to ICANN
> > recommendations), and that DNS servers are processed in listed order for
On Mi, 15.04.20 10:09, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> You're right that continuing to use nss-dns would avoid any such problems
> while maintaining the other benefits of systemd-resolved. That could be a
> fallback plan if needed.
So, it is my understanding that containers as d
On Wed, Apr 15, 2020 at 10:09 am, Michael Catanzaro
wrote:
Hm, it sounds like this is the main outstanding issue from this
discussion. It is beyond my expertise. I guess we'll need a bug
report where the relevant experts can figure out whether we need to
change Kubernetes or systemd here.
Yo
On Wed, Apr 15, 2020 at 10:08 am, Florian Weimer
wrote:
* Ben Cotton:
Enable systemd-resolved by default. glibc will perform name
resolution
using nss-resolve rather than nss-dns.
Is this intended for Fedora Server and others as well, or just
Workstation? I assume it's for everywhere.
On Mi, 15.04.20 10:02, Michael Catanzaro (mcatanz...@gnome.org) wrote:
>
> On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer wrote:
> > And we really need to move /etc/nsswitch.conf out of glibc. We spend
> > some time on maintaining that file, when in fact it doesn't matter
> > because too many s
On Mi, 15.04.20 10:08, Florian Weimer (fwei...@redhat.com) wrote:
> > systemd-resolved has been enabled by default in Ubuntu since Ubuntu
> > 16.10, but please note we are doing this differently than Ubuntu has.
> > Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
> > nss-dns
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 se
On Wed, Apr 15, 2020 at 4:12 pm, Lennart Poettering
wrote:
The suggested line in nsswitch.conf is:
hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname
My plan is to use:
hosts: files resolve [!UNAVAIL=return] mdns4_minimal [NOTFOUND=return]
dns myhostname
Apparently there
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
On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer
wrote:
And we really need to move /etc/nsswitch.conf out of glibc. We spend
some time on maintaining that file, when in fact it doesn't matter
because too many scriptlets and programs patch it.
Moving it to authselect might be sensible.
BTW:
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
On Mi, 15.04.20 16:27, Florian Weimer (fwei...@redhat.com) wrote:
> > That said, resolved has a bus API for resolving hosts too, which gives
> > a bit richer an API to do things, instead of using
> > gethostbyname(). resolved parses and caches /etc/hosts for that
> > natively, so that we can serve
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 program
On Mi, 15.04.20 09:01, Daniel J Walsh (dwa...@redhat.com) wrote:
> > I didn't consider cases where systemd is not running because Fedora
> > hasn't supported booting without systemd in about a decade. But I
> > guess the problem here is for containers where systemd is not running
> > inside the co
* Lennart Poettering:
> On Mi, 15.04.20 09:36, Florian Weimer (fwei...@redhat.com) wrote:
>
>> * Michael Catanzaro:
>>
>> > On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
>> > wrote:
>> >> I guess the lesson here is the nsswitch.conf change should be
>> >> clarified in the proposal.
On Mi, 15.04.20 09:36, Florian Weimer (fwei...@redhat.com) wrote:
> * Michael Catanzaro:
>
> > On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
> > wrote:
> >> I guess the lesson here is the nsswitch.conf change should be
> >> clarified in the proposal.
> >
> > OK, I've just added it
On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
>
> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/systemd-resolved
> >
> > == Summary ==
> >
> > Enable systemd-resolved by default. glibc will perform name resolution
> > usi
On Mi, 15.04.20 11:14, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 14.04.2020 21:23, Ben Cotton wrote:
> > Enable systemd-resolved by default. glibc will perform name resolution
> > using nss-resolve rather than nss-dns.
>
> I've tested systemd-resolved on my laptop for a mo
* 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 resol
On Di, 14.04.20 15:52, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On Tue, 14 Apr 2020 16:18:02 -0500
> Michael Catanzaro wrote:
>
> > NetworkManager has three DNS backends: default (nss-dns, what we use
> > currently), dnsmasq, and systemd-resolved. The default backend just
>
On Di, 14.04.20 12:57, Kevin Fenzi (ke...@scrye.com) wrote:
> Can you expand on what that means?
>
> Does it mean:
>
> a) systemd-resolved will use DNS over TLS if it detects that
> the nameservers it is querying can do so (ie, it would do a query to
> port 853 of the nameservers dhcp or static co
On Mi, 15.04.20 09:33, Florian Weimer (fwei...@redhat.com) wrote:
> * Omair Majid:
>
> > (I was secretly hoping there was a way to bump rlim_cur past
> > the current value of rlim_max...)
>
> Current Fedora seems to set the hard limit to at least 4096 for all
> processes. Isn't that enough?
See
Missing expected images:
Iot dvd x86_64
Iot dvd aarch64
Failed openQA tests: 1/8 (x86_64)
Old failures (same test failed in Fedora-IoT-33-20200414.0):
ID: 577576 Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/577576
Soft failed openQA tests
On 4/14/20 17:26, Michael Catanzaro wrote:
> On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
> wrote:
>> I guess the lesson here is the nsswitch.conf change should be
>> clarified in the proposal.
>
> OK, I've just added it at the end of this part here:
>
> "systemd-libs currently has
> Follow the trail: uglify-js requires nodejs-acorn, which requires
> nodejs-rollup, which requires that.
Ah thanks for checking it. I should run `dnf repoquery --whatrequres` more.
Can someone take uglify-js as a main maintainer? I can give it to you.
https://src.fedoraproject.org/rpms/uglify-js
On Wed, Apr 15, 2020 at 5:31 AM Tom Hughes via devel
wrote:
>
> On 15/04/2020 10:14, Vitaly Zaitsev via devel wrote:
> > On 14.04.2020 21:23, Ben Cotton wrote:
> >> Enable systemd-resolved by default. glibc will perform name resolution
> >> using nss-resolve rather than nss-dns.
> >
> > I've teste
* Tom Hughes:
> I'm not sure OpenVPN itself has any way to do DNS setup automatically
> on linux but the NetworkManager integration might, I don't use that
> though.
Yes, the NetworkManager integration seems to mirror what happens on
Windows, by looking at the foreign_option_* environment variabl
No missing expected images.
Passed openQA tests: 1/1 (x86_64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
On 4/14/20 5:17 PM, Miro Hrončok wrote:
On 14. 04. 20 15:30, Petr Pisar wrote:
I don't know what specific features of rpmdev-vercmp tool you need, but
version comparison is implemented in rpmvercmp() function of rpm library.
Exactly that, but without the need to use ctypes.
Note thought tha
On 15/04/2020 10:14, Vitaly Zaitsev via devel wrote:
On 14.04.2020 21:23, Ben Cotton wrote:
Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.
I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Someti
On Wed, 15 Apr 2020 at 11:13, Jun Aruga wrote:
>
> > jaruga: nodejs-source-map-support, jruby
>
> I am okay to let nodejs-source-map-support orphan.
> I have no idea why nodejs-source-map-support affects me.
Follow the trail: uglify-js requires nodejs-acorn, which requires
nodejs-rollup, which re
On 14.04.2020 21:23, Ben Cotton wrote:
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Sometimes it stopped responding and I needed to manually
re
On 15/04/2020 09:48, Florian Weimer wrote:
>>> Is this expected to work with the Red Hat VPN out of the box, or do we
>>> have to disable all this and use a custom configuration? Has this been
>>> discussed with Infosec? It looks like this will break their DNS
>>> sinkholing for domains such as
Today I had an issue during regular system update. Apparently time was
set on Unix 0 (with +1 hour for a timezone), which confused at least
dnf, upgrade failed and system didn't respond to anything, including
ctrl+alt+del. Kernel was not installed correctly and panicked during
boot. I was able to
> jaruga: nodejs-source-map-support, jruby
I am okay to let nodejs-source-map-support orphan.
I have no idea why nodejs-source-map-support affects me.
Jun
--
Jun | He - His - Him
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe s
On 15/04/2020 09:53, Florian Weimer wrote:
> Thanks. Does this mean that no search list processing happens, for
> neither single-label names (per for the first paragraph), nor for
> multi-label names (per the routing description)? Or is this process
> described in some other context?
That text
* Tom Hughes:
>· Single-label names are routed to all local interfaces capable of IP
>multicasting, using the LLMNR protocol. Lookups for IPv4 addresses
>are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
>only sent via LLMNR on IPv6.
* Tom Hughes:
> On 15/04/2020 09:08, Florian Weimer wrote:
>
>> I cannot find documentation of the systemd stub resolver behavior: how
>> it handles search list processing, and how it decides which upstream
>> name servers to query.
>
> As I understand the terminology the "stub resolver" in system
On 15/04/2020 09:29, Tom Hughes via devel wrote:
> I'm not sure what happens if there are multiple interfaces with
> no specific routing but I think it may try them all?
Found the documentation now - it does try them all. Full details
from systemd-resolved(8) are:
Lookup requests are rout
On 15/04/2020 09:08, Florian Weimer wrote:
I cannot find documentation of the systemd stub resolver behavior: how
it handles search list processing, and how it decides which upstream
name servers to query.
As I understand the terminology the "stub resolver" in systemd-resolved
refers to the th
* Ben Cotton:
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
Is this intended for Fedora Server and others as well, or just
Workstation? I assume it's for everywhere.
> systemd-resolved has been enabled by default in Ubuntu sinc
Hey all, I'd like to write scripts like:
$ cat script
#! /bin/shebang which python3-evaluates this in container from image FOO
print("Hello world")
.. and be able to run them just like `./script [ARGS ...]`.
I played a bit with [1] today, and I'd like to package it to Fedora for at
l
On 15. 04. 20 9:45, David Schwörer wrote:
On 4/14/20 11:06 AM, Miro Hrončok wrote:
orangefs orphan 1
weeks ago
I took orangefs and rebuild it.
However I am not able to close or take the FTBFS bug [1]
The documentation only says I should take t
On 4/14/20 11:06 AM, Miro Hrončok wrote:
> orangefs orphan 1
> weeks ago
I took orangefs and rebuild it.
However I am not able to close or take the FTBFS bug [1]
The documentation only says I should take the bug, but not how [2]
I also took git-c
* Michael Catanzaro:
> On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
> wrote:
>> I guess the lesson here is the nsswitch.conf change should be
>> clarified in the proposal.
>
> OK, I've just added it at the end of this part here:
>
> "systemd-libs currently has
> [https://src.fedor
* Omair Majid:
> (I was secretly hoping there was a way to bump rlim_cur past
> the current value of rlim_max...)
Current Fedora seems to set the hard limit to at least 4096 for all
processes. Isn't that enough?
Thanks,
Florian
___
devel mailing list
On Wed, Apr 15, 2020 at 07:42:12AM +0200, Zdenek Dohnal wrote:
> On 4/14/20 9:23 PM, Ben Cotton wrote:
> > === Multicast DNS ===
> >
> > systemd-resolved's multicast DNS support conflicts with Avahi. Per
> > recommendation from the systemd developers, we will change the default
> > value of this se
No missing expected images.
Failed openQA tests: 1/171 (x86_64)
ID: 577105 Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/577105
Soft failed openQA tests: 17/171 (x86_64)
(Tests completed, but using a workaround for a known bug)
ID: 577068
82 matches
Mail list logo
