devel January 2021

devel@lists.fedoraproject.org

216 participants
347 discussions

our containers with alias vim=vi
by clime 10 Feb '21

10 Feb '21

Hello, could Fedora and CentOS containers for docker and podman come with `alias vim=vi` in ~/.bashrc? I would very much welcome it as I am used to type vim everywhere but if vi starts instead I am happy too. I know that the solution is to create a customized container but often I want to try something on vanilla containers from the whole range. Didn't want to write about this first but maybe there are more people with the same problem. clime

9 24

Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
by Ben Cotton 09 Feb '21

09 Feb '21

https://fedoraproject.org/wiki/Changes/DeprecatePythonMock == Summary == The {{package|python-mock}} ({{package|python3-mock}}) package will be [https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packa… deprecated] in [[Releases/34|Fedora 34]]. The package is a standard library backport for older Pythons, Fedora packages should use `unittest.mock` instead. Many still depend on `mock`, so we cannot remove it yet. Packagers are encouraged to work with upstream to switch to `unittest.mock` when available. A simple `sed` can be applied in `%prep` as a temporary (or even permanent) downstream solution. == Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Email: mhroncok(a)redhat.com == Detailed Description == The {{package|python-mock}} package is the [https://pypi.org/project/mock/ 3rd party backport of the standard library `unittest.mock` module]. > mock is now part of the Python standard library, available as [https://docs.python.org/dev/library/unittest.mock.html unittest.mock] in Python 3.3 onwards. > This package contains a rolling backport of the standard library mock code compatible with Python 3.6 and up. Fedora has recent enough versions of Python, hence using a library backport is redundant. Many packages only use it out of habit. We'd like to encourage both downstream packages and upstreams to switch to [https://docs.python.org/dev/library/unittest.mock.html unittest.mock] instead. Eventually, we'd like to drop {{package|python-mock}} from Fedora entirely, if possible. Before we attempt to remove the package, we need to stop new packages to (Build)Require {{package|python3-mock}}, hence we want to have it [https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packa… deprecated]. Note that the change owner does not currently officially maintain {{package|python-mock}} but the Python Maintenance team maintains the package in RHEL and contributes to the Fedora package when needed. The Fedora package maintainers have been contacted without response. === How to migrate to unittest.mock === In most cases, performing the following replacement should be enough: s/^(\s*)import mock/\1from unittest import mock/ s/^(\s*)from mock import /\1from unittest.mock import / If upstream really needs to support Python versions without `unittest.mock`, we recommend using a `try-import` mechanism, such as: try: from unittest import mock except ImportError: import mock If dual support for `unittest.mock` and `mock` is required, and the `mock` package is required in the metadata (such as in the testing ''extras''), conditionalize it, with: mock;python_version<"3.3" == Feedback == In the past, we've managed to migrate some packages away from python-mock, without a push back: * https://src.fedoraproject.org/rpms/python-urllib3/pull-request/13 * https://src.fedoraproject.org/rpms/python-freezegun/pull-request/10 * https://src.fedoraproject.org/rpms/python-hypothesis/c/65a4191709 == Benefit to Fedora == Eventually, we might be able to no longer maintain a standard library backport in a separate package. == Scope == * Proposal owners: Deprecate {{package|python3-mock}} and update the package description. Provide help migrating to `unittest.mock` to other packagers who ask for it. * Other developers: No action needed. Don't add new dependencies on {{package|python3-mock}}. If interested, migrate existing packages to `unittest.mock` (feel free to ask for help) * Release engineering: no impact on Release Engineering is anticipated * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (not needed for this Change) == Upgrade/compatibility impact == The package will remain available. Only new packages cannot depend on it. Once retired (in distant future), we don't plan to obsolete/provide <code>python3-mock</code> from {{package|python3-libs}}, because it cannot work as drop-in replacement (the import name is different). The package will eventually be obsoleted by {{package|fedora-obsolete-packages}} once Python is updated to 3.N+1 after the removal to avoid broken upgrades. == How To Test == $ repoquery --repo=rawhide --provides python3-mock ... deprecated() ... == User Experience == No changes. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

6 15

Fedora 34 Mass Rebuild
by Mohan Boddu 09 Feb '21

09 Feb '21

