Re: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Vitaly Zaitsev via devel wrote on Sun, Jun 09, 2024 at 09:15:56AM +0200: > On 08/06/2024 00:43, Aoife Moloney wrote: > > OpenSSL will no longer trust cryptographic signatures using SHA-1 by > > default, starting from Fedora 41. > > What about Git? AFAIK, AFAIK, Git heavily uses both SHA-1 and SHA-2 to > validate objects and commits. git does not use OpenSSL to compute the hash, so nothing should change as far as I understand this (..and from a quick look at recent release notes it'll be a while longer until we can see a transition, the support for sha256 commit ids has been implemented a while ago but "Work to support a repository that work with both SHA-1 and SHA-256 hash algorithms has stated" in git 2.45 (29 Apr 2024); right now a repo that wants to use sha256 needs to select that at git init time and pull/push won't work with something using sha1... and all forges like github refuse push if you try sha256. So some conversion path for existing repos and platforms support must come first, and there is none of that yet afaics, with work on the former that apparently just started) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
Christopher wrote on Fri, May 24, 2024 at 02:15:17AM -0400: > A flag to treat the arguments as OR like mlocate did instead of the default > to AND would be great, though I wish plocate would have more closely > mimicked mlocate's default behavior from the beginning and had a flag for > AND instead. Unfortunately, one cannot go back in time. Here's the reply from Steinar: > for OR searches, you can either use --regex, or call plocate multiple times > this is the one deliberate incompatibility between mlocate and plocate, and > it's not going to be changed :-) > both will be slow, but OR-searches are going to be slow anyway (I've added a working mail this time; will let you (Christopher) argue directly if you want to continue, I don't care enough) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
Christopher wrote on Fri, May 24, 2024 at 02:18:04AM -0400: > Are you sure you have the correct address for the plocate developer and > that it's still actively maintained? I just got an error that the > destination email address didn't exist from their mail server when I > replied just now. Yeah, I reached out over irc after sending that mail but not answer yet -- the repo is still active (there was a new release earlier this year), I just decided to drop the '+git' from the mail he uses in his commit messages and his server apparently doesn't like addresses without the + suffix, so that was probably my mistake here but it's not clear where he wants bug reports from [1], probably +web I guess... [1] https://plocate.sesse.net/ I've given him a link to this thread on IRC, so he'll hopefully reply when he checks it. -- Dominique -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
Christopher wrote on Thu, May 23, 2024 at 06:26:57PM -0400:
> One thing I've noticed is that plocate behaves differently when
> supplied with multiple arguments than mlocate. This broke some of my
> scripts.
>
> Previously, I had:
>
> locate rpm{old,new,save,orig,moved}
> # expands to locate rpmold rpmnew rpmsave rpmorig rpmmoved
>
> But now, I need to do:
>
> for x in rpm{old,new,save,orig,moved}; do locate "$x"; done
>
> The frustrating part is that it didn't even break in an obvious way.
> It just ignored all the arguments after the first one, so it was only
> searching for rpmold, and ignored all the others.
>
> In this way (and perhaps only this way?), mlocate was better. plocate
> should handle these arguments, or at least fail with a message letting
> you know that it is ignoring the rest of the arguments.
Looking at the code[1], it's supported multiple arguments since 1.0.0
(2020) so basically forever as far as fedora is concerned; but while
mlocate was looking for each argument individually (according to your
report) plocate is adding, plocate is looking for files that match all
the arguments given; so it's a pretty extreme change of behaviour...
At this point changing it will break scripts for people used to the new
plocate behaviour, so I'm not sure there's a good solution here - perhaps
a new switch that'll toggle whether we want matches for all the words
(plocate behaviour) or all matches for each words (mlocate behaviour)?
Either way, it's something to report upstream so I've added Steinar in Ccs.
[1] https://git.sesse.net/?p=plocate
--
Dominique Martinet | Asmadeus
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Scott Schmit wrote on Sun, Mar 31, 2024 at 05:02:44PM -0400: > Deleting the tests makes no sense to me either, but it seems like a > mechanism that ensures the test code can't change the build outputs (or > a mechanism to detect that it's happened and abort the build) would > allow upstream tests to be run without compromising the integrity of the > build itself. Just to be clear here that wouldn't have been enough: it's not the test step that's modifying the binaries, the actual build step is modified in the right conditions to use data that looks like it belongs to a test (I've read the actual files aren't actually used in any test and just look like test data, I didn't check, it wouldn't be hard to make a test that uses them anyway) So short of deleting all blobs e.g. all test data this wouldn't have been prevented, just not running tests isn't enough. In theory it'd be possible to build twice: - one normal build with test data, and run tests at the end - a second build without test data (and confirm we've got an identical binary, builds are reproducible right?!) But while we might be able to afford the computing cost, I'm not sure it's worth it -- this attack vector happened to use test data, but there are plenty of other ways of doing this, and even just identifying / removing test data in the first place is hard work for packagers (I guess we could try to detect binary files but there is no end to that either, and many builds would just break if we were to automatically remove tests...) (Anyway, I also think tests bring more benefits than risks in our case) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Richard W.M. Jones wrote on Sat, Mar 30, 2024 at 09:37:44AM +: > In the xz case this wouldn't have been enough, it turns out we would > also have to delete m4/build-to-host.m4, which then autoreconf > regenerates. I don't fully understand why that is. I'm not 100% sure about the theory, but it looks like `autoreconf -fi` looks at the 'serial' in the first line of the script. The one bundled in the xz sources was marked very high: # build-to-host.m4 serial 30 But the one in the system (as of f39) is only 'serial 1'. Artificially lowering the serial back to 0 in the file and running `autoreconf -fi` again properly reinstall the one from the system over it, but anything higher will keep it... So if we want to go this route, we should remove the full m4 dir, but unfortunately I've seen quite a few projects that depend on non-standard m4 scripts so we'll need to fix these as we go... (At which point I'd suggest it's probably faster to convert it all to meson or another new shiny, and saner, build system, but getting upstreams to agree will be fun) > (2) We should discourage gnulib as much as possible. > [...] > In the xz case it was a gnulib-derived script which was modified to do > the initial injection (original: > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD). (Honestly I did compare the backdoored script and the real one this morning and I would be hard pressed to say if either is backdoored just looking at either version... Admitedly it was 3AM when I looked at it, but I don't think it's just a late hour problem) > (3) We should have a "security path", like "critical path". > > sshd is linked to a lot of libraries: > > /lib64/libaudit.so.1audit-libs > /lib64/libc.so.6glibc > /lib64/libcap-ng.so.0 libcap-ng > /lib64/libcap.so.2 libcap > /lib64/libcom_err.so.2 libcom_err > /lib64/libcrypt.so.2libxcrypt > /lib64/libcrypto.so.3 openssl-libs > /lib64/libeconf.so.0libeconf > /lib64/libgcc_s.so.1libgcc > /lib64/libgssapi_krb5.so.2 krb5-libs > /lib64/libk5crypto.so.3 krb5-libs > /lib64/libkeyutils.so.1 keyutils-libs > /lib64/libkrb5.so.3 krb5-libs > /lib64/libkrb5support.so.0 krb5-libs > /lib64/liblz4.so.1 lz4-libs > /lib64/liblzma.so.5 xz-libs > /lib64/libm.so.6glibc > /lib64/libpam.so.0 pam-libs > /lib64/libpcre2-8.so.0 pcre2 > /lib64/libresolv.so.2 glibc > /lib64/libselinux.so.1 libselinux > /lib64/libsystemd.so.0 systemd-libs > /lib64/libz.so.1zlib / zlib-ng > /lib64/libzstd.so.1 zstd > > Should we have a higher level of attention to these packages? We > already have "critical path", but that's a broad category now. These > seem like they are "security path" packages, an intentionally small > subset associated with very secure services which are enabled by > default. Before making each of these safer we should make sshd not link with so many things in the first place. On oss-security, Solar Designer made a lot of good points about it (around here: https://www.openwall.com/lists/oss-security/2024/03/29/27 , but the full thread is interesting) But that's specific to sshd, and this problem could happen with any network-facing service: I guess sshd is a juciy target because it runs as root (whereas backdooring e.g. nginx would run as www user and not be as interesting), but in practice that could be bad enough. (hm, well, your point about 'enabled by default' strikes home though - we definitely could pay more attention to these first) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Donate 1 minute of your time to test upgrades from F39 to F40
Miroslav Suchý wrote on Wed, Feb 21, 2024 at 08:11:49AM +0100: > dnf --releasever=40 --setopt=module_platform_id=platform:f40 \ > --enablerepo=updates-testing \ > $(rpm -q fedora-repos-modular >/dev/null && echo > --enablerepo=updates-testing-modular) \ > --assumeno distro-sync Error: Problem 1: problem with installed package calc-libs-2.14.1.5-2.fc39.x86_64 - calc-libs-2.14.1.5-2.fc39.x86_64 from @System does not belong to a distupgrade repository - nothing provides libcustcalc.so.2.15.0.2()(64bit) needed by calc-libs-2.15.0.2-3.fc40.x86_64 from fedora Problem 2: problem with installed package calc-2.14.1.5-2.fc39.x86_64 - calc-2.14.1.5-2.fc39.x86_64 from @System does not belong to a distupgrade repository - nothing provides libcustcalc.so.2.15.0.2()(64bit) needed by calc-2.15.0.2-3.fc40.x86_64 from fedora Problem 3: package emacs-nox-1:29.2-2.fc39.x86_64 from @System requires emacs-common = 1:29.2-2.fc39, but none of the providers can be installed - emacs-common-1:29.2-2.fc39.x86_64 from @System does not belong to a distupgrade repository - problem with installed package emacs-nox-1:29.2-2.fc39.x86_64 Problem 4: package network-scripts-ppp-2.5.0-3.fc39.x86_64 from @System requires network-scripts, but none of the providers can be installed - network-scripts-10.20-1.fc39.x86_64 from @System does not belong to a distupgrade repository - problem with installed package network-scripts-ppp-2.5.0-3.fc39.x86_64 Problem 5: problem with installed package calc-stdrc-2.14.1.5-2.fc39.x86_64 - package calc-stdrc-2.15.0.2-3.fc40.x86_64 from fedora requires calc = 2.15.0.2-3.fc40, but none of the providers can be installed - calc-stdrc-2.14.1.5-2.fc39.x86_64 from @System does not belong to a distupgrade repository - nothing provides libcustcalc.so.2.15.0.2()(64bit) needed by calc-2.15.0.2-3.fc40.x86_64 from fedora Problem 6: package network-scripts-teamd-1.32-4.fc40.x86_64 from fedora requires network-scripts, but none of the providers can be installed - problem with installed package network-scripts-teamd-1.32-1.fc39.x86_64 - package network-scripts-10.20-1.fc39.x86_64 from @System requires initscripts(x86-64) = 10.20-1.fc39, but none of the providers can be installed - network-scripts-teamd-1.32-1.fc39.x86_64 from @System does not belong to a distupgrade repository - initscripts-10.20-1.fc39.x86_64 from @System does not belong to a distupgrade repository So calc, emacs-nox and network-scripts-teamd. Didn't take the time to fill any bz; I might this weekend if nobody does -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue
(Not involved in any way here so feel free to ignore most of what I'm saying) Marc Deop i Argemí wrote on Sat, Feb 03, 2024 at 03:16:47PM +0100: > - If a user decided to install the X11 package and has an issue: who do you > think they are going to reach? who is gonna get the "bad publicity" for the > issue? ( specially when we are forced to tell them we don't support X11...) I don't really understand this one -- why would they reach for the KDE SIG specifically? What does "support" even mean in this context? As a fedora user (not even using KDE), I don't care about SIGs, if I have a problem I'll just open a bz against the package that gives me trouble. Now I'm sure some tickets will be open against KDE without specifying they're using the X11 packages, but at least semi-automated bugs will have a package list so it shouldn't be _that_ much trouble to just reassign the bug to the x11 package if required (especially since x11 is no longer selected by default and requires manual intervention to use, I'd expect most users who care enough to report a bug to be aware of the difference) At this point it's no longer KDE SIG's problem -- it's whoever is maintaining the package's role to follow up on that bz. I haven't seen Kevin or anyone else say they'd just close the bugs as "not my problem" -- x11 is still supported upstream so I'd expect they'd at least forward the bug there, if they don't look into it themselves directly. Also if you're concerend about the "publicity", for users who cannot run on wayland yet for whatever reason (hardware, buggy drivers...) having the possibility to use x11 at all is still going to be much better PR than "nope sorry we don't want to spend time on X11 just suffer through the wayland bugs" which is exactly how this will sound to them (yes I can understand the reasons that were given up for this and rationalize this a bit better, but this isn't how it'll look for someone with problems) Long story short, I agree with the "if someone wants to do it let them do" stance. I can't speak about your second point (delaying upgrades), but from what I've read of this thread it doesn't seem like there'd be a huge delay if some minimal communication is in place, and the suggesstion of having a KDE X11 sig to ensure it's not just a single person also makes sense (although if it's a single package just having multiple maintainers to it sounds enough to me) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mounting USB Storage devices with "sync" option ?
Barry Scott wrote on Fri, Feb 02, 2024 at 08:07:46PM +:
> > On 2 Feb 2024, at 17:58, Florian Weimer wrote:
> > The second one is a standard SATA drive in an USB enclosure, and those
> > have write-reordering caches, as far as I understand it.
>
> We need a kernel storage expert to tell us the definitive truth on this stuff.
> I may be out of date on this stuff.
This isn't really my turf so I just "read the code" (as of 6.7), but...
> What I understand is that the drive will be told via the appropriate SCSI(?)
> command
> that it must not reorder the writes. Failure to implement that command means
> the
> drive will not have WHQL from Microsoft. Without WHQL its very hard to sell a
> drive
> in the market place.
What seems to happen is the other way around:
- the scsi layer sends a SENSE command to query what the drive supports,
but that fails ("No Caching mode page found")
- it then goes on to pick whatever default value is configured
(litteraly assuming the drive works as per the default, hence the
"Assuming drive cache: write through" message)
- In this write through mode the 'WCE' flag is set to 0, which'll in
turn configure the blk queue (linux side) to clear "QUEUE_FLAG_WC" and
"QUEUE_FLAG_HW_WC" flags
- Things are starting to get a little harder to follow from here, but it
looks like that flush ops when QUEUE_FLAG_WC isn't set will clear
REQ_PREFLUSH | REQ_FUA from the request, and if there was no data to
write straight out skip the op... (submit_bio_noacct around the "Filter
flush bio's early so that bio based drivers without flush support don't
have to worry about them." comment - I definitely could be
misunderstanding the code below)
- I also don't see anything that'd tell the disk about our assumption --
there's a "cache_type_store" function that'll expose a cache_type sysfs
knob for userspace to override, but at least kernel doesn't look like
it'll send a scsi command to set it by default.
Also, since we couldn't read the cache mode, there's no guarantee it'd
be settable in the first place.
So I think Florian is correct in that barriers won't be issued on
these disks, and if they internally have such a cache it'd probably be
unsafe...
Now does the disk itself know that it's in such an enclosure and
properly behaves as write through?
I think we'd have a lot more corruptions on our hands if it was
incorrect here, btrfs in particular is very sensitive to disks that
lie with barriers but I'm not sure how much it's used on such drivers.
I've had a quick look but didn't find any 'disk barrier sanity tool'
that'd issue a succession of write + flush ops in an order that'd be
easy to reorder (e.g. 13___2) for one to unplug the disk and then
check there was no hole after plugging it back in; if someone is aware
of one that'd be interesting to test on such an enclosed HDD.
(Of course, getting safe order back is no guarantee that the disk is
always consistent, but it's probably possible to come up with a few
patterns that often fail when manually misconfiguring a disk)
--
Dominique Martinet | Asmadeus
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
John Reiser wrote on Sun, Dec 31, 2023 at 02:52:53PM -0800: > > Additional paths will be inserted into the search path used for > > executables on systems which have a compatible CPU. > > Searching $PATH is a slow operation. It is so slow that a shell script which > typically processes many files using utilities from packages coreutils > and/or binutils often factors-out the PATH search by using > shell variables: > > CP=$(which cp) > ... > $(CP) $file.in $file.out (getting slighly off topic, sorry) That hasn't been needed for as long as I've used a compter, all^W most shells already do this for you. (It's obvious in interactive mode when you need to use hash/rehash built-ins after moving a binary that you ran once, but it's true as well when running scripts: if you e.g. strace for stat() calls a script that calls cp twice you'll see it only looks through PATH once. This is true of at least bash, zsh, dash, and even busybox ash... Interestingly fish doesn't seem to do it, I'm a bit surpised here) Anyway, I'm not arguing PATH lookups are fast -- having seen some setups with 'module's over NFS or networked file systems I know how bad that can get -- just don't undersell your shells :) -- Dominique Martinet | Asmadeus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Getting package NEVR list from core dump ?
Daniel P. Berrangé wrote on Fri, Oct 13, 2023 at 08:41:17AM +0100:
> What's the "right" way to extract the NEVR list from a standalone core
> dump ?
I'd probably not call this the "right" way, and it took me way longer
than I'd like to admit, but I found notes readelf could read in various
loadXXXa sections in dumps I looked at:
$ objdump -h dump | grep load1a
27 load1a1000 55d6d3101000 0001b000 2**12
$ dd if=dump of=dump.t bs=4k count=1 iflag=skip_bytes skip=$((0x0001b000))
status=none
$ eu-readelf --notes dump.t
[...]
Note segment of 204 bytes at offset 0x3c0:
Owner Data size Type
GNU 20 GNU_BUILD_ID
Build ID: 1113de7347150ea48ff1c5bd555cdb09a5422f62
GNU 16 GNU_ABI_TAG
OS: Linux, ABI: 3.2.0
FDO 120 FDO_PACKAGING_METADATA
Packaging Metadata:
{"type":"rpm","name":"qemu","version":"8.1.1-1.fc39","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:39"}
---
Or looping all of them:
---
$ objdump -h dump \
| sed -ne 's/.*load[0-9]*a .* \([0-9a-f]*\).*/\1/p' \
| while read offset; do
dd if=dump bs=4k iflag=skip_bytes skip=$((0x$offset)) \
count=1 of=dump.t status=none \
&& eu-readelf --notes dump.t;
done
...
Note segment of 176 bytes at offset 0x320:
Owner Data size Type
GNU 20 GNU_BUILD_ID
Build ID: 0ee9ccb38a6afaecb63d5fd382c83ad9c1dce9be
FDO 124 FDO_PACKAGING_METADATA
Packaging Metadata:
{"type":"rpm","name":"pixman","version":"0.42.2-2.fc39","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:39"}
...
---
(grmbl something about readelf and eu-readelf both being unable to read
from stdin; I guess parsing elf files isn't trivial enough on a stream)
Long story short, I think strings | grep is probably the best you're
going to get here?
I'm sure gdb/lldb or others could be made to display this, but doesn't
seem to be the case at this point (at least glancing at gdb sources);
and tools like systemd-analyze inspect-elf can get package metadata of a
binary or individual notes sections extracted from the dump but don't
seem to be able to parse the elf either...
If someone can prove me wrong here, please share!
Oh, and you can also just feed it to systemd-coredump to have it do the
work for you, then get infos out of it:
sudo /usr/lib/systemd/systemd-coredump 1234 1000 1000 11 $(date +%s) $((2**31))
test < dump
(in order: pid, uid, gid, signal (11=SEGV on x86_64), timestamp of dump,
ulimit -c but I didn't take time to figure out unlimited, hostname)
I'll let you decide if that's better...
Happy hunting,
--
Dominique Martinet | Asmadeus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Replacing DNF with DNF5: changes reverted and helping steps
Vít Ondruch wrote on Tue, Aug 15, 2023 at 12:09:34PM +0200: > > I think only the mass-prebuild maintainer can help you there. dnf5 > > cannot be set to provide dnf, because it...doesn't. > > > I know and yet again, I have not find any issues using mass-prebuild with > DNF5 and until now, it worked just fine. I probably won't ever understand > this game with names. > > But may be we are on the same boat and your "because it...doesn't." falls > into the same category 路♂️ Perhaps a 'dnf-is-dnf5' providing the dnf command as a symlink to dnf5 (taking inspiration from debian's python-is-python3) would work as a stop-gap, so people who want a system with just dnf could install that package as an alternate dnf provider ? Alternatively making dnf install as dnf4 + provide dnf as an 'alternative' config, and making dnf5 provide dnf as an alternative config with lower priority would likely also work ; but that probably requires modifying the dnf package first to avoid conflict. -- Dominique Martinet | Asmadeus ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Plans for dhclient / ISC dhcp?
Michael Cronenworth wrote on Wed, May 31, 2023 at 10:47:24AM -0500: > I'm not using NetworkManager due to an issue with IPv6 and SLAAC. Clients > under the server get an initial SLAAC IP from NetworkManager, but after the > IP expires they never get a new IP. I've asked upstream about it and didn't > get anywhere. Granted, this was 3 years ago now. Maybe things are better and > I can try NetworkManager again... or systemd-networkd. Could that be the ipv6 "privacy" features? There are two settings I'm aware of: * ipv6.ip6-privacy ; that generates a random address regularly which will be used for outgoing connections by default (2); it can be changed to generate it or not use by default or not generate it at all * ipv6.addr-gen-mode ; that sets the "main" stable address and should default to stable-privacy, which ought to be stable but you can set it to eui64 to generate from mac if it doesn't work. In particular I think stable-privacy uses the connection's uuid, which is random if you leave it all up to defaults for ethernet (defaults to generating an in-memry config with dhcp at every boot afaiu); that shouldn't change on renew but perhaps there's been some other similar fuzziness to it. This probably has already been explained when you brought up the issue so I'm going to assume there was another problem, but in case it helps feel free to give it a try. (Not that I have anything against systemd-networkd, I use both depending on the need for dynamic settings (e.g. laptop with wireless moving around) or not) -- Dominique Martinet | Asmadeus ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora libbpf upgrade to 1.0
(hmm, never seemed to get the first mail...) Just recaping infos I got/researched for nixos. Fabio Valentini wrote on Fri, Nov 04, 2022 at 04:32:35PM +0100: >> I was NOT able to build following packages with libbpf 1.0: >> >>- bcc (needs 0.25 update first) note bcc upgrade in turns breaks gobpf, which indirectly breaks stuff like oci-seccomp-bpf-hook. gobpf got updated in https://github.com/iovisor/gobpf/pull/311 (unreleased, but we don't package it directly so we probably don't care) oci-seccomp-bpf-hook got updated with it in v1.2.8 so that will need an update. Didn't check if there are other reverse dependencies on gobpf in fedora. This one is backwards compatible, so the hook can be updated first with no side effect. >>- bpftrace (needs bcc update first) (update with bcc 0.25 works, so just needs updating together with bcc. Conversely older bpftrace does not work with bcc 0.25 iirc so it's not just one after the other, but both together...) >>- knot knot got fixed in 3.2.1 and also "just" needs to be updated. https://gitlab.nic.cz/knot/knot-dns/-/tags/v3.2.1 >>- suricata suricata got fixed in https://github.com/OISF/suricata/pull/7884 included in 7.0.0-beta1 last week, so will probably need to wait for an actual release... >>- below >>- rust-libbpf-cargo >>- openvswitch (didn't see/check these for nixos) -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
Daan De Meyer via devel wrote on Tue, Nov 01, 2022 at 11:26:13AM -: > I've added a new section to the proposal with the benchmark results of > some benchmarks we performed against a Fedora 37 system built with > frame pointers and a regular Fedora 37 system. The impact on most > benchmarks seems limited aside from the CPython benchmark suite > (pyperformance). See the proposal itself for the detail. For others who rotate their mailbox out regularly and no longer have the start of this thread, here's a link to the change: https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer and quoting the relevant section summary: * Compiling the kernel with GCC is 2.4% slower with frame pointers * Running Blender to render a frame is 2% slower on our specific testcase * openssl/botan/zstd do not seem to be affected significantly when built with frame pointers * The impact on CPython benchmarks can be anywhere from 1-10% depending on the specific benchmark * Redis benchmarks do not seem to be significantly impacted when built with frame pointers with details in https://github.com/DaanDeMeyer/fpbench -- Dominique Martinet | Asmadeus ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: No response on BCC releated bugs
+Jiri in To Dave Stux wrote on Wed, Oct 26, 2022 at 09:39:23PM -: > I have opened bugs relating to bcc, and I see no reply on them. > Currently, at least in my testing, the state of ,pst pf the bcc dependent > tools in F35 is broken. > Examples: > https://bugzilla.redhat.com/show_bug.cgi?id=2127642 > https://bugzilla.redhat.com/show_bug.cgi?id=2057139 bcc 0.22 is quite old and I think you have it right in this bug: just updating to a newer bcc version would likely fix all these issues. fedora 37+ have bcc 0.24 which is more reasonable and probably works, so I guess it'd just be a matter of pushing it for f35/36 as well. (note there's a bcc 0.25 that might be good for rawhide, but it breaks API on bcc_prog_load_xattr() breaking e.g. older gobpf or bpftrace, see https://github.com/iovisor/bpftrace/issues/2340 , so that one should not be backported -- but I'm not aware of any such problem for bcc 0.22 to 0.24) > I have filled non-responsive bug, but there's no reply on it too: > https://bugzilla.redhat.com/show_bug.cgi?id=2136222 > > Can anyone contact Jiri Olsa or update if he is out on vacation? > Is there an additional package maintainer? -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: With F36 systemd-nspawn test environment not usable, no login possible
Peter Boy wrote on Tue, Jul 05, 2022 at 07:19:28AM +0200: > […]# dnf --releasever=36 --best --setopt=install_weak_deps=False \ > --installroot=/var/lib/machines/testf36 install dhcp-client dnf \ > fedora-release glibc glibc-langpack-en iputils less ncurses passwd \ > systemd systemd-networkd vim-default-editor > > I can set a password using > > […]# systemd-nspawn -D /var/lib/machines/testf36 passwd > > I create a container with > > […]# systemd-nspawn -D /var/lib/machines/testf36 -b If you check the syslog of that machine (don't ask me how, I just straced agetty) you'll see it complain that there is no /bin/login: you just need to install util-linux (or possibly busybox) and you'll get a prompt, login should work as well. Maybe it used to be pulled automatically before... -- Dominique Martinet | Asmadeus ___ 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
rpm signing keys (Was: Suggestion: Use a unified kernel image by default in the future.)
Michael Catanzaro wrote on Mon, Jul 04, 2022 at 05:48:28PM -0500: > After installing or upgrading your Fedora or RHEL system, you have to accept > a "do you trust this official Fedora project key" prompt or you cannot > install packages from the official repos. So all our users have been trained > to ignore warnings about untrusted packages because it's mandatory to do so. > If few users think twice about accepting a key as long as it purports to be > from "Fedora" or "Red Hat"... well, the whole system is subverted. This > needs a rethink. The keys come from the installed key packages and have already been written to /etc when that prompts happen -- users can trust these keys because they trusted the package that wrote them in the first place. That being said, you could just as well look at it the other way and say that if something malcious can write keys there they could also accept the prompt for you so you wouldn't see it -- hence the prompt can be said to be useless one way or the other... -- Dominique Martinet | Asmadeus ___ 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: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Wed, Feb 23, 2022 at 10:44:12AM +0100: > According to ICANN [1], there were 8.3 mln IDN domains worldwide. I admit > that is more than I expected. According to verisgn [2], out of 364.6 mln > total, > i.e. around 2%. > Apparently .рф is fairly popular, with 1/5th of .ru registrations [3]. Dmitry mentionned Russia in a sibling mail, Japan also definitley has quite a few of these as well which I see often enough here, I defintely wouldn't say IDN domains are rare in such regions... > But from what I have seen, all those internationalized domains serve > as a redirect or backup to sites also available as ascii. And for command-line > tools or scripting, using those ascii versions seems quite likely… ... but I can also agree with this, I haven't seen any ostensibly used in scripts, although I don't particularly look at Japanese documentations/examples so I wouldn't say I'm sure about that. Searching github for "curl https://xn--; (xn-- is the punycode prefix) did turn out some results though in issues, e.g. acme.sh: https://github.com/acmesh-official/acme.sh/issues/3078 which does make sense, cert renewal happens with these domains usually used in web browsers, so is quite likely to contain such domains if only for testing purposes. With that in mind monitoring is also very likely, stuff like nagios plugins or prometheus web-related probes will definitely want idn support. > I certainly wouldn't want to break things for people using non-latin > scripts. So I'd definitely vote to enable libidn2 in curl-minimal, > _if_ there are people who'd actually use this for real. I'd say if desktop environments and things that might deal with such domains are updated to pull curl-full it'll probably be ok, but at this point I also think anything non-trivial in an international setup would want to pull it in so it might as well get included in curl-minimal. That being said, the point about FTP in another part of the thread is also probably correct, so curl minimal is starting not to feel that minimal... I'm not sure forking a third version of the package for default setup makes sense though. -- Dominique ___ 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: CVE-2021-4034: why is pkexec still a thing?
Demi Marie Obenour wrote on Fri, Jan 28, 2022 at 10:55:43AM -0500: > As an aside, can Linux and/or glibc please disallow passing a NULL > argv[0]? I would honestly be okay with glibc just crashing the process > during startup if argv[0] is NULL or empty. FWIW a patch has already been sent shortly after this all started: https://lore.kernel.org/lkml/20220127000724.15106-1-aria...@dereferenced.org/T/#u And it's already in the mmotm tree so just a matter of time until it reaches linux master -- Dominique ___ 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: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?
Chris Murphy wrote on Mon, Jan 24, 2022 at 02:56:09PM -0700: > Should be true, and if this nspawn container is running on the host > then they should share the same btrfs file system. And even if nspawn > is creating separate subvolumes for the mock build (?not sure if it > does) then because it's a nested subvolume, not mounted, there's no > mount point boundary to cross so you *do* get reflink copies between > subvolumes. For what it's worth the example given does renames in the same directory (since that's what rpm does when installing things anyway), so there is no reflink involved, just a plain rename call I got curious so I tried reproducing but unfortunately I get similar times whether it's in mock or native, but it varies from a run to another. Running with perf record -g, I get the following hog: - 95.11% 0.01% mv [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe 95.10% entry_SYSCALL_64_after_hwframe - do_syscall_64 - 92.40% __x64_sys_renameat2 - 92.40% do_renameat2 - 92.36% vfs_rename - 92.34% btrfs_rename2 - 92.09% btrfs_log_new_name - btrfs_log_inode_parent - 53.42% log_new_dir_dentries - 47.27% btrfs_log_inode + 13.78% btrfs_log_all_xattrs + 11.60% copy_items.isra.0 + 11.58% drop_objectid_items + 4.31% btrfs_search_forward + 2.39% btrfs_search_slot 1.21% btrfs_release_path + 1.00% btrfs_commit_inode_delayed_inode + 2.26% btrfs_search_forward + 1.04% btrfs_iget 0.89% read_extent_buffer - 38.65% btrfs_log_inode - 38.41% log_directory_changes - log_dir_items - 35.01% overwrite_item + 19.04% btrfs_search_slot + 3.59% btrfs_release_path + 3.32% kfree 3.07% __kmalloc 2.84% read_extent_buffer 1.40% btrfs_get_32 0.63% memcmp 1.67% read_extent_buffer So basically the directory modification is costly for each rename and it doesn't seem to get batched, maybe that would give a hint as to somewhere that could be improved. (I wasn't able to reliably produce the slightly shorter times I got to check with perf record, but I did get one run with ~20s when it's usually much longer so there's probably something... Never went as far down as sub-10s though) -- Dominique ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Thu, Dec 30, 2021 at 08:29:54AM +: > $ sudo strace -efile dnf list > ... > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal", > O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4 > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm", > O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5 > ... > > What happens if /var/lib is read-only? Changing (fixing?) this would > be a pre-requisite to this proposal, we don't want 'dnf list' to break. That's easy enough to test. Apparently, of the files already exist the open calls work without problem. If the files don't (e.g. cleared by running 'sqlite3 rpmdb.sqlite vacuum'), then sqlite apparently tries to create them and fails horribly -- but so does rpm -qa: # rpm -qa error: sqlite failure: CREATE TABLE IF NOT EXISTS 'Packages' (hnum INTEGER PRIMARY KEY AUTOINCREMENT,blob BLOB NOT NULL): unable to open database file error: cannot open Packages index using sqlite - No such file or directory (2) error: cannot open Packages database in /var/lib/rpm or for that matter plain sqlite3: # sqlite3 rpmdb.sqlite 'select * from Packages;' Error: unable to open database file So for a read-only filesystem, if the db has wal enabled, the files have to exist. (it's possible to disable WAL mode by running the sqlite 'PRAGMA journal_mode=DELETE;' command when the partition is writable beforehand, but I didn't see how to alter the mode while it is readonly) Anyway, I don't think vacuum ever runs automatically so the files should always be present and it probably should just work™. FWIW I've been running with my rpmdb in /usr (through a bind mount) for a few years precisely to keep the rpmdb in sync with the rest of /usr for snapshots -- it's pretty much necessary to run rpm -q on old snapshots and figure which version of what was where easily. Unless btrfs somehow becomes able to tie multiple subvolume snapshots together I think it's a good change. -- Dominique ___ 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: pipewire memory usage
Carlos O'Donell wrote on Tue, Dec 14, 2021 at 11:07:42AM -0500:
> > So I guess we're just chasing after artifacts from the allocator, and
> > it'll be hard to tell which it is when I happen to see pipewire-pulse
> > with high memory later on...
>
> It can be difficult to tell the difference between:
> (a) allocator caching
> (b) application usage
>
> To help with we developed some additional tracing utilities:
> https://pagure.io/glibc-malloc-trace-utils
Thanks for the pointer, I knew something would be able to do this but I
didn't remember what allowed this.
I don't see this in any package, maybe it'd be interesting to ship these
for easy use?
(yes, it's not difficult to git clone and configure/make locally, but
I'll forget about it again whereas a package might be easier to
remember)
For now, I can confirm that all memory is indeed freed in a timely
manner as far as pipewire-pulse knows.
> > From what I can see the big allocations are (didn't look at lifetime of each
> > alloc):
> > - load_spa_handle for audioconvert/libspa-audioconvert allocs 3.7MB
> > - pw_proxy_new allocates 590k
> > - reply_create_playback_stream allocates 4MB
> > - spa_buffer_alloc_array allocates 1MB from negotiate_buffers
> > - spa_buffer_alloc_array allocates 256K x2 + 128K
> >from negotiate_link_buffers
>
> On a 64-bit system the maximum dynamic allocation size is 32MiB.
>
> As you call malloc with ever larger values the dynamic scaling will scale up
> to
> at most 32MiB (half of a 64MiB heap). So it is possible that all of these
> allocations
> are placed on the mmap/sbrk'd heaps and stay there for future usage until
> freed back.
Yes, that's my guess as well - as they're all different sizes the cache
can blow up.
> Could you try running with this env var:
>
> GLIBC_TUNABLES=glibc.malloc.mmap_threshold=131072
>
> Note: See `info libc tunables`.
with this the max moved down from ~300-600MB to 80-150MB, and it comes
back down to 80-120MB instead of ~300MB.
> > maybe some of these buffers sticking around for the duration of the
> > connection could be pooled and shared?
>
> They are pooled and shared if they are cached by the system memory allocator.
>
> All of tcmalloc, jemalloc, and glibc malloc attempt to cache the userspace
> requests
> with different algorithms that match given workloads.
Yes, I didn't mean pooling as pooling allocator, but I meant live
pooling usage e.g. every objects could use the same objects when they
need to.
I can understand buffers being made per-client so an overhead of 1-2MB
per client is acceptable, but the bulk of the spa handle seem to be
storing many big ports?
$ pahole -y impl spa/plugins/audioconvert/libspa-audioconvert.so.p/merger.c.o
struct impl {
...
struct portin_ports[64]; /* 256 1153024 */
/* --- cacheline 18020 boundary (1153280 bytes) --- */
struct portout_ports[65];/* 1153280 1171040 */
/* --- cacheline 36317 boundary (2324288 bytes) was 32 bytes ago --- */
struct spa_audio_info format; /* 2324320 284 */
...
$ pahole -y impl spa/plugins/audioconvert/libspa-audioconvert.so.p/splitter.c.o
struct impl {
...
struct portin_ports[1]; /* 184 18056 */
/* --- cacheline 285 boundary (18240 bytes) --- */
struct portout_ports[64];/* 18240 1155584 */
/* --- cacheline 18341 boundary (1173824 bytes) --- */
...
Which themselves have a bunch of buffers:
struct port {
...
struct buffer buffers[32]; /* 576 17408 */
(pahole also prints useful hints that the structures have quite a bit of
padding, so some optimization there could save some scraps, but I think
it's more fundamental than this)
I understand that allocating once in bulk is ideal for latency so I have
no problem with overallocating a bit, but I'm not sure if we need so
many buffers laying around when clients are mute and probably not using
most of these :)
(I also understand that this isn't an easy change I'm asking about, it
doesn't have to be immediate)
BTW I think we're getting a bit gritty, which might be fine for the list
but probably leave some pipewire devs out. Perhaps it's time to move to
a new pipewire issue?
--
Dominique
___
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: pipewire memory usage
Wim Taymans wrote on Tue, Dec 14, 2021 at 09:09:30AM +0100: > I can get it as high as that too but then it stays there and doesn't really > grow anymore so it does not seem like > it's leaking. Maybe it's the way things are done, there is a lot of ldopen > and memfd/mmap. Right, I've had a look with massif and it looks like the memory is reused properly -- when the next batch of clients come in all previously used memory is freed and promptly reallocated for the new clients. The problem seems to be more that there is no sign of memory being released even after some time, I've left pipewire-pulse run for a while and it stays at 300ishMB of RSS all this time. Connecting a single new client at this point does increase memory (+8-9MB) so it doesn't look like it's reusing the old memory, but looking at massif the numbers all fell down close to 0 so everything -is- freed successfully... And it's a bit weird. FWIW, here's some massif output file if you're curious. I ran 100 clients, 100 clients, 1 client for a while, then 100 clients again: https://gaia.codewreck.org/local/massif.out.pipewire I've double-checked with traces in load_spa_handle/unref_handle and it is all free()d as soon as the client disconnects, so there's no reason the memory would still be used... And I think we're just looking at some malloc optimisation not releasing the memory. To confirm, I've tried starting pipewire-pulse with jemalloc loaded, LD_PRELOAD=/usr/lib64/libjemalloc.so , and interestingly after the 100 clients exit the memory stays at ~3-400MB but as soon as single new client connects it jumps back down to 20MB, so that seems to confirm it. (with tcmalloc it stays all the way up at 700+MB...) So I guess we're just chasing after artifacts from the allocator, and it'll be hard to tell which it is when I happen to see pipewire-pulse with high memory later on... That all being said, I agree with Zbigniew that the allocated amount per client looks big. From what I can see the big allocations are (didn't look at lifetime of each alloc): - load_spa_handle for audioconvert/libspa-audioconvert allocs 3.7MB - pw_proxy_new allocates 590k - reply_create_playback_stream allocates 4MB - spa_buffer_alloc_array allocates 1MB from negotiate_buffers - spa_buffer_alloc_array allocates 256K x2 + 128K from negotiate_link_buffers maybe some of these buffers sticking around for the duration of the connection could be pooled and shared? -- Dominique ___ 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: pipewire memory usage
Wim Taymans wrote on Mon, Dec 13, 2021 at 09:22:42AM +0100: > There was a leak in 0.3.40 that could explain this, see > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1840 > > Upcoming 0.3.41 will have this fixed. At least I can't reproduce this > anymore with the test you posted below. Thanks for testing! I've also taken the time of rebuilding pipewire from source (current master, just on top of 0.3.41) but unfortunately it doesn't look like it solves the issue here, so it must be something specific in my environment. fresh start: myuser 335184 1.0 0.0 56384 11596 ?Shttps://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: pipewire memory usage
Fabio Valentini wrote on Sun, Dec 12, 2021 at 12:25:11PM +0100: > > on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR, > > but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR. > > 56M is okeyish, but 347M seems a lot. I think firefox is going > > through pipewire-pulse, so that interface might be getting more use > > than native pipewire. But what are the expected values for this? > > That certainly seems high to me. On my system I see values like > - pipewire: resident memory ~18M, shared memory ~8M > - pipewire-pulse: redident memory ~19M, shared memory ~6M > even while playing audio from firefox, for example. > > Where did you get those RSS values? > I checked in gnome-system-monitor and with ps -aux, and both reported > the same values for resident memory (RSS). To add another datapoint I also have always seen pretty high RSS usage from pipewire-pulse: $ ps aux|grep pipewire myuser 14645 0.5 0.4 198772 79100 ?Ssl Dec07 38:08 /usr/bin/pipewire myuser 14646 0.6 3.4 713516 555756 ? SLsl Dec07 45:29 /usr/bin/pipewire-pulse myuser 14652 0.0 0.0 38112 12228 ?Sl Dec07 0:04 /usr/bin/pipewire-media-session (so 555MB RSS) I've also noticed that the background cpu% usage seems to increase, so I'd say the memory is still reachable somewhere and there must be some list getting big and skimmed through from time to time; restarting the pipewire processes when I start seeing them climb too high in htop makes them behave again... ... Okay, so there's an obvious leak when pulse clients connect and leave on pipewire-0.3.40-1.fc34.x86_64, about 3MB per client (!). I've just pkill pipewire to restart it: asmadeus 293661 0.5 0.0 31612 7276 ?Shttps://gaia.codewreck.org/local/tmp/pw-dump But it should be easy to reproduce, I don't think I have anything too specific sound-wise here... Happy to open an issue upstream if there isn't one yet, I haven't had a look. Trying to reproduce on master would likely be first. Please let me know if you take over or I'll look into it further over the next few days... -- Dominique Martinet | Asmadeus ___ 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: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Wed, Nov 24, 2021 at 09:23:37AM +: > > The consequence of that is it takes much longer to complete because the > > clock is down: what previously normally took ~55s real for ~27s of CPU > > time now takes 7m10 for 85s of CPU time -- but honestly I don't care how > > long this takes if it's not noticeable, this is perfect. Thanks again! > > That's a really long time… 55/27 s seems fairly standard, e.g. I get 43/22 s > with a 256 GB SATA disk. But 440/85 s is quite a bit worse. I really don't think it matters: this is a background job. If I want to refresh the locate database for a one-time thing, e.g. because I just updated a lot of files and look for something new, I'd run `sudo updatedb` not `sudo systemctl start plocate-updatedb`... > > Steinar would you consider adding this to the upstream service file? > > I don't think this qualifies as a good default. I would consider it a > hack to fix a local hardware problem. Fans in a laptop simply must not > be loud enough to be annoying. Well, there's annoying and annoying - I'm sure it could be better but I can accept hearing laptop fans if it means I can build a kernel slightly faster (because getting more heat out means thermal throttle doesn't need to hold back as much); but I don't want to hear the fan at random times when I'm not doing anything, even if it's not a horrible sound. Even for a fanless system, the fan itself won't be annoying, but say you want to compile something just as plocate has heated up the CPU and you'll get much lower performance for what you actually wanted to do at this time -- so it makes sense for real background stuff to stay close to idle. (I'm not sure how stuff like intel/amd's "turbo" mode works, but I believe it won't work if your cpu is hot, and I'd take this even for my servers or other non-noisy systems) > > (Zbigniew, does systemd just ignore the setting on systems where cpu > > accounting has not been enabled? iirc some distros still have it off and > > upstream might want to provide defaults that work everywhere) > > > > I would have suggested also adding Nice=5 or something but I don't think > > it's required with this. > > I think that with IOSchedulingClass=idle, niceness doesn't matter anymore. Hmm, I'm not sure what makes you think that. From what I can tell, if nice has been set, the ioprio will derive a value from it automatically (ionice = (nice + 20) / 5 for best effort, and also ioprio set to idle if set to SCHED_IDLE -- see include/linux/ioprio.h in the kernel) I however don't see anything that would hint that the other way around is true, it really seems to be specific to the IO scheduler to me. I don't see anything in block/ioprio.c that would also affect task scheduling. I'll grant you that if no IO can be done, the process will be stuck waiting for IO and not consume a lot of CPU, but that's not really the same as being niced. -- Dominique ___ 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: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Wed, Nov 24, 2021 at 07:58:47AM +: > My understanding is that in order to minimize the overall energy consumption, > the scheduler will try to maximize the cpu frequency and minimize the total > time of computation… So a cpu scheduler will not help much here, as they > will all schedule 100% of the cpu. AFAIK, there is no scheduler that > allows saying "schedule this so that so that the fans don't go on". > From the amount of complaints about loud fans, I think it would be a > popular feature. (There is something similar with "lap protection", where > heating is avoided if the laptop is detected as not-on-a-surface). Right, from a total power consumption point of view this probably makes sense, but it's not necessarily what people are after. > Please try with the following file: > > # /etc/systemd/system/plocate-updatedb.service.d/limits.conf > [Service] > CPUAccounting=yes > CPUQuota=20% > > (then 'sudo systemctl daemon-reload && sudo systemctl restart > plocate-updatedb'). > I think this could work. That's a nice one. For my particular laptop, with governor=performance I'm cutting it too close to fan being audible (and firefox etc also regularily kicks it in), so I'm not surprised even with CPUQuota=20% it's enough to be audible, albeit at a lower level than full throttle (something like +5° instead of +10-15 from where core temp usually stands, that makes a difference to fan RPM) With governor=powersave though it's really worlds appart, no CPUQuota immediately scales up to close to the max and heats just like performance would but with this I barely see any difference from not doing anything, cpufreq stays < 1GHz and heat stays way down. The consequence of that is it takes much longer to complete because the clock is down: what previously normally took ~55s real for ~27s of CPU time now takes 7m10 for 85s of CPU time -- but honestly I don't care how long this takes if it's not noticeable, this is perfect. Thanks again! Steinar would you consider adding this to the upstream service file? (Zbigniew, does systemd just ignore the setting on systems where cpu accounting has not been enabled? iirc some distros still have it off and upstream might want to provide defaults that work everywhere) I would have suggested also adding Nice=5 or something but I don't think it's required with this. Cheers, -- Dominique ___ 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: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
(replying to myself as I got a message on irc from the author) Dominique Martinet wrote on Wed, Nov 24, 2021 at 07:28:25AM +0900: > I see now that it has IOSchedulingClass=IDLE but nothing equivalent > about CPU, but I don't think that'll help: if the computer is mostly > idle it'll still use all the cores (and increase cpufreq automatically) > for long enough to heat up and make the fans kick in. I seem to have misremembered this part: it is single core. (doesn't change much as far as cpufreq/heat is concerned though) Also, it had been a while but it has actually gotten much better after I added /.snapshots and similar paths to PRUNEPATHS, so this isn't as much of a problem as I remembered, but could still be a problem for large filesystems > I don't think there is a laptop friendly scheduler that says if this > task is niced then keep the cpufreq at its minimum, is there? > I've been manually fiddling with my cpufreqs' scaling_max_freq just low > enough to not trigger the fans but it sounds like overengineering to > me... Still interested if anyone knows how to do this! -- Dominique ___ 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: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Ben Cotton wrote on Tue, Nov 23, 2021 at 12:18:56PM -0500: > == Summary == > The venerable `mlocate` program is replaced by `plocate` — a > compatible reimplementation that is faster and uses less disk space. Thanks for doing this! For what it's worth, I've been running plocate locally since it was brought up to the list earlier this year(?), and while it's much faster I have one small complain: the indexing phase is way too power-hungry. This is not actually a complain about power draw (there's the onACpower conditional as rightfully pointed out), but about kicking in the fans a few times a week (because of the randomized delay, it happens when I'm at desk regularily) when I'm at desk. I see now that it has IOSchedulingClass=IDLE but nothing equivalent about CPU, but I don't think that'll help: if the computer is mostly idle it'll still use all the cores (and increase cpufreq automatically) for long enough to heat up and make the fans kick in. I don't think there is a laptop friendly scheduler that says if this task is niced then keep the cpufreq at its minimum, is there? I've been manually fiddling with my cpufreqs' scaling_max_freq just low enough to not trigger the fans but it sounds like overengineering to me... (feel free to ignore me, I'm overall very happy about this change) -- Dominique ___ 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: Announcing LLVM Snapshot Packages for Fedora Linux
Hi Jonathan, Jonathan Wakely wrote on Wed, Nov 03, 2021 at 01:47:22PM +: > And I'll shamelessly plug my copr with weekly GCC snapshots ;-) > https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ I cannot seem to be able to install gcc-latest, do you know what provides libasan/libtsan in the versions it expects? Problem: cannot install the best candidate for the job - nothing provides libasan.so.8()(64bit) needed by gcc-latest-12.0.0-1.2024git3057f1ab7375.fc34.x86_64 - nothing provides libtsan.so.2()(64bit) needed by gcc-latest-12.0.0-1.2024git3057f1ab7375.fc34.x86_64 Respective versions on the fedora 34 package are libasan.so.6 and libtsan.so.0 (I'll probably upgrade to fedora 35 over the next few weeks, but fedora35 rpms for the two seem to provide the same versions so I'm probably missing something) Hi Konrad, Konrad Kleine wrote on Fri, Oct 08, 2021 at 12:13:35PM +0200: > You can grab them here: > > https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/ Thanks! I was able to install these. I see the system's llvm (12) got installed as the copr's llvm12 instead, and llvm became the snapshot -- would it make sense to keep llvm as the system's llvm (12), and install the lvm snapshot as llvm14 instead? That would let people keep using the system's trusted llvm by default, and only use the snapshot when they explicitely require it. Cheers, -- Dominique Martinet ___ 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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
Frank Ch. Eigler wrote on Tue, May 25, 2021 at 02:57:54PM -0400: > > [...] Most of these libraries are nothing I care about. [...] but > > could it be possible to not download anything at this point and only > > download debuginfos when they are really used [...] > > This sounds like a worthwhile suggestion for upstream gdb. We will > follow up with them. Thanks! > > [...] - None of ^C, ^\, ^Z work, when I grew tired of waiting I had > > to switch to another terminal and kill the gdb process. [...] > > OK, in my experiments, ^C did work, so something must have broken here. > We will follow up with gdb folks. I just tried on fedora34, this works here so that must be related to the version used on debian, thanks for pointing out it works. (For others: ^c cancels the download of a single object file, so might need quite a few of these to eventually get to a gdb prompt if there are many objects to download, but it works) > By the way, consider operating your own debuginfod (rawhide or 0.185) > server, federating to upstream. The gdb-gui-download-series process you > experienced could be maybe twice as fast, due to http connection > keepalive improvements. Maybe even faster, once gdb itself takes direct > advantage (patches there are pending). Plus you get a shared cache for > your network. Interesting, I wasn'te aware of such a debuginfod proxifying mode. Are there noticeable advantages over a simple caching http proxy (e.g. squid) besides serving off in-house binaries debuginfo along the way? In my usecase this was a one-off thing for now, but I can see the point if using it a lot. > > [... re. security ...] (distributing just checksums of all debug files > > in the main package, so when debuginfod downloads something it can > > compare with the checksum that was installed and verified locally by > > signed rpm? > > That sounds like something that could fall out from this effort [1], when/if > comes to fruition. We in debuginfod land could naturally follow up with > interfacing & checking glue code. > > [1] https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents Hm, I guess debuginfod could distribute the signature files together with the dwarf files straight from the rpm, but I'm a bit pessimistic whether everyone will have IMA enabled even at relatively long term. The change proposal does state that they won't actually enforce anything: > Note explicitly that we do not intend to install a default policy as > part of this change, and users will need to deploy their own policy > before anything is measured or appraised. This means that after this is > done, users will have the option to enable a policy and have that be > enforced, but there will be nothing automatic. We will, however, > document various example policies people can adapt to their needs. Even when it does become standard many machines with developers will want to continue letting users compile their own code, and these are users likely to rely on debuggers/debuginfod to debug what they just wrote, so would they be protected? (I'm not familiar with how that works, now I'm reading up it looks possible to integrate with selinux to require appraisal by context, but there are still many many machines without selinux or equivalent in enforcing mode nowadays) I guess I'd be fine with that if the debuginfod client implements the signature verification in userspace regardless of the policy if configured for it (I almost wrote if the server sends it, but that'd let malicious server just pretend there is no signature available... heh), other distros will probably take a bit more time to deploy but I guess it will come together eventually. Anyway, thanks a bunch for following up, it's appreciated. -- Dominique ___ 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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)
Björn Persson wrote on Thu, Apr 22, 2021 at 04:26:22PM +0200: > It is however a good illustration of how a network problem can destroy > the user experience. Five minutes is a long wait. I'm glad that we now > have this information. This is an old post but I just used debuginfod for the first time (on debian actually (debuginfod 0.183-1, gdb 10.1-1.7) in case things have changed - forgive me and please correct me if anything I've said is significantly better on current version on rawhide), so figured I'd share... - My usecase admitedly wasn't a very nice one (graphical application, info dll says I have 265 linked libraries...), but it felt very slow. Looking at iftop the server was reliably sending me things at 1mbps which isn't great but with the amount of data involved being slow can't be helped, I guess. What makes it really bad is that such applications link extra libraries at runtime, so when I thought it was finally done and it got into the breakpoints I had set, continuing a bit just ran into another wall of downloads, but this also isn't debuginfod's wrongdoings. Most of these libraries are nothing I care about. I understand gdb tries to find debug infos for libraries it encounters when these are loaded into the program's address space, but could it be possible to not download anything at this point and only download debuginfos when they are really used (the first time an address in such libraries appear in a backtrace to get line number / local variables / etc) ? I realize this isn't obvious, but it'd make my usage much more appreciable -- downloading 4 or maybe 5 libraries for the area I'm debugging in that monster instead of the full 265 of them. - None of ^C, ^\, ^Z work, when I grew tired of waiting I had to switch to another terminal and kill the gdb process. It'd be great if e.g. ^C could skip the current download (or future downloads too?) and continue debugging, or enter the (gdb) prompt like it normally does -- iirc it went into that prompt after the download? or batch of downloads I'm not sure, I just remember it took too long. - unsetting DEBUGINFOD_URLS completely disables the debuginfod client, it would have been nice to use the data available in the client cache anyway. Ultimately I set it to localhost so debuginfod would give up immediately on new requests but still use previously downloaded data. Perhaps there could be an "offline mode" of sorts? I also agree with the security concerns given, debuginfos are usually seen as trusted data and I wouldn't be surprised new bugs get found in their parsing which could compromise developers since the server can send whatever it wants to send. I'm not going to be very helpful on that respect though as I don't have any bright idea (distributing just checksums of all debug files in the main package, so when debuginfod downloads something it can compare with the checksum that was installed and verified locally by signed rpm? Didn't reread the whole thread but I think something similar was suggested), but that topic didn't get much discussion and it sounds important to me. All in all I think it's a very valuable tool, but it would be really great if we could minimize the amount of data actually downloaded, and establish some chain of trust. Thanks, -- Dominique ___ 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: plocate?
(added mlocate maintainer msekleta in Ccs; hopefully that's a still valid address) Zbigniew Jędrzejewski-Szmek wrote on Sat, Feb 20, 2021 at 02:06:00PM +: > Debian is apparently switching to plocate as the the default > locate/mlocate provider [0], a bit faster and more disk-efficient. > Would it make sense to do the same in Fedora? > > I prepared a package [1, 2]. The code seems nice and clean enough. > I'd be happy to take it through review, but I'm not particular keen > on long-term maintenance… Having just tried I think it'd make sense, the difference is striking. Small db update is a bit slower but that's a background activity, and search really feels instant (tens of ms) compared to a handful of seconds. I think that'll require a bit more work though, and we can start by just having the package available it doesn't have to be the default right away (I remembered that there was a discussion but not where it had ended, so was surprised to find no package in main repos!) In particular I think we'll need to first rework mlocate to use alternatives for locate/updatedb, so plocate can use the same names while keeping both packages parallely installable. I guess it'd also be fine if the packages would just plain Conflict and overwrite each other but it's important the commands stay the same (In that case we can probably also get away by not including plocate-build in the package, the command converts mlocate db to plocate format and is probably not going to see any use) (I'm willing to help with the one-time transition to alternatives if that's the way forward, or the initial package integration, but I don't think it'd be reasonable to take plocate myself given my free time lately... Anyway, let's discuss where we want to go first) -- Dominique ___ 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: Can the BTRFS transparent compression mess with RPM's free space checks?
Lyes Saadi wrote on Mon, Apr 19, 2021 at 10:56:51PM +0100:
> It's a bit late to ask this question, but it emerged when I noticed that
> after upgrading my PC to Silverblue 34 and after compressing manually my
> files, and doing some snapshots, rpm-ostree began complaining about the
> absence of free space... While compsize reported that I used only 84G(o/io?)
> of my 249Go filesystem... I then realized that because of the compression
> and the snapshots, ostree thought that my disk was full. The same problem
> happened with gnome-disk. I reported both issues[1][2].
Err, no.
btrfs has been reporting proper things in statfs that programs can rely
on, compsize is only there for you if you're curious and for debugging.
In this case your filesystem is really almost full (around 8GB free
according to your output)
That was a problem very early on and basically everyone complained df
being unuseable would break too many programs.
You probably compressed your / but have snapshots laying around that
still take up space and weren't considered in your compsize command?
If you don't trust df (statfs), you have two btrfs commands to look at
for more details; here's what it gives on my system:
# btrfs fi df /
Data, single: total=278.36GiB, used=274.63GiB
System, DUP: total=32.00MiB, used=48.00KiB
Metadata, DUP: total=9.29GiB, used=6.88GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
# btrfs fi usage /
Overall:
Device size: 330.00GiB
Device allocated:297.00GiB
Device unallocated: 33.00GiB
Device missing: 0.00B
Used:288.39GiB
Free (estimated): 36.73GiB (min: 20.23GiB)
Free (statfs, df):36.73GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:278.36GiB, Used:274.63GiB (98.66%)
/dev/mapper/slash 278.36GiB
Metadata,DUP: Size:9.29GiB, Used:6.88GiB (74.09%)
/dev/mapper/slash 18.57GiB
System,DUP: Size:32.00MiB, Used:48.00KiB (0.15%)
/dev/mapper/slash 64.00MiB
Unallocated:
/dev/mapper/slash 33.00GiB
And for comparison:
# df -h /
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/slash 330G 289G 37G 89% /
In all cases, the Used column actually corresponds to compressed size --
real blocks on disk and not uncompressed data size.
I have way too many subvolumes but here's an output that lists more than
289G "used"; I'm lazy so without snapshots:
# compsize -x / /home /var /var/lib/machines/ /nix
Processed 2722869 files, 1820146 regular extents (2063805 refs), 1625123 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 76% 232G 302G 317G
none 100% 196G 196G 194G
zstd33% 34G 104G 122G
prealloc 100% 1.0G 1.0G 553M
Hm, not very convincing, adding a few (there's more, I guess adding all
of them should bring the Disk Usage column up to 289G but this just
takes too long for this mail -- the "proper" way to track snapshot usage
would be quota but I don't have these enabled here):
# compsize -x / /home /var /var/lib/machines/ /nix /.snapshots/{19,20}*/snapshot
Processed 10803451 files, 2110568 regular extents (7656942 refs), 5960388
inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 75% 249G 331G 732G
none 100% 206G 206G 281G
zstd33% 41G 123G 451G
prealloc 100% 1.0G 1.0G 551M
I would suggest finding what subvolumes you may have (btrfs subvolume
list /) and cleanup old ones, I'm not sure what is used by default
nowadays (snapper?) there might be higher level commands
They might not be visible from your mountpoint if your setup mounts a
subvolume by default, in which case you can mount your btrfs volume
somewhere else with -o subvol=/ for example to show everything and play
with compsize if you want.
--
Dominique
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Wed, Mar 03, 2021 at 08:25:30AM +: > On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote: > > Understand, starting to work on delivering autoconf-2.69 compat package. > > Have to investigate if it would be possible to install autoconf-2.69 and > > autoconf-2.71 next to each other on the system. Will keep you updated. > > Actually, it might not be necessary to have them parallel-installable. > If that is easy, then that's a nice property to have. But just being > able to install one or the other in mock is enough. For what it's worth debian has compat packages so it doesn't look too bad: configure --normal-flags --program-suffix=2.69 make pkgdatadir=/usr/share/autoconf2.69 mv /usr/share/autoconf /usr/share/autoconf2.69 (at install time) seems to be most of it (that said I do agree it's not worth spending hours on it) -- Dominique ___ 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: Don't update to the latest f33!
Michael Catanzaro wrote on Mon, Feb 15, 2021 at 08:46:57PM -0600: > We removed the fallbacks due to complaints from users who didn't want DNS > ever going to Cloudflare or Google. So the lack of fallback is expected and > should not be reported as a bug. setting DNS= (or DNS="") explicitely should not fallback, I agree with that. There are people who want no DNS whatsoever and that should be configurable. But if extract_first_word() returned a non-empty string and manager_add_dns_server_by_string fails (for all iterations of the loop), it should definitely kick some fallback in -- the user obviously wanted *something*, it just doesn't work. > I think we have larger issues with DNS server assignment on cloud servers, > which I've reported as https://pagure.io/fedora-server/issue/10. But I also > notice Steve's case is different, since he really does have some static DNS > configuration, just using commas where spaces are required. So seems like a > misconfiguration by the cloud provider? Not sure where the configuration snippet with comma comes from but yes ultimately it's "just" a configuration error. Nevertheless, a config that somehow worked until a recent update through fallback, I don't think we want more unhappy users :) -- Dominique ___ 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: Don't update to the latest f33!
Steve Dickson wrote on Mon, Feb 15, 2021 at 09:04:52PM -0500: > > I think if no IP was successfully parsed the fallback ought to kick in, > > so it's a systemd-resolved bug -- do you want to report this upstream or > > shall I now I've had a look? > > Fedora bz or an upstream bz? If is the latter where do I report it? We have systemd devs in fedora so I think either would work out. upstream is on github: https://github.com/systemd/systemd/issues -- Dominique ___ 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: Don't update to the latest f33!
Hi Steve,
Steve Dickson wrote on Mon, Feb 15, 2021 at 08:40:17PM -0500:
> When I have DNS=67.207.67.3,67.207.67.2 I get
FWIW the man page states it is a space-separated list of IPs, you might
want to try DNS="67.207.67.3 67.207.67.2"
I quickly had a look at the code and I don't think anything changed
recently with how the parsing works, but dd2e9e1d0e82 ("resolve: ignore
invalid service template name") (18 Nov 2020) changed the error bubbling
up (it's now ignored when it was an error), so the fallback no longer
kicks in for you.
I think if no IP was successfully parsed the fallback ought to kick in,
so it's a systemd-resolved bug -- do you want to report this upstream or
shall I now I've had a look?
--
Dominique
___
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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
Wim Taymans wrote on Tue, Dec 15, 2020: > > In particular I'm worried alsa programs will stop working. > > There is a pipewire-alsa package to support alsa programs Aha! I had missed it, thanks. > > Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's > > pulseaudio implementation? > > It is but then you go through an extra layer of emulation, it's better to > remove the pulseaudio one and use the pipewire one if you remove the > pulseaudio daemon. Definitely, I agree pipewire-alsa suffices and is better (although I'm not sure alsa-plugins-pulseaudio should have unfullfilled dependncies from pipewire-pulseaudio, it's probably saner to have it autoremoved by default to avoid multiple interfaces to the same service) > > or some new alsa-plugins-pipewire should be pulled in at least to > > keep things working one way or another) > > Yes, it should somehow be pulled in, how should that be done? A Suggests: > for pipewire-pulse maybe? I'm not too familiar on this, but a recommends (rather than suggests which will likely be ignored by dnf afaiu) on pipewire-pulseaudio sounds good despite being not directly related to pulseaudio. I'm honestly not sure what would be best, but pulling it without the pipewire service enable sounds more harmful than good... pipewire-pulseaudio sounds like a good reinsurance that pipewire will likely be running. Note: I've now switched packages and also had to enable/start the service: systemctl --user enable --now pipewire-pulse.socket I would suggest installing a preset file that would tell systemd to enable it by default if possible? It looks like pipewire.socket has one from /usr/lib/systemd/user-preset/90-default-user.preset (in fedora-release-common-33-2.noarch) which wasn't obvious to find, I didn't check if fedora34 also enables pipewire-pulse but if not it definitely should (or pipewire should ship its own presets) Thanks, -- Dominique ___ 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)
Gary Buhrmaster wrote on Mon, Dec 14, 2020: > On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab > wrote: > > > # dnf swap pulseaudio pipewire-pulseaudio --allowerasing > > I needed to add --enablerepo=updates-testing With updates-testing enabled here, it's much better than last month (no more gdm being removed), but there still are a few pulseaudio direct dependencies: # dnf swap pulseaudio pipewire-pulseaudio --allowerasing Last metadata expiration check: 0:10:19 ago on Tue 15 Dec 2020 07:52:26 CET. Dependencies resolved. == Package ArchVersion Repository Size == Installing: pipewire-pulseaudio x86_64 0.3.17-3.fc33 updates-testing14 k Upgrading: pipewire x86_64 0.3.17-3.fc33 updates-testing 118 k pipewire-gstreamer x86_64 0.3.17-3.fc33 updates-testing52 k pipewire-libsx86_64 0.3.17-3.fc33 updates-testing 922 k Removing: pulseaudio x86_64 14.0-2.fc33 @updates-testing 4.0 M Removing dependent packages: alsa-plugins-pulseaudio x86_64 1.2.2-3.fc33@fedora 121 k pulseaudio-module-bluetooth x86_64 14.0-2.fc33 @updates-testing 231 k pulseaudio-module-x11x86_64 14.0-2.fc33 @updates-testing 78 k xfce4-pulseaudio-plugin x86_64 0.4.3-3.fc33@fedora 447 k In particular I'm worried alsa programs will stop working. Shouldn't the alsa-plugins-pulseaudio also be compatible with pipewire's pulseaudio implementation? (I see there's also an alsa-plugins-jack, I guess that might work but I don't have it installed right now; or some new alsa-plugins-pipewire should be pulled in at least to keep things working one way or another) -- Dominique ___ 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)
Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020: > On 22.11.2020 12:36, Dominique Martinet wrote: > >That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) > >Perhaps a missing provide? > > Some packages directly depends on the pulseaudio package instead of > the required libraries: That's not gnome-shell's case. $ rpm -q --requires gnome-shell | grep pulse libpulse-mainloop-glib.so.0()(64bit) libpulse-mainloop-glib.so.0(PULSE_0)(64bit) libpulse.so.0()(64bit) libpulse.so.0(PULSE_0)(64bit) $ dnf -C repoquery --whatprovides 'libpulse.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:40 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-0:13.99.2-1.fc33.x86_64 $ dnf -C repoquery --whatprovides 'libpulse-mainloop-glib.so.0(PULSE_0)(64bit)' Last metadata expiration check: 0:09:53 ago on Sun 22 Nov 2020 12:51:10 CET. pulseaudio-libs-glib2-0:13.99.2-1.fc33.x86_64 or, put the other way around: $ dnf -C repoquery --provides pulseaudio-libs Last metadata expiration check: 0:10:47 ago on Sun 22 Nov 2020 12:51:10 CET. config(pulseaudio-libs) = 13.99.2-1.fc33 libpulse-simple.so.0 libpulse-simple.so.0()(64bit) libpulse-simple.so.0(PULSE_0) libpulse-simple.so.0(PULSE_0)(64bit) libpulse.so.0 libpulse.so.0()(64bit) libpulse.so.0(PULSE_0) libpulse.so.0(PULSE_0)(64bit) libpulsecommon-13.99.so libpulsecommon-13.99.so()(64bit) libpulsedsp.so libpulsedsp.so()(64bit) pulseaudio-libs = 13.99.2-1.fc33 pulseaudio-libs(x86-32) = 13.99.2-1.fc33 pulseaudio-libs(x86-64) = 13.99.2-1.fc33 $ dnf -C repoquery --provides pipewire-pulseaudio Last metadata expiration check: 0:11:16 ago on Sun 22 Nov 2020 12:51:10 CET. pipewire-pulseaudio = 0.3.13-4.fc33 pipewire-pulseaudio = 0.3.15-2.fc33 pipewire-pulseaudio = 0.3.16-2.fc33 pipewire-pulseaudio(x86-32) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-32) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.13-4.fc33 pipewire-pulseaudio(x86-64) = 0.3.15-2.fc33 pipewire-pulseaudio(x86-64) = 0.3.16-2.fc33 pulseaudio-libs pulseaudio-libs-glib2 apparently providing pulseaudio-libs / pulseaudio-libs-glib2 does not transitively mean they provide libpulse.so/libpulse-mainloop-glib.so ? Or is the thing just broken atm? I just downloaded the latest and it only contains the server side part (systemd user service/socket for pipewire-pulse): $ rpm -qpl pipewire-pulseaudio-0.3.16-2.fc33.x86_64.rpm /usr/lib/systemd/user/pipewire-pulse.service /usr/lib/systemd/user/pipewire-pulse.socket Yet tries to provide the client (pulseaudio-libs*).. that's just wrong?! (unrelated: I'm getting pavucontrol segfaults with pipewire-pulse server, just opened a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1900339 ) -- Dominique ___ 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)
Vitaly Zaitsev via devel wrote on Sun, Nov 22, 2020: > On 22.11.2020 10:05, Mattia Verga via devel wrote: > >I think the package name is wrong, it should be pipewire-pulseaudio. > >However, it seems it doesn't correctly replace pulseaudio: > > > ># dnf install pipewire-pulseaudio --enablerepo=updates-testing > > This is absolutely fine. You should use dnf swap instead: > > dnf swap pulseaudio pipewire-pulseaudio --allowerasing That removes stuff like gnome-shell.. (as dependent packages of pulseaudio) Perhaps a missing provide? -- Dominique ___ 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)
Ben Cotton wrote on Fri, Nov 20, 2020: > == How To Test == > This change needs to be tested on as many different audio cards as > possible. The same test plan applies here as with PulseAudio. > > To test, one needs to install the pipewire-pulse library (which > removes the pulseaudio package). Took me some time to figure out how to test: - there's no such package; there's a pipewire-libpulse that apparently got integrated into pipewire-libs but doesn't replace pulseaudio unlike the comment above (in fc33's update-testing pipewire-0.3.16-1.fc33.x86_64) - /usr/share/doc/pipewire/README.md talks about pw-pulse to test but not how to replace the user's pulse socket - there's pipewire-pulse and a pipewire.socket/service user service in (the new) pipewire package, but the user service doesn't start pipewire-pulse (unless the exec is commented out in the config maybe?) I ended up manually removing the socket at /run/user//pulse/native, starting pipewire-pulse manually and killing the old pulseaudio instance but I'm sure there's a better way? I've messed around with (very casual) things and everything appears to work, with pipewire-pulse spewing some warnings when I tried pavucontrol [W][001555077.904969][pulse-server.c:411 reply_error()] pulse-server 0x56434a66a640: [PulseAudio Volume Control] ERROR command:87 (EXTENSION) tag:17 error:19 (Operation not supported) and errors when a client disconnect [E][00197.840471][core.c:71 core_event_error()] core 0x56434a67f520: proxy 0x56434a67f520 id:0: bound:-1 seq:667 res:-22 (Invalid argument) msg:"unknown resource 40 op:3" both are probably harmless, and that aside everything looks great; I think making things easier to test (or clarifying the procedure) for fedora 33 would help reassuring people about it. Haven't tested the jack side of things as I don't use it normally. -- Dominique ___ 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 Security Team
Marek Marczykowski-Górecki wrote on Tue, Nov 03, 2020: > Do you know if some parts of the above already exist? I know Debian has > automatic checks for latest upstream versions, but I haven't seen it in > Fedora. Fedora has "Upstream Release Monitoring" https://fedoraproject.org/wiki/Upstream_release_monitoring I sometimes see bug automatically opened to notify of new updates but not for all packages, it looks opt-in ? -- Dominique ___ 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: our containers with alias vim=vi
Gordon Messmer wrote on Tue, Oct 13, 2020: > On 10/13/20 5:38 AM, Chris Adams wrote: > >Rather than script hackery, why not just make vim-minimal and > >vim-enhanced use the alternatives system? They are alternates for > >providing a "vi like" editor. > > I think that's the best option, too. Dominique wrote some > suggestions for speeding up bash startup, in May (subject: Speed up > bash starting time) and I think that eliminating unnecessary > profile.d snippets benefits everyone. Stephen replied in the "Introducing vim-default-editor subpackage - replace nano as a default editor if wanted" thread just two days ago that fedora isn't so much into alternatives except if absolutely required -- search by Message-Id if you can: cannlrdgyruawljcvvffdqpurck_gvoy1ie07wkfdrcqm4wv...@mail.gmail.com My post back in May (ugh! thanks for reminding me about something I didn't follow through..) was mostly about snippets invoking slow subcommands when not really required (e.g. completion in /etc at startup time vs. /usr at first usage time) ; a profile script that doesn't fork isn't going to change very much. At least not enough that I'd want to stick my nose in that :D Besides, Zdenek seems to care about not confusing the two, and alternatives wouldn't allow something like the alias he suggested with a prompt -- I think that's a good idea even if a bit obnoxious for people who know-and-don't-care we can probably live with that. -- Dominique ___ 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?
Roberto Ragusa wrote on Mon, Sep 28, 2020: > >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 There are two problems to that: - you won't ever know what file or even block was mismatched (I've just read that despite check being a 'check', on if it encounters a mismatch it will correct either copy? in there just now : https://serverfault.com/a/854123 But I'm pretty sure that wasn't the case in the past, at least not when there is not enough parity to automatically guess a 'correct' answer, so I'm not sure about that one) There are patches to print the mismatched sector in dmesg e.g. this question has one : https://unix.stackexchange.com/questions/266432/md-raid5-translate-md-internal-sector-numbers-to-offsets But it's still a pain to use and figure which files are impacted (disclosure: I wrote that answer) - some raid array vendors don't initially sync the array, on the basis that the filesystem should never access data it didn't write first, so during the monthly scrub you get zillions of mismatches every single time... Just to save a day at start of operation :( Obviously won't be a problem for everyone, but this is known to happen. So ultimately it's all good if your mismatch_cnt stays at 0 but in case of problem you're in for a longer ride. -- Dominique ___ 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: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
Jan Kratochvil wrote on Thu, Sep 24, 2020: > > That talk doesn't load for me, sorry if I ask something answered in > > there. > > I have added a title there now but the URL loads for me even in lynx+wget. Yeah sorry it finally loaded after 10+ minutes, that was weird. > Copy-pasted it at the bottom of this mail. I do not know the talk but TL;DR > existing DWARF contains some dead DIEs - unused/deduplicated functions and > also > -fdebug-types-section declarations/skeletons which can be removed or converted > to direct DIE references respectively. That way one could reduce the size like > DWZ does but without needing any new complicated support in DWARF consumers. Ok, avoiding duplicate data makes sense there is quite a lot in there. > That is orthogonal - that is one can add it to DWZ or -fdebug-types-section > the same way. It would be for another Fedora Change proposal but I do not > think it matters for F-33 as it already implements: > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression Good point. I did think of rpm size (double compression doesn't work well and rpms use better compression than zlib) but not filesystem compression. Everyone won't benefit from that right away but I guess it makes sense. > I haven't yet checked whether that applies to /usr/lib/debug/ by default. > btrfs is using zstd which has better performance than zlib. I was considering > adding an ELF section compression extension for zstd but with btrfs > transparent compression that looks as not useful. I don't have very much there but it does work well: # compsize /usr/lib/debug/ Processed 720 files, 2232 regular extents (2239 refs), 1 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 32% 74M 229M 230M none 100% 644K 644K 644K zstd32% 73M 229M 229M > That 3.3% size reduction=advantage of DWZ against -fdebug-types-section is > calculated for *-debuginfo.rpm (3.3% is for the whole distribution incl. > binaries, for debug/ itself it is 6.35%). Also it is calculated for DWARF-4, > F-34 will hopefully switch to DWARF-5 (which is smaller by 10-20%) but DWZ is > not yet ported to DWARF-5 so it is impossible to compare -fdebug-types-section > vs. DWZ size for DWARF-5. Ok. That definitely makes more sense to me, thanks for clarifying this. -- Dominique ___ 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: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
Ben Cotton wrote on Thu, Sep 24, 2020: > ** If the 3.3% size increase is a concern I can implement a different > optimization ([https://whova.com/embedded/session/llvm_202010/1193947/ > talk (2)]) as a GCC post-processing phase which would require no > changes in any DWARF consumers. That talk doesn't load for me, sorry if I ask something answered in there. How does this relate to debuginfo compression such as passing -Wl,--compress-debug-sections=zlib ? I haven't tested on very relevant programs but on a single C file (tested with vmtouch, compiled with f32's `gcc -g vmtouch.c` and `gcc -g vmtouch.c -Wl,--compress-debug-sections=zlib`) I see a fairly significant reduction in size: after strip --only-keep-debug it goes down from 32K to 23K, that's 28% down. On a slighly bigger project (wlroots), with LDFLAGS=-Wl,--compress-debug-sections=zlib meson builddir and the same strip; I'm going from 1512 to 732k that's over 50% reduction. As far as I can see, gdb and lldb both support it just fine; and the linux kernel builds with it if CONFIG_DEBUG_INFO_COMPRESSED is set so it looks widespread enough. If not related would it be worth using? Is support somehow still lacking? Thanks, -- Dominique ___ 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: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
Neal Becker wrote on Wed, Sep 09, 2020: > I have tested kde/wayland on F32 but have hit a roadblock. We are all > working from home and need to share screens. Using google chrome, on X11 > when I try to share an app window (which is my usual choice) there are no > problems, but on wayland only some of the windows are given as choices to > share. I haven'tfound any particular pattern to which windows are > listed (is it just from certain desktops?) I believe this isn't > chrome specific (have to retest). I haven't tested but you can probaly only share other Xwayland windows (chrome still runs on Xwayland last I checked) The wayland-native way of sharing app windows is xdg-desktop-portal which has a kde implementation: https://invent.kde.org/plasma/xdg-desktop-portal-kde https://koji.fedoraproject.org/koji/packageinfo?packageID=24326 Do you have xdg-desktop-portal-kde installed? > Where can I report this issue? Now that also needs to be supported by whatever videoconferencing software you use (in this case chrome); you might want to try firefox just to see if it's better... So to sum it up: - if this works on FF but not chrome, it's a chrome bug - if this works on e.g. gnome with either browsers but not plasma, it's a kde bug Good luck (?) -- Dominique ___ 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
Matthew Miller wrote on Sat, Sep 05, 2020: > On Sat, Sep 05, 2020 at 08:46:37AM -0400, Neal Gompa wrote: > > > "BTRFS relatime vs. noatime - Huge Performance Difference - linux" > > > https://www.reddit.com/r/linux/comments/imgler/btrfs_relatime_vs_noatime_huge_performance/?utm_source=amp_medium=_content=post_body > > It's something that's being looked at, see > > https://pagure.io/fedora-btrfs/project/issue/9 > > Huh. That's... unfortunate. > > I use atimes to keep ~/Downloads and ~/tmp from building up with cruft. I'm > sure there's plenty of other practical use cases. I guess with btrfs I > should make separate subvolumes for these or something? It really depends on what you plan on taking snapshots on -- for example if you don't plan on taking snapshots for your home, it won't cost all that much (basically where a classic filesystem would edit the atime in place, btrfs needs to copy it and remove the old one, but overall there really shouldn't be so much difference in how it feels) However if there are snapshots the metadata has to be copied over if the atime changes, it's really a fundamental of cow and snapshots... It will have to keep an extra copy of the metadata around everytime there's a new snapshot with different atimes. And at this point then yes it might make sense to have ~/tmp or whatever in a different subvolume, but I don't suppose regular users would want to have to think about this kind of things. (note I'm also a big user of atimes, for cruft but also for pointless reasons like just looking at what I was doing last year or sorting files by access times in my home all the time... So that just means being reasonable about snapshots for me :P) -- Dominique ___ 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: What do to about massive # of FTBFS bugs?
Fabio Valentini wrote on Fri, Aug 07, 2020: > - waypipe / armv7hl: > https://koji.fedoraproject.org/koji/taskinfo?taskID=48698713 See the "arm/neon LTO-related FTBS" thread on the list for that one; I gave a short recap on the last message on Thursday (Aug 6) I'm still unsure if I should disable LTO for now or just patiently wait for help at this point, so I'll give Jeff and others another week or two first :) Please say if there's anything I can do to help without access to any arm hardware :/ -- Dominique ___ 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: arm/neon LTO-related FTBS
Dominique Martinet wrote on Tue, Aug 04, 2020: > So I'd really need a way to have only that file compiled with the > optimisations, and other files without it -- Jeff or someone else, could > you please advise? I could still use help with that, please. To recap, waypipe: - compiles a single function in single .c file into a static lib (.a) with optimisations e.g. `-mavx512f -mlzcnt -mbmi` or `-mfpu=neon` depending on what the compiler provides. - compiles other stuff without these optimisations; the other stuff knows what has been compiled or not through #ifdefs. - link the other stuff with that aforementioned .a ( - at runtime, decides if it is safe or not to run the optimized function, and only runs it if the hardware supports it -- since the code that makes the decision is compiled without the optimizations the binary as a whole should run on whatever we support) with -flto=auto, the final link step fails with the following: https://kojipkgs.fedoraproject.org//work/tasks/2576/48362576/build.log -- gcc -o test/diff_roundtrip test/diff_roundtrip.p/diff_roundtrip.c.o -Wl,--as-needed -Wl,--no-undefined -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--start-group src/libwaypipe_src.a src/libkernel_neon.a protocols/libprotocols.a -pthread -lrt /usr/lib/libgbm.so /usr/lib/liblz4.so /usr/lib/libzstd.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../src:$ORIGIN/../protocols' -Wl,-rpath-link,/builddir/build/BUILD/waypipe-v0.6.1/armv7hl-redhat-linux-gnueabi/src -Wl,-rpath-link,/builddir/build/BUILD/waypipe-v0.6.1/armv7hl-redhat-linux-gnueabi/protocols /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h: In function ‘run_interval_diff_neon’: /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h:10426:22: fatal error: You must enable NEON instructions (e.g. ‘-mfloat-abi=softfp’ ‘-mfpu=neon’) to use these intrinsics. 10426 | return (uint64x2_t)__builtin_neon_vld1v2di ((const __builtin_neon_di *) __a); | ^ compilation terminated. -- where `run_interval_diff_neon`is the optimised function that was compiled in the first .a with optimization flags From what I have read it's not possible to mark a function or a file as "LTO disabled"? Did I get that correctly? What can I or upstream do about this? I mean, I can disable LTO in the spec file but what _should_ I do ;) Is it a bug I should file a gcc bz for or is that a feature I don't understand? FWIW I don't have the problem with avx512f, it links just fine. Thanks, -- Dominique ___ 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: arm/neon LTO-related FTBS
Dominique Martinet wrote on Tue, Aug 04, 2020:
> I would appreciate slightly less conflicting exchanges in the future;
> I'm happy to do things differently if I'm pointed at problems but there
> *is* a change of behaviour with LTO and that isn't wrong.
>
> I apprently proceeded to fix it in a way that's not appropriate for
> fedora, but this is this and that is that, no need to shout.
Actually I take that back, this really is a LTO/gcc bug.
They compile everything that the compiler supports and at runtime detect
what is available and run the appropriate best function ('best' being
decided uppon the order of an enum, so YMMV, but at least it won't try
to run the neon function on a board that doesn't have neon even if the
binary enables it).
So I'd really need a way to have only that file compiled with the
optimisations, and other files without it -- Jeff or someone else, could
you please advise?
Thanks,
--
Dominique
___
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: arm/neon LTO-related FTBS
Peter Robinson wrote on Tue, Aug 04, 2020: > > The "fix" here is simple and upstream is reactive so I'll just resubmit > > the package with -mfpu=neon appended to linker args as well, but this > > might come bite other projects as well. > > NO! That is not the fix. We explicitly don't build with NEON on armhfp > because there are ARMv7 processors that don't have NEON and that would > then crash on those devices. Hm, yes and no - it is a bug in waypipe as you've said below, but we already were building the neon object before and what broke the build is LTO. So, sure, I can also work towards disabling neon optimisations instead; the meson file doesn't provide an option for that but it's not too difficult. Note there is the same problem with avx, it builds with avx512f if the compiler supports it -- I think it's fairly standard for upstreams to just enable everything by default if it's available, and we need to turn it off. I'm not sure what the standard way is to do that with meson, will have to do some zoology first... neon and avx instructions are pretty mainstream for streaming (waypipe is a kind of vnc) so I expect other packages have fixed similar problems in the past... > On aarch64/ARMv8 it can be assumed there's NEON because it's a > required part of the standard, but it's not a requirement for ARMv7 > processors so the software should do run time detection / fast path > code to optimise if it detects NEON at runtime NOT compile time. waypipe is actually one of the better projects in the regard that there are tests run in the %check section (thanks to whoever made the initial package I took over), and the tests run fine with NEON enabled on arm. Would it be possible to have hardware we're actually supposed to support available for rpm checks? I think it's precisely why we have checks ; this package has been broken for platforms without neon ever since it had been introduced. It's also probably broken on machines without avx512. I don't have access to any such machine where I could do this kind of tests, and I'm not the original packager of this thing, so don't expect me to know how to deal with that. > > I don't think gcc can intuite this so it's probably not a bug though > > (hence I'm not planning on opening a bug), but it is a regression of > > sort... > > You're wrong. I would appreciate slightly less conflicting exchanges in the future; I'm happy to do things differently if I'm pointed at problems but there *is* a change of behaviour with LTO and that isn't wrong. I apprently proceeded to fix it in a way that's not appropriate for fedora, but this is this and that is that, no need to shout. Thanks, -- Dominique ___ 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
arm/neon LTO-related FTBS
Hi, this is more of a head's up than a bug per se (well, I'm actually not sure if it's a bug, is it?), but I've had a package fail to build due to LTO and neon optimisations: https://kojipkgs.fedoraproject.org//work/tasks/2576/48362576/build.log Basically what they do is compile different .a with different level of optimisations as required, and then link them into the final program without any optim flag and intend to have it just use the optimised functions as is. Without LTO, this just embeds the code so the rest of the program was built naively and it used to work, but with LTO the compiler tries to use neon optimisations at some point apparently and the link fails : /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h:10426:22: fatal error: You must enable NEON instructions (e.g. ‘-mfloat-abi=softfp’ ‘-mfpu=neon’) to use these intrinsics. The "fix" here is simple and upstream is reactive so I'll just resubmit the package with -mfpu=neon appended to linker args as well, but this might come bite other projects as well. I don't think gcc can intuite this so it's probably not a bug though (hence I'm not planning on opening a bug), but it is a regression of sort... Anyway I hope this mail can save others a few minutes of research :) Cheers, -- Dominique ___ 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: Very strange compiler/linker related build failures in rawhide
Jeff Law wrote on Fri, Jul 24, 2020: > > Looks like somebody already did that and attached the .ii file to the RHBZ. > > https://bugzilla.redhat.com/show_bug.cgi?id=1859588 > > Unfortunately neither Marek nor I can reproduce with the compilers we've > tested. > Is it possible the OOM killer is killing the process? Is there anything in > the > system logs that might be relevant? I was able to reproduce running a rawhide mock, it's definitely not memory pressure. It's a plain segfault in cc1plus - I'd give a backtrace but it looks mangled up so I didn't take the time to install debuginfos -- Dominique ___ 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
Vitaly Zaitsev via devel wrote on Sun, Jul 12, 2020: > On 11.07.2020 14:20, Dominique Martinet wrote: > > BTW, given the size gains ws. time difference for compression I would > > advocate for default zstd compression instead of :1 -- I'd think another > > 12% compression improvement[1] for almost no time difference isn't to be > > sneezed at? > > Now please open this file again and check Data Operations table. The passage you quoted has nothing to do with the paper, but about another part of the thread. Note I never said this paper wasn't about data, nor that btrfs is good wrt write amplification in the access pattern they do in this paper ; I said you might want to think whether a pattern with small writes and fsyncs in a cow filesystem is a good idea and is going to be representative of a typical user's workload. That is precisely why previously in the thread things like databases have been discussed along with the nocow chattr flag. (Yes, that means applications need to start being concious of what fs they are being run on, or at least the fedora configuration needs to do that check for them) -- Dominique ___ 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
Artem Tim wrote on Sat, Jul 11, 2020: > BTRFS WA is ~8 times higher than ext4. Average profit from compression > about 50% max. Not that hard arithmetic. It's not that simple. The pattern used in that paper is far from a standard workload (random writes within a file with cow is just about as bad as things can get wrt. write amplification) ; so things like the sqlite db firefox uses in your home will be worse as far as that goes with btrfs even if compressed yes certainly. But if you're talking open w/ truncate (or new file), write in a single stride, close and never write again (like what happens when you upgrade packages, compile something, download something etc etc) then the difference won't be that big. As Chris said multiple times, it's hard to find the right way to measure impacts, and I don't have good solutions either, but this definitely isn't the kind of usage I make of my filesystem. I'd be tempted to believe the feedback from facebook on that one, even if adding snapshots into the mix it's not 100% clear if compression has much impact by itself either... BTW, given the size gains ws. time difference for compression I would advocate for default zstd compression instead of :1 -- I'd think another 12% compression improvement[1] for almost no time difference isn't to be sneezed at? [1] https://www.spinics.net/lists/fedora-devel/msg274978.html -- Dominique ___ 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 by default, the compression option
Kamil Paral wrote on Wed, Jul 08, 2020: > On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote: > > > D. Which directories? Some may be outside of the installer's scope. > > > > /usr > > /var/lib/flatpak > > ~/.local/share/flatpak > > I have a concern regarding games. Currently, we have a few a bit more > demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In > the glorious future (tm) we might get more. Games are very sensitive to > available CPU cycles and context switching and usually come with their data > files already compressed. Including the btrfs compression by default on > flatpak dirs could lead to lowered performance whenever the game tries to > load some assets (older titles do that during the loading screen, newer > titles stream new assets constantly during gameplay and any slowdown > manifests as game stuttering). Please test, but if a file is deemed not compressible (based on, not sure what? the first few blocks?) then it will be stored in the non-compressed version. You can check with compsize after the fact if the file had been compressed or not. This should be true unless the compress-force mount option is used, even the chattr is only a hint > I'm personally more concerned about reduced performance in e.g. my web > browser than disk wear out. I don't see much harm in compressing /usr, > because it's a read-only location that gets loaded once when the app starts > (it might delay the app startup a bit, though, and decrease the perceived > snappiness of the desktop). But I'm concerned about compressing locations > which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5 > years and I'm just at 10% of expected TBW (total bytes written). If the SSD > lasts 50 or 100 years is not really important for me, but the desktop and > app responsiveness is (and game performance, of course:)). I think write > amplification is a problem specific to devices with SD cards, and for > anyone else, it might be better to leave it unset and let people enable it > (it's simple) if they want it for their use case. This obviously needs testing on a wide variety of hardware but I haven't noticed any difference in the feeling on an intel laptop (kabylake i5 throttled at 2GHz) ; that being said firefox isn't the most responsive app in my book... -- Dominique ___ 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
btrfs, ssd & metadata single profile
Chris Murphy wrote on Wed, Jul 01, 2020: > This is called 'dup' profile in Btrfs. Two copies of a block group. It > can be set on metadata only, or both metadata and data block groups. > It is the default mkfs option for HDDs. It is not enabled by default > on SSDs because concurrent writes of metadata i.e. they happen > essentially at the exact same time, means the data is likely to end up > on the same erase block, and typical corruptions affect the whole > block so it's widely considered to be pointless to use dup on flash > media. You can use it anyway, either with mkfs, or by converting the > block group from the single profile to dup. This is a safe procedure. Does anyone know if anything in the nvme spec says that creating two namespaces should or could prevent coalescing IO like this? perhaps is the blocksize is different? (this doesn't really help with default setup case, but it could make sense to split the disk in two with data single + metadata raid1 over a nvme namespace for people who can bother creating one. Unfortunately nvme namespaces are rather messy and I don't think autopartitionning tools should mess with that, but having a raid just for metadata is one of btrfs' strength so it's a shame to pass on it... Alternatively it would require something like async copyback of the second metadata copy but that in itself has a lot of other problems and don't really look like an option) -- Dominique ___ 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
Thanks for the reply. It feels a bit dismissive after the time I spent there, so I'll assume I wasn't clear and my point didn't get across (I did send that mail at 1AM and haven't slept much lately...): I'm not complaining about any particular bug here, just that the overall use & feel is way too rough. I think what we (fedora) need right now are more people using it, the thread is full of ""anecdotal evidences"" one way or another, mine isn't anything more or less than that, but first encourage people to use it more and polish tools/documentation then actually make it default. (If this can happen in time for f33 that would be great, but my opinion at this point isn't optimistic) To give one more example I've remembered now, `btrfs scrub` will only report the first file that is corrupted for a given extent. btrfs being cow, it is possible (and was my case yesterday) that some of the extents belong to multiple files and there is no easy way to report all the files involved : the btrfs scrub status command should have an option to do that, really. kernel messages can be throttled so if some line is missing you'll miss a corrupted extent, and parsing dmesg to use `btrfs ins logical-resolve` is far from obvious to a new user. I also feel the mix of "this command runs in foreground" (e.g. defrag, some variants of balance? not clear to me) and "this command starts a background thread" (e.g. scrub unless -B given) is a bit messy and confusing. Yes we don't want users to actually run these manually, so we need things that need to run to automagically start in background and some nice gnome popup or whatever to notify of any problem instead; but that isn't here yet either. Chris Murphy wrote on Mon, Jun 29, 2020: > > Recap of the problems I ran into: > > - bug in btrfs-convert where it just aborts in the middle with an > ... > > - second bug in btrfs-convert, running scrub immediately after > ... > > My view is that btrfs-convert is something of a proof of concept. Yes > it should fail gracefully if it's going to fail, and the rollback > should work short of having made certain modifications (listed in the > documentation) post-install. And maybe there'd be interest in the > Fedora community at some point down the road doing a test day or test > week, to gather a lot of good data on converting ext4 to btrfs. I > don't know but my suspicion is that as any file system ages, it's > becoming increasingly non-deterministic in its layout, and that might > affect the conversion success rate. New file systems seem to convert > without problems, and sometimes older ones don't (and by older I mean > 1-2 years.) Yes, btrfs-convert isn't a battle-hardened tool; I'm not judging btrfs based on just this. Honestly, out of the 4 hours I spent last night; btrfs-convert wasn't even included there. I had failed first then prepared on another copy and things worked rather well overall -- it could get better error messages, a big warning in man page perhaps, but overall I've saved more time with btrfs-convert than I would have spent trying to juggle resizing partition multiple times to copy data over. Once again: not complaining about the result, my point isn't about the bugs I reported but about documentation. > > - I have (had) a working kexec-kdump setup and usually set the sysctl > > kernel.panic_on_warn to 1... That also wasn't great because since > > someone suggested using flushoncommit here I went for it (sounds better > > than chattr +C to me?), but machine crashing after 30s wasn't fun, > > They're noisy WARNON messages, but not crashes. bugs eat data. seriously. I have panic_on_warn on all my systems, so a warn IS a crash for me. Because of the switch kexec wasn't reconfigured yet (needs more than 30s to rebuild initrd) and this was really annoying, I had to take a video of the screen to read it that's just about as bad as things can get... With my kernel developer hat, I'll also say warnings should also never be ignored: even if you're smart enough to decide this one is begnin, you'll miss other bug messages if you let this one happen all the time. > And it's my mistake to even mention it. Fedora folks won't be asked or > recommended to use that. It's not just you. I've seen it recommended by Zygo on IRC as well just the other day. It's not broadly advertised but it is a good feature that really makes sense for some workloads, people will try to use it. What's frustrating is that it's been around since 4.15 and nobody seemed to care: either it's really harmless in the way btrfs use it and it should be quietened down (Zygo said he patches his kernels to remove the message), or it's not and it should be fixed. For reference I currently am using: - autodefrag, because I read it helps with small dbs e.g. firefox sqlite databases and things like that and wanted to see the impact it has in the background - compress=zstd (not sure about your :1, I don't think the cpu usage difference will be that big; it's
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
So, given this already has way too many answers I didn't want to reply, but after spending ~4 hours to get my laptop back to bootable state after a btrfs-convert I guess some people might be interested. Overall thoughts for whoever doesn't want to read the rest is: I think btrfs the FS is probably good enough, but there is a lot of work on the tooling to do as has been said multiple times in this thread. I realise most of the points I make won't impact a new system but it's just illustrating rough edges, and for a single day experience that is probably too many -- well I've converted now, hopefully will be happy ever after? ;) Recap of the problems I ran into: - bug in btrfs-convert where it just aborts in the middle with an unintelligible message if the ext4 fs had some fscrypt files; the conversion fails with ENOTSUP but it's not printed properly because it's overwriting the progress line and there is no message on what failed, that was a good first impression... I've sent a patch to add the inode number that cause the problem as well as repeating the error code, it's a first step ; another fscrypt-specific message might be worth doing later eventually I'll report that separately. Removed these files. - second bug in btrfs-convert, running scrub immediately after converting reported checksum errors. I had copied the whole disk over to debug the previous problem so could also reproduce that multiple times, it's not a transient hardware error I got this on different machines on the same files. This only impacted a single file I can recover but it's still annoying, anyway, I'm in the process of getting a bit more details before reporting this upstream as well, bugs happen, I was told btrfs-convert isn't used all that much, I didn't have more problems with the conversion itself so it could have been worse. - after doing that conversion from initrd and rebooting, all services failed to start. I intuited that to be selinux problems and triggered a relabel that fixed everything, but it would be confusing to most people; I couldn't get to a shell because of the next point so not sure if X would have worked but the boot scrollup was scary (another user removing bootsplash present! :P) - I have (had) a working kexec-kdump setup and usually set the sysctl kernel.panic_on_warn to 1... That also wasn't great because since someone suggested using flushoncommit here I went for it (sounds better than chattr +C to me?), but machine crashing after 30s wasn't fun, especially since kexec hadn't been reconfigured for btrfs yet so I didn't have time to read the warning. I think that flushoncommit should not be suggested before that warning gets removed officially, even if it is harmless for most people, it is really quite verbose and will hide any real problem that could happen. Quite a shame, though; that really looks like a good idea, but this warning has been around since 2018 at least so I'm dubious - after regenerating initrd for some reason it generated an empty crypttab and stopped prompting to decrypt the fs on reboot; there is some autodetection logic in /usr/lib/dracut/modules.d/90crypt/module-setup.sh that apparently worked before and doesn't anymore? There are multiple workarounds like adding rd.luks.name parameter or adding ',force' to crypttab options but this wasn't pleasant either raid1 automount / proper warning also seems important to me but also has been properly ack'd so little point in repeating. raid5 would be nice eventually, but the recap from Zygo on btrfs list is rather clear, I'll stay away from it a while longer even if most problems are workaroundable. I think that's about it, points about VMs / DB needing either chattr +C or removing all fsync and using flushoncommit has been taken properly so I'm not too worried about that one, and rest looks like it will work fine to me. Compression in particular is a very noticeable gain for my local storage (mostly sources and git trees) so I had been wanting to try, this thread gave me the push... (from a quick compsize on fs root: Type Perc Disk Usage Uncompressed Referenced TOTAL 66% 121G 183G 192G none 100% 87G 87G 88G zlib46% 1.8K 4.0K 4.0K zstd35% 33G 95G 104G I need to check what's uncompressible but probably git objects themselves, and a few VM images it looks like ; still more than decent) Good work all, -- Dominique ___ 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: swap on zram
Igor Raits wrote on Fri, Jun 05, 2020: > zramctl shows ALGORITHM > > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lzo-rle 11.7G 4K 74B 12K 8 [SWAP] > > So it is lzo-rle by default, but it should be possible to override this > algorithm. There is an RFE for this already at zram-generator github. There is zstd support in our kernels now so that would be good to compare, I'm seeing impressive results but as this is workload-dependent it is hard to test from an objective point of view, but this is rather impressive: # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 zstd1G 753.4M 150.6M 158.8M 8 [SWAP] (enabled 15 or so days ago manually; according to smem I have bits of qemu, firefox, libreoffice, xorg, urxvt and most of lightdm, sd-pam, rpc.mountd.. in swap so it is quite varied) Either way +1 from me, I've just installed the generator and manually set the limit to 4G/0.5 as suggested in the change; I think such a config file should be added to the f32 rpm so people can try more easily to convince themselves with the actual config that would be installed. Cheers, -- Dominique ___ 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: System-Wide Change proposal: CompilerPolicy Change
Fabio Valentini wrote on Fri, Jun 05, 2020: > Sorry for being off-topic, but can you (Jeff) please not respond to > the mailing list digest and amend the Subject line manually? > I think it screws up the In-Reply-To (?) header in emails, so every > new email from you creates a new thread (for clients that support > this) ... > Right now, this is the 16th thread for this topic in my inbox. It > makes it *really really hard* to follow the discussion. I brought it up to him off-list just a couple of hours ago, he wasn't aware of it. The problem comes from digest mails that his mailer (evolution) doesn't explode correctly to respond with correct in-reply-to header; he said he'd look into it and hasn't given a new reply to the thread yet but I'm sure he took it to heart. (I also suggested getting the message-id from hyperkitty, as its reply button properly gives it to keep threading, but it's more work than replying to emails from the comfort of one's mailbox... Getting the correct message-ids from the digest would be ideal.) Thanks for bringing it up as well, I should have kept the list in Cc to avoid multiple requests! Cheers, -- Dominique ___ 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
Vitaly Zaitsev via devel wrote on Sat, May 30, 2020: > On 30.05.2020 11:51, Iñaki Ucar wrote: > > What are the issues? I have full-disk encryption and > > suspend-then-hibernate enabled (with secure boot disabled, of course), > > and it resumes from hibernation without issues. > > Do you have encrypted by LUKS swap partition? > > Fedora cannot resume from encrypted by random passphrase (parameter tmp > from crypttab) swap partition. Well, yes, how do you expect that to possibly ever work? You'd need to somehow tell the initrd to not regenerate a new luks key but instead enter manually the old random one that you would have meticulously copied out before going into hibernation. If your swap is in a luks partition with a static passphrase (and secureboot is disabled) then hibernate works just fine. (my laptop wakes up on low power from sleep and switches to hibernate automatically if it stays on suspend too long, this is quite awesome and I think off-the-box behaviour for this machine. Wouldn't need that if the battery wouldn't leak so much when in sleep in the first place, admitedly, but I haven't had any recent laptop that could stay in sleep mode for a week unfortunately :/) -- Dominique ___ 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: fedpkg fork broken?
Kevin Fenzi wrote on Fri, May 22, 2020: > So, just to clarify a confusing situation... :) > > a...@pkgs.fedoraproject.org should never have worked. > > If you have pkgs.fedoraproject.org it means you are using SSH, and are a > packager. This is just due to the way pkgs was created. Packagers have > accounts there and can ssh, if you aren't a packager you don't have an > account and can't ssh. So that would probably be a bug that fedpkg adds remote as a...@pkgs.fp.o I started looking at the code but it looks like it got fixed just two weeks ago: https://pagure.io/fedpkg/issue/394 https://pagure.io/fedpkg/c/0da2d94 Looks like we just need to wait for an update :) > > And I think forking your own repo for pull-requests makes perfect sense, > > especially since distgit doesn't allow you to remove temporary branches > > from the main repo. > > +1 I think there might be a confusion here as well. I was thinking of "your own repo" as pkgs.fedoraproject.org/forks/yourfaslogin/rpms/repo.git - which I still don't see much sense in forking, if that is possible at all. But now I think everyone is talking about some original repo you're maintainer of; I have no problem agreeing with that one! -- Dominique ___ 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: fedpkg fork broken?
Richard Shaw wrote on Mon, May 18, 2020: > > Seems to work for me: > > Don't know what's wrong then... I went back and re-read your first mail, it is possible it doesn't work on one of your own projects? I'm not sure how much sense there is in forking your own repo... > Ok, so this is the opposite workflow where you only clone the main repo and > create a remote for your fork. Would be nice if this was documented but > google didn't turn up anything useful for me. The only documentation I > could find still says to do the opposite. Clone your fork and add the > original as the remote (github style). Well you have to clone *something* so fedpkg would know what to fork. I've just done a "fedpkg clone" of a repo to look at it, then assumed fork would do what hitting fork does on the web ui and this is pretty close. I wouldn't want the command to change what origin is, although I'm not sure how `fedpkg push` works I intended to use plain git commands for that... OTOH something did not work, the remote was setup for ssh://a...@pkgs.fedoraproject.org/... and I had assumed there is a magic account with all ssh public keys that does redirection (like github does, everything happens under user 'git') but that didn't work; I had to change the url to specify my user. I might need to specify --user xyz next time... -- Dominique ___ 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: fedpkg fork broken?
Richard Shaw wrote on Mon, May 18, 2020: > I checked src.fp.o/settings and even though my key was still valid, it was > going to expire this month so I went ahead and generated a new api token > and saved it in the specified location: > ~/.config/rpkg/fedpkg.conf I actually hadn't used it yet, so tried just now. Seems to work for me: $ fedpkg fork Fork of the repository has been created: https://src.fedoraproject.org/fork/martinetd/kernel-tools $ git remote -v martinetd ssh://a...@pkgs.fedoraproject.org/forks/martinetd/rpms/kernel-tools.git (fetch) martinetd ssh://a...@pkgs.fedoraproject.org/forks/martinetd/rpms/kernel-tools.git (push) origin ssh://martin...@pkgs.fedoraproject.org/rpms/kernel-tools (fetch) origin ssh://martin...@pkgs.fedoraproject.org/rpms/kernel-tools (push) so to answer your question on the other thread, it operates in place and adds a remote. Exactly what I would have wanted :) Regarding your problem, did you add the ACL "Fork a project" on your API key? I didn't wait after creating it. > GRIPE: You can't actually see the whole key in the website even though I'm > on a 1080p monitor and have a ton of whitespace on either side. So I copied > and pasted it again. No dice. I agree on this one. Double-clicking worked though, whole key was in selection on firefox. fedora 32 with updates-testing enabled if this matters. Cheers, -- Dominique ___ 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: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Zbigniew Jędrzejewski-Szmek wrote on Mon, May 18, 2020:
> > > How should I go about with that? Open bz bugs to all the packages I
> > > listed?
> >
> > I would suggest to directly create pull requests on pagure (with a
> > reference to this thread), as that will make it more likely that this
> > change will actually happen.
>
> +1
I feel like I'm being dumped the work wholesale... :)
This unfortunately might not be that simple, I've just checked from the
first I'm most likely to use (perf) and the install path is decided by
the kernel makefiles.
The kernel ships three completion scripts, two have been updated to
install to /usr/share/bash-completion/completions by default (so
bpftool will just be a matter of NOT setting bash_compdir in the
specfile and just a spec update) but perf will need a kernel patch
first. I believe this was not fluke the first project I looked that does
it that way, there really is some work required... I don't mind going
through it one item at a time, including the kernel patch that will
break packaging anyway, but this really isn't as simple as pagure PRs,
it might be possible to just 'mv' the file there after install but
that's not a good solution.
On the pagure side, I assume the process is something along the lines of:
- fedpkg clone pkg && cd pkg
- modify things
- fedpkg fork
- push in fork
- got create PR in the web interface?
I'll work on it as time permits...
> Please also consider submitting a PR for the packaging guidelines.
> I think this is a change we generally agree on, and a PR should make
> the whole process faster.
This file ?
https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages/index.adoc
Should it be something specific about bash-completion, or something more
generic about avoiding files in etc when possible?
To give a few examples:
- /etc/systemd/system -> /usr/lib/systemd/system
- /etc/udev/rules.d -> /usr/lib/udev/rules.d
- /etc/tmpfiles.d -> /usr/lib/tmpfiles.d
- /etc/bash_completion.d -> /usr/share/bash-completion/completions
I'm sure there are more and don't see anything about any of these... Oh
actually tmpfiles.d is mentionned but not about avoiding /etc, and all
the others have a macro (%{_unitdir}, %{_udevrulesdir} and
%{_tmpfilesdir} respectively) so can be considered as 'autodocumented' ?
> Also:
> $ repoquery --whatprovides '/etc/bash_completion.d/*' --qf '%{name}'
Well... I'll start with what I have on my system as the egoist
person I am :)
Thanks for the full list though.
--
Dominique
___
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: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Samuel Sieb wrote on Sat, May 16, 2020: > On 5/16/20 3:56 AM, Dominique Martinet wrote: >> - down to 0.130s after moving /etc/bash_completion.d/* to >> /usr/share/bash-completion/completions/ > > I thought that generally, the /etc versions of config directories > were intended for the purpose of local overrides of the /usr/share > versions. Well that is for sure where I would install my own completion scripts not in rpms, similarily to how just about everything else works with /etc vs /usr (systemd, udev and friends at least) >> This one is not actually a no-op: bash-completion loads things from /etc >> at shell startup time, but things in /usr at first tab time, so if the >> file in /usr/share is not named by the same prefix as the command it >> help completes it won't work anymore, but in most case here it will >> still work just the same (slightly slower on first use) > > That's a strange separation of functionality. Maybe that's why some > of them are in there? The usual "solution" in this case for products that want to maintain a single script is just to add symlinks to the main one, for example see lvm: lvchange lvcreate lvdisplay etc etc all symlink to 'lvm' in /usr/share/bash-completion/completions. Although in this case very few would need to make one, in the full list above they almost all complete a single command so just renaming the file for some would be enough. In the list I gave, the only two exceptions are lilv which completes two commands so would need one link, and fzf which overrides the existing completion for kill so I guess that one has a valid reason to stay in /etc even if I hadn't noticed until now... -- Dominique ___ 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: Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Vascom wrote on Sat, May 16, 2020: > Are you use SSD? > > I have 0.087s on it. Yes, I have a SSD. The bottleneck here really is cpu speed; I have my laptop's frequency limited to 1GHz in normal circumstances (when not building code or similar activities) so the fan doesn't turn up With max (4.6GHz) clocking the whole time is a bit less drastic, but still worth more than half the time: going from 0.097s to 0.037s I'd rather not use "I have a performant machine" as an excuse, though - my next laptop will likely be based on a low power ARM soc and I might not be that aggressive on throttling since it won't have a fan in the first place, but it will likely be much slower than this :P That's precisely the kind of thinking that makes everything feel just as slow today than they were 20 years ago despite having much more powerful computers... -- Dominique ___ 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
Speed up bash starting time (slow scripts in profile.d, /etc/bash_completion.d)
Hi, once in a while I get annoyed at how slow bash is to startup; using a tiling wm poping a new shell is supposed to be quite fast but I'm staring at a new empty window for ~1s everytime and it gets annoying... According to https://xkcd.com/1205/ wasting 1s 50+ times a day is worth spending some time to try to improve it so let's see what we can do :) Here's the baseline on my machine: $ time bash -l < /dev/null real0m0.341s user0m0.198s sys 0m0.146s And a few low hanging fruits I could find adding `-x 2>&1 | ts "%.s"`: - down to 0.288s after removing /etc/profile.d/flatpak.sh (flatpak-1.6.3-1.fc32.x86_64) - down to 0.225s after removing /etc/profile.d/modules.sh (environment-modules-4.4.1-2.fc32.x86_64) - down to 0.130s after moving /etc/bash_completion.d/* to /usr/share/bash-completion/completions/ This one is not actually a no-op: bash-completion loads things from /etc at shell startup time, but things in /usr at first tab time, so if the file in /usr/share is not named by the same prefix as the command it help completes it won't work anymore, but in most case here it will still work just the same (slightly slower on first use) Here's the list of files I had in there and their packages: authselect-completion.sh authselect-1.2.1-1.fc32.x86_64 fcoeadm fcoe-utils-1.0.32-9.git9834b34.fc31.x86_64 javaws.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 perf perf-5.6.7-300.fc32.x86_64 trace-cmd.bash trace-cmd-2.8.3-1.fc32.x86_64 bpftool bpftool-5.6.7-300.fc32.x86_64 fcoemon fcoe-utils-1.0.32-9.git9834b34.fc31.x86_64 policyeditor.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 xl.sh xen-runtime-4.13.0-7.fc32.x86_64 cargo cargo-1.43.1-1.fc32.x86_64 fzf fzf-0.21.1-1.fc32.x86_64 lilv lilv-0.24.6-2.fc32.x86_64 python-argcomplete.sh python3-argcomplete-1.10.0-4.fc32.noarch dbus-bash-completion.sh dbus-glib-devel-0.110-7.fc32.x86_64 gluster glusterfs-cli-7.5-1.fc32.x86_64 lldpad lldpad-1.0.1-16.git036e314.fc32.x86_64 redefine_filedir bash-completion-2.8-8.fc32.noarch dog sheepdog-1.0.1-10.fc31.x86_64 itweb-settings.bash icedtea-web-2.0.0-pre.0.2.alpha13.patched1.fc32.x86_64 lldptool lldpad-1.0.1-16.git036e314.fc32.x86_64 torsocks torsocks-2.3.0-5.fc32.x86_64 341 to 130ms is a good start I guess, the rest of the waiting time probably now outweights bash and will get some looking at at a later point, but might as well start somewhere. How should I go about with that? Open bz bugs to all the packages I listed? strongly suggesting to get things to move to /usr/share (17) and flatpak (suggest some kind of cache? not sure they'll be interested...) and environment-modules (not sure what to suggest there, I only have environment-modules because I need to test something with openmpi from time to time and it comes with it...) It might also make sense to have a packaging guideline suggesting to avoid /etc/bash_completion.d in favor of the /usr/share variant, I couldn't find anything here[1] but I might not have looked thoroughly enough... [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/ Would anyone be willing to help, something is telling me that doing this alone would take more time than what I'd save in the end, but a few people considering it'll help everyone might be ;) Thanks! -- Dominique ___ 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: AskFedora: Can someone please answer this question on security fixes on
Hi, Ankur Sinha wrote on Sat, May 16, 2020: > As subject says: > https://ask.fedoraproject.org/t/comparing-fedora-centos-security-fix-lag/7117 > > (I looked around a bit and couldn't find any documentation on this). I've tried for a bit (~10 mins) but I really can't get discourse to let me reply, probably an issue on my end but since I'm also curious about it I can give the start of an answer here: - first for opaque security issues, fedora isn't on linux-distro list: https://oss-security.openwall.org/wiki/mailing-lists/distros This means that fedora as its own entity does not benefit from advanced warning when such an issue occurs, apparently. I'm curious about this point, there is a security team[0] so it could be interesting to get one of them on the list? I'm not following quite close enough what they do... [0] https://fedoraproject.org/wiki/Category:Security_Team?rd=Security_Team - However in practice that does not seem to be much of a problem, taking any random recent CVE e.g. CVE-2020-5260 which was made public on April 14 2020 got released April 17 for debian[1], April 21 for rhel7[2] & hitting centos on april 29[3], and april 15 for fedora[4] (stable on 25th[5]). I guess it wasn't marked as critical to skip through testing but overall this isn't so bad, I guess? The update itself actually got pushed to fedora before rhel customers got it, so anyone with fedora-testing enabled would have gotten it pretty damn fast. [1] https://tracker.debian.org/pkg/git (2.20.1-2+deb10u2) [2] https://access.redhat.com/errata/RHSA-2020:1511 [3] http://mirror.centos.org/centos-7/7/updates/x86_64/Packages/ [4] https://koji.fedoraproject.org/koji/buildinfo?buildID=1493735 (for f32 but other branches as well) [5] https://bodhi.fedoraproject.org/updates/FEDORA-2020-c6548b488f Hope this helps, -- Dominique ___ 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: Orphaned packages looking for new maintainers
Hi Dan, Dan Čermák wrote on Thu, May 14, 2020 at 11:58:27PM +0200: > Thanks for the offer to sponsor Dominique Kevin! Yes! Thanks Kevin, I was able to take waypipe just now. > Dominique, would you be interested in joining the sway SIG as waypipe > fits quite well into our maintained packages > (https://fedoraproject.org/wiki/SIGs/Sway#Packages)? I don't actually use sway (although I do have a few patches in it... :D), but sure it does fit well. I'd be very interested in trying to sort out what we can do with redshift as well, upstream has not been very cooperative but it looks like just ENOTIME to me and it might be possible to engage a discussion somehow. I'll start a thread on the sway SIG list; I've just subscribed and will send a mail about that after work. -- Dominique ___ 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: Orphaned packages looking for new maintainers
Hi, Miro Hrončok wrote on Mon, May 11, 2020 at 07:42:09PM +0200: > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > waypipe orphan 5 weeks ago I would be interested in taking waypipe. The project is still active upstream[1] (FTBS[2] in fedora had already been fixed there), does work as of right now (tested on fedora32), and it is generally something I would consider useful... There just aren't many wayland applications one would want to "ssh -X" into yet, but as long as upstream is active I would support it. I'm not a maintainer though, so can't just hit "take". What would the procedure be for that? Wait until it gets orphaned next week and submit it again as a new package? In the off-chance it might get revived without going through the orphan process, I've submitted remote PRs on pagure, both on fedora 32 branch[3] and master[4] ; the simple koji test succeeded in both. [1] https://gitlab.freedesktop.org/mstoeckl/waypipe/-/commits/master [2] https://bugzilla.redhat.com/show_bug.cgi?id=1800245 [3] https://src.fedoraproject.org/rpms/waypipe/pull-request/2 (f32) [4] https://src.fedoraproject.org/rpms/waypipe/pull-request/1 (master) FWIW, looking at the requirements on the "Join the package collection maintainers" page[5], I do have all required accounts, introduced myself in 2015[6] so just took a bit of time to follow through, and can probably beg for a sponsor or two if required (added an ex-coworker in Cc who is an active packager, and who would probably vouch for me if required. Hi Stéphane!); I just don't see anything about starting from an orphaned package. If anyone is on centos lists, I'm also very grumpy, but don't speak up much unless I have good reasons to.) [5] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers [6] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WFMUCQO65M3YGE2NTV4WUXVNN6UBLLN7/ Thanks for guidance, -- Dominique Martinet (martinetd on FAS) ___ 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: python3 entry_points console scripts packaging question
Miro Hrončok wrote on Wed, Nov 27, 2019 at 04:32:27PM +0100:
> If I understand this properly, your package requires (in Fedora):
>
> - /usr/bin/python3
> - python3.8dist(setuptools)
Yes, on Fedora 31 the current requires for clustershell (to continue
with that example) contain these:
$ rpm -q --requires python3-clustershell
/usr/bin/python3
python(abi) = 3.7
python3-PyYAML
python3-setuptools
python3.7dist(pyyaml)
python3.7dist(setuptools)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
> And in Fedora, when you ahve both of those, it also means that
> /usr/bin/python3 is Python 3.8.
Ok, I thought it was just much less likely but it would also fail on
upgrade, good to know.
> However, this might not be the case for EPELs.
Yes, they have python36-setuptools and python34-setuptools at the same
time right now, and the packages do not conflict in any way.
> The easiest way to ensure a specific shebang is:
>
>%global __python3 /usr/bin/python%{python3_version}
Thanks, I will add that for our EPEL builds only.
--
Dominique
___
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
python3 entry_points console scripts packaging question
Hi,
Some context first, skip to the end if you want.
We have a few python packages at $work with setuptools entry_points
console scripts - basically setuptools creates a small python script for
you loading a module and calling the function you specified.
For example, clustershell here defines four commands (clubak cluset
clush and nodeset) here:
https://github.com/cea-hpc/clustershell/blob/master/setup.py#L57
Setuptool embeds whatever python command was executed for running
setup.py at the start of the script, so if the command used in the spec
file was %py3_install as per the guidelines or even %{__python3}
setup.py something, you will get a #!/usr/bin/python3 shebang in your
scripts.
On the other hand, the script depends on what just got installed in
/usr/lib/python3.x/site-packages, so if python3 gets a major upgrade and
the /usr/bin/python3 link changes, the script will stop working
complaining that whatever it tried to import does not exist, while in
reality everything is still there, works if you run it with the right
python version, and the rpm requires ensure this properly.
For packages in fedora this doesn't matter as much as there is a python
mass rebuild when this happens, but I'm not sure it happens with epel
version bump, and it certainly doesn't happen for our internal packages
(hence this message!)
Now for the big question, should we try using `python%{python3_version}`
or fixing the link in scripts somehow for our rpms ?
Can anyone think of a cleaner way?
Another idea that just came to mind would be to try to write in the spec
file that we require /usr/bin/python3 to point to a specific version, so
that at least it fails to upgrade, but that doesn't sound much better
and I wouldn't know how to do that anyway.
Thanks,
--
Dominique
___
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
David Kaufmann wrote on Tue, Nov 26, 2019 at 11:13:15AM +0100: > On Tue, Nov 26, 2019 at 09:45:44AM +0100, Dominique Martinet wrote: > > FWIW this has happened at an association I help at -- they had VMs with > > no root password set, and users created by puppet some of whom have > > sudo. > > They just expected no root password = no login possible, but it turns > > out 'su' just gave out a root shell with no password entered... > > > > It's easy to fix once I realized that, but it had been that way for > > quite a while until then; I'd definitely support removing nullok on the > > default install. > > At least with Fedora 31 the root-Password is invalid by default, so I > guess it has been set to an empty password explicitely. > I'd classify this more as a bug in the puppet-scripts, as it sounds like > it touched security relevant stuff on installation, without admins being > aware of it. Yes, definitely. I'm pretty sure puppet didn't touch it, but they must have set the root password to an empty string somewhere on deployment -- I found it now I'm looking, they run 'passwd -d root' in the image on purpose apparently (don't ask me why...), and people who had done it left and turnover happened and new people weren't aware of it. I really just wanted to answer Adam's "does it really happen?" question - it does. Would the change have been enough to make whoever removed the root password not also re-add nullok ? I don't know, but it might have made them think about it twice and reconsider doing that. In an ideal world I think most people would consider passwordless login ok if you're on the console or a physical seat, and not ok if you come from ssh or some script running somewhere (cgi or whatever). Is that attainable ? -- Dominique ___ 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
Samuel Sieb wrote on Tue, Nov 26, 2019 at 01:38:51AM -0800: > >FWIW this has happened at an association I help at -- they had VMs with > >no root password set, and users created by puppet some of whom have > >sudo. > >They just expected no root password = no login possible, but it turns > >out 'su' just gave out a root shell with no password entered... > > "su" or "sudo"? Your scenario is unclear. both worked -- that is the point, su should not have worked here. They basically gave root access to everyone, regardless of sudoer settings. > >It's easy to fix once I realized that, but it had been that way for > >quite a while until then; I'd definitely support removing nullok on the > >default install. > > I don't think that this proposal would even help with that situation. This > is about user passwords, not root. How were those VMs created? Whatever the virtualization solution they use to create VMs, it just had an empty root password. I haven't checked what is used, I agree it also is a bug in their setup script (fixed since then), but there are plenty of scenarii where an empty root password makes sense for VMs/containers e.g. allow logins from the console by default, so I believe these will continue to do that. > If you're creating users with sudo access, how can you not expect to > have root be accessible? It sure would... I didn't say root user should be locked out to sudoers, just 'su' shouldn't work. An alternative might be to go back to securetty settings allowing console login but not non-interactive su or su over ssh. That does sound harder to setup/easier to miss, though, and if someone does set a root password up they would be doubly surprised... I don't think we can tell it to only look at securetty if the password was empty? -- Dominique ___ 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
Adam Williamson wrote on Mon, Nov 25, 2019 at 03:55:28PM -0800: > I gotta say +1 too. I don't buy that there's a significant 'hardening' > benefit worth all the effort mentioned in the Change *plus* the > additional consequences Kevin and Martin pointed out. At minimum I'd > like to see a much more convincing case that people are creating users > without passwords without understanding what they're doing. FWIW this has happened at an association I help at -- they had VMs with no root password set, and users created by puppet some of whom have sudo. They just expected no root password = no login possible, but it turns out 'su' just gave out a root shell with no password entered... It's easy to fix once I realized that, but it had been that way for quite a while until then; I'd definitely support removing nullok on the default install. -- Dominique ___ 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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]
Tomasz Torcz wrote on Mon, Aug 19, 2019 at 04:45:31PM +0200: > Actually, I don't think systemd touch the kernel default here. > See consoleblank= parameter > https://www.kernel.org/doc/html/v5.2/admin-guide/kernel-parameters.html > Some years ago it was set to be disabled by default, previously had some > other value. interesting, I had missed that it had been disabled in a4199f5eb8096d63[1] From: Tim Gardner Date: Wed, 22 Mar 2017 09:07:20 -0600 Subject: [PATCH] tty: Disable default console blanking interval BugLink: http://bugs.launchpad.net/bugs/869017 Console blanking is not enabling DPMS power saving (thereby negating any power-saving benefit), and is simply turning the screen content blank. This means that any crash output is invisible which is unhelpful on a server (virtual or otherwise). Furthermore, CRT burn in concerns should no longer govern the default case. Affected users could always set consoleblank on the kernel command line. - I guess I can take back my previous mail if this works with plymouth (not sure if it is strictly console ?), thank you for pointing that out. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4199f5eb8096d63828f7333fa45650a7b0a99ed -- Dominique ___ 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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]
Vitaly Zaitsev via devel wrote on Mon, Aug 19, 2019 at 09:31:33AM +0200: > On 19.08.2019 8:18, Joseph D. Wagner wrote: > > It is intended to display the same image on the screen continuously > > Yes. User must enter LUKS password to continue booting. System cannot be > booted until all drives from /etc/fstab will be unlocked and > successfully mounted. > > Screensaver cannot be started on such early stage, because OS is not > even loaded. He's not asking for pretty moving pictures, just blanking the screen is fine. the tty can do it just fine tunable in /sys/module/kernel/parameters/consoleblank so this really is a plymouth bug to me, it should have everything it needs for this embedded in the initrd to be able to do that before the OS fully loads. > > My issue is with displaying the same password prompt forever, causing > > screen burn-in. > > Do you have OLED monitor? Generic LCD/LED monitors does not suffer from > this issue. I never shut down my monitor for years and it works fine. LCD definitely has this issue - display the same image forever and the pixels will remember it / you will be left with an overlay of the previously still image. I'm not sure if the shiniest newest generations of LCD have the problem or not, but I've had multiple generations (latest being 5ish years old) and they all have the issue - for example the top/bottom bars of my window managers are burned in and the rare times I leave it on white-ish background I can still see them, because it's just always there and hardly ever changes. It's unnoticeable most of the time but definitely present, if the luks prompt stays up for a few weeks I'm sure it'll be visible. (It's probably fine overnight, but it can't hurt the electricity bill anyway) -- Dominique ___ 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: Removal of krb5-devel from "stable" F29 buidroot broke my package
Vít Ondruch wrote on Thu, May 16, 2019 at 08:28:45AM +0200: > >> This was removed on my request, triggered by this PR [1]. Nevertheless I > >> concur that this should happen just in Rawhide and never be backported > >> into stable releases. > > > > I don't see why this is a problem. Removing an unneeded build > > dependency from a package shouldn't affect anything else. That it did > > merely pointed out a bug in the other package where the build deps > > were incomplete. The problem is not the build dependency, you can get rid of it everywhere without any impact except for openssl itself. What is less transparent is the removal of an actual Require (two actually, zlib-devel is no longer pulled either) ; that can impact other packages and workflows. Someone installing openssl-devel could have expected it to pull krb5-devel and zlib-devel, now they need to install it explicitely separately for their own use as well, it's a change in user interface. > We lived with this "bug" for years. There is no reason to fix this bug > in stable release just to cause other bugs. And it was obvious it would > broke at least build of Ruby and now it is obvious it did broke not just > Ruby. It would be enough to have to solve this issues in Rawhide. > > Also, (not) pulling -devel package into build root might result in some > subtle bugs such as some part of package functionality disabled based on > build configuration, which might went unnoticed, until the package is > released. This is irresponsible. configure with feature autodetection is a PITA :/ -- Dominique ___ 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: Removal of krb5-devel from "stable" F29 buidroot broke my package
Michal Schorm wrote on Wed, May 15, 2019 at 05:14:23PM +0200: > Another possible cause came up my mind. > > Another package in the buildroot could have brought it as a > dependency, but does not bring it anymore ? Yeah, it used to come with openssl-devel, but got removed very recently: https://src.fedoraproject.org/rpms/openssl/c/7a654fc69c499b54f38543ca40f765fbaf9bdf84 -- Dominique ___ 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: Fixing Wireguard spec file
Joe Doss wrote on Mon, Feb 04, 2019 at 03:43:59PM +: > I know what akmods are and I don't have the bandwidth on my end to > switch to them with WireGuard coming in the 5.0 kernel. It's the second time I read wireguard would be coming in the 5.0 kernel here - what makes you folk say that? I certainly haven't seen anything to that extent lately and 5.0 is petty well under way, something as big a zinc likely won't make the cut this late. (as for akmods, it's packaged as such as well in rpmfusion, and that just works afaict) -- Dominique ___ 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: [Late] F30 System-Wide Change proposal: GCC9
Thank you two for the answer. YOUNG, MICHAEL A. wrote on Sat, Jan 26, 2019 at 12:53:18PM +: > The problem is your gcc build requires libgcc_s.so.1 which is the i386 > version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has > gone wrong in your build process. Eh, even after reading this I was doubting you, but that appears to be true... I guess asking rpm to add a couple of parenthesis after 32bit lib requires to at least look like 64bit libs require and not a simple file require would be asking too much, I never noticed it worked like this for 32bit libs :/ And rightly enough rpm -qp --requires of "my" gcc does have both libgcc_s.so.1 while fc30's libgcc.x86_64 only requires the x86_64 version; interesting given the src.rpm is the same. I've extracted the rpm and am not quite sure where the auto requires comes from, actually? I thought there was a script doing basically ldd on each executable (as described on the rpm website[1]), but nothing in the gcc package seems to require libgcc_s - what am I missing? I can't see anything obviously different between both build logs, either copr's[2] or koji's[3] (caution: files are 10MB (compressed) and 55MB respectively); the logs are too different to diff because of parallel build but at least lines containing "libgcc_s" are similar enough... [1] http://ftp.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html [2] https://copr-be.cloud.fedoraproject.org/results/martinetd/gcc9/fedora-29-x86_64/00850190-gcc/build.log.gz [3] https://kojipkgs.fedoraproject.org//packages/gcc/9.0.1/0.1.fc30/data/logs/x86_64/build.log Will look into how autodepends works a bit more, I'm curious why this is different. Thanks, -- Dominique ___ 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: [Late] F30 System-Wide Change proposal: GCC9
Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +: >> I think it would help having more people test things, and if there are >> build failures would help package owners fix these - it's not always >> obvious to fix a build failure by repeatedly submitting a new package to >> build, and everyone doesn't have a rawhide install around. > > That's what 'mock' is for. Sure, I guess that was a bad argument; as I said I'm not maintaining packages so I can't do that for the tools where I'd have liked to test the new gcc. > >It's probably just me being lazy, though; I'll figure something out if > >there is no such plan :) > > It's really easy to build it yourself: > https://gcc.gnu.org/wiki/InstallingGCC > > Installing binutils is also simple. Build binutils and install it > first, then build GCC to use the same prefix as you installed binutils > to, and the new GCC will automatically use the new GCC. Sure, building a new toolchain is easy; that's one of the many possibilities there are to test it. One could also just use `dnf --installroot=/tmp/foo --releasever=30 isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of these solutions take disk space and aren't systematically used when building stuff so it makes the testing a much more conscious action than just install some rpm and start using it. (yes, if I build a toolchain I could just add it to my PATH and it would just work as well; as I said, I'm just lazy.) Honestly, I also figured dropping the existing fc30 srpm for gcc followed by libtools and friends in a fc29 copr would be even simpler for everyone - copr really is a great tool to test new utility versions, and most of the time it just works. Turns out I wasn't correct here as for some reason gcc9 does build fine but I can't get it to install in a chroot, feel free to try my attempt if you can figure why: https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/ I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but trying to install gcc itself yields: Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none of the providers can be installed - libgcc-8.2.1-6.fc29.i686 has inferior architecture - libgcc-8.2.1-2.fc29.i686 has inferior architecture - cannot install both libgcc-8.2.1-6.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - cannot install both libgcc-8.2.1-2.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but none of the providers can be installed - cannot install the best candidate for the job while it really looks to me that it should be provided by the newer libgcc? # rpm -q --provides libgcc libgcc = 9.0.1-0.1.fc29 libgcc(x86-64) = 9.0.1-0.1.fc29 libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit) So, meh, I'll probably pick something else but I don't like not understanding why something doesn't work. -- Dominique ___ 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: [Late] F30 System-Wide Change proposal: GCC9
Hi, Ben Cotton wrote on Mon, Jan 21, 2019 at 03:16:56PM -0500: > == Detailed Description == > GCC 9 is currently in stage4 since January 7th, in prerelease state > with only regression bugfixes and documentation fixes allowed. The > release will happen probably in the middle of April. > rpms have been built are since today in rawhide. (writing "today" in a change page that stays on a wiki can be confusing if it gets updated later on) > * Other developers: First few days/weeks just voluntary rebuilds using > the new system gcc, if things fail, look at > http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, > if there is a gcc bug or suspected gcc bug, analyze and report. I don't have packages to rebuild (evil lurker here), but love to test on some programs I contribute to. Is there any plan to have a copr with gcc+libtools for fedora 29 or would that be too much extra work at this point? I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around. It's probably just me being lazy, though; I'll figure something out if there is no such plan :) Thanks, -- Dominique ___ 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: Reduce *-devel packages dependencies on other unneeded *-devel packages
Igor Gnatenko wrote on Sun, Aug 12, 2018 at 10:46:34PM +0200: > I've submitted > https://fedoraproject.org/wiki/Changes/Stop_pulling_dependencies_for_static_libraries > to improve the situation. I've posted on the other overlinking thread about pkgconfig and got corrected that Requires.private is not just for static linking. Short version: Requires = pulls in link and cflags (include paths etc) Requires.private = pulls in cflags and (libs if --static) Requires.internal = pulls in libs only with --static Long version can be found in this freedesktop bug: https://bugs.freedesktop.org/show_bug.cgi?id=105572 (We, fedora, use pkgconf that already has this implemented in 1.5.0 that is in f29/rawhide; the original freedesktop pkgconfig has not yet but would seem to agree on principle) So going by the same rule, Requires.private means headers from these libs can be used... and headers are in -devel packages, so they would need to be pulled as they currently are. -- Dominique Martinet ___ 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/AGIYXJYHNBOWARINON4LK2X3SU6CQQBE/
Re: F29 System Wide Change: Remove Excessive Linking
Rex Dieter wrote on Thu, Aug 02, 2018 at 10:14:13AM -0500: > Dominique Martinet wrote: > > In practice, `pkg-config --cflags foo` will only fetch cflags for > > dependencies listed in Requires, not Requires.private > > pkg-config --cflags foo > fetches cflags of Requires.private items in foo.pc for me. I see, that indeed appears to work on fedora, but not on the nixos box I tested (because having different include paths made testing easier there, but now I'm testing on fedora it looks OK there as you say) The difference between the two is that nixos is using the freedesktop pkg-config[1] while fedora uses pkgconf[2], so it would appear this isn't standard maybe? At which point the man page could use being more explicit about it... Oh, now I'm looking there's a (rather long) bug open about this here: https://bugs.freedesktop.org/show_bug.cgi?id=105572 [1] https://www.freedesktop.org/wiki/Software/pkg-config/ [2] https://github.com/pkgconf/pkgconf > I've patched many packages to use that feature, and haven't noticed any > breakage (so far). Well, packages can be fixed on the fedora side, but as upstream I wouldn't accept such a change until the freedesktop version behaves the same as I'd want to support users of either pkg-config version. Igor Gnatenko wrote on Thu, Aug 02, 2018 at 06:12:23PM +0200: > The real problem here is when you have complex frameworks like gtk. > > pkg-config basically will link you against gdk, gdk-pixbuf, gtk and a lot > of other stuff. But in practice, not every application need to link against > all of them. Yeah, complex frameworks are difficult with that, but upstream is actually dealing with it indirectly by switching to more modern build systems (for gtk, see gnome's MesonPorting[3] page) meson will automatically add --as-needed to the linker flags as appropriate (don't ask me what is appropriate), so we won't need to force it for them when they're done. Eventually some autotools/libtool macro could be added for other projects to use.. [3] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting -- Dominique Martinet ___ 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/MC4Z6HAQRVVHR7MOX5JEQ5FJ6WLLRFLJ/
Re: F29 System Wide Change: Remove Excessive Linking
Rex Dieter wrote on Thu, Aug 02, 2018 at 08:37:34AM -0500: > > Wearing a lib developer hat, I don't see how you can make a .pc that > > doesn't overlink if you provide something a bit entangled with other > > libs. > > The problem is that if your headers use any sub-lib type you need to add > > that lib in Requires: so that --cflags will pull that lib's include > > path; > > That's what Requires.private is for I'm aware of Requires.private, but that's not how I understand things currently work. man pc(5) says this for Requires and Requires.private: --- Requires Required dependencies that must be met for the package to be usable. All dependencies must be satisfied or the pkg-config implementation must not use the package. (optional; dependency list) Requires.private Required dependencies that must be met for the package to be usable for static linking. All dependencies must be satisfied or the pkg-config implementation must not use the package for static linking. (optional; dependency list) --- I'm not sure I see how that would be related to what is used for compiling and what is used for linking. In practice, `pkg-config --cflags foo` will only fetch cflags for dependencies listed in Requires, not Requires.private I haven't tested how autotools/libtool handle this but I doubt it's much different than invoking pkg-config manually, and at least meson will only add cflags for dependencies put in 'Requires' as I would have expected. Am I missing something? -- Dominique Martinet ___ 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/ULSIOZQG7E2RBY2OOEXPAPSCAZINRTUM/
Re: F29 System Wide Change: Remove Excessive Linking
Karel Zak wrote on Wed, Aug 01, 2018 at 01:17:29PM +0200: > Well, --as-needed is workaround and nothing else. The real problem is > mess in makefiles and .pc (pkg-config) files. > > It would be better to use --as-needed for testing purpose only, and > ask maintainers why the result with --as-needed is different. Wearing a lib developer hat, I don't see how you can make a .pc that doesn't overlink if you provide something a bit entangled with other libs. The problem is that if your headers use any sub-lib type you need to add that lib in Requires: so that --cflags will pull that lib's include path; and that will in turn add that sub-lib to the linked libs even if the program likely doesn't care about it (either because they didn't even use that part of your lib, or because all uses of that lib will be done through your own anyway so it wasn't required in the first place) This isn't obvious if you only support systems like fedora where most packages include dirs are standard to /usr/include but if you want to start supporting people working with dependencies in subdirs or distros like nixos that will have one include directory per dependency, you really need to put every external headers your depend on as 'Requires'. Unless you can tell pkgconfig "take all of these dependencies for --cflags but not for --libs" I do not see how this can be improved, and that's where --as-needed is helpful. It's not the ideal solution, but I don't have anything better right now, and pkg-config is by far not the worst solution to handling dependencies... -- Dominique Martinet ___ 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/WD7WBZSVKQVF2KWABZGBYQFFW6EIOMGR/
Re: LizardFS NFS Ganesha integration with no shared library available
Dominique Martinet wrote on Fri, Jan 19, 2018 at 09:04:46AM +0100: > In principle this should be fine, VLC does that too -- libvlc (the core) > is LGPL and vlc itself with the gui is GPL. (It occured to me that VLC isn't in fedora so that doesn't help much with regards to packaging, but I guess that'll still work out somehow, as the GPL FSAL is in its own package?) -- Dominique, optimistic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: LizardFS NFS Ganesha integration with no shared library available
Hi, Kaleb S. KEITHLEY wrote on Thu, Jan 18, 2018 at 01:16:35PM -0500: > The LizardFS FSAL is GPLv3. NFS-Ganesha is LGPLv3+. > > From a Fedora packaging standpoint is it acceptable to build a GPLv3 > plug-in for an otherwise LGPLv3+ binary? > > If the licenses were reversed, I'd be reasonably confident that that > combination is okay. > > What sayeth our "I'm not a lawyer but I play one on Fedora Devel mailing > list" legal beagles? In principle this should be fine, VLC does that too -- libvlc (the core) is LGPL and vlc itself with the gui is GPL. What matters is that proprietary stuff™ that want to use ganesha do not link with the GPL FSALs -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: bash style guide on Fedora?
Jun Aruga wrote on Mon, Aug 22, 2016 at 10:36:48AM -0400: > shellcheck? you mean "sh -n something.sh"? Yes, I will do it too :) He does mean shellcheck[1]. It's nice; doesn't do style check (e.g. trailing spaces or whatsnot) but catches quite a lot of errors. [1] https://www.shellcheck.net/ -- Dominique Martinet -- 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
Hi, Lennart Poettering wrote on Wed, Jun 01, 2016 at 03:48:04PM +0200: > Again, this isn't just work-arounds around broken programs. It's a > security thing. It's privileged code (logind, PID 1) that enforces a > clear life-cycle on unprivileged programs. > > Any scheme that relies on unprivileged programs "being nice" doesn't > fix the inherent security problem: after logout a user should not be > able consume further runtime resources on the system, regardless if he > does that because of a bug or on purpose. I actually don't understand this as being security, at least with the current default values where a user can set lingering for themselves and run explicitely separate sessions; anything they could do can still be done and it's just more work. If a sysadmin wants to "secure" their environment (and it definitely does make sense in some use cases, like shared stations), they will also want to disable lingering, so they'll need to change something anyway to disable that possibility; so the default doesn't suit them. If a sysadmin wants their users to be "least surprised", they will very probably want to change the new default back off, so they need to do something too. All is left is single user workstations that may be happy with the new default value, but my personal narrow-minded opinion thinks that represents less... While I'm actually writing a mail I might address a few more points: - I definitely have more programs than just screen & tmux I want to keep running, although most could be started with nohup/systemd-run, I usually don't bother (&/^Z, bg and disown is how I usually do it afterwards if I notice) - Only screen/tmux come back all the time, but there are other alternatives - neercs, dtach to name two I know by name and occasionally use. I'm sure there are more. I'm not sure they will all want to adapt, like tmux that seems to refuse right now, and it will be a pain to manage downstream... - I'll agree I mostly lock my screen on my own station if I want things to keep running, there however are particular cases where I need to close firefox/crap running and I will logout to close the X cruft; I'd still expect things like my fetchmail loop to run then (it's in a screen) This mainly happens on friday afternoons when I have mettings in another building and will log in from a shared post there, and the home directory is shared so my main station needs some cleanup (and logging out cleans all I want cleaned right now, but it doesn't have the new user session dbus system yet... Although I guess I don't care if that keeps running.) - FWIW, I'm also of the opinion there are less non-X things that I want killed than things I want to stay (assuming things connected to X will die anyway when the session closes); so if we're going through the trouble to make an interface so programs can explicitely ask to not be killed, I don't see why these programs that we want killed (the user dbus, pulse, gnome calendar) could not just voluntarily ask "please kill me when the session is closed". I think both solutions make sense, and if we want to allow both usages doing both might actually be the way forward that will please both side: admins can chose which camp they're in through a simple switch AND their relogging is not broken in either case. -- Dominique -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
systemd 230 change - KillUserProcesses defaults to yes
Hi, Just noticed this change on rawhide... https://github.com/systemd/systemd/blob/master/NEWS#L29 * systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout. While the user is logged in at least once, user@.service is running, and any service that should survive the end of any individual login session can be started at a user service or scope using systemd-run. systemd-run(1) man page has been extended with an example which shows how to run screen in a scope unit underneath user@.service. The same command works for tmux. After the user logs out of all sessions, user@.service will be terminated too, by default, unless the user has "lingering" enabled. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them. See loginctl(1) for details. The default polkit policy was modified to allow users to set lingering for themselves without authentication. Previous defaults can be restored at compile time by the --without-kill-user-processes option to "configure". So, now, I've read this and I could possibly remember to use systemd-run or to set myself as lingering... Except that I don't want to have to go through the pain of remembering to either change the system config on all my servers or always starting stuff with systemd-run if it's a bit long and I think I might want to ^Z/bg/disown it to let it finish. Thinking further when my users get that update I don't see myself telling them to do that when they want to start a screen/tmux/nohup-job, users do not read every update changelogs (tbh I don't either unless there's a problem); and they probably wouldn't think of systemd if they ever get that particular issue.. heck they probably don't even know what systemd and logind are (even if yes, they are "advanced" enough to ssh into other servers to run *long* tasks that must continue overnight/when the user logs out ; it doesn't mean they know what they're using exactly) Sure, this change will work for the whole probably targetted audience of simple desktop users on shared workstations where we probably want to kill lingering processes; but how much is that compared to servers ? I know that if this gets through I will have to change the system default on all my servers... And while the big batches of thousands of compute nodes are automated there's still quite a few places to update, especially since this will be the first time we need to change logind.conf so it's not just adding a line to a file already propagated Anyway, I don't really want to start (yet) a(nother) troll on systemd, I appreciate it's also brought good things; I'd just like the default values to be sane for most of the users. I did not see any discussion about this particular setting in the systemd-devel mailing list so I have hope that it is still open to change, but I'd rather start with a community where there are more admins who will likely agree that this change will do more harm than good. Even if nothing comes out of it, at least more people will be aware of the issue and will be able to prepare to avoid most of the chaos that will come if this stays like this... Thanks for reading, -- Dominique Martinet -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora lists From munging/DMARC (Was: audio problems)
gil wrote on Mon, May 23, 2016 at 04:10:26PM +0200: > i dont care . this is only a your businnes > > please, don sent me another email with the same contents I don't know, but if you're asking for help you might want to watch your spelling and your attitude. I have no idea what your problem is, but I sure don't feel like looking at it now... > >Actually, gil, it is not just him. Every message you send goes into > >my spam folder, too. Gmail is marking all of your emails as spam, for > >every gmail user. Richard Hughes noted this a couple of months ago: > > > >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5XYYEECCDF6KVN5XPNSWQCRV4AXBKTWF/ > > > >I believe this explains the problem: > > > >https://productforums.google.com/forum/#!topic/gmail/khxUtu5iDco The problem Jerry James pointed at is actually pointed at libero.it asking for strict host checking and gmail actually implementing it, as well as fedora mailing list not handling DMARC properly (which isn't really possible, but list softwares make do by rewriting the From field nowadays) Gmail is technically right by dropping your mails to spam, because your email provider asks it to. There are a few others doing it, but I guess we don't have many yahoo subscriber on this list ;) The question is, should fedora's lists be configured to rewrite the from ? I'm pretty sure mailman 3.1 can handle it, if we want it to. I haven't seen any discussion about this, has it ever been brought up? Do the admins have any opinion on it? (I don't care, I don't use gmail and $work doesn't enforce spf strictly at the moment) -- Dominique Martinet -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: wayland in rawhide
Hi, Tom Hughes wrote on Thu, Nov 12, 2015 at 02:22:35PM +: > I think the bug explains fairly well why that is a bad idea. Sorry to butt in, but no, it explains why a handful of people think it is a bad idea, with another saying it's a good one. > It's not so much on the paste side, where having middle click paste whatever > was in the clipboard side would not be a major problem. > > It's more that you probably wouldn't want your clipboard buffer overwritten > whenever you selected some text. > > Currently X has two (well three, but let's ignore the secondary selection) > buffers. One for primary selection that is overwritten when you select and > pasted with middle click and one for the clipboard selection that is > overwritten on Ctrl+C and pasted on Ctrl+V. It really didn't take me long after first using X-based interfaces to make use of the primary buffer, and I've pretty much never used ^C/^V ever since. I only ever touch the mouse when I need to select something to copy/paste it, so I'm not going to try to pretend I understand people saying they don't want this behavior -- but likewise please don't say that the "selection copies" behavior is bad for everyone. It really isn't something I (and seemingly many others) want to lose, ever. I also don't think multiple buffers is a good idea, I've always found that confusing in X and this has been said in the bz as well, so we really should try to keep a single buffer too. If we can't get to a compromise just make it an option and everyone will be happy (except maybe for the nagging of what should be the default, but people can just make a poll for that -- I personally don't care as long as it's possible without having to hack code and rebuild) -- Dominique Martinet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
