Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)

2021-05-13 Thread Roberto Ragusa

On 5/13/21 12:13 PM, Juha Tuomala wrote:


Make a plugin interface for adding additional methods to obtain public keys as
there are a lot different sources for those. Fedora itself has tools for PKI
and public key based security and it would be quite low hanging fruit to fill
the gap between those components, in cases like this.

In this case before doing advanced cloud based things, let's try to also have
a simple "paste your key here" textarea, which is the only sane method I would
want to use when creating a virtual machine.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Meaning of Size Directories

2021-02-26 Thread Roberto Ragusa

On 2/26/21 7:07 AM, Eric Sandeen wrote:


In short, "size" of a dir doesn't tell you much.


In ext4 it tells you (proportionally to other dirs) how many files
you have got at maximum in that directory in its entire history. :-)

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: New memory tester application potentially to replace memtest86+: PCMemTest

2021-02-09 Thread Roberto Ragusa

On 2/8/21 10:46 AM, Vít Ondruch wrote:

Being devils advocate, but should we have the memtest86 or similar by default? 
I have certainly not used this feature in my 10+ yeas with Fedora.

I've not used GNOME in my 18 years with Fedora (plus 5 pre-Fedora).
Can we consider removing it?

Having memtest86 saved my life just a few months ago: random crashes, 
apparently caused by pressing
in the middle of the keyboard.

It was able to demonstrate _live_ that the pressure was causing bit flips.
Press, errors, don't press, no more errors (including appearance/disappearance 
of vertical bands
in the display, because of integrated chipset, VRAM=RAM).

Opened the laptop, reseated two DIMMs, TESTED AGAIN, TESTED AGAIN, shaken the 
laptop,
TESTED AGAIN, no problem anymore since then.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: New memory tester application potentially to replace memtest86+: PCMemTest

2021-02-07 Thread Roberto Ragusa

On 2/7/21 12:16 PM, drago01 wrote:


On Sunday, February 7, 2021, Roberto Ragusa mailto:m...@robertoragusa.it>> wrote:

It can only be an alternative, not a replacement, since it is dropping 
features:

«In particular, no attempt is made to measure the cache and main memory 
speed,
or to identify and report the DRAM type.»


  Which is nice to have but not really the point of a memory tester ...


I'm pointing out that memtest86+ is not just a memory tester.
Is there any other tool covering that functionality?

--
   Roberto Ragusamail at robertoragusa.it
___
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: New memory tester application potentially to replace memtest86+: PCMemTest

2021-02-07 Thread Roberto Ragusa

On 2/7/21 10:07 AM, Neal Gompa wrote:

Hey all,

I discovered today that there's a new replacement for memtest86+ that
appears to even have UEFI support called PCMemTest[0].


It can only be an alternative, not a replacement, since it is dropping features:

«In particular, no attempt is made to measure the cache and main memory speed,
or to identify and report the DRAM type.»

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: Ars claims: Fedora 32 is sluggish

2021-02-05 Thread Roberto Ragusa

On 2/4/21 9:52 PM, Alexander Ploumistos wrote:


considerable lag. In the last 4 or so years I remember issues with
tracker, gnome-shell, mutter/clutter and friends on specific GPUs,
default or popular shell extensions and dbus services. A recent bug


If tracker is enabled the performance drop after booting is huge.

rpm -e tracker-miners

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-28 Thread Roberto Ragusa

On 1/28/21 12:05 PM, Panu Matilainen wrote:

On 1/28/21 12:21 PM, Roberto Ragusa wrote:

On 1/28/21 9:34 AM, Panu Matilainen wrote:

On 1/27/21 8:30 PM, Kevin Fenzi wrote:



SO, I don't really understand... Patrick says in the Change:

"The size of the rpmdb increases from 22952 to 28416 bytes, a 20%
increase. This is on an install size of 1.7GB in total, so this 5MB
increase is a 0.3% size increase on the final installed system."

Is that just because he used the server install with fewer files?


As directories are not signed, in a smaller installation the directory vs file 
ratio could be different, making the overhead smaller than in a larger install. 
Looking at the F33 server edition install, there are
59246 files total, 22837 of which are directories. That's a very different 
ratio to my laptop install where there are 402158 files total of which 70874 
are directories.

So it's a case of "it depends" and it depends quite a lot. By no means the 
overhead is always 45% but neither is it always 20% - depending on the exact package set 
it can be even be quite a bit more or less than either figure.



My data point: I have 1864399 files in rpm DB (rpm -qla|wc -l).


That'd be the total number of file entries, including directories. To exclude 
directories, try

 rpm -qalv|grep -v ^d|wc -l


The rpm database is 770MB (du /var/lib/rpm).


For statistics, you might want to compact the db first:

 rpmdb --rebuilddb

Although that clearly is one *big* installation so dunno how much air there 
might be (or not) in that number.


Maybe a big installation, but just a laptop.

rpm -qalv|grep -v ^d|wc -l

is giving 1652583 files (excluding dirs)
and

rpmdb --rebuilddb && du /var/lib/rpm

is giving 442MB.

The extra size would be 162*1652583 = 267MB, which amounts to +60%.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-28 Thread Roberto Ragusa

On 1/28/21 9:34 AM, Panu Matilainen wrote:

On 1/27/21 8:30 PM, Kevin Fenzi wrote:



SO, I don't really understand... Patrick says in the Change:

"The size of the rpmdb increases from 22952 to 28416 bytes, a 20%
increase. This is on an install size of 1.7GB in total, so this 5MB
increase is a 0.3% size increase on the final installed system."

Is that just because he used the server install with fewer files?


As directories are not signed, in a smaller installation the directory vs file 
ratio could be different, making the overhead smaller than in a larger install. 
Looking at the F33 server edition install, there are
59246 files total, 22837 of which are directories. That's a very different 
ratio to my laptop install where there are 402158 files total of which 70874 
are directories.

So it's a case of "it depends" and it depends quite a lot. By no means the 
overhead is always 45% but neither is it always 20% - depending on the exact package set 
it can be even be quite a bit more or less than either figure.



My data point: I have 1864399 files in rpm DB (rpm -qla|wc -l).
The rpm database is 770MB (du /var/lib/rpm).
An additional 162 bytes per file would raise it by 302MB (+39%).

Looks expensive to me, especially when considering that I get no feature for 
this overhead.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-21 Thread Roberto Ragusa

On 1/21/21 12:29 AM, Patrick マルタインアンドレアス Uiterwijk wrote:

https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents



I'd like to point out that after many requests, I have updated the change page 
for this significantly, with more details as to the goals (and non-goals) of 
this feature, and answers to many other questions asked.

Please have another look if you are interested in this.



On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the /usr directory size does not change at all (both are exactly 1417064 bytes). 


How is this physically possible?
(and one million bytes for a directory makes no sense, I wonder what 
measurement this is)

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

2021-01-07 Thread Roberto Ragusa

On 1/7/21 10:41 AM, Panu Matilainen wrote:

On 1/5/21 8:12 PM, Matthew Miller wrote:

On Tue, Jan 05, 2021 at 01:05:01PM -0500, Ben Cotton wrote:

We want to add signatures to individual files that are part of shipped RPMs.


This is for _every file_ in every RPM? Or some files in some RPMs?



Every file in every RPM is the idea.
This comes at at a very significant size increase for everything.

Taking the rather small and trivial popt package with 39 files as an example, 
pre and post file-signing [1]:

  58254 Jan  7 11:19 /tmp/popt-1.18-1.fc33.x86_64.rpm
130222 Jan  7 11:21 popt-1.18-1.fc33.x86_64.rpm

Isn't there a cost in the fileystem too?
Adding more and more additional file attributes increases space overhead
and pushes people to ugly "DB in a file" "packs", while we know that small files
is the right way to do many things (e.g. "*.d" directories for confs).

Can't this stuff be moved out of the main rpm and used only by whoever cares
about signatures? Like debuginfo has been addressed (for sure an immensely
more useful thing to have).

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: gpg-agents all over the place

2020-12-24 Thread Roberto Ragusa

On 12/23/20 1:56 PM, Oron Peled wrote:


More problematic, but possible.

The key is using "--pinentry-mode=loopback" (I don't have my scripts in front 
of me for further details)

There are simple use cases that are very problematic.
Consider this:

[me@localhost tmp]$ date >date.txt
[me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt   ### this asks 
for a passphrase
[me@localhost tmp]$ ls -l
total 8
-rw-rw-r-- 1 me me  32 Dec 24 16:59 date.txt
-rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg
[me@localhost tmp]$ rm date.txt
[me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg   ### this does 
not ask!
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: AES encrypted data
gpg: encrypted with 1 passphrase
[me@localhost tmp]$ ls -l
total 8
-rw-rw-r-- 1 me me  32 Dec 24 17:00 date.txt
-rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg

that would be a very simple tutorial about symmetric encryption and it is
absolutely surprising, since decryption happens without any need to supply
the passphrase.
Because an agent was forked and it remembers the symmetric
passphrase I've used! Crazy.

So let's see if we can use --batch: using it on encryption conflicts with 
pineentry,
using it on decryption doesn't disable the gpg-agent usage.

We should try to avoid the agent, let's see in the man page:
   --use-agent
   --no-use-agent
  This is dummy option. gpg always requires the agent.
Wow, the option you want, but with a dummy implementation.

There is a --no-autostart, let's try it: more wasted time.

The use case I care about is for a script that reads some data
from an encrypted file, asking me the passphrase when necessary.
Something like:

token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)"
# use $token

The passphrase should not be hardcoded in the script or remembered by
a magic gpg-agent forked behind my back.

My only solution has been:
  dnf install gnupg1

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: gpg-agents all over the place

2020-12-16 Thread Roberto Ragusa

On 12/16/20 2:55 AM, Kevin Kofler via devel wrote:


Believe it or not, GNU/Linux is no longer a text-only operating system, nor
are window managers just a container for terminal emulators. :-)


But that is different than saying the GNU/Linux has become a no-text operating 
system.Version 2 of gpg is impossible to use in scripts.

--
   Roberto Ragusamail at robertoragusa.it
