On 4/25/19 6:10 PM, Björn Persson wrote:
It's perfectly possible for a number to be unique without being random.
As an example, you could hash the machine ID, which is supposedly
unique in space, and the system clock, which is unique in time. That
makes the hash unique in both space and time.
Lennart Poettering wrote:
>On Do, 25.04.19 13:14, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
>> That leaves the invocation IDs---the UUIDs need to be random to be truly
>> Universally Unique, but a limited entropy system is implicitly isolated, so
>> maybe the limited UUIDs could be
On Do, 25.04.19 13:14, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> On 4/25/19 5:14 AM, Lennart Poettering wrote:
> > For the hashtable seeds we use classic /dev/urandom (i.e. entropy from
> > a possibly non-initialized pool) since it's OK if those seeds are
> > crappy initially, as
On 4/25/19 5:14 AM, Lennart Poettering wrote:
For the hashtable seeds we use classic /dev/urandom (i.e. entropy from
a possibly non-initialized pool) since it's OK if those seeds are
crappy initially, as long as they get better over time, since we
reseed if we see too many hash collisions.
I
On Mi, 24.04.19 17:28, Björn Persson (Bjorn@rombobjörn.se) wrote:
> Lennart Poettering wrote:
> >As mentioned before: systemd itself already needs entropy itself (it
> >assigns a random 128bit id to each service invocation, dubbed the
> >"invocation ID" of it, and it generates the machine ID and
On Mi, 24.04.19 17:43, Tomas Mraz (tm...@redhat.com) wrote:
> > But how can it be successful? If systemd already needs to wait until
> > the pool is full to get the randomness it needs (and thus blocks
> > system boot-up as a whole) then what's the point in running rngd
> > afterwards? To reach
On Mi, 24.04.19 08:27, Adam Williamson (adamw...@fedoraproject.org) wrote:
> > a. systemd starts before rngd.
> > b. rngd runs before the entropy pool is full.
> > c. the entropy pool needs to be full for systemd to start
> >
> > a before b before c before a before b before c before a? How's that
On Wed, 24 Apr 2019 at 11:30, Björn Persson wrote:
> Lennart Poettering wrote:
> >As mentioned before: systemd itself already needs entropy itself (it
> >assigns a random 128bit id to each service invocation, dubbed the
> >"invocation ID" of it, and it generates the machine ID and seeds its
>
On Wed, 2019-04-24 at 14:16 +0200, Lennart Poettering wrote:
> On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com)
> wrote:
>
> > > As mentioned before: systemd itself already needs entropy itself
> > > (it
> > > assigns a random 128bit id to each service invocation, dubbed the
> > >
Lennart Poettering wrote:
>As mentioned before: systemd itself already needs entropy itself (it
>assigns a random 128bit id to each service invocation, dubbed the
>"invocation ID" of it, and it generates the machine ID and seeds its
>hash table hash functions)
Given that access to entropy during
On Wed, 2019-04-24 at 14:25 +0200, Lennart Poettering wrote:
> On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> > > As mentioned before: systemd itself already needs entropy itself (it
> > > assigns a random 128bit id to each service invocation, dubbed the
> > >
On Wed, 2019-04-24 at 12:02 +0200, Nikos Mavrogiannopoulos wrote:
> Can the jitter entropy gather be done by the kernel? It seems yes via
> the jitterentropy_rng module. So a combo of CONFIG_RANDOM_TRUST_CPU
> and the jitterentropy_rng may help in simplifying fedora (if people
> agree :).
This
On Wed, 24 Apr 2019 at 08:26, Lennart Poettering
wrote:
> On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> > > As mentioned before: systemd itself already needs entropy itself (it
> > > assigns a random 128bit id to each service invocation, dubbed the
> > > "invocation
On Mi, 24.04.19 06:40, Stephen John Smoogen (smo...@gmail.com) wrote:
> > As mentioned before: systemd itself already needs entropy itself (it
> > assigns a random 128bit id to each service invocation, dubbed the
> > "invocation ID" of it, and it generates the machine ID and seeds its
> > hash
On Mi, 24.04.19 12:37, Nikos Mavrogiannopoulos (n...@redhat.com) wrote:
> > As mentioned before: systemd itself already needs entropy itself (it
> > assigns a random 128bit id to each service invocation, dubbed the
> > "invocation ID" of it, and it generates the machine ID and seeds its
> > hash
On Wed, 24 Apr 2019 at 06:24, Lennart Poettering
wrote:
> On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote:
>
> > On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering
> > wrote:
> > > Sure, you can invoke rngd before systemd, in which case it would have
> > > to be able to
On Wed, Apr 24, 2019 at 12:24 PM Lennart Poettering
wrote:
> > > But why do that in userspace at all? the "Trust CPU RNG" kernel
> > > compile time option shows that these things are trivial to solve if
> > > people just want to. Instead of involving rngd at all, why not add a
> > > similar
On Mi, 24.04.19 12:02, Nikos Mavrogiannopoulos (n...@redhat.com) wrote:
> On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering
> wrote:
> > Sure, you can invoke rngd before systemd, in which case it would have
> > to be able to run as PID 1 itself pretty much and then hand over
> > things.
> >
>
On Thu, Apr 18, 2019 at 10:23 AM Lennart Poettering
wrote:
> Sure, you can invoke rngd before systemd, in which case it would have
> to be able to run as PID 1 itself pretty much and then hand over
> things.
>
> But why do that in userspace at all? the "Trust CPU RNG" kernel
> compile time option
On Mo, 22.04.19 08:35, Robert Marcano (rob...@marcanoonline.com) wrote:
> > What's the story anyway for rngd? Why would userspace be better at
> > providing entropy to the kernel than the kernel itself? Why do we
> > enable it on desktops at all, such systems should not be
> > entropy-starved.
>
On Do, 18.04.19 09:16, stan (upai...@zoho.com) wrote:
> On Thu, 18 Apr 2019 10:22:27 +0200
> Lennart Poettering wrote:
>
> > On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote:
>
> > > This seems like a false dichotomy, no? Surely, things like this are
> > > a possibility:
> >
On 4/17/19 4:38 AM, Lennart Poettering wrote:
On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
I think all of these are good ideas. "No udev-settle" seems like a nice
highlevel goal to shoot for.
Another one I might add: "No stuck stop jobs" - it annoys me every
On Thu, 18 Apr 2019 10:22:27 +0200
Lennart Poettering wrote:
> On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote:
> > This seems like a false dichotomy, no? Surely, things like this are
> > a possibility:
> >
> "LP" == Lennart Poettering writes:
LP> Yes it is. But so is rngd afaik?
The software isn't exclusive to any particular architecture, though it
may of course have different sources of entropy on different
architectures.
- J<
___
devel mailing
On Wed, 2019-04-17 at 10:55 -0400, Steve Grubb wrote:
> On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
> >
> >
> > > > I think all of these are good ideas. "No udev-settle" seems like a
> > > >
On Wed, Apr 17, 2019 at 10:55:58AM -0400, Steve Grubb wrote:
> On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
> >
> >
> > > > I think all of these are good ideas. "No udev-settle" seems like a
>
On Mi, 17.04.19 15:25, Simo Sorce (s...@redhat.com) wrote:
> On Wed, 2019-04-17 at 15:14 -0400, Steve Grubb wrote:
> > Many have tried to convince upstream about this. If anyone here has
> > influence,
> > please try.
>
> If upstream is currently resistant, what about turning rngd into a
>
On Mi, 17.04.19 16:05, Chris Murphy (li...@colorremedies.com) wrote:
> On Wed, Apr 17, 2019 at 11:36 AM Lennart Poettering
> wrote:
> >
> > Yeah, all that stuff is stuff the kernel could do better on its
> > own. If the CPU jitter stuff or the TPM stuff is a good idea, then why
> > not add that
On Mi, 17.04.19 15:14, Steve Grubb (sgr...@redhat.com) wrote:
> #!/bin/sh
>
> while [ 1 ]
> do
> /bin/cat /proc/sys/kernel/random/entropy_avail
> sleep 1
> done
>
> Then in another:
>
> cat /dev/random >/dev/null
>
> After a couple seconds, hit ctl-c to kill cat. Watch what
On Mi, 17.04.19 11:29, Japheth Cleaver (clea...@terabithia.org) wrote:
> On 4/17/2019 10:36 AM, Lennart Poettering wrote:
> > On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
> >
> > > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > > > rngd runs as regular
On Mi, 17.04.19 13:01, Jason L Tibbitts III (ti...@math.uh.edu) wrote:
> > "LP" == Lennart Poettering writes:
>
> LP> That's not true anymore. There's a kernel compile time option now
> LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel
> LP> sets that since a while.
>
>
On Wed, Apr 17, 2019 at 11:36 AM Lennart Poettering
wrote:
>
> Yeah, all that stuff is stuff the kernel could do better on its
> own. If the CPU jitter stuff or the TPM stuff is a good idea, then why
> not add that to the kernel natively, why involve userspace with that?
> i.e. if the TPM and the
On Tue, Apr 16, 2019 at 09:06:02AM -0700, Adam Williamson wrote:
> On Tue, 2019-04-16 at 11:48 -0400, Matthias Clasen wrote:
> > On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering
> > wrote:
> >
> > > Heya,
> > >
> > > today I installed the current Fedora 30 Workstation beta on my new
> > >
On Wed, 17 Apr 2019 15:14:54 -0400
Steve Grubb wrote:
> Ah...the devil is in the details. It does not credit entropy. This
> can easily be tested. systemctl stop rngd. Then open 2 terminal
> windows. In one terminal start this shell script:
>
> #!/bin/sh
>
> while [ 1 ]
> do
> /bin/cat
On Wed, 2019-04-17 at 15:14 -0400, Steve Grubb wrote:
> Many have tried to convince upstream about this. If anyone here has
> influence,
> please try.
If upstream is currently resistant, what about turning rngd into a
loadable kernel module and then insure it is in the initramfs and
loaded at
On Wednesday, April 17, 2019 1:36:08 PM EDT Lennart Poettering wrote:
> On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
> > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > > What's the story anyway for rngd? Why would userspace be better at
> > > providing
On 4/17/2019 10:36 AM, Lennart Poettering wrote:
On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
rngd runs as regular system service, hence what's the point of that
altogether? I mean, it runs so late during
> "LP" == Lennart Poettering writes:
LP> That's not true anymore. There's a kernel compile time option now
LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel
LP> sets that since a while.
Isn't this arch-dependent?
config RANDOM_TRUST_CPU
bool "Trust the CPU
On Wed, 2019-04-17 at 19:36 +0200, Lennart Poettering wrote:
> On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
>
> > On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
> > >
> > >
>
On Mi, 17.04.19 10:55, Steve Grubb (sgr...@redhat.com) wrote:
> On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> > On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
> >
> >
> > > > I think all of these are good ideas. "No udev-settle" seems like a
>
On Wednesday, April 17, 2019 4:38:18 AM EDT Lennart Poettering wrote:
> On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
>
>
> > > I think all of these are good ideas. "No udev-settle" seems like a
> > > nice
> > > highlevel goal to shoot for.
> > >
> > >
> > >
> > >
On Wed, Apr 17, 2019 at 10:38:18AM +0200, Lennart Poettering wrote:
> On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
>
> > > I think all of these are good ideas. "No udev-settle" seems like a nice
> > > highlevel goal to shoot for.
> > >
> > > Another one I might add:
On Di, 16.04.19 09:06, Adam Williamson (adamw...@fedoraproject.org) wrote:
> > I think all of these are good ideas. "No udev-settle" seems like a nice
> > highlevel goal to shoot for.
> >
> > Another one I might add: "No stuck stop jobs" - it annoys me every single
> > time when I reboot and
On Tue, 2019-04-16 at 11:48 -0400, Matthias Clasen wrote:
> On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering
> wrote:
>
> > Heya,
> >
> > today I installed the current Fedora 30 Workstation beta on my new
> > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> > crashed five
On Tue, Apr 9, 2019 at 12:08 PM Lennart Poettering
wrote:
> Heya,
>
> today I installed the current Fedora 30 Workstation beta on my new
> laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> crashed five times or so on me, always kicking me out of anaconda
> again, just because
On Sa, 13.04.19 14:03, Steve Grubb (sgr...@redhat.com) wrote:
> > If you enable lingering for a user, it's the "systemd --user" instance
> > (i.e. the per-user service manager) that is started at boot and
> > terminated at shutdown (instead of started at first login and
> > terminated at last
On Fri, 12 Apr 2019 11:21:13 +0200
Lennart Poettering wrote:
> On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosow...@nist.gov)
> wrote:
>
> > > The logic in systemd is more strict on putting boundaries on
> > > resource usage, and thus will by default not allow you to consume
> > >
On Fri, 12 Apr 2019 10:01:33 +0200
Dridi Boukelmoune wrote:
> > Was this the privileged operation? What privilege does it require? I
> > just run the command as a non-admin user and saw no errors or
> > prompts for passwords or anything.
>
> Are you part of the wheel group
No, this account
On Fri, 2019-04-12 at 16:29 +, Akarshan Biswas wrote:
> Mlocate too. I am not sure why is this package required but It
> tremendously slows down all of my PC(using magnetic disk hard drive).
> The first thing I do after installing Fedora Worstation is to remove
> it.
It only does that *one
Mlocate too. I am not sure why is this package required but It tremendously
slows down all of my PC(using magnetic disk hard drive). The first thing I do
after installing Fedora Worstation is to remove it.
Regards,
Akarshan Biswas
___
devel mailing
On Fri, Apr 12, 2019, at 7:13 AM, Lennart Poettering wrote:
> On Fr, 12.04.19 11:35, Dominik 'Rathann' Mierzejewski
> (domi...@greysector.net) wrote:
>
> > > Interestingly I think Google Chrome needs this when it installs,
> > > though it seems nonsensical to me. (Chrome is installed by about
On Friday, 12 April 2019 at 14:47, Chris Adams wrote:
> Once upon a time, Dominik 'Rathann' Mierzejewski
> said:
> > Chrome doesn't require atd explicitly (nor is it pulled in by any of its
> > dependencies).
>
> That's incorrect. The Google Chrome RPM requires /usr/bin/lsb_release,
> which is
Once upon a time, Dominik 'Rathann' Mierzejewski said:
> Chrome doesn't require atd explicitly (nor is it pulled in by any of its
> dependencies).
That's incorrect. The Google Chrome RPM requires /usr/bin/lsb_release,
which is from redhat-lsb-core, and that requires /usr/bin/at.
--
Chris
Le vendredi 12 avril 2019 à 13:12 +0200, Lennart Poettering a écrit :
> On Fr, 12.04.19 11:35, Dominik 'Rathann' Mierzejewski (
> domi...@greysector.net) wrote:
>
> > > Interestingly I think Google Chrome needs this when it installs,
> > > though it seems nonsensical to me. (Chrome is installed
On Fri, Apr 12, 2019 at 01:12:51PM +0200, Lennart Poettering wrote:
> Just out of curiosity, why does a web browser need a daily chrome job?
From the script's comment:
# It creates the repository configuration file for package updates, since
# we cannot do this during the google-chrome
* Lennart Poettering:
> Just out of curiosity, why does a web browser need a daily chrome job?
It uses this to persist itself, so that it is more difficult to remove
the Google repository.
I guess we can be lucky that it doesn't does this via /etc/ld.so.preload
or a kernel module.
Thanks,
On Fr, 12.04.19 11:35, Dominik 'Rathann' Mierzejewski (domi...@greysector.net)
wrote:
> > Interestingly I think Google Chrome needs this when it installs,
> > though it seems nonsensical to me. (Chrome is installed by about 50%
> > of our users given some informal stats, so writing it off would
On Thursday, 11 April 2019 at 18:09, Paul Frields wrote:
> On Tue, Apr 9, 2019 at 12:07 PM Lennart Poettering
> wrote:
[...]
> [...]
> > 3. atd? Do we still need that? Do we have postinst scripts that need
> >this? If so, wouldn't systemd-run be a better approach for those?
> >Isn't it
On Do, 11.04.19 20:49, Steve Grubb (sgr...@redhat.com) wrote:
> > > I run a bunch of background jobs like harvesting podcasts that are
> > > released weekly, collecting weather stats for my garden watering
> > > system, monitoring my power feed and UPS, collecting ADSB data,
> > > etc. I don't
On Do, 11.04.19 17:08, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> > The logic in systemd is more strict on putting boundaries on resource
> > usage, and thus will by default not allow you to consume resources
> > while you are not logged in. It's really how this always should have
>
> Was this the privileged operation? What privilege does it require? I
> just run the command as a non-admin user and saw no errors or prompts
> for passwords or anything.
Are you part of the wheel group and is wheel configured to be
password-less in sudo?
Dridi
On 4/11/2019 8:32 AM, Przemek Klosowski wrote:
On 4/11/19 10:16 AM, Lennart Poettering wrote:
However, that's intended for system services only (i.e. for services
running as users UID < 1000). For regular users (i.e. human ones,
those with UID >= 1000), the idea is to install timer units in the
On 4/11/19 1:08 PM, Lennart Poettering wrote:
I run a bunch of background jobs like harvesting podcasts that are released
weekly, collecting weather stats for my garden watering system, monitoring
my power feed and UPS, collecting ADSB data, etc. I don't think of those as
'system' services, so
On Thu, 11 Apr 2019 19:08:38 +0200
Lennart Poettering wrote:
> On Do, 11.04.19 11:32, Przemek Klosowski (przemek.klosow...@nist.gov)
> wrote:
>
> > On 4/11/19 10:16 AM, Lennart Poettering wrote:
> > > However, that's intended for system services only (i.e. for
> > > services running as users
On Thu, Apr 11, 2019 at 12:48:13PM -0400, Colin Walters wrote:
>
>
> On Tue, Apr 9, 2019, at 12:07 PM, Lennart Poettering wrote:
> > Heya,
> >
> > today I installed the current Fedora 30 Workstation beta on my new
> > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> >
On Do, 11.04.19 11:32, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> On 4/11/19 10:16 AM, Lennart Poettering wrote:
> > However, that's intended for system services only (i.e. for services
> > running as users UID < 1000). For regular users (i.e. human ones,
> > those with UID >= 1000),
On 4/11/19 2:12 AM, Vojtěch Trefný wrote:
That's actually a bug in libblockdev, only multipath plugin should
depend on device-mapper-multipath.
Bug opened.
https://bugzilla.redhat.com/show_bug.cgi?id=1699071
I can make the spec changes if you need help, but I wanted to document this action
On Tue, Apr 9, 2019, at 12:07 PM, Lennart Poettering wrote:
> Heya,
>
> today I installed the current Fedora 30 Workstation beta on my new
> laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> crashed five times or so on me, always kicking me out of anaconda
> again, just
On Tue, Apr 9, 2019 at 12:07 PM Lennart Poettering wrote:
[...]
> Can we maybe reduce the default set of packages a bit? In particular
> the following ones I really don't think should be in our default
> install:
Although somewhat orthogonal to your notes below, overall there's a
lot of
On 4/11/19 5:32 PM, Przemek Klosowski wrote:
I think the Android model is more relevant in this IoT age than the traditional
timesharing, 'kick-me-off-when-I-log-out' mode.
I would agree and observe that even the timesharing model was never really
kick-me-off-when-I-log-out.
Processes have
On Wed, 2019-04-10 at 12:49 +0200, Kamil Paral wrote:
> On Tue, Apr 9, 2019 at 8:21 PM Lennart Poettering
> wrote:
>
> > Hmm, but the installed OS is not 100% the same as the livesys, or is
> > it? If not, it should be possible to add a "systemctl disable
> > dmraid.service --root=/path/to/os"
On 4/11/19 10:16 AM, Lennart Poettering wrote:
However, that's intended for system services only (i.e. for services
running as users UID < 1000). For regular users (i.e. human ones,
those with UID >= 1000), the idea is to install timer units in the
per-user instance of the systemd service
On Do, 11.04.19 14:19, Steve Grubb (sgr...@redhat.com) wrote:
> > > But what, exactly, has cron fallen short in?
> >
> > In this case, I was trying to communicate that if systemd, which seems
> > to want to replace cron, can't meet all the use cases, we should be
> > reporting those that we find
On Thu, Apr 11, 2019 at 03:57:30PM +0200, Lennart Poettering wrote:
> On Do, 11.04.19 11:18, Daniel P. Berrangé (berra...@redhat.com) wrote:
>
> > > I don't know off hand of anything that would prevent it. Libvirt does
> > > process events from running qemu VMs, but if there's no API users
> > >
On Do, 11.04.19 11:18, Daniel P. Berrangé (berra...@redhat.com) wrote:
> > I don't know off hand of anything that would prevent it. Libvirt does
> > process events from running qemu VMs, but if there's no API users
> > connected to the daemon then I don't think libvirtd needs to be running;
> >
I'd say that backward compatibility is important and as a Fedora
workstation and server user I expect crond to work OOTB. Yes, users can
install and enable the service if needed but cron is such an essential
part of every system that I see no reason to exclude it.
On 4/11/19 6:30 AM, Brian (bex)
On Thu, 11 Apr 2019 12:30:11 +0200
"Brian (bex) Exelbierd" wrote:
> To: Japheth Cleaver
> CC: Development discussions related to Fedora
> Subject: Re: Can we maybe reduce the
> set of packages we install by default a bit? Date: Thu, 11 Apr 2019
> 12:30:11 +0200 Reply-To: Development
On Wed, Apr 10, 2019 at 8:54 PM Japheth Cleaver wrote:
>
> Reducing the Minimal size is, in general, good, but it's possible to go
> too far, and I think that's the case with low-level, *nix wide tools
> like this. I'm reminded of the time someone thought tar needed to go
> too:
On Tue, Apr 09, 2019 at 02:55:51PM -0400, Cole Robinson wrote:
> On 4/9/19 2:24 PM, Lennart Poettering wrote:
> > On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote:
> >
> >> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>> On Tue, Apr 09, 2019 at 06:07:09PM +0200,
On 4/10/19 11:57 AM, Kamil Paral wrote:
> On Wed, Apr 10, 2019 at 2:35 AM Chris Murphy
> wrote:
>
>>> 1. multipathd.
>>
>> I'm pretty sure it gets dragged in by the installer
>
>
> Nope, multipath seems to be present because libblockdev and udisks (and
> perhaps some more), which is in turn
On 4/10/2019 4:10 AM, Brian (bex) Exelbierd wrote:
On Tue, Apr 9, 2019 at 8:40 PM Japheth Cleaver wrote:
Is this really worth the effort? cronie in F30 is a 103K package, and a
decent chunk of that might be the ChangeLog. crontabs is all of 18K,
which is 95% the GPL and the RPM header. It
On Wed, Apr 10, 2019 at 3:22 PM Michael Watters wrote:
>
> You mean like systemd? ;)
Given the origin of this thread, I tried not to go there. However,
now that you've broached it, yes. This :D.
systemd is a lot of things, but it also is the way forward we think
that our audience wants. It
You mean like systemd? ;)
On 4/10/19 7:10 AM, Brian (bex) Exelbierd wrote:
> Adding software the user doesn't want
> to have it as assumed for other users is always a trade-off.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
On Tue, 2019-04-09 at 14:20 -0400, Neal Gompa wrote:
> On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson
> wrote:
> > On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote:
> > > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering
> > > wrote:
> > >
> > > > Heya,
> > > >
> > > > today I
On Mi, 10.04.19 08:16, Julen Landa Alustiza (ju...@zokormazo.info) wrote:
> I'm really interested on the livet crash, but I can't reproduce it with
> latest branched compose.
> Can you provide us with reproduction steps?
Urks, I don't remember. I think created an ESP part, two ext4
partitions,
On Di, 09.04.19 18:34, Chris Murphy (li...@colorremedies.com) wrote:
> > Ideally, the top 4 wouldn't be installed at all anymore (in case of
> > the first two at least on the systems which do not need them). But if
> > that's not in the cards, it would be great to at least not enable
> > these
On Mi, 10.04.19 12:49, Kamil Paral (kpa...@redhat.com) wrote:
> > Hmm, but the installed OS is not 100% the same as the livesys, or is
> > it? If not, it should be possible to add a "systemctl disable
> > dmraid.service --root=/path/to/os" somewhere, no?
>
> AFAIK, they are 100% same. There's a
On Tue, Apr 9, 2019 at 8:40 PM Japheth Cleaver wrote:
> Is this really worth the effort? cronie in F30 is a 103K package, and a
> decent chunk of that might be the ChangeLog. crontabs is all of 18K,
> which is 95% the GPL and the RPM header. It seems like a very small
> price to pay for something
On Tue, Apr 9, 2019 at 8:21 PM Lennart Poettering
wrote:
> Hmm, but the installed OS is not 100% the same as the livesys, or is
> it? If not, it should be possible to add a "systemctl disable
> dmraid.service --root=/path/to/os" somewhere, no?
>
AFAIK, they are 100% same. There's a hack, check
On Wed, Apr 10, 2019 at 2:35 AM Chris Murphy
wrote:
> > 1. multipathd.
>
> I'm pretty sure it gets dragged in by the installer
Nope, multipath seems to be present because libblockdev and udisks (and
perhaps some more), which is in turn required by GNOME:
$ rpm -q --whatrequires
Le mardi 09 avril 2019 à 10:11 -0700, Adam Williamson a écrit :
>
> To be specific here, 'at' is part of the @standard group. 'chrony' is
> pulled in several ways. It's part of @standard *if gnome-control-
> center
> is being installed*, so effectively it'll be installed with
> Workstation
> but
I'm really interested on the livet crash, but I can't reproduce it with
latest branched compose.
Can you provide us with reproduction steps?
Hau idatzi du Neal Gompa (ngomp...@gmail.com) erabiltzaileak (2019 api. 10,
az. (02:59)):
> On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy
> wrote:
> >
> >
On Tue, Apr 9, 2019 at 8:35 PM Chris Murphy wrote:
>
> On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering
> wrote:
> >
> > Heya,
> >
> > today I installed the current Fedora 30 Workstation beta on my new
> > laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> > crashed five
On Tue, Apr 9, 2019 at 10:07 AM Lennart Poettering wrote:
>
> Heya,
>
> today I installed the current Fedora 30 Workstation beta on my new
> laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
> crashed five times or so on me, always kicking me out of anaconda
> again, just because
On Tue, Apr 9, 2019 at 12:11 PM, Adam Williamson
wrote:
To be specific here, 'at' is part of the @standard group. 'chrony' is
pulled in several ways. It's part of @standard *if
gnome-control-center
is being installed*, so effectively it'll be installed with
Workstation
but not other
On 4/9/19 2:14 PM, Lennart Poettering wrote:
> On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote:
>
>> I think these two are here because of the blivet you mentioned earlier.
>> Advanced partitioning requires them to be there... and there do seem to be
>> people who actually do
On Di, 09.04.19 20:12, Richard Hughes (hughsi...@gmail.com) wrote:
> On Tue, 9 Apr 2019 at 19:27, Lennart Poettering wrote:
> > Hmm? Can you elaborate? Why does fwupd's runtime have something to do
> > with display flickers? Not grokking the connection?
>
> More information in
>
On Tue, 9 Apr 2019 at 19:27, Lennart Poettering wrote:
> Hmm? Can you elaborate? Why does fwupd's runtime have something to do
> with display flickers? Not grokking the connection?
More information in
https://github.com/hughsie/fwupd/commit/75b965d01d80d70ae51816acd4d4cafdaf792e99
-- in the case
On 4/9/19 2:20 PM, Lennart Poettering wrote:
> On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) wrote:
>
>> Basically, anything that's part of the install environment is going to
>> be present after a live install. That accounts for both of the above:
>> the installer supports
On 4/9/19 2:24 PM, Lennart Poettering wrote:
> On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote:
>
>> On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>> On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
multipathd [...] And beyond that, this daemon is
1 - 100 of 115 matches
Mail list logo