Hi all, Per the Fedora 34 schedule[1] we will start a mass rebuild for Fedora 34 on Jan 20th 2021. We will run a mass rebuild for Fedora 34 for the changes listed in: https://pagure.io/releng/issues?status=Open&tags=mass+rebuild Mass rebuild will be done in a side tag (f34-rebuild) and moved over when completed. Failures can be seen https://kojipkgs.fedoraproject.org/mass-rebuild/f34-failures.html Things still needing rebuilt https://kojipkgs.fedoraproject.org/mass-rebuild/f34-need-rebuild.html FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on freenode, by dropping an email to our list[2] or filing an issue in pagure[3] Regards, Mohan Boddu. [1] https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)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-announce@lists.fedorapr…

13 31

Fedora 34 Change: fbrnch (Self-Contained Change proposal)
by Ben Cotton 08 Feb '21

08 Feb '21

https://fedoraproject.org/wiki/Changes/fbrnch == Summary == Add the [https://github.com/juhp/fbrnch fbrnch] packager tool to Fedora. == Owner == * Name: [[User:Petersen|Jens Petersen]] * Email: <petersen(a)redhat.com> == Detailed Description == fbrnch (F(ed) Branch) is a tool designed to help simplify or semi-automate workflow processes for Fedora Packagers. It was first presented at "Nest with Fedora" last year, and has received some favorable feedback from users. It is currently only available in a [https://copr.fedorainfracloud.org/coprs/petersen/fbrnch/ Copr repo]. This Change is simply to bring the package into Fedora itself and broaden awareness about the tool. See the Benefit section below for more details about the functionality that fbrnch provides. == Benefit to Fedora == fbrnch is a CLI tool for Fedora Packagers, which supports some common tasks like: * merging and building packages across release branches * automatic parallel builds of sets of packages in dependency order in Koji sidetags * srpm, scratch, local install, and mock builds from arbitrary package branches * cloning and listing Fedora packages from Pagure * progressive Copr builds across chroots * creating, updating and listing one's package reviews * requesting new repos and branches, and importing new packages directly from package reviews and more. See https://github.com/juhp/fbrnch#readme for example usage. == Scope == * Proposal owners: ** Release fbrnch with new dependencies on the Haskell Hackage repository and add to Stackage. (Latest current version tagged in github and built in copr is 0.6.8.) ** Submit and complete package review(s). ** Build packages. ** Test fbrnch package working correctly. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (check by Release Engineering not needed: this just adds a few new package(s)) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == fbrnch has already been tested quite bit over the last 6 months. * dnf install fbrnch The [https://github.com/juhp/fbrnch#readme Readme file] contains examples of usage, and <code>fbrnch --help</code> provides help output. == User Experience == Fedora Packagers who wish to use fbrnch will be able to install it without having to add another Copr repo, and benefit easily from the advanced packaging workflow features provided by fbnrch. The package will get updated through Bodhi and with more testing, will gain broader confidence from Packagers. == Dependencies == A few package reviews will need to be completed in time. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) In the case the Change is not completed, the remainder can safely be deferred until Fedora 35. == Documentation == * https://github.com/juhp/fbrnch#readme * https://github.com/juhp/presentations/blob/master/fedora-nest-2020-fbrnch/f… -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

3 3

Review swap: voikko-fi (for Finnish spell-checking)
by Ville-Pekka Vainio 07 Feb '21

07 Feb '21

Hi, This is a re-review for a rename and going from arch-specific to noarch: https://bugzilla.redhat.com/show_bug.cgi?id=1919688 The arch-noarch stuff was discussed here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Voikko 4.3, which is needed to build this, is not yet in Rawhide. I'll push it as soon as someone commits to working on this review. Pushing Voikko 4.3 to Rawhide will break Finnish spell-checking until this package is in Rawhide as well. The best packages for me to review would probably be autotools-based C/C++ stuff and Python stuff. I usually have time for Fedora work only during weekends. -Ville-Pekka

2 2

Fedora 34 Change: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)
by Ben Cotton 05 Feb '21

05 Feb '21

