Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Zdenek Kabelac]

Dne 25. 05. 23 v 1:47 Demi Marie Obenour napsal(a):

On 5/24/23 08:44, Zdenek Kabelac wrote:

Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a):

I noticed that by default, Qubes OS has voluntary kernel preemption
as opposed to full preemption.  I found that enabling full preemption
(preempt=full on kernel command line) makes the system significantly
more responsive under heavy I/O load.  In particular, if I build a
kernel in a Qubes OS VM, it significantly degrades responsiveness
without preempt=full.  With preempt=full, the system remains
responsive.  The storage stack used is LVM thin provisioning on LUKS,
and I have observed significant CPU usage in dom0 kernel threads with
names that indicate they are related to dm-thin and dm-crypt.

The kernel config used by the Qubes kernel package I use (6.1.28) is
based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd)
indicated that the same arguments apply to Fedora.  Therefore, I am
asking if Fedora should use full kernel preemption by default.


Hi Demi


Could you please provide   'dmsetup table'   - so we could see how doe your
device stack looks like ?

The output of 'dmsetup table' contains all qube names so I would prefer to not
post it publicly.  The device stack is NVMe -> crypt -> linear -> thin pool -> 
thin.


Hi


You could always 'anonymize' table names with awk/python/perl/sed   - aka just 
leave there first letter  - names are not important - rather the content of 
table line itself and the complexity of device stack. There are some limits 
over which the active usage of thins  may degrade the performance of the system.


But it's always easier to see & reproduce on some user's data.

So just unify/mange/anonymize the names - but tables would be interesting to 
see.

You may also add  'dmsetup info -c' &  lsblk



Regards


Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Zdenek Kabelac]

Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a):

I noticed that by default, Qubes OS has voluntary kernel preemption
as opposed to full preemption.  I found that enabling full preemption
(preempt=full on kernel command line) makes the system significantly
more responsive under heavy I/O load.  In particular, if I build a
kernel in a Qubes OS VM, it significantly degrades responsiveness
without preempt=full.  With preempt=full, the system remains
responsive.  The storage stack used is LVM thin provisioning on LUKS,
and I have observed significant CPU usage in dom0 kernel threads with
names that indicate they are related to dm-thin and dm-crypt.

The kernel config used by the Qubes kernel package I use (6.1.28) is
based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd)
indicated that the same arguments apply to Fedora.  Therefore, I am
asking if Fedora should use full kernel preemption by default.



Hi Demi


Could you please provide   'dmsetup table'   - so we could see how doe your 
device stack looks like ?


Aren't you disabling work-queues on the table line for crypt targets ?


Regards


Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Zdenek Kabelac]

Dne 10. 09. 20 v 17:53 Michael Catanzaro napsal(a):

On Thu, Sep 10, 2020 at 9:36 am, Kamil Paral  wrote:
On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov 
 wrote:

# authselect apply-changes
 [error] [/etc/authselect/nsswitch.conf] has unexpected content!
 [error] Unexpected changes to the configuration were detected.
 [error] Refusing to activate profile unless those changes are removed or 
overwrite is requested.
 Some unexpected changes to the configuration were detected. Use 'select' 
command instead.


I see the same error.


I'm a bit concerned that two different people are seeing this. I don't think 


Well count me as 3rd. - I've seen this to happen on upgrade from fc32 rawhide
to fc34 rawhide.

It's been basically horrible experience reported here:

https://bugzilla.redhat.com/show_bug.cgi?id=1875000

so I've originally accounted zero length nsswitch.conf issue to this problem,
but it most like relates to this thread (and yeah - it took me a while
to figure out how to make networking DNS running properly again,
but nothing compered with restoration of crashed DNF transaction...

Regards

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

[Zdenek Kabelac]

Dne 01. 07. 20 v 10:29 Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a):

On 29.06.2020 22:04, Ben Cotton wrote:

Fedora only support these RAID sets when they are already configured in
the BIOS at installation time. So we can solve the problem of
dmraid.service still depending on the obsolete udev-settle service by
making dmraid.service disable itself if no supported RAID sets are found
on its first run.




We also shouldn't be lightly recommending masking or uninstalling of
packages because unexperienced users see such recommendations and may
follow them without fully understanding what the effect is.

Instead, services should be smart enough to exit quickly if they have
nothing to manage (which lvm2-monitor already does). And ideally,
storage services should only be started in response to hotplug events
that detect given hardware type to exist (which apparently could be
improved a bit, but as long as the noop cost is small, this is not a
such a big issue).



Hi

And this is exactly what is our lvm2 service doing - it exits when it's being 
idle for some tens of seconds.


Yep I also believe 'default' should just work in most configuration - even 
when it's not always the top most optimal way to handle things.


Then skilled admins should be capable to set more optimal setups.

But I also believe making the lvm2 installation more 'optional' would be good 
thing in making i.e. VM/container images actually smaller - as those often
do not need to have these tools & service installed at all  - they just got a 
single storage device to be on. But since currently lot of package now

get transient dependecy chains - lvm2 is often sucked-in even when
there is clearly no use for it at all.

So that's why having better 'package dependency' design matter - and the size 
and efficiency still is important for some of us


Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

[Zdenek Kabelac]

Dne 30. 06. 20 v 14:08 Hans de Goede napsal(a):

Hi,

On 6/30/20 1:27 PM, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a):

Hi,

On 6/30/20 12:27 PM, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a):

Hi,

On 6/30/20 11:42 AM, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a):

On 30.06.2020 11:23, Igor Raits wrote:

Sadly you can't have lvm2 not installed:


Yes, but it can be disabled.





I'm sorry but e.g. dmraid-activation still running on every Fedora
Workstation install, instead of it being event activated does not give
the impression of you paying attention.


Yes -  you are most likely missing that 'lvm2-monitoring' does something 
only when it's in-use.


Ok, so I just checked an you are right, in my memory I was
disabling this because it kept a running process around
doing nothing, but now I see:

[hans@x1 ~]$ sudo systemctl status lvm2-monitor.service
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeve>
  Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled; 
ven>
  Active: active (exited) since Tue 2020-06-30 10:37:37 CEST; 3h 20min ago
    Docs: man:dmeventd(8)
  man:lvcreate(8)
  man:lvchange(8)
  man:vgchange(8)
    Main PID: 903 (code=exited, status=0/SUCCESS)
   Tasks: 0 (limit: 18803)
  Memory: 0B
     CPU: 0
  CGroup: /system.slice/lvm2-monitor.service

Ideally this would not start at all when not necessary, but
yes there is lower hanging fruit, sorry for the noise. >


Well there can be some extras bit of settings tuned slightly better - but
overall I believe we do a pretty good here - service is automatically exiting 
also when last user goes away for a longer period of time -  so really

lvm2-monitoring as long as is not in-use shouldn't be bothering users.



For me lvm2-monitor.service quickly exits using just 34mS CPU time.



ATM we are not recommending users to enable services themselves once the 
come to conclusion they need it - we consider them granted from installation 
of package.


1.) If the user does not need lvm2 - it should not be installed.


Well this one is a bit tricky, for one because even basic lvm support
(just VGs and LVs and nothing else) brings in support for all the
other less basic features which lvm/dm has.

And with livecd installs, the package-set which is on the livecd
is also what will end up being installed, even if the user has chosen
to use a raw partition (note since lvm is the default this is not a
big issue I guess).


It's probably still valuable to i.e. get notification in syslog about
full snapshot or thin-pool - so I'd say  34mS is reasonable compromise,
compared with the complexity we would have put on users to play with
services themself.

But it's good we came to conclusion lvm2-monitor service is not a problem ;)

Regards

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

[Zdenek Kabelac]

Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a):

Hi,

On 6/30/20 12:27 PM, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a):

Hi,

On 6/30/20 11:42 AM, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a):

On 30.06.2020 11:23, Igor Raits wrote:

Sadly you can't have lvm2 not installed:


Yes, but it can be disabled.





I'm sorry but e.g. dmraid-activation still running on every Fedora
Workstation install, instead of it being event activated does not give
the impression of you paying attention.


Hi

dmraid has been obsoleted already many Fedoras back -  why it's still
installed on any LiveCD I've no idea...

AFAIK dmraid can probably handle a few very exotic hw raid devices
which are not supported by mdraid.

But as said dmraid has been put into dust many years back, and there
is zero activity put into this package.

But problems need to be solved properly - not by 'ad-hock'  hijacking 
correct configuration.


On a default Fedora install with typically either a single sata
or NVME disk, with a VG with a single PV on that single disk +
3 LVs for / /home and swap, lvm2-monitor.service is simply not
necessary. It does not do do anything useful as per the
dmeventd manpage.


On default - UNTIL lvm2 command contacts monitoring and asks to monitor a 
device, moniting service does precisely nothing - so nothing is really wasted

in terms of CPU cycles.

BTW - if someone really DOES care about CPU - I'd probably recommend to focus 
on packages like dnf/rpm/Firefox/Chrome/Thunderbird/cups and lot's of other 
where the amount of wasted energy is really high - and I can continue with

large amount of network traffic with package upgrading... but let's not
side-track this discussion too much.



In this case disk failure simply is fatal, as it is with a
raw partition install and there is no provisioning / snapshotting
which can run out of overcomitted diskspace.

Have I misunderstood something here, is my analysis correct that
in this case starting dmeventd has 0 added value ?


Yes -  you are most likely missing that 'lvm2-monitoring' does something only 
when it's in-use.


In the old history days without the systemd world  - these monitoring service 
were forked exactly at the moment user has activated them - now in the systemd 
world where the services are supposed to be handled by systemd -  lvm2 simply 
follows given rules - and  we have the service which is contacted by lvm2

and service starts to work at the moment there is something to monitor.
Has this design changed again?

AFAIK there is nothing wasted - service is there (just like gazzilion of other 
systemd services nowadays).


As mentioned before - if someone is worried about having systemd lvm2 
monitoring service in the system -  he likely doesn't want to have lvm2 on his 
system at all - then the correct fix is to make sure - packages are properly 
packaged in a way they also work without lvm2 installed on system.