___
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: f33: systemd-resolved hang on ip query

2020-12-11 Thread Roberto Ragusa

On 12/10/20 7:16 PM, Paul Wouters wrote:

On Wed, 9 Dec 2020, Dridi Boukelmoune wrote:

This again leads to a required architecture change. We really need to
have a captive portal namespace, that handles all of this while the
applications still consider the network is down. Once the captive
portal has passed and our internet link is "clean", should this be
bridged into the regular network namespace so applications see the
network as "active". Any state of DNS/browser that was used inside
the captive portal namespace is then destroyed (it is untrusted and
unverifiable data)


That is how Android manages captive portals.
Whoever created this captive portals concept should be slapped
each day for ever, but that's where the world has gone.



--
   Roberto Ragusamail at robertoragusa.it
___
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: How do really work RAID1 on btrfs?

2020-12-09 Thread Roberto Ragusa

On 12/9/20 1:31 AM, Kevin Kofler via devel wrote:


It follows that the solutions are nonnegative under the following
conditions:
* a+b≥c
* a+c≥b
* b+c≥a
which are quite logical. Consider a=4, b=1, and c=1, i.e., disks of 4 GB,
1 GB, and 1 GB. Each of the 1 GB disks can only mirror (at most) 1 of the
4 GB, so where would you want to mirror the remaining 2 GB to?

And without attempting a formal proof, I would suspect that there
is not a unique solution for more than 3 disks, since you get a lot
more freedom, but in any case the bigger disk can't be bigger than the
sum of all the others, because then of course losing that would be
impossible to recover. That condition will be necessary,
and I think sufficient too.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

2020-11-23 Thread Roberto Ragusa

On 11/23/20 5:23 PM, stan via devel wrote:

On Sun, 22 Nov 2020 15:47:04 +0100
Andy Mender  wrote:


Is ALSA still a valid use case? I thought ALSA support was phased out
from most relevant software?


It is for me.  I run some audio software that I do not want interrupted
while it is running.  So, I use pavucontrol to turn it off to pulse and
make it available only to alsa.  Then, I can directly configure, send
commands to, and use the sound device, ignored by pulse.  As near as I
can tell, it is still available in audacity, as well.

My use case for pure alsa is video grabbing of VHS tapes.
Sound is captured at alsa level, I do not want any pulseaudio in the middle.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: list major languages first in anaconda

2020-10-27 Thread Roberto Ragusa

On 2020-10-22 11:57, Christopher Engelhard wrote:


I think that makes sense. I usually set English even though my other
languages are well supported, because it means less mentally switching
back and forth.



Indeed. Ok with guessing defaults as far as I can immediately change them
to something else.

For example, in my case: language English_US, timezone CET, keyboard it_IT.

(and some things are still not customizable though the system,
e.g. having ISO 8601 dates)

Best regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: F34 Change proposal: Compress Kernel Firmware (Self-Contained Change)

2020-10-23 Thread Roberto Ragusa

On 2020-10-23 17:56, Chris Murphy wrote:


That's curious, when I mount the server dvd ISO, those files have
different inode numbers.

I can't tell from the isoinfo man page what the numbers in brackets mean.


Even if inodes are different, data blocks can be reused.
The filesystem is readonly so there is no COW complication.

I've tried to have a dir with 9 hardinked copies of a 9MB file.
A simple mkisofs -o ../test.iso gave me a 10MB iso file (instead of >80MB).

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: paranoid md raid1 -> Btrfs migration tools?

2020-09-28 Thread Roberto Ragusa

On 2020-09-26 23:31, Daniel Pocock wrote:


1) check for differences between source file sectors on each source drive


[...]


I could imagine using kpartx to script a solution to (1) above, skipping
over the md headers.  Some kind of shim may be needed to fool the kernel
to see a different UUID for each source volume so they can be mounted
simultaneously without md.

The kernel can do it, on a fully operational array.

cat /sys/block/md0/md/sync_action
echo check > /sys/block/md0/md/sync_action
cat /sys/block/md0/md/sync_action

then

cat /proc/mdstat
cat /sys/block/md0/md/mismatch_cnt

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: BTRFS, relatime vs. noatime

2020-09-06 Thread Roberto Ragusa

On 2020-09-06 01:35, Chris Murphy wrote:


I figured nothing was using it these days and it was a complete waste. If 
tracker uses atime, maybe I'll get more worried. But if it uses mtime, I'm not.



I've found atime useful in several cases. If you are doubting about a 
configuration file being
read or not by an application, you just check the atime before and after 
running it
(way easier than strace). If you are investigating what a suspect script or 
confused user
has just done, you can find for recent atime.

After it took years to go back from noatime to a weak relatime, we are now 
going to
lose it completely again.

Did any filesystem developer ever think about storing atime in a different way, 
instead
of usual inode metadata? Maybe a dedicated journal of overriding atime entries
(column based DB vs inode's row based DB) to cope with "access many files"
patterns.

And what happened to "lazytime"? It sounded like a great approach.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Blender 2.90 release exclusive to 64 bits arch and Wayland

2020-09-06 Thread Roberto Ragusa

On 2020-09-05 23:53, Luya Tshimbalanga wrote:

Blender 2.90 was released few week ago which a noticeable change, it is now 
exclusively available for 64 bits architecture meaning 32 bit arch support is 
discontinued by upstream. For that reason, the build will only apply for 
Rawhide and Fedora 33.

Maintainers for armv7 architecture are welcome to bring improvement.

Additionally, Blender 2.90 is the first release to include initial support of 
Wayland (currently disabled by default) meaning Wayland developers can help 
Blender team to effectively improve the codes.

So, Wayland support has just been included (and still disabled by default),
while the subject suggests that both 64 bit and Wayland are required.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-01 Thread Roberto Ragusa

On 2020-09-01 08:52, John M. Harris Jr wrote:

On Monday, August 31, 2020 8:32:49 AM MST Vitaly Zaitsev via devel wrote:

On 31.08.2020 17:07, John M. Harris Jr wrote:


ship a release with "fallback" to Google and Cloudflare DNS?



Big Brother will be happy. :-)


Sure, those two companies will be thrilled, I'm sure. This is a huge
disservice to our users. Why in the world does systemd try to force DNS
servers when none are configured? If no DNS servers are configured, there
should be no DNS servers in use.


Standard DNS has a hierarchical structure with roots and delegation.
The idea of asking somebody to do DNS resolution for you comes from the 
widespread
tendency to centralize everything (i.e. inability to understand how the 
Internet was
originally designed).

Insisting on using a DNS server for name resolution is like insisting on using 
a proxy
for HTTP access.

The only sane DNS server we should have is the one on localhost (doing proper 
caching
according to TTLs).
I do not know what this new systemd thing will provide (and hardcoded defaults 
would be
a wrong beginning); in my case it has been bind on localhost for years; it lets 
me have
local zones (e.g. plugged in when a VPN goes up) and I can also make it 
authoritative for
external things I want to override (i.e. playing like a super-powered 
/etc/hosts).

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: booting successfully with read-only file system

2020-07-03 Thread Roberto Ragusa

On 2020-07-03 08:07, Zbigniew Jędrzejewski-Szmek wrote:


Ubuntu's MOTD are well known and people seem to like them a
lot. Fedora hasn't been making that much use of them. But I think we
should in general.


Do not follow Ubuntu on this too much.
I've had a case of a machine with many short-lived incoming ssh connections
where the performance bottleneck was the constant regeneration of
the motd on each login. Sabotaging that stuff brutally was the only way
to get back to good performance.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-02 Thread Roberto Ragusa

On 2020-07-01 23:04, Michael Catanzaro wrote:

On Wed, Jul 1, 2020 at 11:01 pm, Roberto Ragusa  wrote:

The real solution would be to make wise usage of LVM, for example by not
allocating 100% of the extents at the beginning (or even dm-thin) and/or
using filesystems where a shrink is supported (I'm here blaming xfs
for not having this, while ext4 has).


Leaving space unallocated doesn't gain us anything because the user still has 
to manually resize both logical volumes and the partitions inside them. Our 
default needs to be something that doesn't require users to resize partitions.


But those are things that can be done in a few seconds with one or two commands.
Attempts to make easy things easier lead to making other things difficult:
some not so inexperienced users will find themselves with their disk having 
only one
big partition, no LVM, everything inside (system+data) and trying to decipher 
the
suggestion found on a forum "with btrfs you can sort of format / without losing 
/home
even if you do not have separate partitions".

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Roberto Ragusa

On 2020-07-01 18:53, Michael Catanzaro wrote:

The options we are seriously considering for our default going forward are (a) 
btrfs, (b) failing that, probably ext4 all one big partition without LVM, (c) 
less-likely, maybe xfs all one big partition without LVM. This is being 
discussed in https://pagure.io/fedora-workstation/issue/152


One partition without LVM? Maybe labeling this partition C:\

The real solution would be to make wise usage of LVM, for example by not
allocating 100% of the extents at the beginning (or even dm-thin) and/or
using filesystems where a shrink is supported (I'm here blaming xfs
for not having this, while ext4 has).

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Roberto Ragusa

On 2020-07-01 04:07, Nico Kadel-Garcia wrote:

On Sun, Jun 28, 2020 at 6:21 AM Antti  wrote:


Hello,

I'm in total opposition to this proposal as a long-time Fedora user. The btrfs 
is unstable and not ready for production. Most of what I'm about to write is 
admittedly anecdotal but it's the only file system in Linux which has actively 
and regularly caused me to lose data on desktops, laptops, servers and even on 
mobile phones when I haven't taken precautions and done regular backups. 
Something I don't have to actively do when using ext4 in my workstations and 
notebooks.


We had similar excitement back when reiserfs was popular. My limited
play with btrfs reminds me of reiserfs: feature-filled but fragile and
unsuitable for "/" partitions.


My experience with reiserfs has been very different.
It was a wonderful filesystem, with journaling when nobody had it (ext3 did not
exist, we only had ext2).
It was able to raise the disk capacity of the disk (thanks to tail-packing)
and the performance was great (I was able to immediately notice if the 
filesystem
was ext2 or reiserfs, as soon as you deleted a big iso: reiserfs was immediate,
thanks to extents vs blocks, I think).