https://fedoraproject.org/wiki/Changes/RPMCoW == Summary == RPM Copy on Write provides a better experience for Fedora Users as it reduces the amount of I/O and offsets CPU cost of package decompression. RPM Copy on Write uses reflinking capabilities in btrfs, which is the default filesystem in Fedora 33. == Owners == * Name: [[User:malmond|Matthew Almond]], [[User:dcavalca|Davide Cavalca]] * Email: malmond(a)fb.com, dcavalca(a)fb.com == Detailed description == Installing and upgrading software packages is a standard part of managing the lifecycle of any operating system. For the entire lifecycle of Fedora, all software is packaged and distributed using the RPM file fomat. This proposal changes how software is downloaded and installed, leaving the distribution process unmodified. === Current process === # Resolve packaging request into a list of packages and operations # Download and verify new packages # Install and/or upgrade packages sequentially using RPM files, decompressing, and writing a copy of the new files to storage. === New process === # Resolve packaging request into a list of packages and operations # Download and '''decompress''' packages into a '''locally optimized''' rpm file # Install and/or upgrade packages sequentially using RPM files, using '''reference linking''' (reflinking) to reuse data already on disk. The outcome is intended to be the same, but the order of operations is different. # Decompression happens inline with download. This has a positive effect on resource usage: downloads are typically limited by bandwidth. Decompression and writing the full data into a single file per rpm is essentially free. Additionally: if there is more than one download at a time, a multi-CPU system can be better utilized. All compression types supported in RPM work because this uses the rpm I/O functions. # RPMs are cached on local storage between downloading and installation time as normal. This allows DNF to defer actual RPM installation to when all the RPM are available. This is unchanged. # The file format for RPMs is different with Copy on Write. The headers are identical, but the payload is different. There is also a footer. ## Files are converted (“transcoded”) locally during download using <code>/usr/bin/rpm2extents</code> (part of rpm codebase). The format is not intended to be “portable” - i.e. copying the files from the cache is not supported. ## Regular RPMs use a compressed .cpio based payload. In contrast, extent based RPMs contain uncompressed data aligned to the fundamental page size of the architecture, e.g. 4KiB on x86_64. This alignment is required for <code>FICLONERANGE</code> to work. Only files are represented in the payload, other directory entries like symlinks, device nodes etc are constructed entirely from rpm header information. Files are referenced by their digest, so identical files are de-duplicated. ## The footer currently has three sections ### Table of original (rpm) file digests, used to validate the integrity of the download in dnf. ### Table of digest → offset used when actually installing files. ### Signature 8 bytes at the end of the file, used to differentiate between traditional RPMs and extent based. === Notes === # The headers are preserved bit for bit during transcoding. This preserves signatures. The signatures cover the main header blob, and the main header blob ensures the integrity of data in two ways: ## Each file with content has a digest. Originally this was md5, but today it’s usually sha256. In normal RPM this is only used to verify the integrity of files, e.g. <code>rpm -V</code>. With CoW we use this as a content key. ## There is/are one or two digests (<code>PAYLOADDIGEST</code> and <code>PAYLOADDIGESTALT</code>) covering the payload archive (compressed cpio). The header value is preserved, but transcoded RPMs do not preserve the original structure so RPM’s pre-installation verification (controlled by <code>%_pkgverify_level</code> will fail. <code>dnf-plugin-cow</code> disables this check in dnf because it verifies the whole file digest which is captured during download/transcoding. The second one is likely used for delta rpm. # This is untested, and possibly incompatible with delta RPM (drpm). The process for reconstructing an rpm to install from a delta is expensive from both a CPU and I/O perspective, while only providing marginal benefits on download size. It is expected that having delta rpm enabled (which is the default) will be handled gracefully. # Disk space requirements are expected to be marginally higher than before: all new packages or updates will consume their installed size before installation instead of about half their size (regular rpms with payloads still cost space). # <code>rpm-plugin-reflink</code> will fall back to simple file copying when the destination path is not on the same filesystem/subvolume. A common example is <code>/boot</code> and/or <code>/boot/efi</code>. # The system will still work on other filesystem types, but will ''always'' fall back to simple copying. This is expected to be slightly slower than not enabling CoW because the source for copying will be the decompressed data. # For systems that enable transparent filesystem compression: every file will continue to be decompressed from the original rpm, and then transparently re-compressed by the filesystem. There is no effective change here. There is a future project to investigate alternate distribution mechanics to provide parallel versions of file content pre-compressed in a filesystem specific format, reducing both CPU costs and I/O. It is expected that this will result in slightly higher network utilization because filesystem compression is purposely restricted to allow random I/O. # Current implementation of <code>dnf-plugin-cow</code> is in Python, but it looks possible to implement this in <code>libdnf</code> instead which would make it work in <code>packagekit</code>. === Performance Metrics === Ballpark performance difference is about half the duration for file download+install time. A lot of rpms are very small, so it’s difficult to see/measure. Larger RPMs give much clearer signal. (Actual numbers/charts will be supplied in Jan 2021) === Terminology === * '''Copy on Write (CoW)''' is a broad description of any technology that reduces or eliminates data duplication by sharing the data behind the scenes until one of the references makes changes. This has been a cornerstone technology in memory management in Unix systems. Here we are using it to specifically reference Copy on Write as supported in modern filesystems, e.g. btrfs, xfs and potentially others. * '''Reflink''' is the verb for duplicating stored data on a filesystem. See [https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html ioctl_ficlonerange(2)] for the specific call we use on Linux * '''Extent''' (based RPMs) refers to how payload file data is stored in within an RPM. Normal RPMs simply contain a compressed CPIO archive. Extent based RPMs contain the raw data uncompressed, which can be referenced with reflink. == Benefit to Fedora == Faster package installs and upgrades == Scope == * Proposal owners: ** Merge changes to rpm, librepo to enable capabilities ** Add dnf-plugin-cow to available packages ** Test days ** Aid with documentation * Other developers: ** rpm, librepo: review PRs as needed * Release engineering: https://pagure.io/releng/issue/9914 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == None, RPM with CoW is not enabled by default. Upgrades with <code>keepcache</code> in dnf.conf will be able to use existing packages, but it will not convert them. This only happens at download time. If a system is configured to keep packages in the cache (<code>keepcache</code> in <code>dnf.conf</code>) and <code>dnf-plugin-cow</code> is removed then the packages will be unusable. Recommend <code>dnf clean packages</code> to resolve this. == How to test == Enable RPM with CoW with <pre>$ sudo dnf install dnf-plugin-cow ... $ sudo dnf install hello ... $ hello Hello, world!</pre> There should be no end user visible changes, except timing. == User experience == No anticipated user visible changes in this change proposal. This makes the feature available, but does not enable it by default. == Dependencies == # A copy-on-write filesystem; this Change is primarily targeting btrfs, but RPM with CoW should work with XFS as well (untested) # Most package install paths and the dnf package cache on the same filesystem / subvolume. # <code>rpm</code> with Copy on Write patch set: https://github.com/malmond77/rpm/tree/cow # <code>librepo</code> with transcoding support: https://github.com/malmond77/librepo/tree/transcode_cow # dnf-plugin-reflink (a new package): https://github.com/facebookincubator/dnf-plugin-cow/ == Contingency plan == * Contingency mechanism: will not include PR patches if not merged upstream, skip <code>dnf-plugin-cow</code> * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == Documentation will be available at https://github.com/facebookincubator/dnf-plugin-cow in the coming weeks == Release Notes == RPM with CoW is not enabled by default. To enable it: <pre>$ sudo dnf install dnf-plugin-cow</pre> -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

27 70

ELN build order
by Vít Ondruch 05 Feb '21

05 Feb '21

Can the ELN be fixed to stop doing rebuild like this? Of course the issue is not in rubygem-thin but the issue is that once the Ruby side tag was merged, ELN did not bothered with build order and now there is rubygem-eventmachine which was built against Ruby 2.7 where is should have been build against Ruby 3.0. I can't rebuild it, because that would require release bump in Fedora (I don't want to do that, because Fedora maintainers should not be bothered with ELN, right?). I think that ELN should try to follow the Rawhide build order. If it can't do that, then it should wait for manual intervention. I think that ELN should have done gating or scratch build and check if the dependencies are the same as in Rawhide or something. I think that ELN should check the build result for dependency issue and stop blindly submitting builds. Vít -------- Přeposlaná zpráva -------- Předmět: bpeck/jenkins-continuous-infra.apps.ci.centos.org's rubygem-thin-1.7.2-16.eln108 failed to build Datum: Mon, 11 Jan 2021 08:49:37 +0000 (GMT) Od: notifications(a)fedoraproject.org Komu: vondruch(a)redhat.com Notification time stamped 2021-01-11 08:49:35 UTC bpeck/jenkins-continuous-infra.apps.ci.centos.org's rubygem-thin-1.7.2-16.eln108 failed to build http://koji.fedoraproject.org/koji/buildinfo?buildID=1666628 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications/vondruch.id.fedoraproject.org/…

6 11

Cfitsio soname bump
by Sergio Pascual 04 Feb '21

04 Feb '21

Hello, I'm going to build new cfitsio 3.490 in Rawhide in a week. This involves a soname bump. The affected packages are the following: CCfits LabPlot astrometry bes cpl elements-alexandria gdal healpix indi-gphoto kst kstars libindi luminance-hdr nightviewperl-Astro-FITS-CFITSIO phd2 python-astropy python-fitsio python-healpy root siril skyviewer sourcextractor++ ufraw vips wcslib Best regards, Sergio

2 2

Boost 1.75.0 in rawhide, with soname change
by Jonathan Wakely 03 Feb '21

03 Feb '21

Tom Rodgers completed the Boost 1.75.0 build for the change https://fedoraproject.org/wiki/Changes/F34Boost175 and I've rebuilt most of the packages that depend on it. The following packages failed to build. I'll look at the ones that appear to be due to Boost changes. OpenImageIO -- libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::FieldCache\<Imath_2_5::Vec3<half> >::ms_singleton' http://koji.fedoraproject.org/koji/buildinfo?buildID=1672976 PDAL -- You must configure the bibtex_bibfiles setting http://koji.fedoraproject.org/koji/buildinfo?buildID=1672663 blender -- depends on OpenImageIO ceph -- executor_work_guard has no member 'defer' http://koji.fedoraproject.org/koji/buildinfo?buildID=1672666 elements-alexandria -- fatal error: boost/io/detail/quoted_manip.hpp: No such file or directory http://koji.fedoraproject.org/koji/buildinfo?buildID=1673017 freecad -- error: expected template-name before '<' token http://koji.fedoraproject.org/koji/buildinfo?buildID=1673027 gnucash -- error: #warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" http://koji.fedoraproject.org/koji/buildinfo?buildID=1673033 gnuradio -- patches fail to apply (see rhbz#1917167) http://koji.fedoraproject.org/koji/buildinfo?buildID=1672972 gr-osmosdr -- depends on gnuradio kea -- error: 'memcpy' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] http://koji.fedoraproject.org/koji/buildinfo?buildID=1672779 libndn-cxx -- error: call of overloaded 'make_shared\<...>' is ambiguous http://koji.fedoraproject.org/koji/buildinfo?buildID=1673051 libreoffice -- Bad file: /builddir/build/SOURCES/0001-rhbz-1918152-fix-FTBFS.patch: No such file or directory (see rhbz#1918152) Already fixed and rebuilding now. libzypp -- error: in "LookupAttr_solvable_attribute_substructure": check q.size() == 10473 has failed [12760 != 10473] http://koji.fedoraproject.org/koji/buildinfo?buildID=1673061 luxcorerender -- depends on OpenImageIO mkvtoolnix -- internal compiler error: Segmentation fault http://koji.fedoraproject.org/koji/buildinfo?buildID=1672798 openms -- error: using typedef-name 'glp_prob' after 'struct' http://koji.fedoraproject.org/koji/buildinfo?buildID=1673070 openshadinglanguage -- depends on OpenImageIO http://koji.fedoraproject.org/koji/buildinfo?buildID=1673342 prusa-slicer -- error: field 'm_connected' has incomplete type 'std::atomic<bool>' http://koji.fedoraproject.org/koji/buildinfo?buildID=1673077 pulseview -- error: no match for 'operator<<' http://koji.fedoraproject.org/koji/buildinfo?buildID=1673089 rb_libtorrent -- Test #15: test_dht .........................***Failed http://koji.fedoraproject.org/koji/buildinfo?buildID=1672822 rstudio -- error: 'bind' is not a member of 'boost' http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105 sourcextractor++ -- depends on elements-alexandria http://koji.fedoraproject.org/koji/buildinfo?buildID=1673118 springlobby -- depends on rb_libtorrent supercollider -- error: invalid use of incomplete type 'class boost::asio::executor' http://koji.fedoraproject.org/koji/buildinfo?buildID=1673122

7 24

cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed
by Martin Gansser 03 Feb '21

03 Feb '21

Hi, i am trying to compile cxxtools 2.2.1 [1] on Fedora 34 with gcc11 but this fails with following error messages [2] on Fedora build server. make[2]: Entering directory '/builddir/build/BUILD/cxxtools-2.2.1/src' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../src -I../include -I../include -Wno-long-long -Wall -pedantic -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 -c -o settingswriter.lo settingswriter.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../src -I../include -I../include -Wno-long-long -Wall -pedantic -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 -c settingswriter.cpp -fPIC -DPIC -o .libs/settingswriter.o In file included from settingswriter.h:31, from settingswriter.cpp:28: ../include/cxxtools/char.h: In static member function 'static std::char_traits<cxxtools::Char>::char_type* std::char_traits<cxxtools::Char>::move(std::char_traits<cxxtools::Char>::char_type*, const char_type*, std::char_traits<cxxtools::Char>::int_type)': ../include/cxxtools/char.h:337:80: warning: 'void* memmove(void*, const void*, size_t)' writing to an object of type 'std::char_traits<cxxtools::Char>::char_type' {aka 'class cxxtools::Char'} with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess] 337 | return (cxxtools::Char*)std::memmove(s1, s2, n * sizeof(cxxtools::Char)); | ^ In file included from settingswriter.h:31, from settingswriter.cpp:28: ../include/cxxtools/char.h:65:11: note: 'std::char_traits<cxxtools::Char>::char_type' {aka 'class cxxtools::Char'} declared here 65 | class Char | ^~~~ In file included from settingswriter.h:31, from settingswriter.cpp:28: ../include/cxxtools/char.h: In static member function 'static std::char_traits<cxxtools::Char>::char_type* std::char_traits<cxxtools::Char>::copy(std::char_traits<cxxtools::Char>::char_type*, const char_type*, std::size_t)': ../include/cxxtools/char.h:344:79: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'std::char_traits<cxxtools::Char>::char_type' {aka 'class cxxtools::Char'} with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess] 344 | return (cxxtools::Char*)std::memcpy(s1, s2, n * sizeof(cxxtools::Char)); | ^ In file included from settingswriter.h:31, from settingswriter.cpp:28: ../include/cxxtools/char.h:65:11: note: 'std::char_traits<cxxtools::Char>::char_type' {aka 'class cxxtools::Char'} declared here 65 | class Char | ^~~~ In file included from /usr/include/c++/11/bits/basic_string.h:48, from /usr/include/c++/11/string:55, from ../include/cxxtools/char.h:32, from settingswriter.h:31, from settingswriter.cpp:28: /usr/include/c++/11/string_view: In instantiation of 'class std::basic_string_view<cxxtools::Char, std::char_traits<cxxtools::Char> >': settingswriter.cpp:42:26: required from here /usr/include/c++/11/string_view:98:21: error: static assertion failed 98 | static_assert(is_trivial_v<_CharT> && is_standard_layout_v<_CharT>); | ^~~~~~~~~~~~~~~~~~~~ /usr/include/c++/11/string_view:98:21: note: 'std::is_trivial_v<cxxtools::Char>' evaluates to false make[2]: *** [Makefile:740: settingswriter.lo] Error 1 [1] https://martinkg.fedorapeople.org/ErrorReports/cxxtools-2.2.1-25.fc33.src.r… [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60804463 I use the following patch for gcc11: --- include/cxxtools/char.h.orig 2021-01-28 10:15:36.017763265 +0100 +++ include/cxxtools/char.h 2021-01-28 10:16:14.833762026 +0100 @@ -68,9 +68,7 @@ typedef int32_t value_type; //! Constructs a character with a value of 0. - Char() - : _value(0) - {} + Char() = default; //! Constructs a character using the given char as base for the character value. Char(char ch) --- src/char.cpp.orig 2021-01-29 09:50:47.876669852 +0100 +++ src/char.cpp 2021-01-29 09:51:37.747675779 +0100 @@ -140,7 +140,7 @@ cxxtools::Char ctype<cxxtools::Char>::do_widen(char ch) const { - return cxxtools::Char(ch); + return cxxtools::Char(static_cast<unsigned char>(ch)); } but this patch didn't solve the issue. Any ideas ? Regards Martin

2 5

← Newer
1
2
3
4
5
6
7
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2021