What is surely not our plan is that with each activation lvm2 command would be 
reevaulating  systemd  services and would be notifying users that their

systems needs service enabling  - lvm2 considers user has simply prohibited
monitoring - such usage is supported - user will just miss important 
modification or some functionality.


Installed lvm2 simply means present lvm2 services - nothing more nothing less.
Maybe we could provide some 'explicit' package for such services - but we 
would surely like to have such package installed by default.



But this is not about udev-settle, this is about lvm2-monitor.service
running on millions of systems where it really is not necessary.


IMHO see the above where the energy (and outcomes) are way more valuable


With that said I can file a bug for this if you think that that will
help.


Yes please - if you have a system which does not need monitoring
and the monitoring slows down your boot considerably - then surely open BZ.
It should not be happening and it's likely a bug somewhere.
But that needs logs & analysis.


monitoring of non-existent raid-sets and non-existent thin-provisioning
should be disabled. The problem is that the lvm2-monitor.service runs
even if there are no dm raid sets and no thin-provisioning/snapshotting
clearly in that case the right thing would be to not run it?


ATM we are not recommending users to enable services themselves once the come 
to conclusion they need it - we consider them granted from installation of 
package.


1.) If the user does not need lvm2 - it should not be installed.
2.) If the skilled! user is 100% sure he does not need monitoring while he 
uses lvm2 - he can disable service - that's out current default view.


If there something is wrong in those 2 statements - let's open BZ and discuss 
the issues.


Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 

Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)

[Zdenek Kabelac]

Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a):

Hi,

On 6/30/20 11:42 AM, Zdenek Kabelac wrote:

Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a):

On 30.06.2020 11:23, Igor Raits wrote:

Sadly you can't have lvm2 not installed:


Yes, but it can be disabled.




Of course, you can disable this yourself if you are skilled admin and you do 
not need it or use it (you can mask it which is even better).


Default for unskilled users who may use lvm2  - should remain enabled.


So I just did some research on this and the lvm2-monitor.service name is 
somewhat
misleading. This service starts dmeventd (through lvm commands) and on most 
normal

lvm setups, as we create them with anaconda's default auto-partitioning dmeventd
is not necessary at all. Actually I use the auto-partitioning on all my systems
and I always disable lvm2-monitor.service without any bad side-effects.

man dmeventd helps a lot here, dmeventd monitors events on devices used by
device-mapper and acts on them through plugins the following plugins are
available (see man dmeventd and then the "LVM PLUGINS" section) :

mirrorring/raid -> In this case dmeventd attempts to handle device failure,
this is definitely good to have but only if mirroring/raid is used,
which in practice means that dmraid is used.

snapshot/thin/vdo -> dmeventd monitors if the storage pool is running out
of space and if it is it sends a warning to syslog. This maybe is somewhat
useful but only in combination with another monitoring system monitoring
syslog for these messages and pro-actively contacting the admin; and this
is only relevant if snapshot/thin/vdo lvm features are used, which in a
default Fedora install they are not.

So this is a third case (next to dmraid and device-mapper-multipath) of
a device-mapper/lvm related service which is always starting itself
(taking time and resources) needlessly on 99.9% of all Fedora workstation
installs.

I really wish that the lvm/device-mapper team would pay more attention
to this. As Lennart mentioned in the thread, the dmraid issue has been
a known issue for 10 years now and dmraid really need to be changed to
be activated based on blkid results rather then always start and scan
all disks.