I've never had filesystem corruption on reiserfs even on very hard workloads.
A specific episode remains in my mind: I had rsync hardlink based backups
on a server with software RAID disks. One day I decided to delete about
one year of backups, at four per day it was around 1000 directories, each
of them with 100,000 files (heavily cross hardlinked, of course). To try
to get good parallelism out of the RAID and the elevator, I submitted 1000
rm commands in background and then realized that I was deleting
100,000,000 files with an enormous lock and refcount stress testing on the fs.
After a few hours, operation completed, no issue.
The same production server was switched years later to ext4, since continuing
with a mostly world-forgotten reiserfs option had no point. After a few days
with ext4... fs corruption and data loss, simply because of an online expansion
that was nothing special on reiserfs. Turns out ext4 kernel/tools combination
was bugged.
I've been able to find my comments on bugzilla (year 2012).
https://bugzilla.redhat.com/show_bug.cgi?id=852833#c25

including this:
(BTW, ...spent the weekend restoring a couple terabytes from backups...)
(As a tribute to justice in the world, I want to say, so that search engines 
index it,
that this system has been in production since 2005 on reiserfs and abused and 
resized
without any similar issues; it was rebuild recently on new hardware and 
switched to ext4
and now I really risked to lose the data, as the remote versioned backup is 
also (resized) ext4,
and the remote-remote backup is also (resized) ext4. I'm not complaining,
but reiserfs really has a much worse reputation than actually deserved).


--
   Roberto Ragusamail at robertoragusa.it
___
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: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Roberto Ragusa

On 2020-06-30 15:34, Jóhann B. Guðmundsson wrote:


Share your thoughts and comments on how such move might affect you so feedback 
can be collected for the future on why such a change might be bad, how it might 
affect the distribution and scope of such change can be determined for 
potential system wide proposal.

I've never really seen any reason to switch to UEFI since it appeared years ago.
It just looked much more complicated (and buggy at the time), for no reasonable
gain.

I'm currently using BIOS, grub, grub2 basically everywhere, even on fresh new 
machines,
for the simple reason that grub2 is really flexible; recently with GPT and 
code-EF02 bios boot partition.
(GPT scheme 21686148-6449-6E6F-744E-656564454649: "Hah!IdontNeedEFI")

In some cases I have complex setups where grub2 is installed two times, with 
the first one offering
some entries, including chainloading the second one for additional entries 
(possibly on a different
drive not always connected and which each operating system having their own 
grub2 and /boot).
These things are either impossible with UEFI or would require learning 
everything again.

I've seen lilo, grub and grub2, which has matured for years; we have finally 
started to understand it
fully, we got the new blscfg thing too, and now... everything reinvented again?
IMHO the firmware (BIOS/UEFI/something) should just be able to run a 
bootloader, everything else
added is not an advantage.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Roberto Ragusa

On 2020-06-27 10:47, Igor Raits wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, 2020-06-27 at 10:35 +0200, Roberto Ragusa wrote:

On 2020-06-26 22:13, Justin Forbes wrote:


Saying production on millions of systems is a bit misleading here,
when you are talking about millions of systems at a single company.


...in a redundant configuration where losing a disk is tolerated by
design
and managing data that have very low vale (mostly pictures of cats
and random chats).

Filesystem quality must be measured in other conditions: have a
Postgres
on it, financial transactions, random blackouts, etc.


Do you run postgres, financial transactions and random blackouts on
your laptop / workstation? If so, isn't it just for testing purposes?

No, but I do run on my laptop/workstation the same technologies that
have been proven to be good for serious stuff.
That is the fundamental Linux advantage, or at least has always been,
and that's why I'm using Linux daily since when other people were
waiting for the release of Win95.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Roberto Ragusa

On 2020-06-26 22:13, Justin Forbes wrote:


Saying production on millions of systems is a bit misleading here,
when you are talking about millions of systems at a single company.


...in a redundant configuration where losing a disk is tolerated by design
and managing data that have very low vale (mostly pictures of cats
and random chats).

Filesystem quality must be measured in other conditions: have a Postgres
on it, financial transactions, random blackouts, etc.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Supporting hibernation in Workstation ed., draft 1

2020-05-31 Thread Roberto Ragusa

On 2020-05-30 12:59, Iñaki Ucar wrote:


If your swap is in a luks partition with a static passphrase (and
secureboot is disabled) then hibernate works just fine.


Actually, I can tell that a swap partition as an LVM volume living on a luks
encrypted PV works perfectly fine.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: f32-backgrounds look like crap

2020-04-20 Thread Roberto Ragusa

On 2020-04-19 22:26, Peter Oliver wrote:

Well, I don't see how it makes sense to deliberately create a low-quality
image with no technical need (nor technical benefits such as size saving).


I'd suggest it's for roughly the same reason that people still paint paintings 
when, nowadays, they could just take a photograph.  I don't pretend to know 
much about art, but that seems to be pretty intrinsic to how it works.



The problem is when the artistic touch leads people to thinking their graphics 
drivers
are defective.

Showing to someone who has just installed a new system some color
dithering from 1990 is not a good idea. Absolutely not for a default choice.

(and this is also the kind of background that can really waste a lot of network 
traffic
when doing screen sharing)

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: swap-on-ZRAM by default

2020-02-11 Thread Roberto Ragusa

On 2020-02-11 05:05, John M. Harris Jr wrote:


They do, but that doesn't negate the fact that it is actually supported (you
can hibernate your system), and using swap on zram outright breaks hibernation
(for obvious reasons).


You would need to

swapon /dev/arealdisk
swapoff /dev/zram0
hibernate

certainly a slow process.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

2020-01-06 Thread Roberto Ragusa

On 2020-01-06 18:31, Kamil Paral wrote:


FWIW, the behavior on Android is very close to what is proposed here. If your 
application exceeds the amount of available memory, it simply closes right in 
front of your eyes. No explanation, nothing, it's just gone (might be different 
on latest Android versions). The same thing would happen with EarlyOOM - some 
application would disappear.



The analogy is not completely fair.
On Android applications are designed to be Started and Stopped by the system, 
and they are supposed to save
their entire state so that when restarted nothing has apparently happened, from 
the point of view of the user.
(many applications are badly written, but that's another story...)
And we are talking about background applications, on a system where only one 
application is in foreground
(only very recently you can have two applications in foreground).
Finally, it is the applications that are stopped (by asking them nicely trough 
an event), not general system
processes; Android would never kill a wpa_supplicant process, for example.

Android has a concept of "cache" of background applications, they are there, if 
possible,  just to have them
back very quickly; it is similar to how Linux keeps dirty disk content in RAM 
and pushes it to disk
when RAM must be freed.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

2020-01-06 Thread Roberto Ragusa

On 1/5/20 12:38 AM, Chris Murphy wrote:

On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova  wrote:


Since in the Change we are not introducing just the earlyoom tool but enable it 
with a specific profile I would add those details here. Smth like:

"earlyoom service will choose the offending process based on the same oom_score as 
kernel uses. It will send a SIGTERM signal on 10% of RAM left, and SIGKILL on 5%"


I add this information to the summary. Also, I think these numbers may
need to change to avoid prematurely sending SIGTERM when the system
has no swap device.

I read that sentence in a different way:
"earlyoom will make only 90% of your RAM available,
so it is effectively using 10% of your RAM".

On my 32GB laptop that means 3.2GB of RAM gets unusable.
And on my 64GB machine I'm being robbed of 6.4GB. Wow.

How low can these numbers be pushed? Even 3% would be 1GB out of 32GB.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-04 Thread Roberto Ragusa

On 12/4/19 12:28 AM, Chris Murphy wrote:


I actually prefer the idea that'd if I'm not logged in, my data is
considered at rest and crypto home is locked, in contrast to how FDE
does it which treats my data as not at rest even though I'm not logged
in at all.


On the other hand I would expect my cronjobs to be able to run "as me"
even if I'm not physically present.
This "logged in" concept coming from Windows and OS X never fits too well
with Linux.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Fedora 31 System-Wide Change proposal: No More i686 Kernels

2019-06-26 Thread Roberto Ragusa

On 6/26/19 2:34 AM, Michal Schorm wrote:

I - and a people around me - have plenty of 32-bit hardware.


Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines,
updated to recent Fedora versions and still usable.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: C++ help needed fixing VXL on 32 bit architectures

2019-05-28 Thread Roberto Ragusa

On 5/28/19 2:26 PM, Roberto Ragusa wrote:

On 5/28/19 1:57 AM, John Reiser wrote:


    if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); }

 Such code is an abomination for lack of clarity.
 Also, the preceding line
 for (int x=0,t=0; x
Isn't t forced into 0..6 by the t&=7 evaluation in the first if?


0..7, sorry for mistyping.

--
   Roberto Ragusamail at robertoragusa.it
___
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: C++ help needed fixing VXL on 32 bit architectures

2019-05-28 Thread Roberto Ragusa

On 5/28/19 1:57 AM, John Reiser wrote:


    if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); }

     Such code is an abomination for lack of clarity.
     Also, the preceding line
     for (int x=0,t=0; x
Isn't t forced into 0..6 by the t&=7 evaluation in the first if?

--
   Roberto Ragusamail at robertoragusa.it
___
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: Upgrade to F30 gone wrong

2019-05-06 Thread Roberto Ragusa

On 5/6/19 1:40 PM, Julen Landa Alustiza wrote:


We found this bug before releasing, but it is not a release blocking bug (the 
upgrade criteria just cover clean n and n-1 upgrading to n+1 and this bug just 
happens whith continously upgraded systems since fc21 or lower)


Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?".
Is this a precedent that n-installed is different than n-through-upgrades?

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Upgrade to F30 gone wrong

2019-05-06 Thread Roberto Ragusa

On 5/5/19 7:59 PM, Nico Kadel-Garcia wrote:

On Sun, May 5, 2019 at 7:49 AM Roberto Ragusa  wrote:


[root@localhost ~]# grep fedora-release /root/install.log
Installing fedora-release-3-8.i386.
[root@localhost ~]# uname -a
Linux localhost 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux


You're kind of begging for pain, at this point. Thee have been enough
subtle, fundamental, and functionally incompatible updates to
filesysems such as ext4 and xfs that a surprise at upgrade should not
shock you too much.


You are supposing the the filesystem has remained the same.
Instead, the content has been copied over a couple of times, so it is now a
fresh ext4 (on lvm, on dmcrypt, with SSD discard enabled,...).


This system was upgraded from Fedora 3 up to 29.
Also note it started as i386, but at Fedora 16 got transformed into x86_64, a 
kind of (manual) upgrade never
officially considered possible.


*Ouch*. OK, now you're just hurting yourself. Definitely time to back
up your old system and do a fresh install.


Turning an i386 to x86_64 was easier than expected.
First you switch to 64 bit kernel (64 bit kernel with 32 bit userspace is
a good but not widely known idea); then you add the x86_64 libs (that can
often live in parallel to i686 ones); then you switch the real applications
to x86_64 and finally you can remove i686 libs you don't want anymore (possibly
every one of them). All done with yum and rpm on a live system.
This has been my daily work system for about 15 years, no reason to scratch it.
it probably contains no traces of the initial setup (apart from 
/root/install.log),
it evolved without any discontinuity.
Last time I ran anaconda for upgrading was in F14 (according to 
/root/upgrade.log);
after that it has always been yum/dnf.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: Enable dmarc mitigations

2019-05-05 Thread Roberto Ragusa

On 5/4/19 11:04 PM, Vitaly Zaitsev via devel wrote:


That's why it's time to deprecate all mailing lists and switch to modern
Web 2.0 platforms.


I swear I've intended this as a joke, before reading replies
and realizing it was supposed to be serious.

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: Upgrade to F30 gone wrong

2019-05-05 Thread Roberto Ragusa

On 5/4/19 10:50 PM, Sam Varshavchik wrote:
> One of my bricks that will soon get Fedora 30 was originally installed with 
Fedora Core 4.
>
> Obviously a minority; but you'll be surprised to learn how many systems there 
are which have been running Fedora for a very long time. Fedora 20 is what, about 
five years old? There are many, many systems which are at least five years old. 
People don't really swap hardware every 2-3 years, any more.
>

My contribution to the surprise:

[root@localhost ~]# grep fedora-release /root/install.log
Installing fedora-release-3-8.i386.
[root@localhost ~]# uname -a
Linux localhost 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux

This system was upgraded from Fedora 3 up to 29.
Also note it started as i386, but at Fedora 16 got transformed into x86_64, a 
kind of (manual) upgrade never
officially considered possible.

I don't understand the consideration about old or new hardware.
Why would I have to reinstall the system when getting new hardware?
My Fedora system has jumped across 4 machines and who knows how many HDD/SDD 
replacements.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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: Can we maybe reduce the set of packages we install by default a bit?

2019-04-11 Thread Roberto Ragusa

On 4/11/19 5:32 PM, Przemek Klosowski wrote:

I think the Android model is more relevant in this IoT age than the traditional 
timesharing, 'kick-me-off-when-I-log-out' mode.


I would agree and observe that even the timesharing model was never really 
kick-me-off-when-I-log-out.
Processes have an owner (username) and run by themselves. Some effects related 
to father-child lifecycle
are almost accidental (broken pipe and so on) and easily avoided (nohup, 
screen).
The concept of "login" was just associated to how you entered the system 
(authentication,...), and there
was no real concept of "session".
The "session" concept mostly came from the graphical interfaces, where many 
pieces have to collaborate to
give the final experience, that started the "session daemons" fashion.
Some not-Unix operating system that were almost useless without a login (and 
without a graphic card)
reinforced this idea that "the machine does something only when somebody is logged 
in".

Regards.
--
   Roberto Ragusamail at robertoragusa.it
___
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: /etc/yum.repos.d -> /etc/distro.repos.d

2019-03-15 Thread Roberto Ragusa

On 3/15/19 12:32 PM, Michal Domonkos wrote:


That said, if we should pick a different name today, "yum" seems like
the most sensible choice. While still far from ideal, it has
stickiness within the Fedora/RHEL community, and is a "trademark",
really.


Yesterday's Updater Modified
:-)

--
   Roberto Ragusamail at robertoragusa.it
___
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: /etc/yum.repos.d -> /etc/distro.repos.d

2019-03-14 Thread Roberto Ragusa

On 3/13/19 6:10 PM, Björn Persson wrote:


It was discussed on this list last June. The renaming to DNF never
happened in RHEL/CentOS. It's Yum in RHEL 7 and (I hear) it will be Yum
in RHEL 8. Presumably the reason for this is that the sysadmins who
manage RHEL systems like continuity, dislike pointless renaming, and
really hate having to remember to type "dnf" on some servers and "yum"
on others for no good reason.


Renaming dnf to yum is IMHO the best option.
I constantly use the wrong tool when switching between Fedora and Centos,
and the painful "yum.repos.d" string issue (code + docs) would disappear.

Considering that yum has no future and that the options are sufficiently
similar, why not just consider dnf as a new and slightly incompatible yum
version.
(remember egcs -> gcc many years ago)

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
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


Adding zstd support for mksquashfs

2019-02-20 Thread Roberto Ragusa
Hi,

squashfs is now supporting the interesting zstd compression algorithm,
but the mksquashfs tool in Fedora doesn't support zstd.
The upstream code does, it is in the master branch, but there have not
been releases for years (version 4.3 since fedora 19).

https://sourceforge.net/p/squashfs/code/commit_browser

I tried compiling it and it went fine after adding a couple of
#include 
not actually related to zstd.

Which is the correct way to get this into Fedora?

Regards.
-- 
   Roberto Ragusamail at robertoragusa.it
___
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: F30: System-Wide Change proposal: DNF UUID

2019-01-11 Thread Roberto Ragusa
On 1/8/19 4:22 PM, Lennart Poettering wrote:

> If all you want to do is count, then it should be entirely sufficient
> to do it like this:
> 
>GET /metalink?repo=fedora-28=x86_64==1 HTTP/1.1
> 
> the first time within each one-week window and a simple
> 
>GET /metalink?repo=fedora-28=x86_64= HTTP/1.1
> 
> all other times.

As an additional improvement, is it really needed to count every machine?
We can subsample a lot, and only let some specific machines to show
up for counting.

That is, apply the logic above only if(hash(machine_id)%1000==0)
(this becomes a poll instead of a referendum, results must then be multiplied 
by 1000)

Or, to avoid having somebody constantly be counted and other constantly ignored,
the rule could be if(hash(machine_id)%1000==hash(weekofthecentury)%1000)

With this setup I know that 99.9% of the weeks I'm not reporting anything at 
all.

Of course 1000 is a constant that may be tuned, but looks a good choice
to me if the expected total number is on the order of 1 million.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

2018-11-22 Thread Roberto Ragusa
On 11/22/2018 05:55 AM, Kevin Kofler wrote:
> 
> The thing is, with a fast network and a slow CPU, deltarpms actually slow 
> you down. No wonder users in such a situation hate them.
> 

Actually, with a fast network and even a FAST CPU, deltarpms actually slow
you down.
There is no CPU where deltarpms is faster than the megabytes/s of a good 
network.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
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: Better fonts by default?

2018-11-12 Thread Roberto Ragusa
On 11/11/2018 01:10 PM, Nikolaus Waxweiler wrote:

> All I remember saying is that subpixel rendering is
> not essential to getting nicely rendered fonts, as you can see in Qt5:
> 
> https://i.postimg.cc/t4XnfGzt/Bildschirmfoto-vom-2018-11-11-11-45-41.png
> https://i.postimg.cc/c4GnRngz/Bildschirmfoto-vom-2018-11-11-11-46-28.png

This is not an example of good rendering IMHO.
It looks like the standard blurry grayscale you get on a Mac.
Subpixel rendering (rgb, slight hinting, slight filtering) would improve
this a lot.

> Download the original PNGs and compare  subpixel rendering (here with
> the light LCD filter) can improve contrast a bit, but grayscale looks
> pretty good, too. Provided you like the overall smooth look of light
> hinting.
Any links for the subpixel variants?

-- 
   Roberto Ragusamail at robertoragusa.it
___
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: Attention Gmail users, please turn off HTML mail

2018-10-18 Thread Roberto Ragusa
On 10/09/2018 04:06 PM, Anderson, Charles R wrote:

> One click is too much for my terminal email client via SSH on my
> phone.  My email client already supports filtering into separate
> mailboxes for each list and also supports threads shown in a
> hierarchy.  If Fedora lists go away in favor of a web forum, I will
> probably just not participate anymore.

That's more or less the same for me.
My fetchmail, procmail and thunderbird setup gives me a way to
keep an eye on this (and many other mailing lists) without much effort.
I will not consider switching to a forum based website, since
my experience with projects using them has been discouraging.
Any "mailing list mode" will be a second class citizen, with
limitations and constant babysitting, and certainly due to be removed
in the future because "most of our users are using the web UI".

I'll probably not follow Fedora anymore.
My folders contain all fedora and fedora-devel mails
since my subscription, on 24/12/2005 (that is, Fedora 4),
not sure if there will be a 2019 folder.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
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: Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything

2018-09-05 Thread Roberto Ragusa
On 09/03/2018 02:07 PM, Hans de Goede wrote:

> The boot menu should show if the previous boot is considered
> unsuccessful I guess that you have left the gnome-initial-setup
> gnome-shell session sit around for more then 2 minutes and then
> the boot is considered successful if you press "ctrl + alt + F4"
> and then "ctrl + alt + del" as soon as you get the broken
> gnome-initial-setup screen, it should reboot into the menu
> (this worked for me when I hit the same issue).

Have we seriously reached the point of engineering things
so that the way the system boots depends on your speed
at cursing at the software when things don't work?

Regards

-- 
   Roberto Ragusamail at robertoragusa.it
___
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: I would like to propose that we turn on XFS Reflink in Fedora 29 by default

2018-05-25 Thread Roberto Ragusa
On 05/02/2018 11:35 AM, Marius Vollmer wrote:
> Neal Gompa <ngomp...@gmail.com> writes:
> 
>> And there's still the fun restriction of XFS not being able to shrink.
> 
> But note that even ext4 can't shrink while being mounted.

I consider that an annoying limitation of ext4, and I would not expect
a replacement filesystem to remove features instead of adding them.

We should have got online shrinking as standard nowadays, IMHO.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
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/HO4PILV5VQQRPBTSIDR52CF25HW5P3K3/


Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

2018-02-17 Thread Roberto Ragusa
On 02/16/2018 10:35 PM, Jason L Tibbitts III wrote:
>>>>>> "RR" == Roberto Ragusa <m...@robertoragusa.it> writes:

> RR> Was that a valid consideration? Has something changed on that front?
> 
> It was, and packages will now fail to build (via brp-ldconfig) if they
> don't package those symlinks.  Though in practice packages which did not
> do this would have been exceedingly rare anyway and when I checked the
> package set looking for examples a year ago I think I only turned up two
> examples.

Thank you for clarifying this.
So in theory without ldconfig symlinks could have remained misconfigured,
but nowadays packages are forced to take care of links themselves.
Indeed, even in the old world, my upgrade went fine, I can't exclude that
some scripting may have failed, but I never noticed any unexpected issue.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: [HEADS UP] Replacing %post/%postun -p /sbin/ldconfig

2018-02-16 Thread Roberto Ragusa
On 02/14/2018 10:14 PM, Matthew Miller wrote:

> I'd be super-interested in benchmarks comparing before and after
> install times. I guess since the plan is to do this _after_ the mass
> rebuild, we'll need to wait until after the *next* rebuild to see how
> much impact this has.

Many years ago, I remember a Fedora upgrade (from version 4 to 5, I think)
on a SATA disk on a Dual CPU PowerMac G5 (great machine at that time).
The upgrade was progressing incredibly slow, and I was able to discover
that every lib package upgrade was triggering ldconfig and spending a lot of 
time.
So I renamed /sbin/ldconfig away (replaced with a stub or something), and speed
went way up. After the RPM upgrade phase, I restored ldconfig and run it 
manually.

When I proposed this kind of optimization in some mailing list (maybe this 
one?!),
I was answered that my method was not entirely safe because there could have 
been
problems for some rpm scripts calling libraries that had been just upgraded
(e.g. perl libraries) without a proper ldconfig refresh.

Was that a valid consideration? Has something changed on that front?
I was convinced that ldconfig was a sort of cache, not critical to actually
find libraries.

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Remove old GPG keys?

2017-10-31 Thread Roberto Ragusa
On 10/31/2017 09:52 AM, Miroslav Suchý wrote:
> I just stumbled upon
>   
> https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remove-rpmkeys
> with the nice link to:
>   
> https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from-rpm/
> And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we 
> automate the removal of old keys?

They indeed pile up after many upgrade cycles:

# rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l
64

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: GnuPG 2.2.0 and replacement of GnuPG1

2017-09-04 Thread Roberto Ragusa
On 09/04/2017 06:13 PM, Till Maas wrote:
> On Mon, Sep 04, 2017 at 09:23:05AM +0200, Roberto Ragusa wrote:
> 
>> $ date|gpg2 --passphrase aaa -ca
>>
>> This shows a popup asking me for a passphrase, while it works
>> perfectly on gpg v1.
> 
> You need to add --batch to the command line:
> $ LANG=C date|gpg2 --batch --passphrase aaa -ca | gpg2  --batch --passphrase 
> aaa
> gpg: AES encrypted data
> gpg: encrypted with 1 passphrase
> Mon Sep  4 18:12:56 CEST 2017

You are right, but existing scripts do not expect this,
especially if they are calling "gpg" and getting gpg2.


-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: GnuPG 2.2.0 and replacement of GnuPG1

2017-09-04 Thread Roberto Ragusa
On 09/04/2017 08:56 AM, Remi Collet wrote:

> gnupg v2 is a nightmare for "server", I maintain some PHP extensions and
> libraries which works perfectly against v1, and not against v2
> 
> And, AFAIK, v1 is still maintained.

$ date|gpg2 --passphrase aaa -ca

This shows a popup asking me for a passphrase, while it works
perfectly on gpg v1.

???



-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Firefox crashing in updated F25: consider this fix

2017-03-09 Thread Roberto Ragusa
Hi,

on my updated F25, Firefox has been crashing (sometimes on startup, during 
restore session),
and one time it was able to crash Xorg too.

I found that this patch solves the problem:

https://bugzilla.mozilla.org/attachment.cgi?id=8839990=diff

I do not see it included in koji builds, please consider adding it.
My rebuilt rpm is working fine.

Regards.

Attachment #8839990: clean gtk window's surface provider before it gets 
destroyed. r=karlt for bug #1335827

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Important: NSS + Firefox + Thunderbird + Seamonkey + Icecat + Xulrunner

2017-01-24 Thread Roberto Ragusa
On 01/21/2017 04:15 PM, Kai Engert wrote:
> On Sat, 2017-01-21 at 15:47 +0100, Christian Dersch wrote:

> The current Firefox 50.x will go unsupported on Tuesday, replaced by Firefox 
> 51.
> Usually new important security fixes are contained in the new Firefox update.

Going unsupported upstream is not the end of the world.
If we keep 50.x for a few days, worst case scenario is to have to address
a fresh critical security vulnerability and then you have two
possible option:
1) rush to 51.x (with good reason, this time)
2) backport any fix to 50.x even if upstream does not (this was once normal way
to maintain packages)

Regards.
-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Debugging random suspend?

2017-01-06 Thread Roberto Ragusa
On 01/04/2017 06:55 AM, John Reiser wrote:

> One of the causes of Suspend is the hardware generating the signal for
> "the laptop lid has been closed."  Look at the boot messages ("dmesg"
> or "journalctl -b") for info on the power switch, the lid switch, etc.
> 

Or low battery level.
If the battery is incorrectly reported at 1% or 0% for an instant, suspend 
could be triggered.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: RFC: Change the default hostname for Fedora 26+

2016-11-10 Thread Roberto Ragusa
On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:

>> Having it CAPS doesn't sound very nice ...
>> 
> 
> Yeah, that's fine. I was kind of copying off the windows approach, but I 
> really don't care at all whether we present it in lower-case or upper-case as 
> long as it's consistent.

All lower case, please.
Lower case is the default everywhere in Unix, and the hostname also contains
an Internet related meaning, where only lower case is used.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

2016-10-07 Thread Roberto Ragusa
On 10/04/2016 08:10 PM, stan wrote:

> I think I can confirm this advice.  I always run dnf manually from the
> command line, in a VT logged in as root.  And I can run X while doing
> this and I've never had a dnf update issue.

The problem with this is that the VT doesn't have a long history,
so if you can't really see what dnf has done.
(e.g. I visually search any rpmsave rpmorig rpmnew warning)

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: systemd 230 change - KillUserProcesses defaults to yes

2016-06-04 Thread Roberto Ragusa
On 06/02/2016 01:04 PM, Lennart Poettering wrote:

> Well. Let's say you are responsible for the Linux desktops of a large
> security-senstive company (let's say bank, whatever), and the desktops
> are installed as fixed workstations, which different employees using
> them at different times. They log in, they do some "important company
> stuff", and then they log out again. Now, it's a large company, so it
> doesn't have the closest control on every single employee, and
> sometimes employees leave the company. Sometimes even the employees
> browse to the wrong web sites, catch a browser exploit and suddenly
> start runing spam bots under their user identity, without even
> knowing.

Do you really want to support a disruptive change in default behaviour
with such a specific use case?

-- 
   Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: systemd 230 change - KillUserProcesses defaults to yes

2016-05-30 Thread Roberto Ragusa
On 05/27/2016 03:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
> This change was done for a reason: left-over session processes
> are causing real problems.

The original error was in fact having random processes spawned
without user consent: configuration handlers, sound mixing,
policy handlers and other stuff.

Now a problem is solved by adding a new problem.

-- 
   Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: F25 System Wide Change: Use /etc/distro.repos.d as default reposdir

2016-05-17 Thread Roberto Ragusa
On 05/17/2016 04:48 PM, Lukas Zapletal wrote:

> Sure. I always find annoying when there are two entities:
> 
> something.conf
> something.d/
> 
> so in order to expend the directory, I need to tab twice. I hope there
> will be no repos.conf :-)

Right.
Wouldn't have been better to go with the following?

something.conf.d/something.conf [base conf file, handled by something.rpm]
something.conf.d/*.conf [additional files, handled by other rpms or 
manually]

In this way the rule would have been "if you do not see something.conf,
it is actually inside something.conf.d", and expansion would be very 
straightforward.

Regards.
-- 
   Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: LibreOffice packaging is a messy dependency graph

2015-12-02 Thread Roberto Ragusa
On 12/02/2015 02:42 PM, David Tardon wrote:

> On Tue, Dec 01, 2015 at 02:20:34AM -0500, Dan Book wrote:
>> I have run into this before and it was very confusing, it really should be
>> a separate command from remove for when you actually want to remove what
>> dnf thinks is now "unused".
> 
> Why? Remove is the opposite of install. "dnf install foo" will install
> package foo _and_ all its dependencies. So it is only logical that
> "dnf remove foo" should remove package foo _and_ all its (unneeded)
> dependencies.

Maybe it is not so simple.
There are dependencies with no use apart the main tool (tool requires 
tool-libs),
but in some cases the dependency is useful on its own (e.g. fonts).

So, I counter your reasoning with this:

- dnf install foo (also installs bar)
- dnf install bar (oops, already installed, good)
- dnf remove foo (wow, why did it remove bar, I explicitly "installed" it 
yesterday!)

Is dnf able to recognize that bar was "wanted" and not "accidental"?

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org


Re: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

2015-08-16 Thread Roberto Ragusa
On 08/14/2015 02:38 PM, Wei-Lun Chao wrote:
 Hi,
 
 Is there already any discussion about:
 rename arch name noarch to all
 rename arch name x86_64 to amd64
 rename package name kernel-PAE to kernel
 and even rename package name kernel to linux

IMHO

kernel-PAE - kernel is reasonable, if the nonPAE is suppressed

x86_64 - amd64 is a good idea, as the architecture was created
by AMD; dropping an underscore is nice too

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: noarch vs. all, x86_64 vs. amd64, kernel vs. linux and PAE

2015-08-16 Thread Roberto Ragusa
On 08/16/2015 10:55 AM, Reindl Harald wrote:
 
 no the architecture was created by Intel
 
 AMD added the 64bit capabilities in a compatible way other than Intel itself 
 tried with Itanium which was not able to run i686 instructions and later 
 Intel was forced to license the AMD extensions

Well, saying that the architecture was created by Intel is an evident
rewrite the history exercise.

You immediately contradict in the second sentence, where you describe the IA64 
fiasco,
and the adoption of AMD64 by Intel.
Or maybe you think that licensing the AMD extensions is equivalent to the 
architecture
was created by Intel?

Let's recap how it really went:

- Intel designed a new incompatible arch (IA64), it was useless at emulating 
the i386
and was a substantial market failure
- AMD designed the AMD64, as an extension if IA32
- Linux was running on AMD64 immediately at day 0, as AMD had been giving 
around simulators
for chips not created yet
- Microsoft, who had already ported Windows to IA64, created an AMD64 version 
too
- Intel tried to avoid the humiliating acceptance that their rivals did a 
better job
than them, by going to extend the ia32 in a different way
- Microsoft told Intel I already did a port for you, you do not dare asking me 
another
- Intel released the EM64T architecture
- Linus wrote a furious email saying that he had spent time studying the EM64T 
manuals
only to finally realize that it could all have been replaced with just the 
sentence
it's AMD64 (differences are only found in little details)

Nowadays some use AMD64 and some x86_64, with Intel preferring the second 
for obvious reasons.

Having said that, the cost of change has got probably too high, so we will keep
the current mix of AMD64 (used by BSD, Windows, Solaris, Java, Debian)
and x86_64 (used by Linux, Fedora, SuSE, gcc).

Regards.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: Abotu setting 'PermitRootLogin=no' in sshd_config

2014-11-21 Thread Roberto Ragusa
On 11/21/2014 09:42 AM, Reindl Harald wrote:

 why? because they are servers for specific tasks and *any* non-root login 
 would be followed by su - root anyways and for automated rsync scripts 
 backing up data only root has access you need it also

For rsync-as-root use cases my usual approach is to create another
account with userid=0 and login with ssh on this account.
It is not root, but it has the same powers (because the numeric uid is the only
thing it really matters).

Just wanted to share the trick.

Best regards.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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

2014-10-22 Thread Roberto Ragusa
On 10/21/2014 10:02 PM, Lennart Poettering wrote:

 Maybe
 that's actually a strategy to adopt here: upload the encryption keys
 into the firmware as efi vars, and then pull them out on next boots or
 so (assuming that efi vars can be marked to survive soft reboots
 without making them fully persistent...)

Hmmm, surrendering your encryption keys to the only software
part which you do not have control on?

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: No more deltarpms by default

2014-10-17 Thread Roberto Ragusa
On 10/06/2014 07:57 PM, Reindl Harald wrote:
 
 oh no - don't tie all together for reasons which did not destory the world 
 over years - it is a damned good design that the part dealing with rpm 
 packages don't need to know anything aboutt delta rpms because the normal 
 packages are created before that step
 

And, going further on the same road... why don't we just find a way to
locally produce the original rpm by downloading through rsync?
Are compressed rpms completely impossible to diff efficiently by rsync?
(losing a bit of compression efficiency could be acceptable if rpms
became rsyncable)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: No more deltarpms by default

2014-10-17 Thread Roberto Ragusa
On 10/06/2014 07:25 PM, Reindl Harald wrote:

 the last discussions suggested that the result needs to be *identical* to the 
 full RPM downloaded for not break signatures

Bizarre design; the signature should protect the content (uncompressed), not
the transport method (compressed).

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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

2014-09-16 Thread Roberto Ragusa
On 09/12/2014 05:47 PM, Richard Hughes wrote:

 That's just not safe. Have you ever had firefox open and done a
 firefox update? Widgets start disappearing, redraws start having weird
 artifects and then after a little while it just crashes. Other
 applications like LibreOffice behave the same. Anyone that says things
 like the old version of the library stays in memory obviously hasn't
 actually done much real-world GUI programming in the last decade, or
 runs any kind of secure desktop system.

You are basically saying that modern software is just breaking
things which were perfectly solved decades ago.
If applications would just use libraries correctly, the kernel
would be able to let parts of deleted files be available for lazy
loading.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: delta rpms - can we turn them off

2014-06-29 Thread Roberto Ragusa
On 06/29/2014 12:34 PM, drago01 wrote:
 Well they should (or have some other source of documentation) ... the
 config file isn't really the right place for documentation, given
 that it does not get updated once you have edited it once ... you will
 miss new options / changed semantics that way.

This is way you keep an eye an any *.rpmsave, *.rpmnew
and merge the differences (with a proper tool, like meld).

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: OpenH264 in Fedora

2013-11-06 Thread Roberto Ragusa
On 11/04/2013 07:30 PM, Alberto Ruiz wrote:

 A media codec should not be a system wide component (I'd go as far as
 saying it should not be user-session wide, but application bundled).

???
Would you so apply the same reasoning to libjpeg and libtiff?
Security nightmare.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: Dracut HostOnly or ConfigurationOnly?

2013-09-06 Thread Roberto Ragusa
On 09/06/2013 11:05 AM, poma wrote:
 On 05.09.2013 16:51, Harald Hoyer wrote:
 
 This Fedora release builds an initramfs tailored especially for your computer
 hardware. If you change your machine or partitions or significant hardware, 
 you
 might have to boot with the Rescue boot entry and execute dracut
 --regenerate-all. If you want your initramfs to be hardware independent,
 install the dracut-nohostonly rpm package. If you don't want rescue images 
 at
 all (like in virtual machines), install the dracut-norescue rpm package.

 
 Package over here, package over there.
 It's not so long ago called configuration.
 Now if we want to configure something, we install a package.
 Can someone package a pizza and send it here.
 Oh wait, I forgot about prosciutto.
 Install a prosciutto package, please.

Using package installation as configuration is quite bizarre.

Wasn't there a specific policy that installation and configuration
are two different things?
You installed httpd, ok, so you have the stuff on your disk, but that
does not mean it will run at next reboot, you have to configure and
activate it explicitly.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
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: Bad file access on the rise

2013-06-09 Thread Roberto Ragusa
On 06/08/2013 04:13 PM, Doug Ledford wrote:
 
 Yes, but none of these results show the .12s time that your first
 noatime test run showed in your original post.  If you are now saying
 that atime is faster than noatime by about .005 to .010s, then these
 results seem to show that.  But your original post was from .019 to .12,
 or a difference of .10+s.  That was cache load time, not just the
 syscall difference.

Hmm, someone is misreading the results.
I've reread multiple times, and I see a difference of 12s, not .12s.

--- real   0m12.645s
--- user   0m0.003s
--- sys0m0.159s

And 12 seconds (elapsed, with 0.159s system) means 12s/5000=2.4ms
which could only be explained with the auditing system doing fsync
calls on its log files.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: FYI: F20 Feature: Migrate to Bluez5

2013-05-06 Thread Roberto Ragusa
On 05/06/2013 11:13 AM, Peter Robinson wrote:
 On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnoc...@redhat.com wrote:

 For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to
 be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5.
 Packages for BlueZ5 will be available as soon as we figure out how to
 integrate a few downstream features that were in the Fedora packages.

 Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
 other applications relying on Bluez4 will need to be ported by their
 respective maintainers.
 
 
 Any analysis to what packages are affected, how many are yet to
 support the new API and how hard it will be for them to be ported
 over.
 

Impact on KDE?

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Do you think this is a security risk and if not is it a bad UI decision?

2013-05-05 Thread Roberto Ragusa
On 05/04/2013 06:35 PM, Adam Williamson wrote:
 http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-passwords
 
 Well, that escalated quickly.

And in one of the replies:

http://it.slashdot.org/comments.pl?sid=3716785cid=43628711

  I like the way Windows 8 addressed this problem. They added a button that
  looks like an eye on the right hand side of the password field to show
  the password as you've typed it. That seems like a better compromise than
  briefly showing the password characters.

I think Microsoft just succeeded in teaching Linux something about security 
practices.
And this is not something to be proud of.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ANNOUNCE] xf86-video-intel 2.20.16

2012-12-17 Thread Roberto Ragusa
On 12/16/2012 09:44 PM, Reindl Harald wrote:

 i notice slow gui / hangs after running KDE fpr many hours on machines with 
 VMware-Workstations guests in background which is a little bit strange on 
 IvyBrdige machines with 16 GB RAM and RAID10
 
 after logout / login all is snappy again and note that the in the background 
 running VMs are not touched - so this must be graphics related at all

Does vmware continuously blink something in the system tray?

It could be tripping into this:

http://lists.x.org/archives/xorg-devel/2012-November/034555.html

It happened to me with psi, I fixed it with this patch, but
my attempt to have it merged has been ignored completely...

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

2012-12-09 Thread Roberto Ragusa
On 12/08/2012 07:52 PM, Rahul wrote:
 On 12/08/2012 01:48 PM, Roberto Ragusa wrote:
 (my two cents, as someone using Red Hat / Fedora daily since RH5.1, and 
 never stepping up as Fedora packager because too scared by the bureaucracy) 
 
 Can you be more specific?  What sort of bureaucracy do you think is avoidable 
 in the current process?  What would it take for you to get started?

I do not have specific suggestions, as I actually do not know the process well,
and even less the motivations behind each steps.

I can only say that at
  https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
23 steps are shown under Becoming a Fedora Package Collection Maintainer.

Some of them are technical and more or less unavoidable (koji, expiring 
certificates,
scm, bodhi), others are more social (ask a review, introduce, inform upstream,
get sponsorship), finally there is legal stuff (the CLA).

My enthusiasm has never been powerful enough to overcome such an amount
of static friction.
I do not have a bag of packages to add to Fedora, so going through all the
steps just to maintain one rpm or two is costly. I'm sure that after being
inside the willingness to do more will raise easily, but the initial
investment appears unjustified.
Replying to random posts on the MLs or contributing patches to random projects
is more appealing (write mail, click send, finished).

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

2012-12-08 Thread Roberto Ragusa
On 12/07/2012 08:26 PM, Mark Bidewell wrote:
 
 It underscores the need for the base OS or core to be absolutely as small as 
 possible.  FreeBSD provides a good model, small installed system customized 
 with packages/ports.  Personally I would like to see a three-level approach:
 
 Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - 
 moves the slowest.
 Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, 
 KDE/QT, GNOME, etc - moves faster.
 Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
 
 A major change to one level should cause a rebuild of higher layers to avoid 
 the API issues you mention.  Changes within a layer should be independent.  I 
 would propose change rates of:
 
 Level 1 - 12-18 mos
 Level 2 - 6-12 mos
 Level 3 - release as soon as stable packages are available.

IMHO it is not the level of things which is problematic.
I have no problem with rapid updates for the kernel (great for hardware
support and bug fixes), or for X11 (same reasons), gcc upgrades never
gave me problems, I like the fast updates to KDE.

There are two things which are problematic:

1) projects undergoing great revolutions. They are quickly absorbed
by Fedora and all the immaturity issues of the projects cast shadows on Fedora.
Two examples: GNOME 2-3, KDE 3-4; exactly the same problem, upstream
changing everything and users unhappy about the results (even if different
answers were given by KDE (wait, we will readd what is missing) and
by GNOME (forget what is missing, this is how it will be).
Obviously a regression of the desktop environment is not a small detail
for end users (read: Fedora doesn't work).

2) revolutions at the system level. Things that replace other things and
everything changes: command line tools, GUIs, config files, logs, ...
Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld.
These projects sometimes have bugs (being in their infancy), often
are badly documented and are always completely unknown by end users; the
result is that things do not work and who knows how this should be fixed.
In many cases the impact on the collateral utilities (dracut,
system-config-*, anaconda, ...) contribute to the chaos.

As a final consideration, the fixability of the issues is important.
I can easily revert to a previous kernel, I can less easily throw
away pulseaudio, and I can in no way fix GNOME 3.

(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and
never stepping up as Fedora packager because too scared by the bureaucracy)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: raising warning flag on firewalld-default feature

2012-11-14 Thread Roberto Ragusa
On 11/13/2012 05:35 PM, Richard W.M. Jones wrote:
 On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote:

 It could be argued that python is more suited to long lived programs:

 $ time /bin/true
 real 0m0.002s
 
 Hmmm:
 
 $ echo ''  true.ml
 $ ocamlopt.opt true.ml -o true
 $ time ./true
 
 real   0m0.002s
 user   0m0.000s
 sys0m0.001s
 
 $ time /bin/true
 
 real   0m0.001s
 user   0m0.000s
 sys0m0.001s
 
 This seems about right to me: Both ocamlopt  gcc generate native
 x86-64 programs, but there's a small amount of overhead in the OCaml
 binary (initializing the minor heap of the GC).

Just for fun, let's see who is the worst.

$ cat JavaTrue.java
public class JavaTrue {
public static void main(String[] args) {
System.exit(0);
}
}
$ javac JavaTrue.java
$ time java -cp . JavaTrue

real0m0.071s
user0m0.037s
sys 0m0.035s

Hmmm. Slow and with a lot of sys...
Let's try compiling it to native.

$ gcj -o JavaTrue JavaTrue.java --main=JavaTrue
$ time ./JavaTrue

real0m0.026s
user0m0.016s
sys 0m0.010s

Good improvement, but still quite slow.

(OT: what a pity gcj is abandoned... great project)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: yum upgrade from F17 to F18

2012-11-09 Thread Roberto Ragusa
On 11/09/2012 10:19 AM, drago01 wrote:
 On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý msu...@redhat.com wrote:
 On 11/08/2012 03:10 PM, Roberto Ragusa wrote:

 Hmm, I now see there is a set -e at the beginning.
 Still a little scary.:-)


 Scary is only the idea. And only because we are not used to do rolling
 upgrades. Ask somebody from Debian experiance if this is scary ;)
 
 There are some upgrade tasks that you simply cannot do from within a
 running system (ex: usermove).

Serious question: why usrmove is not doable?
If you have all the dirs in your path, and move executable files from one
place to another, why should this fail?

I managed to do a 32 bit - 64 bit transition (you know, the absolutely
unsupported upgrade) on a system which was running an entire KDE session.
My upgrade commands (rpm, yum, bash, everything else) started 32 bit,
then were mixed, then ended to be 64 bit.
Usrmove appears simpler. Am I missing something?

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: yum upgrade from F17 to F18

2012-11-08 Thread Roberto Ragusa
On 11/08/2012 02:41 PM, Jóhann B. Guðmundsson wrote:

 You should file this as an RFE against yum since arguably this should be the 
 default behavior when users run yum upgrade but since the yum maintainers 
 have not done that already there has to be some gotcha- you are forgetting

The process can fail in a lot of places, so having a script to blindly go ahead
is dangerous.

I would personally always use a script like this as a sequence of commands
to be run by hand.
If something happens in the middle of the steps, I have to solve it manually
(e.g. removing some external rpm in case of dep problems).

Hmm, I now see there is a set -e at the beginning.
Still a little scary. :-)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox / Thunderbird 17 ESR for Fedora 16/17

2012-09-23 Thread Roberto Ragusa
On 09/22/2012 09:03 PM, Matthew Miller wrote:
 On Sat, Sep 22, 2012 at 07:37:13PM +0200, Roberto Ragusa wrote:
 Does it mean Fedora will stop shipping the latest FF/TB and stick to ESR
 instead? Or is it for parallel-installation purposes?
 Assuming RHEL will have ESR (which is reasonable), either Fedora also stays
 with ESR (which is against the first F) or RHEL loses the tested in 
 Fedora
 advantage.
 
 Wait, which F is that? Freedom? I think both ESR and regular firefox
 releases are 100% free and open source software.
 
 Or did you mean First?

First :-)


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox / Thunderbird 17 ESR for Fedora 16/17

2012-09-22 Thread Roberto Ragusa
On 09/22/2012 01:02 PM, Julian Sikorski wrote:

 Does it mean Fedora will stop shipping the latest FF/TB and stick to ESR
 instead? Or is it for parallel-installation purposes?

Assuming RHEL will have ESR (which is reasonable), either Fedora also stays
with ESR (which is against the first F) or RHEL loses the tested in Fedora
advantage.

Is anyone going to clarify the strategy?

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-09-13 Thread Roberto Ragusa
On 09/13/2012 03:54 AM, Pádraig Brady wrote:
 I'm going to err on the side of leaving sort(1) as is
 and using /tmp by default, as detailed at:
 http://lists.gnu.org/archive/html/coreutils/2012-09/msg00139.html

This is the perfect solution for all the people who
will switch /tmp back to disk immediately after installation.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-07-13 Thread Roberto Ragusa
On 07/12/2012 09:54 PM, Harald Hoyer wrote:

 Again.. tmpfs is restricted to half the RAM size by default. You can't
 store 8-9GB of trash.. only 2GB, which might land on swap over time.

As I have already pointed out some time ago, isn't a bizarre situation
that as an application developer I can either use malloc() and store things
up to RAM+swap (lets' say 4+6=10GB) or use temporary files and store
things up to RAM/2 (lets' say 4/2=2GB)?

Once upon a time you used to use files to go *beyond* RAM limits.

And the answer to this objection is? move to /var/tmp.
So patch everything (and good luck with closed source stuff).

Wouldn't have been more reasonable to create a /ramtmp and patch
the applications? (this would have just been patched for speed, not
patched for correctness as the sort case).
Hey, wait, we already have /dev/shm. So we just had to patch
the applications (if anyone cares).


-- 
   Roberto Ragusamail at robertoragusa.it


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

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-06-21 Thread Roberto Ragusa
On 06/20/2012 08:06 PM, Brian Wheeler wrote:
 So the default is that I can use 2G in /tmp regardless of how much swap is 
 present if the system memory size is 4G?  So the only way to get more /tmp is 
 to either mess with the max% or buy more ram?

Let's say it in this way:
on a 4GB machine if the application uses the RAM, it works until (4GB+swap),
but if the application uses a /tmp file, it works until 2GB!
...so using /tmp means you have less space... (facepalm)

/tmp has always historically been a place where you dump large data.
Disk size increases faster than RAM size.
Switching disk storage to RAM storage by default is simply wrong.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: Sandy Bridge - lags, missing effects, ui-crashes

2012-06-16 Thread Roberto Ragusa
On 05/29/2012 11:29 PM, Reindl Harald wrote:

 the follwoing params making things better and stop especially
 the lags most of the time, but on the same machine over a long
 time was set to pcie_aspm=force and all i915 option at 1
 
 pcie_aspm=off i915.i915_enable_rc6=0 i915.semaphores=0 
 i915.i915_enable_fbc=0
 
 i think i have to mention taht VT-d is active in the BIOS and
 i was wondering that it was stable because the combination of the
 i915 options with VT-d (hardware supported virtualization IO) is
 classified to be unstable

No issues for a couple of weeks, after disabling VT-d in the BIOS,
but there were kernel updates too, in the meantime.
(And I now expect the problem to show up immediately
after sending this mail) :-)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Important kernel update should not break stuff

2012-06-14 Thread Roberto Ragusa
On 06/14/2012 04:54 AM, Kevin Kofler wrote:
 Felix Miata wrote:
 Is never appropriate even if one's own experience is with 3 systems? 7
 systems? 13 systems? 40 systems? Never say never, or always. ;-)
 
 That can widen the class of affected devices, but from there to all Intel 
 WiFi is still a long stretch. (For a starter, last I checked they didn't 
 even all use the same driver, but some legacy chipsets had legacy drivers. 
 Then AFAIK there are different code paths in iwlwifi for different device 
 generations, and also different firmware. And then of course different 
 hardware behaves differently. Plus, WiFi issues also tend to depend on the 
 exact configuration you're using, in particular on how the access point is 
 set up. And finally there can be interaction with other hardware or drivers 
 on the machine.)

And do not forget the BIOS version, especially for suspend-related ACPI bugs.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Action required: Rawhide: /tmp is now on tmpfs

2012-06-01 Thread Roberto Ragusa
On 06/01/2012 03:55 PM, Pádraig Brady wrote:

 Not all /tmp user-cases need to move to /var/tmp
 
 sort is special in this regard in that it only uses
 external files when there isn't enough RAM.
 I.E. is expects it to be slower (larger).

Would you mind debating if anything else is special?

#  strings /usr/bin/*|grep ^/tmp$|wc -l
361

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-05-31 Thread Roberto Ragusa
On 05/31/2012 02:40 AM, Lennart Poettering wrote:
 Heya!
 
 Please be aware that since the most recent systemd uploads /tmp is now
 in tmpfs by default in Rawhide/F18.
[...]
 This will most likely lead to a problem or two with software that isn't
 happy about /tmp being small.

For example sort.

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

2012-05-31 Thread Roberto Ragusa
On 05/31/2012 12:55 PM, Ralf Corsepius wrote:
 On 05/31/2012 12:45 PM, Pádraig Brady wrote:

 Now /var/tmp should be more persistent which we don't need,
 Correct, using /var/tmp is wrong and a mistake.
 
 IMO, advising people to modify their code to using /var/tmp instead of /tmp 
 is absurd and evidence of ignorance towards traditional use of /tmp and the 
 FHS.
 
 So I'll patch sort to default to /var/tmp rather than /tmp.
 This would mean introducing a bug.

As far as I know:

/tmp is for large data with no expectation of reboot persistence
/var/tmp is for large data with expectation of reboot persistence

tmpfs is for *small* data, so not a good choice for /tmp,
it is certainly optimal for /var/run /var/lock and so on.

I suppose that an additional small-tmp (e.g. /tmpram) could
be useful for some programs currently using tmp for very
small files. But these programs should be patched to deviate
from a traditional Unix convention.
As small (and short lived) files are equally fast on tmpfs
or disk based /tmp, the whole effort is probably pointless.

What would be a really good solution is the ability to specify
very long timeouts for the VM write-back of a normal filesystem.
Having /tmp dirty data in memory for 2 hours (and immune to normal sync
commands) is the perfect approach.
Have RAM? Use RAM. RAM pressure? Becomes a normal disk.
(letting tmpfs swap is NOT the actually same thing, and I
doubt you can set tmpfs much bigger than real RAM)

It is quite easy to come up with use-cases where a small /tmp
will be a problem.

- any kind of temporary unpack/copy pattern, such as entering
a tar.gz with mc, unpacking of installation files for (mostly
proprietary) packages, ...

- vmware uses /tmp/ram0 (immediately unlinked) as guest RAM
backstore

- I personally use /tmp for large files (including ISOs of
DVD I want to burn and delete); maybe I'm the only one doing
that...

- I just discovered that my /tmp is currently 3.2GiB. The
majority of the space is for /tmp/kde-myusername/konsole*.tmp
(700MiB+520MiB+364MiB+305MiB+117MiB+), as I run konsole
with unlimited scrollback buffer and some shells have easily
been open for weeks.

If the feature is implemented and activated by default,
I will just turn it off and live happy. It will just be one more
thing in the growing list of defaults that should have never been
changed.
But be prepared to more than one or two future bugs of the
kind Oracle can't be installed, my backup program fails,
the machine slows down to a crawl and only a reboot fixes it, ...

Best regards.
-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: Sandy Bridge - lags, missing effects, ui-crashes

2012-05-29 Thread Roberto Ragusa
On 05/27/2012 07:54 PM, Reindl Harald wrote:
 Hi
 
 i notice growing problems on F16 with Intel Sandy Bridge graphics
 
 * desktop effects in KDE partly not working (3D cube as example)
   this worked well over months after upgrade from F14 to F15 and
 
 * sometimes the whole desktop hangs with display errors
   like missing parts of windows solveable mostly by logout
   but sometimes resulting in a complete system hang

This happened to me too.
Apparently in normal situations (scrolling a window, ...), I was almost
suspecting a hardware bug.

 * lags while starting applications or activate windows
   of running apps

Long lag (5 seconds) while starting LibreOffice; the window is frozen
at half-transparency while appearing and nothing else updates
(clock is stuck).

Fully updated x86_64 F16.
Nothing logged by the kernel.

It surely happened with more than one kernel: last time was today with
3.3.6-3.fc16.x86_64.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09)

Another thing, possibly related, long lag (20 seconds) when coming out of
suspend-to-ram; it seems to happen if I suspend on battery and resume with the
AC power connected (ACPI interaction???).

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SSD drives

2012-05-28 Thread Roberto Ragusa
On 05/26/2012 03:53 PM, Juan Orti Alcaine wrote:

 I suspect it isn't working because cryptsetup status
 /dev/mapper/luks-uuid does not say anything about discards. I think
 it must say flags: discards
 
 Any suggestion?

Directly testing if discard is working is doable, but not easy.
Create a file with known content, and identify the hardware sector
where it is mapped.
You can use filefrag -v, but you will have to compensate for
all the layers (LV, PV, luks).

Maybe it is easier to play with

blktrace -o - --dev YOUR_DEVICE |blkparse -i -

and identify the physical blocks you are writing your file to
(sync, start blktrace, create the file, sync, stop blktrace).

Then you read (with dd) the blocks from the crypted device (that is,
the one which does not do any decryption, e.g. /dev/sda), delete the file
and read the block again. If you get all zeros, discard is really
working; if not, it is probably not working.

Thinking about it: maybe blktrace is able to show you the discard command
in its output...

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SSD drives

2012-05-25 Thread Roberto Ragusa
On 05/24/2012 03:20 PM, Gerry Reno wrote:

 Since I'm putting an SSD in my laptop this is important because the laptop 
 drive must be encrypted.

I hope your CPU has AES-NI.
A powerful i7 does AES at 50MiB/s (don't remember exactly, but below 100MiB/s)
without AES-NI and about 900MiB/s with AES-NI.
SSDs speed is usually around 250MiB/s, so AES-NI is required to maintain speed.

Additional hint: I would avoid xts modes, as the speed is halved (450MiB/s)
for not really convincing security reasons.

I'm running AES with NI on a SSD and the CPUs are almost undisturbed by disk
activities.

Cipher name:aes
Cipher mode:cbc-essiv:sha256
Hash spec:  sha256



-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: SSD drives

2012-05-24 Thread Roberto Ragusa
On 05/24/2012 02:38 AM, Gerry Reno wrote:
 What does Fedora do currently, if anything, to optimize for solid-state 
 drives (SSD).
 
 Things like swap and logging can generate a huge number of writes.  So I 
 suppose those should maybe be placed on a
 rotating drive if one is available but if not does Fedora do anything to 
 reduce the amount of writes?  Or is everything
 related to SSD the responsibility of the user?

I think Fedora aligns partitions to 1MiB boundaries and disables atime (with 
relatime),
both things are good for SSD drives.

Using tmpfs for /tmp is also ok.

I've been using SSD drives for a couple of years, and in my opinion
concerns about logs and swap are exaggerated.

And having swap on SSD is a GREAT thing if you use hibernation. :-)


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [announce] yum: parallel downloading

2012-05-20 Thread Roberto Ragusa
On 05/20/2012 06:10 AM, Glen Turner wrote:
 On 19/05/12 01:04, José Matos wrote:
 
 The total number of connections should be the same, as far as I
 understand only the number of connections from a single host will be three.
 
 The risk is the rise in the maximum number of concurrent connections. A
 server happily supplying 50,000 concurrent connections should not be
 assumed to remain happy at 150,000 concurrent connections.

Why do you think that there will be 150,000 concurrent connections?
The difference could be that instead of
- 50,000 concurrent users, each downloading one file
you have
- 16,667 concurrent users, each downloading 3 files
The number of concurrent users is now lower because, well, each of them
now completes a yum update in one third of the time.

Reality could be different for several reasons (are users bandwidth limited?
if the server bandwidth limited?), but the concept is fine and it has
been perfectly expressed by Jose.

 Since it should be safe to assume that the downloads are independent
 events then there should not be any significant difference for busy
 servers. :-)
 
 I am afraid that I have missed your point here. I am somewhat blinded by
 the use of the word independent. I have a statistical background and
 that word carries a meaning similar to unrelated.

50,000 connections from different users are independent.
50,000 connections from 16,667 users doing 3 connections are almost
as independent as before.
Statistically, consider a random variable which is 0 (not downloading)
or 1 (downloading).
Compare:
  sum of N independent variables
to:
  three times the sum of N/3 independent variables
If N3, not only the average is the same, but higher-order statistics are
only slightly higher. It is reasonable to say that the probability distribution
is practically the same.

An example:

- is_downloading_one_file probability p=0.01
- number of users N=1,000,000

-- concurrent downloads: average=10,000 (sigma=~100)

vs

- is_downloading_three_files probability p=(0.01/3)
- number of users N=1,000,000

-- concurrent downloads: average=10,000 (sigma=~170)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

2012-03-27 Thread Roberto Ragusa
On 03/27/2012 05:23 AM, Gregory Maxwell wrote:
 On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy li...@colorremedies.com wrote:
 So then the question is, if urandom is what's recommended, are faster 
 substitutes just as good? If they are just as good, then why aren't they the 
 first recommendation? And if this step is superfluous, then I'd suggest 
 documentation be changed to eliminate the suggestion altogether.
 
 Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the
 key and one of the secure block modes (e.g. aes-lrw or aes-essiv).
 Then I fill the dmcrypt device with /dev/zero.  This goes fairly fast,
 filling the device with securely encrypted zeros.
 
 Then I drop the volume and set up luks normally.

Nice trick. Does this saturate the disk speed?

Last time I had to do this I compiled my own random generator,
using some code from a research article.
That was fast C code, when compiled for x86_64 with good gcc
options the speed (/dev/null) was 1.75GB/s (!!!).


-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

  1   2   >