Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
On 12/31/23 18:27, Dominique Martinet wrote: 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) Some programs DO search $PATH because they use execlp() or execvp() or execvpe(). Example of /usr/bin/rpm searching for "sh": = [edited for clarity] $ echo $PATH /A:/B:/usr/local/bin:/usr/bin: ... $ strace -f -e trace=newfstatat rpm --install -p zip-3.0-37.fc38.src.rpm 19792 newfstatat(AT_FDCWD, "/A/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/B/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/usr/local/bin/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/usr/bin/sh", ...}, 0) = 0 = That's with rpm-4.18.2-1.fc38.x86_64 and glibc-2.37-16.fc38.x86_64. -- ___ 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)
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 Do not add directories to $PATH. Any executable which may benefit significantly from micro-architectural enhancements should use the IFUNC mechanism explicitly. If the developer of the executable cannot be bothered to use IFUNC, then the uses of the executable should not slow down EVERY shell path search in the entire session. Glibc already uses IFUNC for many mem*() and str*() functions (such as memcpy, strlen, etc.), which covers the vast majority of "random" cases which usually benefit from such microarchitecture enhancements. Fedora binaries for the AMD64 architecture are compiled with code-generation flags that support almost all CPU variants. But newer generations of processors gained additional instructions that may be used to generate faster code. A vendor-independent x86-64 psABI supplement defines four "microachitecture levels": `x86-64-v1` (the baseline, our code targets this), `x86-64-v2` (+`SSE3`, CentoOS targets this), `x86-64-v3` (+`AVX`[edit: and + 'AVX2']), `x86-64-v4` (+`AVX512`) [1]. Please note the edit: -v3 includes both AVX and AVX2. There are x86_64 CPUs which have AVX (128-bit xmm registers) but not AVX2 (256-bit ymm registers): for instance, AMD A10-7890K (cpu family 21, model 56: 4 CPU cores, 8 graphics cores), which was current in 2019. Why is there no corresponding microarchitecure level? In many cases AVX2 provides significant benefit over AVX, without the monstrosity of AVX512 (512-bit zmm registers) which requires vastly more chip area and power consumption. -- ___ 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: Can we assume all chroots follow UsrMove?
Is it safe to assume that this symbolic link [/lib64 -> usr/lib64] exists in all chroots? This includes the initial ramdisk, recovery environments, and chroots for confining services. It is unsafe unless prominently documented in the places that are likely to be seen by affected developers, now and especially *in the future*: man glibc, info glibc, man chroot, info chroot, man docker, man virtmgr, etc. Such a change has aspects of being a System-Wide Change for Fedora. For instance, I have a recipe for an "embedded" Docker that will have to add the symlink. -- ___ 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: Linker Error on Security Issues (System-Wide)
Also, under what circumstances would thread local storage segments be executable? When the assembly-language source contains a statement such as .section my_section_name,"atx" where the "atx" are the attributes of the ElfXX_Section. See the key to the abbreviations in the output of readelf --sections a.elf Namely: - Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), D (mbind), l (large), p (processor specific) - ___ 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: Analysis of the overhead of frame pointers on gcc compiles
On 10/20/23 13:23, Richard W.M. Jones wrote: Today I've read (twice) that the overhead of frame pointers on the runtime of the compiler, GCC, is 10%. This number is nonsense. The actual overhead is 1%, and I have done the tests that show this. Both the 1% and the 10% results can be valid. In particular, I have seen variance of up to 15% in CPU time for consecutive runs of the same CPU- saturating task on the SAME physical machine, due to the lack in Linux of cache coloring considerations when allocating physical page frames for virtual memory, and the resulting random affects on the performance of the data cache. See https://en.wikipedia.org/wiki/Cache_coloring : A virtual memory subsystem that lacks cache coloring is less deterministic with regards to cache performance, as differences in page allocation from one program run to the next can lead to large differences in program performance Page coloring is employed in operating systems such as Solaris, FreeBSD, NetBSD and Windows NT. [Note the conspicuous absence of Linux from that list.] Other sources of real-time contention should be considered, too. Queuing delays in a file system due to encryption, journaling, block allocation and placement, etc., might mask real-time measurement of CPU+cache. Any potentially-competing activity such as graphical desktop environment, use of network or video or audio, or crontab or tasks controlled by systemd, should be minimized. It may be best to measure when the machine has been booted to single-user mode. Because of the impact of data cache performance, it is important to state the CPU, RAM, and cache characteristics when measuring performance. Such as: the beginning of /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz stepping: 3 microcode : 0xf0 cpu MHz : 3418.725 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 On Intel x86_64 Core CPUs with hyperthreading, then the two threads per core compete for the 256KiB L2 cache per core. On x86_64, then the CPUID instruction reports cache organization, which can be interpreted, such as: 22 GenuineIntel TLB/Cache: eax=76036301 ebx=00f0b6ff ecx= edx=00c3 1 repeat for more info 63 03 dTLB: 4 KByte pages, 4-way, 64 entries 76 iTLB: 2M/4M pages, fully associative, 8 entries ff Use CPUID leaf 4 b6 f0 64-byte prefetching c3 Cache: eax=1c004121 ebx=01c0003f ecx=003f edx= 1 Data Cache 1 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 2 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 8 ways of associativity 64 number of sets 32768 total size 0 WBINVD/INVD acts on this level only 0 cache includes lower levels 0 complex cache indexing Cache: eax=1c004122 ebx=01c0003f ecx=003f edx= 2 Instruction Cache 1 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 2 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 8 ways of associativity 64 number of sets 32768 total size 0 WBINVD/INVD acts on this level only 0 cache includes lower levels 0 complex cache indexing Cache: eax=1c004143 ebx=00c0003f ecx=03ff edx= 3 Unified Cache 2 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 2 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 4 ways of associativity 1024 number of sets 262144 total size 0 WBINVD/INVD acts on this level only 0 cache includes lower levels 0 complex cache indexing Cache: eax=1c03c163 ebx=02c0003f ecx=1fff edx=0006 3 Unified Cache 3 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 16 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 12 ways of associativity 8192 number of sets 6291456 total size 0 WBINVD/INVD acts on this level only 1 cache includes lower levels 1 complex cache indexing Cache: eax= ebx= ecx= edx= ___ 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: SPDX Statistics - Munich Agreement edition
New projection when we will be finished is 2024-08-06. Pure linear approximation. Especially because texlive was such an outlier, then any linear estimate should state the starting and ending dates that were used for the projection. Similar to financial statistics, it might be better to use a moving average over a constant trailing duration (such as previous 90 days), perhaps with adjustment due to texlive. ___ 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: mame validation time takes forever on rawhide/aarch64
mame package uses mame -validate as %check step. It has recently started
to cause problems on rawhide/aarch64:
- 0.259 build is stuck since ca. 1600 UTC yesterday [2]
I managed to reproduce this on the aarch64 machine in mock. Validation seems to
get stuck right away at:
(gdb) bt
#0 0xb5bddb08 in ___ZN4bgfx12VertexLayoutC1Ev_bti_veneer ()
#1 0xf5870b2c in __libc_start_main_impl () from /lib64/libc.so.6
#2 0xaef01570 in _start ()
One question: the binary in /builddir/build/BUILD still has symbols in, correct?
The backtrace above does not contain a filename or line number for frame #0,
so it looks like the app (or a library that it uses) was compiled without "-g",
or the debug information has been stripped or separated after building.
Of course the app does contain some global symbol information
that is required for run-time dynamic linking ("readelf --symbols
--use-dynamic ./my_app"). It is remarkable that the symbol
for frame #0 '___ZN4bgfx12VertexLayoutC1Ev_bti_veneer'
begins with three underscores instead of only 1.
___
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: zlib-ng as a compat replacement for zlib
On 8/6/23 02:00, Peter Robinson wrote: We tried to pull some of the optimisations in some time ago to the Fedora package and they caused some issues with compatibility. Please provide *any* documentation! Such as: the dates the work was performed, the participants, the nature of the issues, the "other side" of the problem cases (the other packages, the use cases, etc.) ___ 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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)
On 6/27/23 02:00, Miro Hrončok wrote:
On 26. 06. 23 20:24, Fabio Valentini wrote:
On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok wrote:
(snip)
---
The current problem with Python without tzdata is:
===
>>> from zoneinfo import ZoneInfo
>>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key
Europe/Prague'
===
Not that ZoneInfo("UTC") also fails:
===
>>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
===
So we would need to patch Python to detect missing tzdata and report something
like:
ZoneInfoNotInstalledError: 'No time zone information installed on the system,
you can only use UTC'
We would also need to ensure UTC work even without tzdata installed.
I would be reluctant to carry this as a downstream-only patch. And the upstream
window for changes like this has already closed for Python 3.12.
Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Yes. That's why it is Required and not Recommended.
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.
Either that or adapt their code to fail in a reasonable way. Both sound quite
unreasonable to me.
The case with LANG seems analogous. If LANG is unset, then any software
should use the default LANG=C, and should work acceptably well.
If TZ is unset (or there is no other indication
of which timezone to use, or if the timezone data is unavailable)
then any software should use UTC, and should work acceptably well.
(In formal scientific work then UTC *is* the default timezone.)
For either unset LANG or missing timezone info, it is optional
for an application to emit a polite informative message *once* on stderr.
In particular, the zoneinfo module should handle all the details
so that individual applications need not bother.
.
___
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: more distinct default bash prompt?
FWIW Haiku uses bash and has a prompt which changes colour (green/red) depending on whether the status code of the last command was good or bad. I found this surprisingly useful. They use: \[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m"; fi`\]\w[\e[0m\]> Warning: This is intrusive because reading the status code via "$?" resets it to zero: $ false $ echo $? 1 $ echo $? 0 $ So a follow-on script cannot tell whether the command just before the color-changing prompt succeeded or failed. ___ 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
After today's "dnf5 upgrade" F38 beta does not boot
After this morning's daily "dnf5 upgrade", my system does not boot: not F38 beta, not the 0-rescue entry, not the Debian systems installed in separate partitions. The console message is error: ../../grub-core/fs/fshelp.c:257 file `/boot/vmlinuz-6.2.6-300.fc38.x86_64 not found error: ../../grub-core/loader/i386/efi/linux.c:258:you need to load the kernel first Press any key to continue... and then after 10 seconds or so it reverts to the screen to choose the system to boot. ___ 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-legal-list] Update on SPDX license id adoption in Fedora
On 2/20/23 17:51, Richard Fontana wrote: If anyone has suggestions for what form such documentation could take that would be helpful. :) Presentation: a .ods spreadsheet with one row per identifiable hunk of software, with columns: name, version, release, architecture(s), minimum date, maximum date, SPDX license(s) name-and-version (perhaps one column for each applicable license.) Then the user can search, sort, select, print, etc. The spreadsheet should be additive (cumulative) since its inception; the user easily can select any combination of desired versions, releases, etc. ___ 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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
On 2023-02-18 at 03:08 UTC, Gordon Messmer wrote: The point where compatibility becomes an issue is the use of old packages or third-party packages that don't Provide versioned virtual packages to fulfill the requirements of Fedora packages. Because Fedora package dependencies must be fulfilled entirely by other Fedora packages as a matter of policy, this potential incompatibility really only affects packages that are intended to replace a Fedora package. Those would need to be built with the improved ELF dependency generator in order to satisfy the requirements of Fedora packages. About once per year I find it necessary or convenient to use /usr/bin/alien (provided by Fedora package alien-8.95-18.fc36.noarch, for instance) to import one or more Debian .deb package into Fedora as .rpm. I don't see how this could work with the proposed change, unless 'alien' is significantly enhanced. ___ 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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator
On 2023-02-18 @ 03:03 UTC, Gordon Messmer wrote:
use libtool-style versions collected from library filenames to provide
versioned library requirements
How does this affect the output from "readelf --symbols --version-info foo.o"
which displays symbols and symbol versions? How much more space is required
in an ET_REL file? Suppose there is an .rpm package
"hello_world-1.0.f40.x86_64.rpm"
for printf("Hello world!\n") which delivers an ET_DYN main program and an
ET_DYN .so
shared library. Please show explicitly the literal differences in
corresponding files
(.spec, .rpm, .so, a.elf, .o) before and after implementing the proposed
improvement.
Packages built on a system where the _elf_require_fallback_versions macro was
enabled would not be usable on a system that was built without the
_elf_provide_fallback_versions macro enabled.
Packages built on a system without the _elf_provide_fallback_versions could not be used on Fedora as replacements or alternatives to Fedora dependencies, after the _elf_require_fallback_versions macro was enabled in Fedora.
That sounds to me like "not compatible in any way." That is, any attempt at
using
both old packages and new packages together, will fail. I don't like that.
That means that nobody can interact with Fedora packages unless they adopt
the proposed change; and that is very unfriendly.
___
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: s390x emulation build woes
On 2/10/23 19:57, Richard Shaw wrote: So I know the s390x builders are down but I have an active BZ for tests failing with s390x so I figured what the heck, maybe doing a local mocbuild attempt using qemu could help here like it did with aarch64. Well at first everything seemed to be working as normal but all of the repo package GPG checks failed. Almost certainly an endian problem (or two, or three). x390x is big endian; almost everything else is little ehdian. Run the self tests of each crypto piece using the same emulator. ___ 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: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()
On 1/17/23 14:37, Björn Persson wrote: So as things stand, these rebuilds need to be done by a human who knows the dependency graph. Requiring "a human who knows the dependency graph" is *severely* broken. There should be a shell script which computes an acceptable order from the old installed version, and outputs the order for examination and modification. Probably the script involves ldd, "readelf --dynamic", and tsort. For new dependencies the script may need to be re-run during the builds. ___ 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: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On 12/21/22 13:49, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients X server implementations (e.g. Xorg and Xwayland) allow clients with an endianess different to that of the server to connect. Protocol messages to and from these clients are byte-swapped by the X server. However, the code in the X server that does this is virtually untested, providing a large attack surface for malicious clients. There is a technological solution which eradicates the byte-swapped attack surface. All existing byte-swapping bugs (known and unknown) are fixed, and all future byte-swapping bugs are prevented. In C++, re-code each 'struct' by using a typedef for each member that can suffer byte-swapping. Create a template for each struct containing such members, where the typedefs for members are template parameters for the templated struct. Create a template for each function which uses such structs, again with the typedefs as template parameters (possibly subsumed inside other templated objects.) When the X server accepts a connection from a client of different endian-ness, then automatic template instantiation and matching by the C++ compiler will invoke the correct top-level function(s), which will invoke the correct lower-level functions. An example is https://github.com/upx/upx/blob/devel/src/p_mach.h and p_mach.cpp, which handles both width (32 vs 64) and endian-ness for processing any Mach-O executable by the UPX program compressor running on any machine (same or different width and endian-ness). A years-earlier "by-hand" example of related coding in plain-C is scripts/recordmcount.c in the source code for Linux kernel. ___ 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: memtest86plus v6.00
... it [memtest.efi] can be accessed by a trivial two line command. Please write the literal two-line command here. It takes too long to search documentation or invent the code, and the various imagined versions might have bugs. ___ 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: Fwd: F36 BTRFS crashed
Linux Fedora 5.17.5-300.fc36.x86_64 ... btrfs-progs v5.16.2 Label: 'fedora-LIVE' uuid: ... Total device 1 FS size 5.1 GB devid 1 39GB used 6.52 GB path /dev/sda2 unable to mount device to get output Any help would be appreciated to recover the data. Use /usr/bin/nc to copy the entire contents of /dev/sda2 to a file on some non-virtual system that is running some not-so-bleeding-edge OS such as Fedora 35 (etc.) Use "-o loop" to mount the file as a filesystem, then extract what you wish. ___ 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: hardened malloc is big and slow
On 9/5/22 19:45, Daniel Micay wrote: On Wed, Aug 31, 2022 at 10:19:51AM -0700, John Reiser wrote: Bottom line opinion: hardened_malloc ... costs too much. Attempting to be constructive: Psychologically, I might be willing to pay a "security tax" of something like 17%, partly on the basis of similarity to the VAT rate (Value Added Tax) in some parts of the developed world. The comparison is being done incorrectly. Since hardened_malloc builds both a lightweight and heavyweight library by default, That claim is false. The Makefile for commit 72fb3576f568481a03076c62df37984f96bfdfeb on Tue Aug 16 07:47:26 2022 -0400 (which is the HEAD of the trunk) begins = VARIANT := default ifneq ($(VARIANT),) CONFIG_FILE := config/$(VARIANT).mk include config/$(VARIANT).mk endif ifeq ($(VARIANT),default) SUFFIX := else SUFFIX := -$(VARIANT) endif OUT := out$(SUFFIX) = and builds only one library, namely $OUT/libhardened_malloc$SUFFIX.so which for the case of "no options specified" is out/libhardened_malloc.so . If would be better for external perception if the name "libhardened_malloc.so" were changed to something like "libhardened_malloc-strong.so". Having both -strong and -light versions built every time would highlight the difference, and force the user to decide, and encourage the analysis that is required to make an informed choice. and since I already explained this and that the lightweight library still has optional security features enabled, it doesn't seem to have been done in good faith. My previous posts where I provided both concise and detailed information explaining differences and the approach were ignored. Why is that? As I said previously, hardened_malloc has a baseline very hardened allocator design. It also has entirely optional, expensive security features layered on top of that. I explained in detail that some of those features have a memory cost. Slab allocation canaries have a small memory cost and slab allocation quarantines have a very large memory cost especially with the default configuration. Those expensive optional features each have an added performance cost too. Measuring with 100% of the expensive optional features enabled and trying to portray the performance of the allocator solely based on that is simply incredibly misleading and disregards all of my previous posts in the thread. I measured the result of building and using with the default options. Unpack the source, use "as-is" with no adjustment, no tweaking, no tuning. If the default source is not appropriate to use as widely as implied by the name "malloc" (with no prefix and no suffix on the subroutine name), then the package is not suitable for general use. Say so immediately at the beginning of the README.md: "This software is not suitable for widespread general use, unless adjusted according to the actual use cases." hardened_malloc builds both a lightweight and heavyweight library by default. The lightweight library still has 2 of the optional security features enabled. None of the optional security features is provided by glibc malloc and if you want to compare the baseline performance then none of those should be enabled for a baseline comparison. Take the light configuration, disable slab allocation canaries and full zero-on-free, and there you go. I reported an end-to-end measurement and comparison based on data. Where have you reported actual end-to-end measurements and comparisons? [[snip]] ___ 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: hardened malloc is big and slow
On 9/5/22 21:02, Daniel Micay via devel wrote: On Wed, Aug 31, 2022 at 05:59:42PM +0200, Pablo Mendez Hernandez wrote: Adding Daniel for awareness. Why was the heavyweight rather than lightweight configuration used? Why compare with all the expensive optional security features enabled? The default configuration was used. " ...; make" produces out/libhardened_malloc.so and no other shared library. Even the lightweight configuration has 2 of the optional security features enabled: slab canaries and full zero-on-free. Both of those should be disabled to measure the baseline performance. Using the heavyweight configuration means having large slab allocation quarantines and not just zero-on-free but checking that data is still zeroed on allocation (which more than doubles the cost), slot randomization and multiple other features. It just doesn't make sense to turn security up to 11 with optional features and then present that as if it's the performance offered. The use case is a builder and distributor of software packages to a large, diverse audience. There is concern about the possibility of malware attacking the build process, a "supply-chain attack". Of course there are other protections already in place, but the possibility of better protection is reasonable to investigate. A network search revealed a dearth of end-to-end performance measurements, and/or comparisons based on actual data. I'm here to provide clarifications about my project and to counter incorrect beliefs about it. I don't think it makes much sense for Fedora to use it as a default allocator but the claims being made about memory usage and performance are very wrong. I already responded and provided both concise and detailed explanations. I don't know what these nonsense measurements completely disregarding all that are meant to demonstrate. I reported an actual measurement and comparison of two allocators using commonly-available tools and a documented, repeatable methodology. The choice of which two allocators is reasonable for the use case. > [[snip]] ___ 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: hardened malloc is big and slow
Bottom line opinion: hardened_malloc ... costs too much. Attempting to be constructive: Psychologically, I might be willing to pay a "security tax" of something like 17%, partly on the basis of similarity to the VAT rate (Value Added Tax) in some parts of the developed world. ___ 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
hardened malloc is big and slow
Here is one end-to-end performance measurement of using hardened_malloc. sudo sh -c "echo 1 >/proc/sys/vm/drop_caches" /usr/bin/time rpmbuild -bc kernel-5.15.11-100.fc34.spec >rpmbuild.out 2>&1 For glibc, the result was 19274.30user 2522.87system 1:49:06elapsed 332%CPU (0avgtext+0avgdata 3389052maxresident)k 148504inputs+217900040outputs (18221major+1005715216minor)pagefaults 0swaps For the same task, but preceded by export LD_PRELOAD=/usr/lib64/libhardened_malloc.so the result was 26108.73user 4805.55system 2:22:43elapsed 360%CPU (0avgtext+0avgdata 1881564maxresident)k 586704inputs+217900504outputs (31876major+1848825755minor)pagefaults 0swaps So compared to glibc-2.33-21.fc34.x86_64, hardened_malloc used 1.3 times as much wall clock (8563 / 6536 in seconds) 1.35 times as much user CPU (26108 / 19274) 1.9 times as much sys CPU ( 4805 / 2522). The environment was a physical machine running fedora 5.17.12-100.fc34.x86_64: Intel Core i5-6500 @3.2GHz (4 CPU, 4 cores, 256kB L2 cache per core, 6MB L3 shared) 32GB DDR4 RAM /usr ext4 on SSD, /data ext4 on 4TB spinning commodity hard drive In the .spec, I changed to: %define make_opts -j4 so that much of the compiling ran 4 jobs in parallel. /usr/bin/top showed minimal use of swapspace: 4MB, hardened_malloc required (as documented in its README.md): - /etc/sysctl.d/hardened_malloc.conf # (Fedora 5.17.12) default is 65530 (2**16 - 6), # libhardened_malloc suggests 1048576 (2**20) # we choose 1048570 (2**20 - 6) vm.max_map_count = 1048570 - else the job crashed: BTF .btf.vmlinux.bin.o memory exhausted The libhardened_malloc source code version was: commit 72fb3576f568481a03076c62df37984f96bfdfeb of Tue Aug 16 07:47:26 2022 -0400 Bottom line opinion: hardened_malloc's added security against exploit by malware costs too much. I will not choose hardened_malloc for this task. ___ 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: fltk rebuild issue: uname -i "unknown"?
... there can't be that many people developing for both at the same time on one machine natively (builds in mock would still work fine). I use only one machine (a x86_64) and no 'mock' to develop the same software for both x86_64 and i686. For i686 I start with "dnf install glibc-devel.i686" and "export CC=gcc -m32". I also replace "$(uname -m)" with "$TARGET_ARCH" after setting "export TARGET_ARCH=...". ___ 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: glibc 2.36 and DT_HASH (preserving it for F37+)
On 8/21/22 10:14, Demi Marie Obenour wrote: On 8/21/22 12:51, John Reiser wrote: it's clear there's a documentation problem [with DT_GNU_HASH] Partly due to lack of documentation, already I have seen "abuses" of the DT_GNU_HASH format. In particular, some versions of Rust and/or musl run-times use (0 == nbucket) to mean something like "there is no hash table information" but do not specify all the implications for the run-time symbol table. Other versions use (1 == nbucket && 0 == buckets[0] && 1 == n_bitmask && 0 == bitmask[0]) for a similar purpose. Similarly, Rust and Android can trim "unused" zero entries from the end of _array[nbucket], even though buckets[] and hash_array[] should be parallel. Please report a bug at https://github.com/rust-lang/rust/issues. https://github.com/rust-lang/rust/issues/100859 "abuse of DT_GNU_HASH descriptor" ___ 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: glibc 2.36 and DT_HASH (preserving it for F37+)
it's clear there's a documentation problem [with DT_GNU_HASH] Partly due to lack of documentation, already I have seen "abuses" of the DT_GNU_HASH format. In particular, some versions of Rust and/or musl run-times use (0 == nbucket) to mean something like "there is no hash table information" but do not specify all the implications for the run-time symbol table. Other versions use (1 == nbucket && 0 == buckets[0] && 1 == n_bitmask && 0 == bitmask[0]) for a similar purpose. Similarly, Rust and Android can trim "unused" zero entries from the end of _array[nbucket], even though buckets[] and hash_array[] should be parallel. ___ 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: rpmbuild is very slow with large files
On 7/11/22 Marius Schwarz wrote:
I have just create(d/ not finished yet, started 15 minutes ago) a ~2.5 GB rpm
and found, that rpmbuild is an extrem bottleneck.
IMHO, this is caused by a fileread function which reads files in 32k blocks,
which is very slow and extrem IO intensive. The result is a task running at 1
core at 100% perma. With changes to larger chunks, we can speed up so many
build tasks on the farm.
Multicore use would also be helpful i.e. while packing the files.
Any counter-arguments ?
If you give the complete package name and URL of the repo,
then more persons may be likely to help investigate.
Specifying a reproducible example is always good.
If you know "strace -p $PID" then please learn "perf record -p $PID".
If the size of the package is in gigabytes, then upstream bears some
responsibility for investigating and documenting the use of
data compression with the package. What does upstream say?
In the few samples of "read(" from the output of strace,
there I see text similar to JSON or XML tags. A large dataset
that contains zillions of repetitions of only a few dozen
tags, creates O(n**2) work for deflation. Finding many matches
of any particular tag is quick, but which match can be extended
the most, considering the exact context of prefixes and suffixes?
A "looser" compression such as "gzip -3" or lzo might be
much faster with only slightly larger output.
A software implementation of a hardware technique such as WK,
or even "ancient" modem compression MNP5 or MNP10,
might also be a good choice.
___
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 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
Do you really need more than five or so *physical* stack frames during profiling, to figure out what is going on? Graphs generated from DWARF unwinding typically will show logical stack frames from inlining, too, and appear much deeper. Yes, more than a couple times per year I encounter cases that require 10 to 12 physical stack frames in order to understand what is happening. The current (deepest) level can more than 5 or so frames from the nearest level that has meaning for the application programmer. This happens particularly often in Boost, other C++ object-oriented programming (std::string and relatives have several physical levels that tend to obscure) and python (or any interpreter with a deeply-recursive implementation.) ___ 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: Still confused about PIE/PIC and default build flags
On 6/13/22 04:59, Richard Shaw wrote: On Sun, Jun 12, 2022 at 9:23 PM John Reiser wrote: Please post a recipe to reproduce those complaints: the .spec file (or URL), other context for building, etc. Sorry, I was hoping it was obvious. I'm only building in locally right now so I have uploaded it here: https://hobbes1069.fedorapeople.org/emqx-nanomq.spec <https://hobbes1069.fedorapeople.org/emqx-nanomq.spec> There still are missing pieces. From that .spec file: # Deal with git submodules not in the archive # git clone --recurse-submodules https://github.com/emqx/nanomq.git # from extern project subdirs # git archive -o ../../../l8w8jwt.tar.gz HEAD Source1:l8w8jwt.tar.gz Source2:nng-fork.tar.gz Patch0: nanomq.patch Where is nanomq.patch ? And the path ../../../l8w8jwt.tar points to a directory which is outside of the build environment. It would be much easier to help, if the _complete_ information was specified. Present the issue as a bug report, including the build environment (Fedora 36? Rawhide? ...) ___ 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: Still confused about PIE/PIC and default build flags
On 6/12/22 Richard Shaw wrote: So I run into this occasionally and it's still not clear to me. In this specific case I'm trying to build nanomq[1] and I get the following error: /usr/bin/ld: CMakeFiles/nano_test.dir/test.c.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE Please post a recipe to reproduce those complaints: the .spec file (or URL), other context for building, etc. When I build according to README.md at https://github.com/emqx/nanomq "Building From Source", without Ninja: git clone https://github.com/emqx/nanomq.git ; cd nanomq git submodule update --init --recursive mkdir build && cd build cmake .. make then I see no complaints from /usr/bin/ld. The software package itself is low quality. gcc complains dozens of serious errors such as: nng/src/nng.c:2269:1: warning: control reaches end of non-void function [-Wreturn-type] nng/src/sp/protocol/mqtt/nmq_mqtt.c:271:51: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] nng/src/supplemental/mqtt/mqtt_qos_db.c:620:13: warning: unused variable ‘rv’ [-Wunused-variable] 620 | int rv = sqlite3_exec(db, "COMMIT;", 0, 0, 0); ___ 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: Uninitialized variables and F37
On 5/16/22 07:33, Michael Catanzaro wrote: On Mon, May 16 2022 at 07:23:20 AM -0700, John Reiser wrote: Zero is the worst possible auto-int value. It will hide the most bugs. That's true, but using zero also converts code execution vulnerabilities into denial of service vulnerabilities. Dereference a NULL pointer and you get a non-exploitable crash. Dereference 0x81818181 and you have a much more serious problem at predictable location. The goal of this change is to mitigate security bugs, and using a nonzero value does not accomplish that goal. Today on x86_64 Linux does not allow 0x8181...81 to be mapped in a user process (except for i686 software running under x86_64 kernel, which may be prevented via configuration choice), so the addressing fault for 0x8181...81 is just as fatal as for zero. SIGSEGV is generated in both cases, and handled independent of address value. ___ 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: Uninitialized variables and F37
On 5/11/22 19:35, Steve Grubb wrote: On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote: [snip] Fast-forward a few months and I see GCC 12.1 is released now with -ftrivial-auto-var-init option support [2]. Are you going to take this idea forward and make a formal change proposal for Fedora to set -ftrivial-auto-var-init=zero by default in its default RPM build flags ? I've connected with the gcc folks and we will file a proposal in the near future. Zero is the worst possible auto-int value. It will hide the most bugs. Zero is unrecognizable as an auto-init value by hardware, code, and humans. The auto-init value should be recognizable instantly in all circumstances. The value which comes to mind is 0x81 in every byte. This is the "core constant" used by the Michigan Terminal System beginning 1967 (yes, 55 years ago!) on IBM S/360-67 and S/370 hardware; see https://en.wikipedia.org/wiki/MTS_system_architecture. As a signed integer the value is negative, which trips assumptions of "positive or zero" for loop counters or array indices. As a virtual address, (void *)0x818181..81 triggers a fault, thus catching uninit pointers. 0x81 stands out in a hex dump. Programmers quickly learn the 32-bit integer value "-2122219135". Please do not use zero as the default auto-init value. Use 0x818181..81 instead. ___ 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: Static library linking error
* Florian Weimer: * Richard Shaw: I added the following to the libmqttc library and verified -fPIC -pie is in the build flags[1] per the recommendation from the hardening page[2] but the error remains. Code that is linked into a shared object (with -shared) must be compiled as PIC, not PIE. So using "-fPIC -pie" should elicit a warning from the compiler, something like: warning: '-pie' turns off '-fPIC' with an analogous warning whenever a command-line parameter conflicts with an earlier command-line parameter. ___ 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: Static library linking error
On 5/10/22 06:21 UTC, Mamoru TASAKA wrote: Richard Shaw wrote on 2022/05/10 12:07: I'm working on some IIoT related packages in my COPR where I have a dynamic library linking to a static library and getting the following error: /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o): warning: relocation against `mqtt_fixed_header_rules' in read-only section `.text' /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o): relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules' can not be used when making a shared object; recompile with -fPIC I added the following to the libmqttc library and verified -fPIC -pie is in the build flags[1] per the recommendation from the hardening page[2] but the error remains. Any ideas? Thanks, Richard [1] https://download.copr.fedorainfracloud.org/results/hobbes1069/IIoT/fedora-rawhide-x86_64/04386803-mqtt-c/builder-live.log.gz This log no longer seems to exist. I was able to access it just now. Some relevant lines are: = [ 18%] Building C object CMakeFiles/mqttc.dir/src/mqtt.c.o /usr/bin/gcc -DMQTT_USE_BIO -I/builddir/build/BUILD/MQTT-C-1.1.5/include -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\ -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -pie -MD -MT \ CMakeFiles/mqttc.dir/src/mqtt.c.o -MF CMakeFiles/mqttc.dir/src/mqtt.c.o.d -o CMakeFiles/mqttc.dir/src/mqtt.c.o \ -c /builddir/build/BUILD/MQTT-C-1.1.5/src/mqtt.c [ 27%] Linking C static library libmqttc.a /usr/bin/cmake -P CMakeFiles/mqttc.dir/cmake_clean_target.cmake /usr/bin/cmake -E cmake_link_script CMakeFiles/mqttc.dir/link.txt --verbose=1 /usr/bin/ar qc libmqttc.a CMakeFiles/mqttc.dir/src/mqtt_pal.c.o CMakeFiles/mqttc.dir/src/mqtt.c.o /usr/bin/ranlib libmqttc.a = which confirms that "-fPIC -pie" was used when compiling mqtt.c into CMakeFiles/mqttc.dir/src/mqtt.c.o . Suggestion: extract mqtt.c.o from libmqttc.a, then run "readelf --all --wide mqtt.c.o > foo" and look in file foo for more information about: relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules' Also, upstream should remedy complaints from the compiler: = /builddir/build/BUILD/MQTT-C-1.1.5/examples/bio_publisher.c: In function 'main': /builddir/build/BUILD/MQTT-C-1.1.5/examples/bio_publisher.c:47:5: warning: 'ERR_load_BIO_strings' is deprecated: \ Since OpenSSL 3.0 [-Wdeprecated-declarations] 47 | ERR_load_BIO_strings(); | ^~~~ In file included from /usr/include/openssl/cryptoerr.h:17, from /usr/include/openssl/crypto.h:38, from /usr/include/openssl/bio.h:30, from /builddir/build/BUILD/MQTT-C-1.1.5/include/mqtt_pal.h:100, from /builddir/build/BUILD/MQTT-C-1.1.5/include/mqtt.h:43, from /builddir/build/BUILD/MQTT-C-1.1.5/examples/bio_publisher.c:10: /usr/include/openssl/cryptoerr_legacy.h:31:27: note: declared here 31 | OSSL_DEPRECATEDIN_3_0 int ERR_load_BIO_strings(void); | ^~~~ = and: = /builddir/build/BUILD/MQTT-C-1.1.5/examples/simple_subscriber.c: In function 'main': /builddir/build/BUILD/MQTT-C-1.1.5/examples/simple_subscriber.c:73:24: warning: passing argument 2 of 'mqtt_init' makes pointer from integer without a cast [-Wint-conversion] 73 | mqtt_init(, sockfd, sendbuf, sizeof(sendbuf), recvbuf, sizeof(recvbuf), publish_callback); |^~ || |int = plus several more int vs pointer conflicts. ___ 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: F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)
On 4/13/22 23:28, Gordon Messmer wrote: I've gotta ask... How much memory does the new dnf daemon take while idle? I know this comes up time to time... As it is, PackageKitd and gnome-software both, individually, take ~ 450MB of RAM without any user interaction (other than logging in to a desktop) on a F36 system I updated for general testing. Assuming that there is minimal "bloat" in app data structures, then the root cause of such high usage of address space is python memory management. By default, python does not collect and re-use memory "garbage" (previous allocations that no longer are accessible) until the OS denies a request to allocate a new page. The typical result is a long time before the first collection, because Linux will allocate new pages until /proc/meminfo.CommitLimit is reached (and/or swap space is exhausted, which invokes OutOfMemory process killer.) In particular, a python daemon which starts and reaches a (near-)steady state soon after system boot might not ever collect garbage unless the system runs for weeks or months before a re-boot. In order to reduce the memory footprint then the python strategy must be changed, and/or the app must pay attention (explicitly delete and collect garbage.) In the particular case of rpm package management on a system with 64-bit pointers, then the app also should use arrays instead of linked structures. There is no case of more than (1<<24) packages, and nearly all invocations manage fewer than (1<<16) packages. Thus a 2-byte or 3-byte ordinal (packed) can be used instead of an 8-byte pointer. This may require non-trivial code changes. For instance, the stack cannot be used as the residence for a temporary package structure. Also, using text compression might reduce significantly the RAM that is required to store character strings. Even without compression, in many apps character strings tend to persist forever without modification, so just append them into chunks of (1<<20) bytes, with a separate array of (1<<12) pointers to chunks. Then such a string can be identified by a 32-bit ID instead of a 64-bit pointer, which saves 4 bytes for the pointer plus at least 8 bytes of accounting overhead used by the default malloc(). ___ 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: grub2 BIOS booting iso and code
It would be very nice to run /sbin/dmidecode, which is on the .iso, and report the "BIOS Information" section, such as: Is the attached any use? In the attachment I see these interesting lines (snipped): = SMBIOS 3.0.0 present. BIOS Information Vendor: American Megatrends Inc. Version: 0801 ## first release (01) for product line 08 Release Date: 01/25/2017 ## only 5 years old ROM Size: 16 MB ## probably has lots of VGA-gui "eye candy" Boot from CD is supported Selectable boot is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported ## claims to be *not* "BIOS-only" BIOS Revision: 5.12 ## the low-level BIOS code Base Board Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: STRIX Z270H GAMING ## only 3 hardware generations old; current is Z5xx Version: Rev 1.xx = ___ 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: grub2 BIOS booting iso and code
- Dell XPS 15 L502X 8GB RAM (BIOS only) CD-R physical media It would be very nice to run /sbin/dmidecode, which is on the .iso, and report the "BIOS Information" section, such as: = # dmidecode 3.3 Getting SMBIOS data from sysfs. SMBIOS 2.5 present. 70 structures occupying 2511 bytes. Table at 0x000F0730. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 1613 Release Date: 12/03/2008 Address: 0xF Runtime Size: 64 kB ROM Size: 1 MB Characteristics: ISA is supported PCI is supported PNP is supported APM is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 16.13 = of which the Vendor, Version, and Release Date are the most important. In the installer, type Ctrl+Alt+F2 to get a TTY, re-direct the output of dmidecode into a file, and copy the file to a machine with a more- hospitable environment (using wired ethernet, USB flash memory, etc.) If there are any errors or unusual behavior, then it also is interesting to know if the interface for the Floppy disk drive is enabled; but often this requires searching through BIOS configuration screens. Sometimes a CD or DVD can be Read under Floppy emulation, and it is easy for the BIOS to try this regardless of settings. Try disabling the Floppy in the BIOS settings, then re-booting. ___ 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: grub2 BIOS booting iso and code
https://bcl.fedorapeople.org/boot-grub2-f36.iso I installed successfully using physical CD-R and physical DVD+R on American Megatrends Inc version 1613 BIOS of 12/03/2008 running on Intel Core2 Duo (E8400, 3GHz, 8GB). The USB reade was LG Slim Portable DVD Writer GP50NB40 (August 2014). The media check took 5 minutes on CD and 2.5 minutes on DVD. On the installed system, "dd if=/dev/sr0 bs=32k of=/dev/null" was 48 seconds faster than the media check for CD, and 24 seconds faster than the media check for DVD. ___ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 07:07, Vitaly Zaitsev via devel wrote: On 14/04/2022 15:31, John Reiser wrote: Some of them even have "without data loss" in the page title. Without moving data to another physical drive this operation is too dangerous. I tried on my testing VM and lost all data from that VM. Restored snapshot. Please show what "sudo fdisk $DEVICE_NAME" says for the 'p' (print) command (then 'q' to quit), both before and after the attempted conversion. ___ 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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On 4/14/22 02:01, Vitaly Zaitsev via devel wrote: On 13/04/2022 23:11, Matthew Miller wrote: It'd be cool to see if we can make a bios-to-uefi thing like Clover work. I don't think it's possible because the MBR -> GPT conversion will destroy all partitions on the original drive. An internet search for "convert MBR to GPT" yields many results, including some from authoritative sources including Microsoft and Dell. Some of them even have "without data loss" in the page title. I myself have done this at least twice in 5 years with no data loss, using the 'gdisk' utility (man 8 gdisk) in Fedora. The conversion is particularly easy when the MBR partitions do not cover the first and last 1MB of the drive, which has been a prevalent practice for many years. ___ 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: FESCo wants to know what you use i686 packages for
If you use i686 packages for something now, please respond to this thread. I use glibc.i686 and libgcc.i686 to support customers whose i686 machines have not yet died. (Some are about 12 years old, and expected live another 3 years. The ability to use almost 4GB of address space when running ELF.i686 on Linux.x86_64 has provided room for data growth.) I build the software by using cross-platform tools not packaged in Fedora, and the -m32 option of gcc.x86_64. ___ 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: Orphaning deltarpm
On 3/14/22 12:23, Samuel Sieb wrote: On 3/14/22 09:34, John Reiser wrote: Just setting `deltarpm` to False in dnf.conf do the same. Just saying. The deltarpm option has low discoverability. The information is available, but the discovery chain is too long and not explicit enough. The main configuration file /etc/dnf/dnf.conf does not list each option, its default value, and perhaps a short comment. The main configuration file does not reference "# See 'man 5 dnf.conf'." Why wouldn't that be the first thing you tried anyway? The first thing is to look at the manual page "man dnf", whose FILES section points to the main configuration file /etc/dnf/dnf.conf. I expect dnf.conf to list all the options and their default values, or if not, then to point to the documentation which does. The manual page "man dnf" says nothing about deltarpm. The default /etc/dnf/dnf.conf lists only a few options with no individual documentation, and contains no explicit pointer to more documentation. I expect better: all reasonable attempts should lead quickly to the relevant documentation. This is the meaning of "good discoverability". If I get anywhere close, then I should find the answer or a direct pointer to the answer. Enable multiple pathways (both the main manual page AND the configuration tile should point to "man 5 dnf.conf") so as to reduce the number of steps. ___ 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: Orphaning deltarpm
Just setting `deltarpm` to False in dnf.conf do the same. Just saying. The deltarpm option has low discoverability. The information is available, but the discovery chain is too long and not explicit enough. The main configuration file /etc/dnf/dnf.conf does not list each option, its default value, and perhaps a short comment. The main configuration file does not reference "# See 'man 5 dnf.conf'." ___ 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: Orphaning deltarpm
On 3/6/22 13:39, Demi Marie Obenour wrote: I have also strongly disliked deltarpms. They very rarely help and significantly increase attack surface. If deltarpm succeeds and both the old .rpm and the new.rpm are signed, then how is the attack surface larger, as long as any consumer verifies the signature? ___ 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: ABI incompatible change or not?
$ fedabipkgdiff --from fc37 codec2-1.0.3-1.fc37.x86_64.rpm
[[snip]]
1 function with some indirect sub-type change:
[C] 'function void mbest_search(const float*, float*, float*, int, int,
MBEST*, int*)' at mbest.c:123:1 has some indirect sub-type changes:
parameter 3 of type 'float*' changed:
entity changed from 'float*' to 'int'
type size changed from 64 to 32 (in bits)
parameter 5 of type 'int' changed:
entity changed from 'int' to 'MBEST*'
type size changed from 32 to 64 (in bits)
parameter 6 of type 'MBEST*' changed:
in pointed to type 'struct MBEST':
entity changed from 'struct MBEST' to 'int'
type size changed from 128 to 32 (in bits)
parameter 7 of type 'int*' was removed
Any package that contains a call to mbest_search() must be re-compiled,
and will fail due to type mismatch.
Changing parameter type {from: pointer, to: integer; or vice-versa}
is incompatible. Changing pointed-to type {from: struct, to: integer}
is incompatible.
___
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: Uninitialized variables and F37
Of course gcc -fsanitize=undefined cannot be used on production code. Why not? Will it find too many errors? Perhaps because it looks like an ABI change: requires at least one of /usr/lib64/libasan.so or libubasan.so . ___ 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: Uninitialized variables and F37
It might be worthwhile to have a CFLAG that can tell glibc (or other allocators) to substitute something like calloc for malloc. The environment variable MALLOC_PERTURB_ has been used by glibc malloc for over 15 years. ___ 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: Is it possible to find out which packages were used when building the package?
Thanks, for answer. I build every day rpm packages from git locally with mock. ... It might be more efficient to run a shell command in your build environment to review /var/log/dnf.log, even in a "mock" build environment, rather than trying to parse out the dependencies directly b reading the RPM or the .spec file. It can be a real adventure to resolve all the dependencies on dependencies on dependencies, especially for a complex python based package. RPM and yum also do not prove a package was actually used, merely that it was managed as a build requirement. strace -f -e trace=file -o strace.out mock ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New openssh in Rawhide can't connect to RHEL 6 servers
On 12/5/21, Richard W.M. Jones wrote: openssh 8.8p1 (just released in Rawhide) cannot connect to older servers. The error is: Unable to negotiate with [server] port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss It seems like the cut-off point is RHEL <= 6 broken, RHEL >= 7 is OK. I eventually found a workaround/solution to this deep in an Arch thread: https://bbs.archlinux.org/viewtopic.php?pid=2006291#p2006291 or the equivalent on the command line: ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa rhel6 Both config options seem to be necessary. Thank you for concisely documenting the problem and workaround. ___ 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: Linux 5.13 To Allow Zstd Compressed Modules, Zstd Update Pending With Faster Performance
FWIW, I've been playing with zstd-coompressed initrd images. With a large initd image, it shaves about 1 second from the boot time. Please give numeric statistics. How many MB is large, and how many seconds does it take? ___ 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: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'
I'd need help with the following issue with apitrace, which failed the mass rebuild with: apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:70: undefined reference to `__libc_dlopen_mode' apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:72: undefined reference to `__libc_dlsym' The code triggering this is below. Have these symbols disappeared from libc resp is there any alternative? I've raised this upstream but so far no activity [1]. I'm not really knowledgeable enough in this area to judge the best way to fix this. Is anyone able to help with this? Otherwise I'll have to orphain/retire apitrace for F35+. According to the comments in https://github.com/apitrace/apitrace.git file wrappers/dlsym.cpp , the purpose is "to obtain the true dlsym" by explicit lookup in libdl.so.2, which is a library that no longer exists in glibc-2.34, having been combined into libc.so itself. The only legitimate way to find "the true dlsym" is to trust dl_iterate_phdr (/usr/include/link.h) and call it, dig through all the Dynamic sections to find all the symbols named 'dlsym', then choose the one you want: perhaps by being defined in a file whose DT_SONAME is "libc.so" and having symbol version GLIBC_2.2.5 . Because such code has not been contributed, then apitrace should be orphaned/retired in F35+. ___ 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: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'
Depending on the threat model, then DT_BIND_NOW and/or LD_PRELOAD can be used to find the desired instance of dlsym(). Also there is dl_iterate_phdr() (declared in /usr/include/link.h) which enables examination of all the symbols known to the runtime linker. ___ 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: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'
We are working on improving LD_AUDIT support, which is the plugin API of the dynamic loader. It can in theory be used to implement such things. Depending on the threat model, then DT_BIND_NOW and/or LD_PRELOAD can be used to find the desired instance of dlsym(). If the threats include "just in time" modification of the instruction stream, then you must control the system calls execve, mmap, mprotect, and ptrace. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Meaning of Size Directories
On 3/16/21, David Howells wrote: John Reiser wrote: See the manual page "man 2 getdents". Um, which bit? I don't see anything obvious to that end. On that manual page: = The system call getdents() reads several linux_dirent structures from the directory referred to by the open file descriptor fd into the buffer pointed to by dirp. [snip]] On success, the number of bytes read is returned. = So the return value is related to the size of the directory; the sum of the values returned before End-Of-File should be quite close to the .st_size of the directory. If a program is walking through the directory, reading all the entries via getdents64(), then .st_size of the directory is the only thing known in advance about the total size. (Of course anything involving a directory can depend on concurrent create/delete/rename of files within the directory.) On AFS directories are handled as files that the filesystem downloads and parses locally. The size returned in st_size is the size of the directory content blob. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Meaning of Size Directories
Tools such as ls or stat report the size of a directory. Of course it is not the content size. stat -c %s /home/sergio/.config 6550 What does 6550 mean in btrfs context? Regardless of filesystem type, the size of a directory is the sum of the sizes of the struct linux_dirent (or linux_dirent64) for the filenames of the contained files. See the manual page "man 2 getdents". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New memory tester application potentially to replace memtest86+: PCMemTest
«In particular, no attempt is made to measure the cache and main memory speed, or to identify and report the DRAM type.» Which is nice to have but not really the point of a memory tester ... When the tester reports errors then it is handy to know as much as possible about where the errors lie, including the manufacturer and part number if an error can be isolated to an address range. For a system which added memory in mid-life using a different brand of RAM, it is helpful to confirm the brand which is failing. /usr/sbin/dmidecode reports what it knows, but that requires cross-referencing etc. ___ 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: Popularity contest for Fedora
I think we can simply parse server-side access logs to count package downloads, no? That ignores the effect of caching proxies, which are prevalent in academic and corporate environments. ___ 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: finding recursive builddeps
On 2020-11-16 02:23 UTC, Sérgio Basto wrote: dnf builddep fedora-review.spec ? after reading what fbrnch does, I remembered that Unfortunately "dnf builddep" has a DESIGN error: it does not separate the task "find the names of the missing packages" from the task "install packages". "find the names" should be performed without sudo, but dnf does not. As a result, "sudo dnf builddep" can fail mysteriously: https://bugzilla.redhat.com/show_bug.cgi?id=1663619 ___ 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: Help needed: vtk FTBFS, undefined reference to std::__detail::__to_chars_10_impl(char*, unsigned int, unsigned int)::__digits
/usr/lib64/ccache/g++ \ [[snip]] One more level of expansion of command lines can be obtained by using the '-v' parameter: g++ -v ... and a final level by adding -v to collect2, then re-running collect2. The collect2 command is revealed by "g++ -v". Also look at the transitive closure of all the [DT_]NEEDED entries in the Dynamic section. Something like: for lib in $(find ... -name 'lib*.so*'); do # every shared library that the build uses echo $lib readelf --dynamic $lib | grep NEEDED done If some build succeeds, then "ldd vtkIOXMLCxxTests" gives another list of shared libraries. ___ 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
nfs-utils: compiler error tracking strlen on Rawhide armv7hl and i686
Let's handle some preliminary errors in this thread on building nfs-utils, before they spread even more. 1. Be specific. State the package name in both the Subject and the first line of the body. This provides context which aids the scanning of Subjects and enables detection and correction of copy+paste errors. 2. The return value from both printf() and snprintf() with a format of "%s/%s" is s(trlen(str1) + 1 + strlen(str2)) /* +1: the '/' separator */ [note that this is strlen() of the unconstrained destination array], and the number of bytes written (if not limited by the size parameter to snprintf()) is 1 more because of the terminating NUL byte '\0'. Thus the minimum size of the unconstrained destination is (2 + strlen(str1) + strlen(str2)). 3. Do not use "PATH_MAX + 1". Almost always it indicates a programmer error. From /usr/include/linux/limits.h we see that #define PATH_MAX4096 /* # chars in a path name including nul */ Increasing the size does not work: if (4096 <= strlen(path)) /* Yes, '<=' */ then the Linux kernel will do something other than what you naively expect. The "destination too small" error condition for (rv = snprintf(array, size, format, ...)) is (size <= rv); using anything else is a bug. After taking care of those bugs above, and looking at the constants such as '2147483645' and '2147483648' in the compiler's complaints, it is obvious that the compiler erred when tracking the result value from some call to strlen(). If you want help then please supply the complete source code. I could not locate the downloadable source for [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=55125502 even after following several links. ___ 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: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)
On 2020-09-01 at 12:13 UTC, Kamil Paral wrote: [[snip]] I'd like to ... hugely speed up the installation instead [[snip]] Zstd is faster than xz at de-compression, but a much larger speed improvement would be to parallelize and pipeline "rpm --install". This would benefit both install and the creation of 'mock' build environments. Topologically sort the .rpm packages by dependency. All packages within a given tier (tier 0 is the packages that have no dependencies, tier 1 is the packages that have no uninstalled dependencies after installing tier 0, etc.) can be installed in parallel. Even for scriptlets that might force serialization [such as selinux], all processing before the first Write-to- destination-filesystem can be parallel. For any individual .rpm, the stages of fetch the package (from network, USB flash memory, DVD, etc.), decompress, and process the contained files, can be pipelined at the block level (4KiB to 64KiB) so that the memory cache (L3 on Intel x86_64 CPUs) suffers a Read miss only rarely. But I repeat myself, from 2002 (18 years ago): https://bugzilla.redhat.com/show_bug.cgi?id=71184 RFE: 2X to 6X faster install via software pipeline and controlled memory footprint Side note: Inexpensive USB flash memory storage does not have to be slow. Reading from my 128GB flash memory device "ID 03f0:da07 HP, Inc" is competitive with reading from a spinning harddrive: From a USB 3.0 port the flash drive gives: # dd if=/dev/sde1 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes (2.1 GB, 2.0 GiB) copied, 13.8432 s, 151 MB/s From a USB 2.0 port the flash drive gives: # dd if=/dev/sde1 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes (2.1 GB, 2.0 GiB) copied, 55.0733 s, 38.1 MB/s ___ 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 CPU extensions can we assume are available by arch?
On 4/25/20 12:24 UTC, Kevin Kofler wrote: Richard Shaw wrote: As far as LCPNet itself I've communicated with the primary developer quite a bit over the last week. LPCNet *will not work* without optimizations (at least not in real time which is the point). Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version of the vector code? Most of LPCNet computation is "embarrassingly parallel"; for each vector operation, then each output element could be computed simultaneously. So an SSE2 version would be competitive with the AVX1 version (use the same instructions, just don't VEX encode them) except for any advantage that AVX gains from using 3-operand instructions instead of just 2-operand. The existing code should be enhanced to align each 'float' array to a cache-line boundary, and to place scalar members of 'struct's into any "holes". Also, the existing code is single-threaded. A two-threaded version with one thread computing vector elements [0, 16*floor(N/32)) and a second thread computing the rest, would be nearly twice as fast as long as synchronization was fast [futex to the rescue.] Two threads might trigger thermal throttling on older CPUs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F32 ELF file analysis
On 4/11/20 4:38 AM, Kevin Kofler wrote: Steve Grubb wrote: readelf -s $f 2>/dev/null | grep FUNC | egrep 'seccomp_rule_add|seccomp' Since seccomp is a substring of seccomp_rule_add, it is pointless to grep for both. Yes, the output is the same. But the documentation is not as explicit. A comment might be helpful: ... | grep seccomp # also covers seccomp_rule_add ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F32 ELF file analysis
What are you using to check for your STACK_PROT This is annocheck Alternate: - $ readelf --segments ./the_app Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align GNU_STACK 0x 0x 0x 0x 0x RW 0x10 - where this app uses only "RW" and not "X", so the stack is not executable. ___ 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: koji build fails on arch armv7hl
On 2/10/20 6:20 AM, Martin Gansser wrote:
the koji build on armv7h fails by this command:
koji build rawhide --arch=armv7hl --scratch
/home/martin/rpmbuild/SRPMS/speed-dreams-2.2.2-6.fc31.src.rpm
File "/usr/lib/python3.7/site-packages/requests/models.py", line 828, in
content
self._content = b''.join(self.iter_content(CONTENT_CHUNK_SIZE)) or b''
MemoryError
Internet search says "python Memory Error" probably means running out of
address space,
such as on a 32-bit armv7hl. What uses lots of address space? Could there be
too much contention from other jobs on the machine? Paging space (swap space)
is a "temporary" constraint on address space of every running processes
During handling of the above exception, another exception occurred:
File "/usr/sbin/kojid", line 1339, in handler
fn = self.localPath("work/%s" % pkg)
File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 489, in localPath
resp.close()
UnboundLocalError: local variable 'resp' referenced before assignment
That's a bug in the exception handler.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
John M. Harris Jr wrote: Using swap on zram disables the ability to hibernate, making it a non-starter for many users. If this is going to be thrown into anything, the user needs to be asked whether they want it or not in the installer, otherwise you're just taking away features. Why not create a utility program to convert dynamically between swap-on-zram and swap-on-disk? ___ 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: Change proposal discussion - Optimize SquashFS Size
On 2/3/20, David Cantrell wrote: https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS [[snip]] Being the engineering steering committee, we all had our own ideas and opinions about what the problem is and how best to approach it. [[snip]] It seems to me that there is not enough practical experience with anything other than the current xz (+ ext4 + squashfs). So run an experiment, such as: Before beta freeze, if a [rawhide] compose starts on an odd-numbered day-of-month, then use xz. If a compose starts on an even-numbered day, then use zstd -19 -b 1M. At beta freeze, then reduce the frequency of changing from daily, to weekly or less. Changing back-and-forth ought to affect only a small number of packages such as: compose tool, dracut, ananconda. Such an experiment should provide experience to better-inform a choice. ___ 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: [Test-Announce] Fedora 32 Rawhide 20200122.n.1 nightly compose nominated for testing
You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200122.n.1_Summary On x86_64 the package gcc-c++ is available only at version 9.2.1-1.fc32.3 whose installation downgrades gcc from 10.0.1. Bummer. ___ 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: Not a bug
On 2020-01-19 00:21 UTC, Ken Dreyer wrote: On Sat, Jan 18, 2020 at 5:09 AM Richard W.M. Jones wrote: [[snip]] Sorry, not a bug. I remembered that I had put some alternate certificates into ~/.koji to access another Koji instance. I think there is a usability RFE here. If we get an SSLError *and* the Koji client is configured to use one specific CA bundle file on disk, then we should log that path to the CA file we used. +1. This is analogous to ENOENT, where the error message should include the actual path that was attempted, and not just "File not found". Even using a pronoun such as "configuration file not found" is not enough; give the actual path. ___ 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: Why does gdb dlopen() librpm instead of linking to it?
On 1/3/20 22:35 UTC, Neal Gompa wrote: On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil wrote: On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote: Can someone please explain why gdb dlopen()'s librpm instead of just doing proper compile-time linking? [[snip]] gdb.spec could auto-detect the current librpm version. I think it'd be nice if it auto-detected this stuff. It's weird having to go and fix that manually. Please do not predict the environment at run time by detecting the environment at compile time. That is generally safe only for the simplest properties such as base-level hardware architecture. Detecting the version of some other package is particularly problematic if the ultimate result is to be distributed beyond the datacenter where it was built. Even when the result works, it facilitates "version creep" of dependencies: requiring version N+1 (because because a Fedora builder tends to have newest versions) when version N would suffice. ___ 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: Suggestion for Fedora change proposal: -Bsymbolic-functions default in LDFLAGS
If you are running into that kind of problems where plugins/modules/dynamically linked objects may have conflicting requirements then see dlmopen(): https://sourceware.org/glibc/wiki/LinkerNamespaces ___ 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: Build Python 3 to statically link with libpython3.8.a for better performance
Thinking aloud: does anyone ever use symbol overriding for anything other than glibc? Yes. It is particularly useful for "spear fishing" debugging of lower-level interfaces in large, complex multi-process applications. That only seems to need shallow interposition, though. In most cases, I doubt you are interested in API calls from the library self because those are probably unproblematic. One actual case: why exp(600.0) ? Yes, the first use of overriding was shallow and libm (part of glibc). But the caller was deep within a scientific library, and the second overriding was not shallow at all. ___ 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: Build Python 3 to statically link with libpython3.8.a for better performance
On 2019-11-15 at 14:51 UTC, David Malcolm wrote: Thinking aloud: does anyone ever use symbol overriding for anything other than glibc? Yes. It is particularly useful for "spear fishing" debugging of lower-level interfaces in large, complex multi-process applications. By some means you determine that [part of] the bug involves a bad parameter to a particular API, but a conditional breakpoint in gdb has too much overhead (if you can figure out at all how to invoke gdb in the cloud of processes.) So: LD_PRELOAD a .so which overrides the API and checks the parameter. If no problem then pass control to the original implementation via RTLD_NEXT. If bad, then raise an alarm, prepare a backtrace, pause or spin until rescued by manual attach of gdb, etc. ___ 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: Build Python 3 to statically link with libpython3.8.a for better performance
On 11/5/19, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup
== Summary ==
Python 3 traditionally in Fedora was built with a shared library
libpython3.?.so and the final binary was dynamically linked against
that shared library. This change is about creating the static library
and linking the final python3 binary against it, as it provides
significant performance improvement, up to 27% depending on the
workload. The static library will not be shipped. The shared library
will continue to exist in a separate subpackage. In essence, python3
will no longer depend on libpython.
<>
There are alternatives that provide gradations in the tradeoffs.
0) Include _Py_UnixMain in libpython3.POINTVER.so, also set ElfXX_Ehdr.e_entry
and include enough -startfiles so that execve(libpython3.POINTVER.so, ...)
will act as if execve(python, ...). Compare execve("/lib64/libc.so.6", ...)
which prints the credits for glibc. Then python3 and libpython3.POINTVER.so
can be hardlinked or symlinked. This removes one DT_NEEDED from the
startup of python3.
1) Do not flag python3 and libpython3.POINTVER.so with DT_BIND_NOW or
DF_BIND_NOW.
This removes the need to perform relocation processing for every slot in the PLT
at process startup.
2) Use -Wl,-Bsymbolic during the build (static bind) of libpython3.POINTVER.so.
This removes all intra-library symbolic relocations (hence PLT slots) at the
cost
of also removing the ability to override (interpose) them.
3) Compile and build libpython3.POINTVER.so as ET_EXEC (without -fPIC, without
-shared, without -fPIE), static bind with
-Wl,-Ttext-segment=$(< /proc/sys/vm/mmap-min-addr)
to put the library below the pages of any default ET_EXEC, static bind with
--export-dynamic (or --dynamic-list=) to make visible all Python primitives,
and enhance the dynamic linker ld-linux to dlopen(ET_EXEC, ...) as if ET_DYN
but OR-in MAP_FIXED when mmap() of PT_LOAD. The dynamic linker can be
tricked today by changing ElfXX_Ehdr.e_type from ET_EXEC to ET_DYN,
as long as the linux kernel honors the hint of mmap(non_zero, ...)
without MAP_FIXED.
Today's /lib64/libpython3.7m.so.1.0 occupies about 3.4 MB of pages, which fits
between default mmap-min-addr of 64K and default -Ttext-segment of 4M.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
Chris Murphy wrote: ... If the change is approved, I'll suggest Docs team revise documentation to recommend any resize of the pre-installed OS (macOS or Windows) be done within those operating systems using their tools. Right now, there's no support for resizing any macOS file system layout anyway, so we have to advise the user accordingly anyway. When I do this (at least every Fedora release) I use gparted (via a LiveUSB if necessary) to produce the physical partitions that I want, then use the Manual partitioning dialog to choose and assign them. ___ 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: i686 hw builders running out of ram in cpio?
Anyone else seeing this? It seems to only happen on physical i686 machines, not vm's, but that's based on only three builds so far. https://koji.fedoraproject.org/koji/taskinfo?taskID=36329825 BUILDSTDERR: create archive failed: cpio: write failed - Cannot allocate memory Very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1729382 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
Kevin Fenzi wrote: Neal Gompa wrote: [[snip]] This will also make it impossible for people to locally do multilib build/installs. It will remove COPR’s ability to do the same. For that reason alone, I don’t particularly want this change to happen. Can you expand on what you mean by 'locally do' ? I want to run "gcc -m32 -o my_app-i686 *.o ..." locally on my own box to build executables that run as 32-bit apps on multilib x86_64. For some apps 2GB of malloc() arena is plenty, and they run faster in 32-bit mode because a 64-byte cache line contains 16 pointers instead of only 8. [[snip]] Finally, if you would prefer this not happen now, is there a time when you would further down the road? Whats the critera/goalpost/cutoff? One year after Red Hat Enterprise Linux version 7 reaches end-of-support. It would be handy for Fedora to have 32-bit *-devel packages until then. ___ 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: CMake Error: file INSTALL cannot find
when compiling olive [1] on F30, i get this error message: [[snip]] CMake Error at app/cmake_install.cmake:57 (file): file INSTALL cannot find "/home/martin/rpmbuild/BUILD/olive-85b5bbd5d6fb97ef215efd118b3fc156ebfba9bd/app/effects/internal/cornerpin.frag". Therefore a better Subject for the original email would be olive: CMake INSTALL cannot find cornerpin.frag because it contains high-value words such as the package name and the the basename of the missing file, and because it omits fluff such as "Error:" and "file". ___ 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: gcc/g++ compiler memory exhaustion on build vms
On 6/26/19 00:25 UTC, Philip Kovacs via devel wrote: I am finding that one of my c++ packages has compilation units that generate very large assembly (.s) files -- so large that any attempt to build them in memory (e.g. with -pipe) causes memory exhaustion. The only way I have found to reliably get the build to run to completion is by using -save-temps to force g++ to save the .s assembly files to disk. Please quantify: What is the byte size of the .s file? First hint: give the virtual machine enough resources! Either RAM, or "swap" (paging) space. Also, -pipe itself uses at most (16 * 4KiB) more memory. Memory (RAM) exhaustion is caused by having all the (.data+.bss) of both the compiler and the assembler resident at the same time. (Most of this will be the symbol table for the assembler.) Even then, if you have enough swap space (shown by the utility program /usr/sbin/swapon, also by /usr/bin/top | grep Swap) then compilation will succeed, although much more slowly due to demand paging. You can increase swap space by using one or more "instantiated" files in the filesystem; see "man swapon". It may be possible to use the gcc option -ffunction-sections (possibly combined with a filter using /usr/bin/sed, etc.) as a hint to the assembler to discard the symbols for local labels upon reaching the end of each function. For particular cases, you can use "gcc --verbose ...", or even "strace -f -o strace.out -e trace=execve -s 500 gcc ...", to recover command sequences that may be edited according to desire. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
If we did this, wouldn't it make it very difficult to use tools like mock on RHEL / CentOS 7 to build for Fedora 3x? Or does RHEL 7 RPM support zstd? We're pretty much screwed here. Also, since RHEL 8's rpm package does not have zstd support compiled in, it too cannot handle the RPMs. Hence it needs to be configurable. Fedora EPEL RPMs need to be built with xz. Everything else that's expected to be consumed by Fedora 29 and higher, can use either zstd or xz. I'd expect RHEL built packages intended for Fedora would use xz, and Fedora's RPM would support that just fine. Fedora should provide a means to convert from .rpm-with-compression-A to .rpm-with-compression-B. Already there is 'alien' which converts between .rpm, .deb, and .tgz. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: C++ help needed fixing VXL on 32 bit architectures
https://github.com/vxl/vxl/issues/638
Independent of that particular issue, it is hard to believe the claim
"vxl: A multi-platform collection of C++ software libraries ...".
They're not making a good-faith effort to be portable.
The first hint is that "-Werror" (turn all warnings into errors)
has not been used when compiling.
There are so many basic portability errors, such as:
= portability error 1
v3p/netlib/triangle.c:219: #define TRIANGLE_PTRINT size_t
Using #define is silly when typedef is suitable.
v3p/netlib/triangle.c:3685:23: warning: format '%lx' expects argument of type
'long unsigned int', but argument 2 has type 'unsigned int' [-Wformat=]
printf("triangle x%lx with orientation %d:\n", (TRIANGLE_PTRINT) t->tri,
"%zx" solves this problem and has been available for many years.
= portability error 2
v3p/clipper/clipper.cpp:722:34: warning: 'void* memset(void*, int, size_t)'
clearing an object of non-trivial type 'struct ClipperLib::TEdge'
Learn from the compiler; it is smarter than this programmer.
(Example: if there are any 'virtual' functions [now or later!],
then using memset zaps the vtable pointer.)
== portability error 3
core/vil1/vil1_memory_image_impl.cxx:210:63: warning: suggest parentheses
around assignment used as truth value [-Wparentheses]
return property_value ? (*(bool*)property_value) = true : true;
This is unmaintainable, especially when not explained in a comment.
= portability error 4
core/vil1/file_formats/vil1_pnm.cxx:360:11: warning: this 'if' clause does not
guard... [-Wmisleading-indentation]
if ((t&=7)==0) *++ib=0; int a; (*vs_) >> a; if (a) *ib|=static_cast(1<<(7-t)); }
Such code is an abomination for lack of clarity.
Also, the preceding line
for (int x=0,t=0; xhttps://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: Using SCLs to build a C++ library for EL 7?
It would be useful for posts to be specific, and/or to include a link to a detailed explanation. Such information might attract the interest of others, and tend to encourage the discovery of multiple approaches towards dealing with the underlying problems. On 4/29/19 1210 UTC, Jonathan Wakely wrote: On 29/04/19 07:52 -0400, Neal Gompa wrote: On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák wrote: Hi list, I'm co-maintaining a C++ library that has been continuously updated in Which library in which package? CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7. What is the nature of the incompatibilities, and what are specific examples? Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too. Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, For example, or a link to an explanation? but allows us to avoid that problem entirely. If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the For example; or a link to an explanation? problem isn't avoided entirely. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
In file included from ../src/lib/comp/zstd/zstd.c:34:
../src/lib/zck_private.h:92: error: redefinition of typedef 'zckCtx'
include/zck.h:49: note: previous declaration of 'zckCtx' was here
As far as I can see, gcc-4.7 doesn't like that I'm typedefing the same
struct to the same type twice. Later versions don't see it as a
problem at all.
How about this:
#ifndef zckCtx_DEFINED /*{ workaround for gcc-4.4.7 */
#define zckCtx_DEFINED 1 /* gcc-4.4.7 demands only one declaration of a
typedef */
typedef struct zckCtx zckCtx;
#endif /*}*/
and similarly for the other 8 "multiply-defined" typedefs? After
pre-processing,
then the compiler will see exactly one definition of the typedef.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we use SCLs for building for EPEL 6?
Unfortunately, the gcc in EL6 is too old to build zchunk In what specific way(s)? Can the complaints from gcc [which version?], or other tools in the toolchain, be listed here? Other developers may have faced the same or similar problems, and may have tools to help. ___ 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: clang segmentation fault on armv7hf
On 4/1/19 6:08 AM, Richard Shaw wrote: On Sun, Mar 31, 2019 at 10:22 PM John Reiser mailto:jrei...@bitwagon.com>> wrote: On 3/31/19 7:31 AM, Richard Shaw wrote: > I'm working on building PySide2 for Fedora and have a problem with clang segfaulting only on armv7hf[1]... > [1] https://kojipkgs.fedoraproject.org//work/tasks/4670/33794670/build.log https://kojipkgs.fedoraproject.org/packages/ does not have python-pyside2-5.12.1-1.fc31.src.rpm, and searching the 'net for python-pyside2-5.12.1-1.fc31.src.rpm yields no download. If you want help, then please post good links. Sorry, yes scratch builds are hard to find if you don't have the link... https://koji.fedoraproject.org/koji/taskinfo?taskID=33817221 That still does not provide a downloadable link to the .src.rpm. Please do this: attach the .src.rpm to the bugzilla report for the crash by clang, and post the URL of the bugzilla report. That will make it easy for those who wish to help, and easy for you, too! ___ 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: clang segmentation fault on armv7hf
On 3/31/19 7:31 AM, Richard Shaw wrote: I'm working on building PySide2 for Fedora and have a problem with clang segfaulting only on armv7hf[1]... [1] https://kojipkgs.fedoraproject.org//work/tasks/4670/33794670/build.log https://kojipkgs.fedoraproject.org/packages/ does not have python-pyside2-5.12.1-1.fc31.src.rpm, and searching the 'net for python-pyside2-5.12.1-1.fc31.src.rpm yields no download. If you want help, then please post good links. ___ 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: Packaging HTML/Javascript "application" for visualizing some json data
The next release of valgrind (3.15.0) will have an updated dhat tool which creates a json output file. To make it easier to use the data it comes with a small html/css/js "application" that makes it easy to sort/visualize the data. This html/css/js application is self-contained, it doesn't use any other javascript code/libraries. It consists of 4 files: dh_view.html, dh_view.css, dh_view.js and dh_test.js. You would use it something like: $ valgrind --tool=dhat /bin/sort < /usr/share/dict/words > /dev/null Which generates a json file dhat.out.3759 [was attached]. Which you can then "load" into the dh_view.html app to see various different representations of the data collected. The output dhat.out.3759 should be created in the current directory or at the destination specified by valgrind's usual --xml-*= command-line parameters. This is no different from any other output generated by valgrind. The user will enter the URL to the browser app's "load" command as file:// or as the result of a "browse" dialog, much like File > Open. The html/css/js "application" (4 files dh_view.html, dh_view.css, dh_view.js and dh_test.js) belongs in a directory such as /usr/libexec/dhat . ___ 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: rpmlint: new "executable stack" warnings on rawhide
I've noticed that as of some days ago, some packages I build on rawhide are now triggering the "W: executable-stack" warning for all included executables and shared libraries. I'm not sure which change might be the cause of this, but meson 0.50.0 seems to be a good candidate, since all my affected packages are built with meson and the new version landed six days ago. Is that new warning something we should worry about? Yes. The warning means that an executable is not as secure as it could be against malware. The likely cause is some assembly-language source file that lacks a line such as .section.note.GNU-stack,"",@progbits which tells the assembler and static binder (/usr/bin/ld) that "the code in this file does not need an executable stack." To identify the files that lack the line: find src -name '*.S' | sort > files-S.txt grep -l note.GNU-stack $(< files-S.txt) > files-non-W-stack.txt comm -3 files-S.txt files-non-W-stack.txt To remove the warning: append the line to the end of each file listed in the output from 'comm'. ___ 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: apiextractor FTBFS troubleshooting
There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore -lQtXmlPatterns -lQtXml) plus an explicit libapiextractor.so.0.10.1. Did you run nine tests, replacing the pieces one-by-one with their Fedora 29 versions? I'm not sure how to do that in a mock chroot... Boot the Fedora 30 Live Workstation from a USB flash memory drive, then use that. ___ 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: apiextractor FTBFS troubleshooting
Is it definitely the linking? Or should I check the compiler arguments as well? There are 8 libraries (-lQtTest -lQtCore -lQtGui -lxslt -lxml2 -lQtCore -lQtXmlPatterns -lQtXml) plus an explicit libapiextractor.so.0.10.1. Did you run nine tests, replacing the pieces one-by-one with their Fedora 29 versions? ___ 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: apiextractor FTBFS troubleshooting
'addedFunc' itself is 0 (NULL). Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 (from the same source) gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no longer a suspect. I just performed a mockbuild for Fedora 29 and all tests passed... What am I missing? Look at the final command (the static binding) that built the 'testvoidarg' executable: = cd .../BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/testvoidarg.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS \ -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 \ -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables \ -fstack-clash-protection -fcf-protection -Wall -fvisibility=hidden -DNDEBUG -Wl,-z,relro -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rdynamic CMakeFiles/testvoidarg.dir/testvoidarg.cpp.o \ -o testvoidarg -Wl,-rpath,.../BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests \ -lQtTest -lQtCore -lQtGui libapiextractor.so.0.10.10 -lxslt -lxml2 -lQtCore -lQtXmlPatterns -lQtXml = Replace each piece, one-by-one, with the corresponding piece from Fedora 29, (or from Fedora 30, but compiled by gcc-8.2.1-6) and test before replacing the next piece, too. In this case: each '-l' argument, and the libapiextractor.so.0.10.10 . ___ 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: apiextractor FTBFS troubleshooting
That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) on
Fedora 28 and Fedora 29.
Yes, it only seems to affect f30/Rawhide with GCC 9 (though I'm not sure it's
the culprit).
The traceback says:
> 41 QCOMPARE(addedFunc->arguments().count(), 0);
so the suggestion is to check if addedFunc->arguments() is NULL.
'addedFunc' itself is 0 (NULL).
Substituting testvoidarg.cpp.o as compiled by gcc-8.2.1-6.fc28.x86_64 (from the
same source)
gives the same SIGSEGV. So compiling testvoidarg.cpp with gcc-9 is no longer a
suspect.
=
void TestVoidArg::testVoidParsedFunction()
{
const char cppCode[] = "struct A { void a(void); };";
const char xmlCode[] = "\
\
\
";
TestUtil t(cppCode, xmlCode);
AbstractMetaClassList classes = t.builder()->classes();
AbstractMetaClass* classA = classes.findClass("A");
QVERIFY(classA);
const AbstractMetaFunction* addedFunc = classA->findFunction("a");
QCOMPARE(addedFunc->arguments().count(), 0); / line 41
}
=
___
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: apiextractor FTBFS troubleshooting
On 2/25/19 4:26 PM, Richard Shaw wrote: apiextractor builds but pretty much all the tests fail. I got this from gdb in a mock chroot but not sure how to get more (debuginfo install in a chroot?) (gdb) run Starting program: /builddir/build/BUILD/apiextractor-0.10.10/x86_64-redhat-linux-gnu/tests/testvoidarg Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-7.fc30.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". * Start testing of TestVoidArg * Config: Using QTest library 4.8.7, Qt 4.8.7 PASS : TestVoidArg::initTestCase() Program received signal SIGSEGV, Segmentation fault. TestVoidArg::testVoidParsedFunction (this=) at /builddir/build/BUILD/apiextractor-0.10.10/tests/testvoidarg.cpp:41 41 QCOMPARE(addedFunc->arguments().count(), 0); Missing separate debuginfos, use: dnf debuginfo-install glib2-2.59.2-1.fc30.x86_64 libgcc-9.0.1-0.4.fc30.x86_64 libstdc++-9.0.1-0.4.fc30.x86_64 libxml2-2.9.9-2.fc30.x86_64 libxslt-1.1.32-4.fc30.x86_64 openssl-libs-1.1.1a-2.fc30.x86_64 pcre-8.43-0.1.RC1.fc30.1.x86_64 qt-4.8.7-44.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64 (gdb) thread apply all bt full That test 'testvoidarg' succeeds for me (normal termination, no SIGSEGV) on Fedora 28 and Fedora 29. The traceback says: > 41QCOMPARE(addedFunc->arguments().count(), 0); so the suggestion is to check if addedFunc->arguments() is NULL. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On 1/25/19 15:27 UTC, Neal Gompa wrote: On Fri, Jan 25, 2019 at 10:17 AM Frantisek Zatloukal wrote: Why is this Self-Contained Change and not a System Wide Change? It seems, at least to me, that it should be System Wide Change, according to https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . Is it really that complicated? It's just a readline bump and bash itself getting bumped. From the Fedora perspective, it means we get to drop a whole bunch of patches we were already carrying since they are part of the 5.0 release. Yes, it is that complicated. "git diff --stat bash-4.4 bash-5.0" shows 528 files changed, 81767 insertions(+), 63829 deletions(-) in the 2 years and 3 months between releases. Some of the changes are included in Fedora's bash-4.4.3-23.1 but some are not. From the shell script language point of view, there is only one notable backwards incompatible change: a behavior change to namerefs, which are not commonly used at all. Already bash-5.0 has two official patches in three weeks. The first one fixes a bug in glob filename expansion. Use of globbing is almost universal, but the test cases did not catch the bug before release of bash-5.0. Often that is an indication that more bugs should be expected. The risk may be large. *EVERY* Fedora package uses bash. rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, and Fedora links /bin/sh -> bash. That surely is "system-wide". -- [[signature snipped]] ___ 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: Minimum fonts required for Fedora en_US
What are the minimum fonts required for Fedora 28/29 with en_US locale? Please ask a better question. It depends on which subset of Fedora (Workstation using GNOME, Server, Minimal, etc.) and what data you ask it to process. Some servers which run Fedora never render any fonts at all. Or, under Fedora Workstation using GNOME desktop environment, then you might try to view a web page, or print a .pdf file to an attached non-Postscript printer, that could "require" an arbitrary font regardless of locale. Here's how to get one useful answer: Download Fedora Workstation Live, boot it from a USB flash memory drive (or in a Virtual Machine, etc.), login and run rpm -ql $(rpm -qa | grep font); in a Terminal session. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead
On 2018-11-16, Jonathan Dieter wrote:
For reference, this is in reply to Paul [Frield]'s email about lifecycle
objectives, specifically focusing on problem statement #1[1].
Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time. This will require changes
to both the rpm format and new features in the zchunk format.
[1]:
https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements#Challenge_.231:_Faster.2C_more_scalable_composes
Currently a compose takes a minimum of around 8.5 hours ([1] and others);
the goal is 1 hour. The goal is particularly relevant during the last
phase of a Fedora release cycle (after code freeze) when each successive
compose contains only a few .rpms that have changed from the previous
compose, and the question-of-the-hour is whether some particular bug
actually was fixed. In this case deltarpms can be ignored.
The goal also is relevant to a future of CI (Continuous Integration)
that has automated gating of changes depending on successful tests
of the entire compose ("Does it boot and pass the test cases?")
Again, deltarpms can be ignored.
Please display some measurements which support the belief
that using zchunk will reduce compose time dramatically,
whether by eliminating deltarpms or by other effects.
Did you view
https://www.youtube.com/watch?v=kW7oz_zbSD0
"Flock 2018 - Improving Fedora Compose process" (Aug.8, 2018; 55min)
They do present measurements [coarse]. The overwhelming
conclusion is that 8.5 hours is a data flow problem, both
large-grain (moving .rpms and other files across the network)
and small-grain (extracting the desired information from
the header of an .rpm that uses data compression.)
The number one request that I heard in the recorded session
was for faster access to fields in the header of an .rpm
that uses data compression. This is slow today because the
header+tail are compressed together as if a single logical stream,
and the code retrieves and de-compresses the whole .rpm in order to access
just the header. However, both xz (liblzma) and gzip (zlib) accept
a parameter to stop decompressing after generating N bytes of output;
why not use this? N can be known, or over-estimated, or iteratively
(and incrementally) approximated until it covers the entire header.
To make de-compression of the rpm header even easier,
call xz_compress twice: once with the header, once with the tail.
The concatenation of the compressed outputs is transparent
by default but visible if you look for it, just like zlib.
In effect the "directory" feature of zchunk can be implemented
for the special case of header-vs-tail (using either xz (liblzma)
or gzip (zlib)) without disturbing other clients of .rpms.
___
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: tzdata update
The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930 No doubt some of the delay is due to compatibility issues with other packages that consume timezone data. Upstream changed the data format: = $ rpm -q --changelog tzdata-2018e-1.fc*.noarch * Wed May 16 2018 [tzdata-ow...@fedoraproject.org] - 2018e-1 - Rebase to tzdata-2018e - North Korea changed from UTC+8:30 to UTC+9 on May 5, 2018. - In this update, the upstream project now defaults to using the "vanguard" data implementation which includes negative DST offsets. However, we are continuing to provide the "rearguard" format for data which does not use negative DST offsets to provide better compatibility with existing tools. We intend to transition to the "vanguard" data implementation in the future. = Unreliable time on the system is a daily annoyance that will be easily fixed by aligning the Fedora version with the upstream's. Aligning with upstream would update tzdata itself, but dealing with the compatibility issues requires work that contradicts the claim of "easily fixed." It is reasonable to infer that the untimeliness of tzdata-2018g-1 affects you personally; so why not fix it for yourself? rpmbuild is not that hard to grok. Then you could report on the compatibility issues. You might even become a maintainer :-) ___ 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: bottlenecks that case my machine to freeze
On 10/25/18 11:27 UTC, Muayyad AlSadi wrote: There are some things that makes my machine to freeze [[snip]] This is a very poor bug report because it does not list the hardware details of the machine. What is the output from "uname -a"? What is one section of "cat /proc/cpuinfo"? How much RAM? (The first 5 lines of /proc/meminfo .) For instance, the RaspberryPi model 2B is subject to hardware(+software) failures of exactly the ilk mentioned: a USB-connected keyboard decides to send "infinitely many" repetitions of the same character, as fast as it can. The initial cause is a hardware failure [intermittent], but the software is not robust enough to recover. ___ 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: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On 10/9/18 0810 UTC, Daniel P. Berrangé wrote: AFAICT, the TCP receive buffer size is about 200 KB per socket. With the current nfile=4096, it looks like a single process can already consume 200 KB * 4096 = ~800 MB of RAM just by using TCP sockets. IOW, does the nfiles limit make a real world difference to avoiding memory DOS, if you can just pick a different DOS attack vector instead? Yes, it does. The attacker might not think of TCP. Also, the usual successful TCP connection requires cooperation from a "far" endpoint, which can be cumbersome to arrange. ___ 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: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On 10/8/18 2026 UTC, Zebediah Figura wrote: On 08/10/18 2000 UTC, John Reiser wrote: Allowing 1M open files per unprivileged process is too many. Megabytes of RAM are precious. A hard limit of 1M open files per process allows each process to eat at least 256MB (1M * sizeof(struct file) [linux/fs.h]) of RAM. If a single user is allowed 1000 processes, then that's 256GB of RAM, which is a Denial-of-Service attack. Yes, 4096 open files is not enough. Raise it to 65536. Correct me if I'm wrong, but wouldn't this be capped by the system-wide limit (i.e. it would hit ENFILE) before presenting a problem? That means that a different DoS can happen even sooner, at (ENFILE / 1M) processes. No other process could open() a file. ___ 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