My proposal for now for the lvm2-monitor.service is to change the
Workstation pre`set to disabled and to make dmraid-activation.service
have a Requires= on it.

This way for dmraid setups we keep the code attempting to deal with
disk-failure.

As for snapshot/thin/vdo we do not use that by default in Fedora workstation
and as mentioned logging a warning to syslog is not all that useful anyways
unless additional manual setup is done to automatically monitor syslog for
this, in which case enabling the service is just a tiny extra step when
already manually setting up the monitoring.



Hi

Of course we DO PAY attention (me being member of lvm2 team)!

But problems need to be solved properly - not by 'ad-hock'  hijacking correct 
configuration.


There are many different types of configuration and each need to be taken care 
separately.


ATM - if you do not have lvmetad (which has been used on older Fedoras for 
auto-actvation)   there should not be a settle dependency on your boot path.


So if we want to track this out properly - I'd simply highly recommend
to open BZ for the issue and provide correct logs for analysis.

It's not solving any issue if you just stating 'monitoring should be disable 
by default'  - as monitoring itself should simply not slow down anything and 
for some use case it's pretty mandatory to have this service enabled.


Zdenek.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

[Zdenek Kabelac]

Dne 30. 06. 20 v 11:53 Vitaly Zaitsev via devel napsal(a):

On 30.06.2020 11:42, Zdenek Kabelac wrote:

Default for unskilled users who may use lvm2  - should remain enabled.


If LVM was not used during installation => Anakonda can automatically
disable it.



Hmm - I don't think this is a good plan - it would be then different how the 
package is installed.


The right plan is to fix all packaged dependencies and allow installation of
packages without lvm2.

If lvm2 is installed on system - it should have one 'default' installed 
configation.


What you are proposing is -  when user would deploy lvm2 DURING anaconda time 
- it would behave the way A),  but if user would just attach lvm2 storage 
later one - it would behave in a way B).


So personally - the only way is to have fixed inter-package deps - and when 
user does not want to have lvm2 on his system - he simply should not be 
installing it - that's IMHO the correct solution here.



Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

[Zdenek Kabelac]

Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a):

On 30.06.2020 11:23, Igor Raits wrote:

Sadly you can't have lvm2 not installed:


Yes, but it can be disabled.




Of course, you can disable this yourself if you are skilled admin and you do 
not need it or use it (you can mask it which is even better).


Default for unskilled users who may use lvm2  - should remain enabled.

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

[Zdenek Kabelac]

Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a):

On 29.06.2020 22:04, Ben Cotton wrote:

Fedora only support these RAID sets when they are already configured in
the BIOS at installation time. So we can solve the problem of
dmraid.service still depending on the obsolete udev-settle service by
making dmraid.service disable itself if no supported RAID sets are found
on its first run.


+1 for this change.

Also the LVM monitor can be disabled too if LVM is not used in current
Fedora installation.

LVM monitor: -2.01 seconds.
RAID: -2.41 seconds.


If the user does not need lvm2, then the package  should not be installed/
However when lvm2 is installed - lvm2 monitoring service is supposed to
be there and enabled - it should not impact load time all that much...


Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Zdenek Kabelac]

Dne 21. 11. 18 v 14:36 Kamil Paral napsal(a):
On Fri, Nov 16, 2018 at 11:13 PM Jonathan Dieter > wrote:


For reference, this is in reply to Paul's email about lifecycle
objectives, specifically focusing on problem statement #1[1].


Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time.  This will require changes
to both the rpm format and new features in the zchunk format.



Hey Jonathan,

thanks for working on this. The proposed changes sound good to me. I'm a bit 
worried that zchunk is not yet a proven format, so it might be a good idea to 
use it for metadata first, see whether it works as expected, and then push it 
for RPM files. But that's for more technical people to judge.


I have some concrete questions, though:
1. I have noticed that especially with large RPMs (firefox, chrome, atom, game 
data like 0ad-data, etc), my PCs are mostly bottlenecked by CPU when 
installing them. And that's with a modern 3.5+GHz CPU. That's because RPM 
decompression runs in a single thread only, and xz is just unbelievably slow. 
I wonder, would zchunk used as an RPM compression algorithm improve this 
substantially? Can it decompress in multiple threads and/or does it have much 
faster decompression speeds (and how much)? I don't care about RPM size 
increase, but I'd really like to have them installed fast. (That's of course 
just my personal preference, but this also affects the speed of mock builds 
and such, so I think it's relevant.)


Well I'm ATM way more concerned about  absurd size of rpm REPO metadata size.

Often my upgrade first download   200MB of metadata to update 20MB of actual 
RPMs.

Please anyone - fix this first before anyone starts to parallelise 
decompression - this is minimal problem compared with the amount of processed 
metadata


Next topic is - to replace/rewrite ONLY new files - files that has NOT changed 
might not be written at all (write of files takes way more time then its 
decompression)  - in fact such file might not be even decompressed (depends on 
compression layout).


Thanks

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Hiding the grub menu by default on single OS installs

[Zdenek Kabelac]

Dne 1.6.2018 v 15:51 Hans de Goede napsal(a):

Hi,

On 01-06-18 15:26, Chris Adams wrote:

Once upon a time, Hans de Goede  said:

For F30, single OS Fedora Workstation install install we get:

1) grub menu not shown, 0 second timeout, no way to get to the menu


What I haven't seen answered is this: what do we really gain from this?
Your initial message said that the EFI firmware scanning USB for a
keyboard "can be quite slow", but that's not explained.  For the typical
use cases, how long are we actually talking about?


It varies but it can easily be a couple of seconds.




It sounds like every Fedora user is doing nothing else then rebooting,
and 2 seconds is going to be a killer feature.

Personally I reboot once maybe twice a week (and just because I need to track 
recent kernels)



Is really the 2 second 'speedup' worth all the trouble with rescue ??


Regard

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4HJB3YKCKCNBQORSOIKUM7K2DLFHKDUI/

Re: RFC: retiring yum

[Zdenek Kabelac]

Dne 2.9.2017 v 16:00 Neal Gompa napsal(a):

On Fri, Sep 1, 2017 at 1:01 PM, Igor Gnatenko
 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

So I think F28/F29 would be best time for retiring YUM. Right now DNF
should be already stable and provide same capabilities (or documented
that something will not be supported).

Hopefully infrastructure / rel-eng folks will finally add support for
rich dependencies[0] which would mean that yum will not work in Fedora
anyway, so..

Do you still have some critical missing functionality in DNF? And let
us know reasons why would you like to keep YUM available (hopefully
there are no)!



There is one other feature I just recalled: arbitrary yum vars for
substitution. DNF only supports substituting releasever and basearch,
while yum allowed for you to define custom variables in /etc/yum/vars.
Scientific Linux and a few other distributions depend on it, and there
are people who use it in local installations for offering things like
login credentials, applicaton tokens, and things like that for secure
repository access.


Hi

What I see critical on this plan is -  when I use Rawhide daily it's not 
uncommon totally UNTESTED dnf lands  in repo  - and yum is then the only 
'easy' way to handle such case without any complexity.


So will be there ANY protection to insert untested core package like dnf is 
into repo which is IN USE by users ??


Not to mentioning -  yum had at least  'yum-complete-transaction'  while  dnf 
is basically useless when upgrade transaction is aborted for whatever reason 
you can think of



Regards

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Zdenek Kabelac]

Dne 11.7.2017 v 23:17 Solomon Peachy napsal(a):

On Tue, Jul 11, 2017 at 10:55:25PM +0200, Michal Schorm wrote:

He won't install it on his home desktop PC or work laptop. He rather find
an old dusty laptop from 2005 in his shed and starts to learn there.


If we're being honest, a typical 2005-era laptop is going to yield a
rather lousy experience with any modern Linux Desktop.  (And an even
lousier experience with modern Windows!)





The question is - why - certainly not  because CPU got less powerfull that 
it's been 10-12 years back -  but  when   gnome clock  needs  30MB,
and rendering of html pages  often takes over 100MB - and nobody cares about 
any performance regression since  new shiny i7 is so fast to 'mask' all 
programmers faults and 32GB or RAM also needs some usage



Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Zdenek Kabelac]

Dne 3.2.2017 v 18:23 Chris Murphy napsal(a):

On Fri, Feb 3, 2017 at 10:18 AM, Chris Adams  wrote:

Once upon a time, Chris Murphy  said:

Further I wonder if /etc/lvm/lvm.conf needs
issue_discards = 1

Both / and /home are actually LV's which are made from the LUKS PV. So
trim pass down from dmcrypt to block device isn't enough to do
anything.


LVM passes discards through automatically, assuming the block device
under the PV supports them.  The issue_discards option tells LVM to
issue discards itself when PV space is released (e.g. an LV is
removed/reduced).


Yep. I just tested it with the default issue_discards=0 and fstrim -v
does work on an LV.

Nevertheless I don't understand the benefit of this feature if
fstrim.service is not enabled by default; nor is a discard mount
option set for the file system in fstab.




Hi

Please read doc about this option first - there is a very good reason
why you have 'issue_discards=0' as default.

This option is purely about discarding 'removed space' by lvm2.
So when you run  'lvremove  vg/lv'   extents occupied by such LV
is discarded. Same applies to 'lvreduce'!.

MAJOR drawback is - such operation becomes   *irreversible* - why the
common rule with lvm2 is - you could 'restore' 1 step back (unless you use 
thin-pools - with those you don't have reverting).


So if someone sets 'issue_discard=1' he automatically loses reversibility.

It should be left to admin to decides which risk he is wiling to take.

Regards


Zdenek


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Video performance degradation in F24

[Zdenek Kabelac]

Dne 12.9.2016 v 17:48 Basil Mohamed Gohar napsal(a):

On 09/11/2016 02:19 PM, stan wrote:

On Sat, 10 Sep 2016 22:04:22 -0400
Basil Mohamed Gohar  wrote:



On 09/08/2016 03:44 AM, Basil Mohamed Gohar wrote:

Even since I installed F24 on both my desktop as well as my laptop
I've noticed a severe performance degradation in terms of video
playback.


Is this using a browser, or a player on the system, like vlc or mplayer?
What does your 'severe performance degradation' consist of?  Dropped
frames?  Lock up?  Artifacts?  Could network congestion or speed be a
factor?  Or do you just mean that the gui is slow to respond?



I've noticed this performance issue in both MATE (my preferred DE)
as well as Gnome.  I have AMD CPUs with AMD GPUs (the laptop is an
APU but also has a discrete card as well).

I don't want to use devel just to report a problem, but I'd also


This really belongs on users.  You can subscribe to users by
sending an email message to
users-requ...@lists.fedoraproject.org
with subscribe in the subject line, and from email address
basilgo...@librevideo.org


like some help in diagnosing the issue so that a fix can be found
– but unfortunately I don't really know where to start.


What does top show happening on your system when you notice the problem?
How about iotop?  Is there lots of disk usage happening? Are there
things like locate or other search aids running in the background to
update their databases?  Are you updating your system when it seems
slow? Is your system memory constrained?  Other cron scheduled jobs?
This usually is really heavy early in system usage as they build their
databases, and then tapers off as only incremental changes are made.

It's unlikely to be due to F24, more likely to be due to your situation.


Personally I'm also interested why the video playback  in Firefox is so 
horrible.

I'm using C2D - this is easily capable to play high bitrate FullHD movies in 
mplayer.


Yet it gets chooked by quite low-bandwidth low quality 640-pixel-wide videos 
from Youtube.


Doesn't really matter much if the native h265 codec is used or it's passed 
through the oldish 'flash' adobe plugin.


Looking at 'perf' trace - it obviously spends ages in libxul -  and it's very 
quickly passing though ffmpeg library used now by 'ff'.


There is some 'minor' difference between   h265/flash playback smoothness - 
but none of them is NOWHERE near to be usable.


So whenever I want to see a video playing fluently without using some later 
4x3GHz i7 CPU -  I simply need to download video and play via mplayer


I'd love to see some progress here - but it's getting worst with each new 
relase of FF - not mentionion  'FF' starts to cut interfaces so less and less 
plugins do work. And no I see zero interest of 'ff' group to solve this issue 
for Linux - they mostly care purely about windows these days :(



And of course horrible playback is in '-safe-mode' as well - so no plugin 
could be accused for this. As well as I'm using -nodebug Fedora kernels

and latest/greatest  SNA xf86 driver.

Regards

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: autoconf test for deprecated readdir_r

[Zdenek Kabelac]

Dne 30.6.2016 v 17:30 Kaleb KEITHLEY napsal(a):


Hi,

Does anyone have a good/working autoconf test for checking for
deprecated readdir_r (for Fedora 25) ?

I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other
things.)

Alternatively it would be nice if there was a some kind of feature test
define in dirent.h.




Cut & paste example code solution from lvm2:

#if !defined(__GLIBC__) || (__GLIBC__ < 2) || ((__GLIBC__ == 2) && 
(__GLIBC_MINOR__ < 23))

/* readdir_r is deprecated with newer GLIBC */
struct dirent entry, *iter = 0;
while ( (errno = readdir_r( d.d, ,  )) == 0 && iter ) {
std::string ename( entry.d_name );
#else
struct dirent *entry;
errno = 0;
while ( (entry = readdir( d.d )) ) {
std::string ename( entry->d_name );
#endif


No need for autoconf

Regards

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Gnome always broken in Rawhide

[Zdenek Kabelac]

Dne 22.1.2016 v 12:37 Vít Ondruch napsal(a):

Hi everybody,

I am wondering why the Gnome updates in Rawhide has to be always broken?


I gave up this long time ago...

I find most Fedora Gnome/Gtk developers thinking 'rawhide' is 'shooting range' 
place to release broken stuff and it gets often unusable (package are not even 
tested by package maintainers!) and it takes months to get simple fixes.


So not worth to spend time with it rather get something that works most of the 
time instead (e.g.  xfce4)


Regards

Zdenek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora IPv6 testing and improvements - request for ideas

[Zdenek Kabelac]

Dne 4.11.2015 v 13:24 Petr Spacek napsal(a):

On 3.11.2015 18:50, Moez Roy wrote:

Hi Pavel Simerda,

The IPv6 updates are breaking stuff (and probably increasing the
attack surface):

Bug 1231946 - unbound-anchor ignores net.ipv6.conf.all.disable_ipv6=1
in /etc/sysctl.conf
https://bugzilla.redhat.com/show_bug.cgi?id=1231946

Bug 1251762 - dnssec-triggerd ignores net.ipv6.conf.all.disable_ipv6=1
in /etc/sysctl.conf
https://bugzilla.redhat.com/show_bug.cgi?id=1251762

(maybe other software like avahi also don't remember right now)

You can reproduce this by putting "ipv6.disable=1" in the kernel command line.

Doing 'setsebool -P domain_kernel_load_modules 1' would reduce the
security provided by SELinux so it is not an option.

Would appreciate fixes please. Thanks.


"ipv6.disable=1" or blacklisting ipv6 modules is going against contemporary
ways how network APIs. Many contemporary software projects are
using IPv6-enabled network calls by default because both IPv6 and IPv4
share the same name space on the machine so you only need to listen on a
IPv6 port to accept both IPv4 and IPv6.

Apparently this is not Fedora-specific in any way because ArchLinux says the 
same:
https://wiki.archlinux.org/index.php/IPv6#Disable_IPv6

"net.ipv6.conf.all.disable_ipv6=1" is good enough and should not have negative
side-effects of "ipv6.disable=1".

Having said that, I'm proposing to close all issues caused by "ipv6.disable=1"
as WONTFIX.


Hi

I strongly object against this idea.

System needs to work in  IPv4 environment  and with kernel without IPv6 enabled.

There is number of reasons for keeping this possibility enabled - e.g.
I want to use  older kernel for regression testing, I want to have disabled
IPv6 stack for security reasons and lots of other...

So please do not replace coder's inability to write correct code to handle 
dual socket interface with disabling usage of while Fedora on kernel with IPv6 
disabled.


I'm fine if the particular software package would be  IPv6 only - as long
as there is no IPv4-only user who cares - it's correct way.

Just do NOT make such package a core system dependency - it has to remain 
optional.


Regards

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Zdenek Kabelac]

Dne 9.10.2015 v 16:16 Adam Jackson napsal(a):

On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote:


I agree - the new wording does appear to give in to poor programming
practices.


Bundling is _not_ intrinsically poor practice.  Firefox is a good
example of this, there have been several cases where using the system
instance of cairo has been a regression relative to the bundled
version, because firefox relied on the internal details of how a
particular version of cairo worked, and a newer and ostensibly better
cairo would break those assumptions.


IMHO  all we need is to support  multiple version of same library
to be installable  -- that's mine point why  usability of Fedora
is miles behind other distros.

Yeah - in ideal world - everyone uses always the latest library
and the library is perfectly compatible.

But in the real-world - version changes, it gets incompatible,
requires some new way how to use it and so on

So for the real-world  we simply need to be able to keep multiple
version of  e.g.  cairo

until all apps  used by users gets migrated to new version - it's that simple.


And BTW we don't need to go long way example - even core libs like
systemd/udev  tends to break compatibility from time to time.

Thus supporting  multiple lib of same package would have forced developers to 
think about their API instead of rebuilding whole Rawhide every second week 
just because library changes


This also solve the issue - when some no longer - but still very usable APP is 
missing - because I'd be able to pick  old libs - and downgrade rest of my 
rawhide -  or not having  app at all.


I really think  rules  should reflect real world - and not some kind of 
virtual ideal universe -  it should be a goal - but not with the price any 
Fedora user has to pay ATM...



Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Zdenek Kabelac]

Dne 9.10.2015 v 16:41 Kevin Fenzi napsal(a):

On Fri, 9 Oct 2015 16:36:37 +0200
Zdenek Kabelac <zkabe...@redhat.com> wrote:


IMHO  all we need is to support  multiple version of same library
to be installable  -- that's mine point why  usability of Fedora
is miles behind other distros.

...snip...

We do.

If you need a different version of a library, you can make a compat
library. It's just assumed that you want the latest/current one.




If all it would take would be e.g. : dnf  install-compat

Otherwise you basically require  that every user of Fedora is supposedly quite 
skilled rpm package-maintainer ??
(Which would roughly cut the user-base  only to those who actively maintain 
package in Fedora)



Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 18:22 Reindl Harald napsal(a):



Am 11.09.2015 um 18:17 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 16:44 Reindl Harald napsal(a):


Am 11.09.2015 um 16:31 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 15:47 Reindl Harald napsal(a):

don't tell me rpmfusion could not easily make that fully automated


This Fedora plan simply puts too much work at everyone's hands.

Sure - people who care about safety might have some option - like  I
always want to have ONLY the latest lib - and drop everything else,
but
there are still lot of users who could live with   older libs quite
happilly  (and especially in the case they do not use the library in
question AT ALL - which is the maint point here)


you said "every one has tons of free time" - well - and who would
maintain the
dozen of versions of libraries packages?


You miss few important points:

1.)
If you have  lib.so.2  and lib.so.4 - it may need far more work then
just running  rpmbuild   - so far away from 'fully automated'.


do we now build distributions backed by "may" and "possible"

in most cases it is just a "rpmbuild" like the mass-build on koji and the
exceptions need some handwork, no big drama


2.)
What maintaining time are we talking about - since Fedora breaks working
thing in the first place for no good reason and force massive
maintenance time on every user of new library in 'short' time for some
potential 'security' fixes - but you may on the other hand put in dozed
of new security breaks anyway  - and when I see how frequently i.e. gtk
libs  may break whole distro -  it would be far more pleasant to see
just couple broken apps at time - instead of rendering whole  rawhide
unusable


just because you don't understand or agree with the reasons don't mean
they
are not good


In real-world developing & testing app to work with all components takes
significantly more time  then in Fedora 'garden'.


don't explain me the real world after 12 years of software development


Not sure why you fail to understand this - I do like to have some apps
to be latest/greatest - while others might be rather 'tested & stable'
or even 'have them' (since they are no longer developed).

More complex projects even fail to fit in 1/2 year release cycle.

In non-Fedora 'world' it's the user who picks what he want to use,
however in Fedora 'garden' a few people selects what user may use and
puts huge walls and pointless obstacle all around if they want to use
something else -  yes I fail to see why this should be good for me


really?

that must be the reason why i run Fedora successful for 7 years now on all
sort of production and development servers and chose for myself which version
of mysql, php, postfix, dovecot, dbmail and what not is running and when it is
deplyoed independent of Fedora reelase cycles in both directions (holding
major upgrades back as well as make them long before Fedora)



We are finally getting to the point

How many machines do you need to use for that setup ?
I prefer to use 1 system on 1 hardware on 1 disk - no kvm, no qemu.
And even containers are not a good fit - thought getting close

Why I cannot use multiple different versions of php on a SINGLE machine ?
Why I cannot use some  10 years old graphical program (unless I do a local 
static compilation, so I'm sure it will work) ?


It's called free of choice

Zdenek

PS: And my Fedora is even older continually upgraded rawhide...

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 19:29 Reindl Harald napsal(a):



Am 11.09.2015 um 19:17 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 18:22 Reindl Harald napsal(a):

In non-Fedora 'world' it's the user who picks what he want to use,
however in Fedora 'garden' a few people selects what user may use and
puts huge walls and pointless obstacle all around if they want to use
something else -  yes I fail to see why this should be good for me


really?

that must be the reason why i run Fedora successful for 7 years now on
all
sort of production and development servers and chose for myself which
version
of mysql, php, postfix, dovecot, dbmail and what not is running and
when it is
deplyoed independent of Fedora reelase cycles in both directions (holding
major upgrades back as well as make them long before Fedora)


We are finally getting to the point

How many machines do you need to use for that setup?


2 - one to test and 1 production host backed by a failover machine running a
dozens of VM's but *not* because different versions but because of different
services / customers and security profiles


I prefer to use 1 system on 1 hardware on 1 disk - no kvm, no qemu.
And even containers are not a good fit - thought getting close


and because you don't want to handle modern technologies like virtualization
others should suck tainting a clean installation?


Why I cannot use multiple different versions of php on a SINGLE machine ?
Why I cannot use some  10 years old graphical program (unless I do a
local static compilation, so I'm sure it will work) ?


uhm i know people which can even configure each of their customers on a single
machine for different php-versions selecting 4.x, 5.0, 5.1, 5.3, 5.4 and 5.5
currently.


Trust me - I'm quite well aware how to handle cases like this -
my machine must be immune against many troubles the life with rawhide could 
bring-in.


You still fail to see my point here is -
WHY Fedora make things so complicated - sometimes one may even think there is 
a team of people who do nothing else then try to just think what they could 
still break even more


Instead of making life easier - there are more and more technologies brought 
in, which even make it impossible to boot my system with 2 year old kernel!


And no 'KVM'/virtualiation is not solution - it's a workaround with it's 
price...

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 15:39 Reindl Harald napsal(a):


Am 11.09.2015 um 15:27 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 15:22 Eric Griffith napsal(a):


On Sep 11, 2015 9:03 AM, "Zdenek Kabelac" <zkabe...@redhat.com
<mailto:zkabe...@redhat.com>> wrote:
 >
 > Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):
 >
 > Fault #1
 > (I've already complained that usage of rawhide & rpmfusion is
getting silly)
 >
 >
How is the usage getting silly? *genuinely confused* Id love for
Fedora to
have everything in the repos (A la Arch) but for legal and philosophical
reasons it's not possible.


My complain here is about packaging libraries.
And just because a library has been upgraded from version .so.2 to
version .so.4  and you can't have both (as the new one replaces old one
by Fedora policy) - you cannot normally use rpmfusion.


the whole point of a *shared library* is to have single versions of libraries
and not 10 versions you need to seek if they are affacted from wahtever
security relevant bug, in many cases it will be impossible to answer that
question

and no, backporting of fixes is not the solution, ignoring manpower here, how
often do you think developers are fixing some bug and even not realize it was
security relevant and so no CVE is assigned

not long ago glibc was affactd by such a case


The best part is - the library itself is mostly useless - but because of
packaging policy - if you want to use rpmfusion - you have to basically
build
lib-compat-like (Fedora way) libraries yourself - that's what I call
silly


no, rpmfusion just need to cope with rawhide changes and rebuild as Fedora does



We are not solving here 'ideal' word where every one has tons of free time and 
could rebuild everything all day


This Fedora plan simply puts too much work at everyone's hands.

Sure - people who care about safety might have some option - like  I always 
want to have ONLY the latest lib - and drop everything else, but there are 
still lot of users who could live with   older libs quite happilly  (and 
especially in the case they do not use the library in question AT ALL - which 
is the maint point here).



Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 15:21 Neal Gompa napsal(a):

On Fri, Sep 11, 2015 at 9:03 AM, Zdenek Kabelac <zkabe...@redhat.com
<mailto:zkabe...@redhat.com>>wrote:

Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):

I have read the whole discussion and I would like to share my opinion,
even if I think it could be a bit off-topic.
Given that Fedora community alone, cannot educate every upstream
developer about unbundling, and considering that it is a problem that
interests all main Linux distributions: I think that Fedora community
could (and should) propose to other Linux distribution communities to
make a general effort to kindly ask upstream devs to reconsider their
work, enforcing unbundling.
This will take years, but I think it is a way we should cover.


How Fedora wants to educate 'upstream' when it rather fails on many levels
when we talk about library handling.

Fault #1

Fedora badly supports multiple libraries of different version - i.e.
typically full rebuild of whole repo is made when new library is
introduced - which is typically quite bad idea (and this is not just
because of simple version change requires reload of many GB of packages)
(I've already complained that usage of rawhide & rpmfusion is getting silly)



Fault #2

Version of libraries is wrongly handled on packaging level as well as on
build level and many library packages are not correctly versioned - so if
someone believe there is some use of  libname.so.major.minor.patch - for
RPM it's mostly useless and if symbols are not properly version inside
library, dependency will simply not work -  and just adding 'constant'
version string to every symbol inside library will not make this work

Zdenek


​I get the feeling this is related to Fedora not aggressively using versioned
package names for libraries, or at least enabling some kind parallel
installing capability. SUSE used to follow a policy similar to our current
one, but switched due to the insanity and impracticality. Mageia also uses a
policy almost identical to SUSE's.

For an example, here's SUSE's policy:
https://en.opensuse.org/openSUSE:Shared_library_packaging_policy​

​I've been meaning to ask about why we don't do this for a while now, but it
seems like now is a good of a time as any...​



I found the idea of making packages purely dependent on versioned symbols as 
not so ideal plan either - as this way you will not  be able handle any new 
flags supported by libraries which uses still same symbols -  UNLESS you 
expected developer to be 'versioning'-fanatic - to maintain versioning of 
symbols at low-level and update 'version' for every tiny upgrade he does for a 
symbol -  how many packages  does that ??
(i.e. your existing API function will handle new 'enum flag' - change its 
version string)


So while 'versioned' symbols do have some logic - it still should not be 
forgotten that  RPM should rather put in  package dependency on the library 
being at least as good as the one used for compilation. Depending purely on 
provided 'symbols' is not exactly what one would expect


Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 16:44 Reindl Harald napsal(a):



Am 11.09.2015 um 16:31 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 15:47 Reindl Harald napsal(a):

don't tell me rpmfusion could not easily make that fully automated


This Fedora plan simply puts too much work at everyone's hands.

Sure - people who care about safety might have some option - like  I
always want to have ONLY the latest lib - and drop everything else, but
there are still lot of users who could live with   older libs quite
happilly  (and especially in the case they do not use the library in
question AT ALL - which is the maint point here)


you said "every one has tons of free time" - well - and who would
maintain the
dozen of versions of libraries packages?


You miss few important points:

1.)
If you have  lib.so.2  and lib.so.4 - it may need far more work then
just running  rpmbuild   - so far away from 'fully automated'.


do we now build distributions backed by "may" and "possible"

in most cases it is just a "rpmbuild" like the mass-build on koji and the
exceptions need some handwork, no big drama


2.)
What maintaining time are we talking about - since Fedora breaks working
thing in the first place for no good reason and force massive
maintenance time on every user of new library in 'short' time for some
potential 'security' fixes - but you may on the other hand put in dozed
of new security breaks anyway  - and when I see how frequently i.e. gtk
libs  may break whole distro -  it would be far more pleasant to see
just couple broken apps at time - instead of rendering whole  rawhide
unusable


just because you don't understand or agree with the reasons don't mean they
are not good


In real-world developing & testing app to work with all components takes 
significantly more time  then in Fedora 'garden'.


Not sure why you fail to understand this - I do like to have some apps to be 
latest/greatest - while others might be rather 'tested & stable' or even 'have 
them' (since they are no longer developed).


More complex projects even fail to fit in 1/2 year release cycle.

In non-Fedora 'world' it's the user who picks what he want to use,
however in Fedora 'garden' a few people selects what user may use and puts 
huge walls and pointless obstacle all around if they want to use something 
else -  yes I fail to see why this should be good for me


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):

I have read the whole discussion and I would like to share my opinion,
even if I think it could be a bit off-topic.
Given that Fedora community alone, cannot educate every upstream
developer about unbundling, and considering that it is a problem that
interests all main Linux distributions: I think that Fedora community
could (and should) propose to other Linux distribution communities to
make a general effort to kindly ask upstream devs to reconsider their
work, enforcing unbundling.
This will take years, but I think it is a way we should cover.



How Fedora wants to educate 'upstream' when it rather fails on many levels 
when we talk about library handling.


Fault #1

Fedora badly supports multiple libraries of different version - i.e. typically 
full rebuild of whole repo is made when new library is introduced - which is 
typically quite bad idea (and this is not just because of simple version 
change requires reload of many GB of packages)

(I've already complained that usage of rawhide & rpmfusion is getting silly)



Fault #2

Version of libraries is wrongly handled on packaging level as well as on build 
level and many library packages are not correctly versioned - so if someone 
believe there is some use of  libname.so.major.minor.patch - for RPM it's 
mostly useless and if symbols are not properly version inside library, 
dependency will simply not work -  and just adding 'constant' version string 
to every symbol inside library will not make this work


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 15:22 Eric Griffith napsal(a):


On Sep 11, 2015 9:03 AM, "Zdenek Kabelac" <zkabe...@redhat.com
<mailto:zkabe...@redhat.com>> wrote:
 >
 > Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):
 >
 > Fault #1
 > (I've already complained that usage of rawhide & rpmfusion is getting silly)
 >
 >
How is the usage getting silly? *genuinely confused* Id love for Fedora to
have everything in the repos (A la Arch) but for legal and philosophical
reasons it's not possible.


My complain here is about packaging libraries.
And just because a library has been upgraded from version .so.2 to version 
.so.4  and you can't have both (as the new one replaces old one by Fedora 
policy) - you cannot normally use rpmfusion.


The best part is - the library itself is mostly useless - but because of 
packaging policy - if you want to use rpmfusion - you have to basically build

lib-compat-like (Fedora way) libraries yourself - that's what I call silly

It has absolutely nothing to do with any 'legal' issues...

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Zdenek Kabelac]

Dne 11.9.2015 v 15:47 Reindl Harald napsal(a):


Am 11.09.2015 um 15:43 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 15:39 Reindl Harald napsal(a):


Am 11.09.2015 um 15:27 schrieb Zdenek Kabelac:

Dne 11.9.2015 v 15:22 Eric Griffith napsal(a):


On Sep 11, 2015 9:03 AM, "Zdenek Kabelac" <zkabe...@redhat.com
<mailto:zkabe...@redhat.com>> wrote:
 >
 > Dne 11.9.2015 v 14:46 Germano Massullo napsal(a):
 >
 > Fault #1
 > (I've already complained that usage of rawhide & rpmfusion is
getting silly)
 >
 >
How is the usage getting silly? *genuinely confused* Id love for
Fedora to
have everything in the repos (A la Arch) but for legal and
philosophical
reasons it's not possible.


My complain here is about packaging libraries.
And just because a library has been upgraded from version .so.2 to
version .so.4  and you can't have both (as the new one replaces old one
by Fedora policy) - you cannot normally use rpmfusion.


the whole point of a *shared library* is to have single versions of
libraries
and not 10 versions you need to seek if they are affacted from wahtever
security relevant bug, in many cases it will be impossible to answer that
question

and no, backporting of fixes is not the solution, ignoring manpower
here, how
often do you think developers are fixing some bug and even not realize
it was
security relevant and so no CVE is assigned

not long ago glibc was affactd by such a case


The best part is - the library itself is mostly useless - but because of
packaging policy - if you want to use rpmfusion - you have to basically
build
lib-compat-like (Fedora way) libraries yourself - that's what I call
silly


no, rpmfusion just need to cope with rawhide changes and rebuild as
Fedora does



We are not solving here 'ideal' word where every one has tons of free
time and could rebuild everything all day


don't tell me rpmfusion could not easily make that fully automated


This Fedora plan simply puts too much work at everyone's hands.

Sure - people who care about safety might have some option - like  I
always want to have ONLY the latest lib - and drop everything else, but
there are still lot of users who could live with   older libs quite
happilly  (and especially in the case they do not use the library in
question AT ALL - which is the maint point here)


you said "every one has tons of free time" - well - and who would maintain the
dozen of versions of libraries packages?


You miss few important points:

1.)
If you have  lib.so.2  and lib.so.4 - it may need far more work then
just running  rpmbuild   - so far away from 'fully automated'.

2.)
What maintaining time are we talking about - since Fedora breaks working thing 
in the first place for no good reason and force massive maintenance time on 
every user of new library in 'short' time for some potential 'security' fixes 
- but you may on the other hand put in dozed of new security breaks anyway  - 
and when I see how frequently i.e. gtk  libs  may break whole distro -  it 
would be far more pleasant to see just couple broken apps at time - instead of 
rendering whole  rawhide unusable


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Firefox addon signing

[Zdenek Kabelac]

Dne 27.8.2015 v 16:09 Dennis Gilmore napsal(a):

On Wednesday, August 26, 2015 03:13:08 PM Richard Z wrote:

On Wed, Aug 26, 2015 at 03:12:25PM +0300, Alexander Ploumistos wrote:

Their FAQ is constantly updated:

https://wiki.mozilla.org/Addons/Extension_Signing#FAQ

I'm not sure if there is a valid practical reason to refuse submitting the
addons that we ship to their signing service or if it is against our
policies; at least mozilla-https-everywhere has been signed.


that would work for Fedora - if it can be guaranteed that they sign new
versions quickly. Immagine if one of our plugins had a security hole and
mozilla would need days or weeks to sign it. As far as I can see Fedora
specific extensions would have to be listed which means they would go
through manual code review at mozilla.

We have no real practical way to do this other than package up the addon and
build it as a -unsigned package, then making a separate package that has the
precompiled binary and signed by mozilla and put into the add on package.

It sounds like the path mozilla is taking will likely prevent us shipping
addons in Fedora.  That of course is their right to pursue that.




I'm wondering what is good replacement option - since the amount of troubles 
with Firefox seems to be just scaling up.


The memory usage - is the story for it self - displaying a tab with just our 
bugzilla pages  eats like 6-8M of RAM  - I used to be running full OS with 
this amount of RAM - now it's not enough to render couple lines and color 
boxes and 'couple' KB of text


Keyboard and mouse has weird focus - so often I type in one windows, but 
keyboard input magically work in another window (i.e. Ctrl+T opens new tab in 
second window)


I've no chance to control what is downloaded - I could partially limit thing 
by using plugins - but they eats possibly more RAM, slows FF down (at least by 
FF reporting messages)  and will likely be sooner or later banned.


Lot's of things are hardly reportable.

Chrome is not an option for me - it eats even more RAM and slows my machine 
even more then FF.


So what are the option - if the person want to view Web with all modern 
technologies being supported ?



Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf install just stops - no explanation

[Zdenek Kabelac]

Dne 9.6.2015 v 17:35 Tonet Jallo napsal(a):

I experimented the same yesterday, anyone knows which is the problem?


count me in  -

https://bugzilla.redhat.com/show_bug.cgi?id=1223803

Zdenek

PS: had great fun with db rebuild and recovery...



2015-06-09 8:41 GMT-05:00 Richard Fearn richardfe...@gmail.com
mailto:richardfe...@gmail.com:

I've experienced the same problem with a F22 VM running in VirtualBox.
(Is yours a VM?) Disabling IPv6 seemed to help a bit, but the problem
never went away completely.

There a few bugs that talk about similar issues, e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=1206878
https://bugzilla.redhat.com/show_bug.cgi?id=1214538

There are various ideas out there for how to fix this, e.g. `dnf clean
all`, or using LIBREPO_DEBUG=1. But none of these worked definitively
for my VM.

Regards,

Richard

--
Richard Fearn
richardfe...@gmail.com mailto:richardfe...@gmail.com
--
devel mailing list
devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




--
Atte. Tonet Jallo




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why sysrq is limited to only sync command on official fedora kernel?

[Zdenek Kabelac]

Dne 25.2.2015 v 18:44 Reindl Harald napsal(a):



Am 25.02.2015 um 18:37 schrieb Paul Wouters:

On Wed, 25 Feb 2015, Lennart Poettering wrote:


Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
cannot allow. Similar, remounting read-only is also security senstive,
which we cannot allow.

Without being logged in there's very little you can do on a host right
now, and sysrq should not open up more there by default.


You must have forgotten your university days

The alternative to not being able to sync-umount-boot using sysrq is to
flip the switch. I'd rather have them use sysrq.

I said it when they closed X ctrl-alt-backspace and I'll say it now.
When you are on console with the power plug, preventing these actions
is stupid


when you are on a machine where you have pysical only keyboard and mouse it is
not - not every PC stands in front of your face - think about kiosk mode and
so on...


When I read such answers - I always wonder myself - how many kiosk ever run 
Fedora...


It's such a bad idea to optimize Fedora for one-in-milion users and those 
999.999 has to suffer instead of require 1 guy to configure more secure version.


On the other hand - Fedora might easily provide a 'script' to disable all 
obscure 'security' settings - if that's the only thing to pass the security 
audit with 'defaults'...


And my recent personal experience - I tried to configure NFS to use it between 
my qemu and host machine - and guess what - first thing which has been 
instantly removed from host was firewalld as this piece is simply 
unconfigurable nonsense and the second one is absurdly broken nfs4 - replaced 
with usable nfs3...


People need to do their works and don't have time to spend ours figuring out 
where the settings has been shifted after some security-person decisions and 
systemd upgrades


Regards

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 6.10.2014 v 08:21 Paolo Bonzini napsal(a):

Il 04/10/2014 18:17, Zdenek Kabelac ha scritto:


And yes - with UsrMove we lost distinction between
what are system tools
and
what are usr tools.


What you call system tools is simply the content of the initramfs.

Paolo


Close - but not exactly.

initramfs needs to have only those tool to mount root volume.
So while my system could have richer set of tools,
not all of those are necessary to bring up the system.

Anyway the main idea is - these basic system tools could happily live
with  'dash' as in /bin/sh - while the users may enjoy bash shell.

Often invocation of sh being bash is just expensive - and it's even more then 
that when such shell is purely used to reexec some other command.


Of course I'm fully aware people are not going to change their habits,
and don't care about that at all - and just always expect bash

Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 6.10.2014 v 08:06 Paolo Bonzini napsal(a):

Il 02/10/2014 11:04, Zdenek Kabelac ha scritto:

It used to give significant boost for automake  libtool based software
- however at some point libtool started to use bashisms and so you
cannot just replace  /bin/sh - dash - as build will fail.


This is wrong.

libtool detects whether you can use bashisms, and falls back to POSIX
shell constructs if it cannot use them.  The non-POSIX constructs are
usually faster because they do not need to fork() the shell.  Autoconf
does the same.  dash rejects some of these constructs, and accept others.

Before Autoconf started doing this, dash was indeed quite a bit faster
than bash on configure scripts.  So your estimate of 50% is valid for
projects on which Autoconf has last been run 7-8 years ago.


Well all I can say is autoconf (at least on my rawhide) doesn't work with dash 
for quite some time.


So yes - I admit my numbers are dated. But purely because I cannot revalidate 
them


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 4.10.2014 v 18:00 Florian Weimer napsal(a):

On 10/04/2014 01:05 AM, Rahul Sundaram wrote:

On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote:

And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or
CentOS or Scientific Linux,  pretty seriously


Please explain how.


Systems which haven't undergone UsrMove don't have /usr/bin/bash.


We still have universal:

#/usr/bin/env bash

Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 4.10.2014 v 18:08 Florian Weimer napsal(a):

On 10/04/2014 06:03 PM, Zdenek Kabelac wrote:

We still have universal:

#/usr/bin/env bash


Sadly, some systems have /bin/env, but not /usr/bin/env.



Sadly it's fault of that distro - Fedora is not here to fix other distro 
mistakes...


'env' is usr tool and needs to sit in /usr/bin - it's simple as that.

In fact it should be used also to resolve pythons and other goodies...

And yes - with UsrMove we lost distinction between
what are system tools
and
what are usr tools.

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):

On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:


Hi

Is it worth considering using Dash as the default (non-interactive) shell
in Fedora?  Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh.  While this appears to have been done primary to
increase bootup efficiency (which is not relevant with systemd), it might
help with security

Since the recent Shellshock aka Bashdoor vulnerability, there have been
some discussions about more distributions switching over (
http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I was wondering
whether it is worth considering for Fedora?  FWIW, both dash and mksh is
already packaged in Fedora.


This sounds really wrong to me.

If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows. You increase the number of packages



When I look in my memory footprint where NetworkManager grabs 20M of RAM
and does nearly nothing whole day - it's funny to even hear dash would 
consuming some significant memory resources.


I suggest to look at other places first if you really care about this.

On the other hand - usage of dash significantly speeds up  compilation of
autoconf projects - it's pretty interesting to see the compilation with dash
is then maybe even 50% faster in non optimized builds (depends on how many 
shells are forked during autoconf builds)


So you may have two shells in RAM - when dash is pretty minimalistic,
and you save tons CPU cycles and seconds on i.e. compile time (being 
environment friendly :)


So while I don't care which shell is default - the argument about memory is 
not worth to mentions


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):

On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:

Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):



On the other hand - usage of dash significantly speeds up  compilation of
autoconf projects - it's pretty interesting to see the compilation with
dash
is then maybe even 50% faster in non optimized builds (depends on how
many shells are forked during autoconf builds)


I don't know what you tested, but I don't see a substantial speed up on
running autoconf-generated configure scripts:

# time SHELL=/bin/bash CONFIG_SHELL=/bin/bash /bin/bash ../configure ...
...
real0m5.775s
user0m0.528s
sys0m0.217s

# time SHELL=/bin/dash CONFIG_SHELL=/bin/dash /bin/dash ../configure ...
...
real0m5.495s
user0m0.340s
sys0m0.194s


Another, more extensive test case:
* bash;
real1m43.115s
user0m34.708s
sys0m16.322s

* dash:
real1m33.283s
user0m30.834s
sys0m13.932s

In other words, I am observing a 5-10% speed up on running autoconf configure
scripts.


Unsure how does your 'bash' environment setup looks like - but on pretty 
simple lvm configure case - but my rawhide (on C2D 2.1GHz, SSD)


dash:

real0m2.819s
user0m0.770s
sys 0m2.098s

bash:

real0m3.600s
user0m1.211s
sys 0m2.695s


xf86-video-intel (intel drm driver)

dash:

real0m8.691s
user0m4.639s
sys 0m4.153s


bash:

real0m9.852s
user0m5.241s
sys 0m4.982s


It used to give significant boost for automake  libtool based software - 
however at some point libtool started to use bashisms and so you cannot just 
replace  /bin/sh - dash - as build will fail.

(zsh doesn't seem to boost the speed)

Also I said - upto 50% - which depends on complexity of configure files.

But even your personally measured 10% speed is in my eyes pretty significant 
if you do builds all day and surely outweighs some RAM (and IMHO even RAM will 
be actually still positive anyway on dash side if you do parallel builds)


Zdenek



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

[Zdenek Kabelac]

Dne 2.10.2014 v 18:00 Haïkel napsal(a):

2014-10-02 17:56 GMT+02:00 Tomasz Torcz to...@pipebreaker.pl:


   Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.



I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Bash is still the most popular script
shell interpreter, having two shell in memory would be a regression.



It's really fun read such arguments.

So now I can see systemd-journal - eats over 8M of RAM (compared with 2M for 
rsyslog) it's wasting CPU doing useless jobs for 95% of users - now I'd call 
this a major regression.


Every bash eats around 4M of resident memory.

Compared with less then 0.8M for dash.

Now - I'm not advocating for switching to dash as default - not at all - I'm 
well aware how bashism spread everywhere.


I'd rather see fixed and improved bash with reduce memory footprint.

Just please STOP using those senseless  arguments...

Zdenek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

[Zdenek Kabelac]

Dne 16.9.2014 v 11:48 Richard Hughes napsal(a):

On 16 September 2014 10:36, Roberto Ragusa m...@robertoragusa.it wrote:

If applications would just use libraries correctly, the kernel
would be able to let parts of deleted files be available for lazy
loading.


Sure, as long as all[1] the resources were either open()d when the
user started the program, or linked in as resources into the library
itself then it works fine. You can certainly design an application
that does this correctly, it's just that very few do. A lot of GNOME
apps compile in resources into the binary itself, using GResource, and
this very much helps live updating.




Just a thought - but wouldn't be better spend time to enlighten Gnome/Firefox 
developers how to write applications in a way the could be upgraded runtime, 
instead of forcing users to reboot machines  which seems seriously ridiculous.


And if we can't fix Gnome -  then let's have there daemon/systemd service 
waiting in background till the 'problematic' app is still running - and run 
upgrade when the app is finally closed (eventually kindly ask user to close 
the app in case of some CVE)


Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

[Zdenek Kabelac]

Dne 16.9.2014 v 12:21 Richard Hughes napsal(a):

On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:

Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
upgraded runtime


So, it's not just the application, it's every application and D-Bus
service the application uses. Even glibc opens files-as-resources at


So it's time to fix D-Bus then as well!

If something is broken - it will not get fixed by hiding broken design behind 
rebootupgrade.


Guys it's 21st. century -  it's so much broken idea to reboot 'machine' 
because I want to upgrade i.e. Firefox - that I simply don't have words for it.


If you can't fix the Firefox (or some other broken tool) and you want to allow
install of new version - then you need to allow i.e. parallel installs of such 
packages - it's that simple - I've been doing this more then 15 years ago at 
University - so really nothing new here...


While the old-firefox is in use - new one could be installed in parallel
and the old one is removed when the last user closes app - of course
this has another problem with dependency hell - again solvable thing - look at 
i.e. NixOS.


Just fix things in their core instead of hiding problem in pointless reboots.

Have any of those 'inventors' of  rebootupdate ever managed multiuser system?

This 'reboot' idea is just 'somehow' usable maybe for a single seat single 
user desktop - but not anywhere else.


Has Fedora given up Unix ??

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

[Zdenek Kabelac]

Dne 16.9.2014 v 16:39 Miloslav Trmač napsal(a):

- Original Message -

Dne 16.9.2014 v 12:21 Richard Hughes napsal(a):

On 16 September 2014 10:55, Zdenek Kabelac zkabe...@redhat.com wrote:

Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
upgraded runtime


So, it's not just the application, it's every application and D-Bus
service the application uses. Even glibc opens files-as-resources at


So it's time to fix D-Bus then as well!

If something is broken - it will not get fixed by hiding broken design behind
rebootupgrade.


Quite true.


If you can't fix the Firefox (or some other broken tool) and you want to allow
install of new version - then you need to allow i.e. parallel installs of such
packages - it's that simple - I've been doing this more then 15 years ago at
University - so really nothing new here...


Well, what we would need is:
1. Ability to keep multiple versions (both ABI-compatible and ABI-incompatible) 
of a single application or library or service installed and running at the same 
time.


Other distributions allow to install multiple version of same libraries - I've 
never understood the Fedora policy to recompile whole Fedora when a new 
version of library is released.


This policy design is quite 'show-stopper' for anything like this...


2. Ability to detect which processes depend on which versions of which 
components.


We already managed to brought in systemd


3. Ability to automatically restart such processes without loosing state 
(either completely transparently or with some user notification for GUIs).


I'm not quite sure why we would need restart - simply delayed lazy release of 
unused packages would do the trick here - doing here state-full design is much 
more complex thing


The primary use-case to target should be to allow reinstall user packages 
while they are in use.




This has all been done before, and can be done again.  (And it would make at 
least half of the userbase clamoring for containers what they need, without 
playing ugly complex nontransparent namespace games.)  But let’s be clear about 
it, 1. means completely changing our filesystem layout, and 3. means changing 
our process model to go way beyond int main(...).

It is technically possible, it is the right thing to do.  Do we want to do it 
and can we do it?


Fedora made not much useful /usr move thing - so maybe it's time to think and 
design something really useful.


As mentioned there are OSes which do handle things much better...

And surprisingly even Systemd guru realized there is something broken with 
current filesystem layout - except solving it with Btrfs is not really a fix...



Has Fedora given up Unix ??


The Unix history is actually closer to “edit header files to match your 
hardware, then rebuild the kernel and userpace with (make world), and reboot“.  
Packaged applications with an ISV source and an update stream separate from the 
OS have certainly been built on top of Unix but have never been a major design 
focus.  Arguably the whole point of a “Linux distribution” has been to get 
closer to the BSD-style single-kernel-and-userspace distribution updated always 
as a whole.


My view rather is - Fedora is taking feature-by-feature away from my box.

Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

[Zdenek Kabelac]

Dne 16.9.2014 v 17:08 Miloslav Trmač napsal(a):

- Original Message -

Well, what we would need is:
1. Ability to keep multiple versions (both ABI-compatible and
ABI-incompatible) of a single application or library or service installed
and running at the same time.


Other distributions allow to install multiple version of same libraries


AFAIK only when the ABI (soname) is different.  We also need to allow for the 
case when the ABI stays the same but the internal implementation changes (e.g. 
changing a format of a resource file that is used by the library, making old 
processes incompatible with the newly installed resource).


That's what I mean - when something changes in the library - soname should 
change.  It's quite broken to release same version of library with the same 
name when there is different internal implementation.  It's something library 
package maintainer should take care of...


There is also support for versioned symbols.





2. Ability to detect which processes depend on which versions of which
components.


We already managed to brought in systemd


I can’t see how systemd helps.  See the other discussions about Python/Ruby 
modules that leave no obvious trace of their dependency after being loaded into 
memory.


It has similar complexity and maybe packages could be described just like 
services - so similar thing could be possibly reused here ?


Anyway - I've not been thinking too deeply about this...





3. Ability to automatically restart such processes without loosing state
(either completely transparently or with some user notification for GUIs).


I'm not quite sure why we would need restart - simply delayed lazy release of
unused packages would do the trick here - doing here state-full design is much
more complex thing


Because otherwise you end up with an old version of Firefox running for 60 days 
(or however long a laptop can run with suspends and no restarts; most people 
about never quit their browser), and that version of Firefox keeping an old 
version of a system-wide daemon running for 60 days as well..


Sure if user is able to run Firefox for 60 days  (though my usually goes out 
of RAM in just a week or so, if it's not crashing earlier...) - then he is 
happy user.


I guess something may show to user some nice gui dialog warning like -  'Hey 
there is a new version installed - so 'restart' your browser to get new cool 
feature'  (FF normally already detects upgrades and suggest restart)


I don't see nothing wrong with this case - it's per user and doesn't require 
upgrade - and if I've something important is running in my browser I could 
delay restart to the moment I don't care.






And surprisingly even Systemd guru realized there is something broken with
current filesystem layout - except solving it with Btrfs is not really a
fix...


The sad thing is that adding more workarounds like namespaces and the like 
really might be easier than agreeing on making a real change and getting it 
done :(  But we will live with the costs forever.


Look at NixOS - there are no namespace or btrfs requirements

Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

[Zdenek Kabelac]

Dne 16.9.2014 v 17:36 Miloslav Trmač napsal(a):

- Original Message -

2. Ability to detect which processes depend on which versions of which
components.


We already managed to brought in systemd


I can’t see how systemd helps.  See the other discussions about Python/Ruby
modules that leave no obvious trace of their dependency after being loaded
into memory.


It has similar complexity and maybe packages could be described just like
services - so similar thing could be possibly reused here ?

Extra manual dependency information that would get obsolete?


Runtime removal of unused packages might be fun.
It could be something like 'fstrim' tool to run through cron...


3. Ability to automatically restart such processes without loosing state
(either completely transparently or with some user notification for
GUIs).


I'm not quite sure why we would need restart - simply delayed lazy release
of
unused packages would do the trick here - doing here state-full design is
much
more complex thing


Because otherwise you end up with an old version of Firefox running for 60
days (or however long a laptop can run with suspends and no restarts; most
people about never quit their browser), and that version of Firefox
keeping an old version of a system-wide daemon running for 60 days as
well..


Sure if user is able to run Firefox for 60 days  (though my usually goes out
of RAM in just a week or so, if it's not crashing earlier...) - then he is
happy user.

Until an exploit _that they have already installed an update for_ steals their 
data.


I guess something may show to user some nice gui dialog warning like -  'Hey
there is a new version installed - so 'restart' your browser to get new cool
feature'  (FF normally already detects upgrades and suggest restart)

No, that’s not good enough.  The OS should restart it for the user (other OSes 
already can do this).  (In the case of user-invisible components there is no 
other option, and for user-visible GUIs it is also the right thing to do.)


As long as Firefox can't restart 'unnoticeable' while playing youtube video - 
this is not an option - when admins updates machine - it just can't kill every 
users' running firefox.


It's fine to place a warning somewhere and require restart with some 'many 
hours' timeout - but for almost all Firefox updates - it's good enough to 
restart it just sometimes latest - and for those  'have to restart' - it still 
upon admins policy  - not upon Fedora package maintainer


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

[Zdenek Kabelac]

Dne 20.6.2014 15:52, Chuck Anderson napsal(a):

On Fri, Jun 20, 2014 at 02:39:25PM +0200, Dennis Jacobfeuerborn wrote:

On 20.06.2014 14:11, Reindl Harald wrote:


Am 20.06.2014 14:04, schrieb Tim Lauridsen:

On Thu, Jun 19, 2014 at 8:47 PM, Dennis Gilmore den...@ausil.us 
mailto:den...@ausil.us wrote:

 In testing dnf on rawhide I nearly always do dnf clean metadata  dnf 
update purely because I found most of
 the time dnfs metadata was out of date. To me dnf fetching the metadata 
behind the scenes just doesn't work
 right. But I'm not sure that me or rawhide fits into the experience dnf is 
trying to give.

 Dennis


Dnf-0.5.2 has a --refresh option, there will a check if the repo metadata is 
newer than the cached one.

so.

dnf update --refresh will check and update metadata if needed


*that* would be a useful default instead background-refreshes



I think these are two separate issues. Independent of the background
refreshes dnf should always check if its current view of the world is
up-to-date (that is the data in its cache is current).
This can be fairly important when it comes to security issues. When a
fatal exploit is fixed in a package you don't want dnf to say that there
are not updates available when this is in fact not true.


Agreed.  In fact, when I'm doing updates (which doesn't happen as
frequently as it should due to the disruption to work it causes) I
want to be absolutely sure I'm not working out of a stale cache--I
often do yum clean expire-cache; yum update since I know I can trust
that to give me the latest updates.  It would be nice if I could just
trust dnf to do the right thing without resorting to extra command
line arguments.




Well I'm still curious why everyone solves upgrade of metadata, but every 
developer of yum and dnf stays pretty much away of any  'error-case' handling 
situation.


So whenever there is some crash fault during upgrade the installation is left 
broken in the middle - and after decades of rpm/yum development there simply 
doesn't exist tool to fix it.  So yes - skilled user will deal with that, but

I'm pretty sure any unskilled one is directly heading to reinstall...

Also for years Debian supplies short update 'diffs' - so user doesn't have to 
download multiple MB sized files - just couple short small files - again 
something much nicer then running a daemon to download tens of MB on 
background daily...


Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: lvresize and XFS, was: default file system

[Zdenek Kabelac]

Dne 28.2.2014 00:02, Eric Sandeen napsal(a):

On 2/27/14, 4:40 PM, Chris Murphy wrote:


On Feb 27, 2014, at 3:32 PM, Chris Murphy li...@colorremedies.com wrote:



On Feb 27, 2014, at 3:02 PM, Jochen Schmitt joc...@herr-schmitt.de wrote:


On Thu, Feb 27, 2014 at 04:08:46PM -0500, James Wilson Harshaw IV wrote:

A question I have is XFS worth it?


I have done some testing with RHEL 7 Beta which use XFS as a default file 
system.

I have to recorgnize, that the -r switch of the lvresize command doesn't 
cooperate
with xfs in oppoiste of ext4.


Where you growing or shrinking the fs, and was it mounted at the time, and what 
error did you get? XFS doesn't support shrink, and only can be grown online. 
I'm pretty sure lvresize -r supports xfs_growfs via fsadm.


worksforme

Starting with a 10TB XFS volume, 5TB x 5 disk VG.


# lvresize -r -v --size 15T VG/LV
 Finding volume group VG
 Executing: fsadm --verbose check /dev/VG/LV
fsadm: xfs filesystem found on /dev/mapper/VG-LV
fsadm: Skipping filesystem check for device /dev/mapper/VG-LV as the 
filesystem is mounted on /mnt
 fsadm failed: 3


snip


However, I don't know what fsadm failed: 3 means.


fsadm.sh:

 if detect_mounted ; then
 verbose Skipping filesystem check for device \$VOLUME\ as the 
filesystem is mounted on $MOUNTED;
 cleanup 3
 fi

...
cleanup() {
...
 exit ${1:-1}
}

the script exits with error 3 meaning, well, 3, I guess, when the fs is 
mounted.  Not the nicest error reporting IMHO :)



man fsadm

DIAGNOSTICS
   On  successful completion, the status code is 0.  A status code of 2 
indicates the operation was interrupted by the user.  A
   status code of 3 indicates the requested check operation could not be 
performed because the filesystem is mounted  and  does
   not support an online fsck(8).  A status code of 1 is used for other 
failures.


Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: lvresize and XFS, was: default file system

[Zdenek Kabelac]

Dne 28.2.2014 14:37, Chris Murphy napsal(a):


On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac zkabe...@redhat.com wrote:



 fsadm failed: 3





man fsadm

DIAGNOSTICS
   On  successful completion, the status code is 0.  A status code of 2 
indicates the operation was interrupted by the user.  A
   status code of 3 indicates the requested check operation could not be 
performed because the filesystem is mounted  and  does
   not support an online fsck(8).  A status code of 1 is used for other 
failures.


Yeah but did fsadm fail? No, as a whole its operation succeeded. Can we say 
fsadm failed to run fsck? I guess that's one way to look at it, but then it 
failed to understand it shouldn't request a check operation on XFS in the first 
place.

Chris Murphy



Current logic of lvm is to call fsadm  to check blockdevice  (lvm2 knows 
nothing about about filesystems).


fsadm translate this to check xfs - which is not supported by xfs (I've no 
idea if there ever be support for this operation) - so fsadm reports it has 
failed to do any check.


lvm2 detects through error code 3 that requested operation is not supported, 
but considered safe to be ignore and continues.


Of course fsadm could return 0 - but then it wouldn't be able to recognize
if check really was made or just skipped.

This message is only shown in verbose mode - and it's mainly for developer to 
know what has happened (or actually not happened)


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: lvresize and XFS, was: default file system

[Zdenek Kabelac]

Dne 28.2.2014 15:12, Eric Sandeen napsal(a):

On 2/28/14, 7:54 AM, Zdenek Kabelac wrote:

Dne 28.2.2014 14:37, Chris Murphy napsal(a):


On Feb 28, 2014, at 1:33 AM, Zdenek Kabelac zkabe...@redhat.com wrote:



  fsadm failed: 3





man fsadm

DIAGNOSTICS
On  successful completion, the status code is 0.  A status code of 2 
indicates the operation was interrupted by the user.  A
status code of 3 indicates the requested check operation could not be 
performed because the filesystem is mounted  and  does
not support an online fsck(8).  A status code of 1 is used for other 
failures.


Ok, granted, I should have read the fsadm manpage.  :)


Yeah but did fsadm fail? No, as a whole its operation succeeded.
Can we say fsadm failed to run fsck? I guess that's one way to look
at it, but then it failed to understand it shouldn't request a
check operation on XFS in the first place.

Chris Murphy



Current logic of lvm is to call fsadm  to check blockdevice  (lvm2 knows 
nothing about about filesystems).

fsadm translate this to check xfs - which is not supported by xfs


Well, it failed to check it because it is *mounted*, right?  It said this:


fsadm: Skipping filesystem check for device /dev/mapper/VG-LV as the 
filesystem is mounted on /mnt
fsadm failed: 3


extN does the same thing:

# e2fsck /dev/sdb3
e2fsck 1.41.12 (17-May-2010)
/dev/sdb3 is mounted.
e2fsck: Cannot continue, aborting.

# xfs_repair /dev/sdc4
xfs_repair: /dev/sdc4 contains a mounted filesystem

fatal error -- couldn't initialize XFS library


(I've no idea if there ever be support for this operation) - so fsadm
reports it has failed to do any check.


xfs certainly does have check and repair tools - man xfs_repair.
You can run it with -n if you want check-only.

However, I see that (at leat my copy of) fsadm reqiures xfs_check,
which has been deprecated upstream in favor of xfs_repair -n.
xfs_check doesn't scale, and xfs_repair -n performs the same
tasks.


XFS_CHECK=xfs_check


so I guess I should file a bug on that.


https://bugzilla.redhat.com/show_bug.cgi?id=1051871


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

[Zdenek Kabelac]

Dne 31.7.2013 10:39, Florian Weimer napsal(a):

On 07/29/2013 08:38 PM, Ric Wheeler wrote:


If application A does a stat or statvfs() call, sees 1GB of space left
and then does a write, we could easily lose that race to any other
application.

If you want to reserve space, you need to grab the space yourself
(always works with a large write() but preallocation can also help
without dm-thin).


In order to have it work always, you'll have to write unpredictable data.
If you write just zeros, the reservation isn't guaranteed if the file system
supports compression.

I'm pretty sure we want a crass layering violation for this one (probably a
new mode flag for fallocate), to ensure proper storage reservation for things
like VM images.



If someone wants to use preallocation - thus always allocate whole space,
than there is no reason to use provisioned devices unless someone want's to 
use its snapshot feature (for this  there could be probably introduced 
something like creation of fully provisioned device) - but then you end-up

with the same problem once you start to use snapshot.

For me this rather looks like misuse of thin provisioning.

ThinP should be configured in a way that admin is able to extend pool to 
honour promised space if really needed. It's not a good idea, to provision 1EB 
if you have at most just 1TB disk and then you expect you will have no 
problems when someone fallocate() 500TB.


I.e. if someone is using  iSCSI disc array with 'hw' thin provisioning 
support, there is no scsi command to provision space - it's admin's work to 
ensure there is enough disc space to keep up with user demands


Maybe - just an idea - there could be a kernel bit-flag somewhere, which might 
tell if the device used by fs is 'fully provisioned' or 'thin provisioned' 
(something like rotational/non-rotational)  But there is no way to return 
information about free disc space - since it's highly subjective value and 
moreover very expensive to calculate.


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

[Zdenek Kabelac]

Dne 29.7.2013 23:06, Lennart Poettering napsal(a):

On Mon, 29.07.13 16:52, Ric Wheeler (rwhee...@redhat.com) wrote:


Oh, we don't assume it's all ours. We recheck regularly, immediately
before appending to the journal files, of course assuming that we are
not the only writers.


With thinly provisioned storage (or things like btrfs, writeable
snapshots, etc), you will not really ever know how much space is
really there.


Yeah, and that's an API regression.




I guess  there  is major misunderstanding what is the whole purpose
of thin provisioning.

From this thread one could get the feeling that thinp just complicates
estimations of free space for filesystem :)

But the usage is quite different from the beginning.

- disk space is costly resource
- resizing of filesystem (i.e. ext4) is blocking usage and could be risky.
- lot of filesystems does not support native snapshots.

So thinp is here to help with these things.

- Instead of running multi terrabyte disk arrays when user is only using gigs
of disk space - thinp allows to add storage when needed (so you could
slowly extend your disk arrays with more hw which needs more energy)

- Instead of resizing fs all the time - you create large fs from the beginning
and you let the block layer to resolve magic (at the price of disk 
fragmentation)

- Instead of repeatedly writing code for snapshots to every fs - again you let 
the block layer to handle it (at the price of less efficient disk space usage).



So the idea that fs would return  different number of free space when it's 
being run on thinly provisioned device is simply wrong from many points.


And there is no point to support this - since  with LVM you could replace
thinp device with linear mirrored device online if that would be needed.
Obviously this would give you very floating results for any stats() functions 
you think there should be supported.


Secondly - thinpool is designed to grow - so from which number you would 
actually want to estimate the free size -  from the current pool size ?
from the free size in whole volume group ? from the size of all attached disks 
which could be attached to volume group ?
If you have multiple thin pools in VG - then what do you think the result 
value should be here?


And finaly - the snapshot features makes the estimation of free space very 
costly operation - if you run multiple snapshots -how do you estimate free 
space ? What would be the meaning of this value ?



thinp should work the same. Of course, this requires that the block
layer has to pass more metadata up to the file systems than before, but
there's really nothing intrinsicly evil about that, I mean, it could be
as basic as just passing along a provisioning perentage or so which
the fs will simply multiply into the returned values... (Of
course it won't be that simple, but you get the concept...)


Sorry, but the only broken concept I can see here is to allocate
50% of free disk space just because it can be made -  disk space is not
local RAM - if the FS tells you it has 1EB doesn't mean the program should 
just allocate 500TB for nothing.


In this case  admin obviously must properly configure provisioned disk space 
for those users who are used to eat every single byte from their fs.  Thinp 
can't resolve this.


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct